당신이 "비하적인" 것에 대해서는 옳았지만, 나는 당신이 "사용자를 끌어들이는 것"에 대해 지나치게 자신하고 있다고 생각합니다.
하지만 계속하십시오. 아마도 프로그래밍 방법을 알고 있지만 동시에 "손"을 거래하는 사람이 있을 것입니다.
수동 거래를 위한 잘 알려진 미국 플랫폼이 있다고 생각합니다. 직업적인. 얼마나 많은 사람들이 거기에서 손을 거래합니까? 플랫폼 내에서 작업을 부분적으로 자동화할 수 있는 기회가 있지만 이를 수행할 수 있어야 합니다. API도 있습니다. 하지만 얼마나 많은 사람들이 그것을 마스터할 것인가?
편리한 반자동 기계를 작성하여 고객에게 제공할 수 있습니다. 그리고 그들뿐만이 아닙니다. 수동으로 거래하는 모든 거래자는 작업의 부분 자동화를 제공하고, 테이블에서 시장을 모니터링하고, 대화 상자 를 통해 프로그램과 상호 작용합니다. 시장 이벤트에 대한 메시지를 표시합니다. 글쎄, 어쩌면 내가 뭔가를 모르고 이해하지 못할 수도 있지만 이론상 그렇게?
편리한 반자동 기계를 작성하여 고객에게 제공할 수 있습니다. 그리고 그들뿐만이 아닙니다. 수동으로 거래하는 모든 거래자는 작업의 부분 자동화를 제공하고, 테이블에서 시장을 관찰하고, 대화 상자를 통해 프로그램과 상호 작용합니다. 시장 이벤트에 대한 메시지를 표시합니다. 글쎄, 어쩌면 내가 뭔가를 모르고 이해하지 못할 수도 있지만 이론상 그렇게?
알아낼 수 있는 방법은 한 가지뿐입니다.
이미 무언가를 게시하십시오.
완벽하지 않고 만두가 없으면(필요한 경우 나중에 추가) 사용자의 수요 + 피드백이 이동하는 것을 즉시 볼 수 있고 더 파헤쳐야 할 방향이 더 명확해질 것입니다.
이 작업을 더 빨리 수행할수록 더 많은 시간을 절약할 수 있습니다(더 정확하게 말하면 시간을 덜 잃을 것입니다... :(
IMHO, mql용 gui는 중요하고 필요합니다(그리고 아마도 메타 언어도 마찬가지일 것입니다). 그러나 이것이 OOP없이 수행되면 방법이 아니라 작성자의 의식 상태에 대해 말합니다. 4일 동안 38페이지가 굉장합니다. 분명히 모든 사람이 이러한 마음 상태를 좋아합니다.
개인적으로 좋아하지 않는 mql의 OOP에 대해 뭔가가 있습니다. 모든 "빈" 개체는 16바이트를 사용합니다. 플러스 8바이트의 포인터. 데이터를 계산하지 않는 요소 1개당 총 24바이트입니다. 대신 속성 행렬을 만들면 1개의 "빈" 개체 대신 6개의 int를 작성할 수 있습니다. 각 개체에는 문자열을 제외한 거의 모든 것을 저장할 수 있습니다(99%의 경우 시간 또는 가격의 경우 int이면 충분합니다).
음, dynamic_cast 유형을 캐스팅 하는 작업은 속도 측면에서 전혀 저렴하지 않습니다. 따라서 경박함의 출현으로 topikstarter 방법(물론 보지는 않았지만 이론적으로)은 OOP가 있는 아날로그보다 더 빠르게 작동하고 메모리를 덜 차지할 수 있습니다.
음, dynamic_cast 유형을 캐스팅 하는 작업은 속도 측면에서 전혀 저렴하지 않습니다. 따라서 경박함의 출현으로 topikstarter 방법(물론 보지는 않았지만 이론적으로)은 OOP가 있는 아날로그보다 더 빠르게 작동하고 메모리를 덜 차지할 수 있습니다.
따라서 아무도 거대한 전역 배열에 대한 직접 액세스가 이러한 모든 인터페이스 종소리와 유형 변환보다 빠르다고 주장하지 않습니다. 이중 디스패칭이 있는 방문자와 같은 디자인 패턴도 기억할 수 있습니다. 거기에는 엄청난 오버헤드가 있습니다.
그러나 이 모든 것이 지원 및 수정의 편의를 제공합니다. 불행히도 프로그래밍 개발의 주류는 오랫동안 정신적 노력을 컴퓨터에 최대한 전달하는 것이었습니다. 산술 진행의 합은 잘 알려진 합 공식을 사용하지 않고 루프를 사용하여 계산된다는 점입니다. 이런 의미에서 나는 사람들이 "비하적"이라는 베드로의 말에 동의합니다.
그러나 슬프게도 선택의 여지가 없습니다. 모든 사람과 "저하"시키거나 너무 빨리하지 않으려 고 노력하거나 절망적으로 뒤에 있습니다. 그리고 당신의 프로그램이 비효율적이라는 사실은 중요하지 않습니다.
여기에서 나는 포식자-피식자 관계에서 생물학의 경쟁과 유사한 것을 봅니다. 실제로 늑대에게서 도망치는 토끼는 늑대와 전혀 경쟁하지 않고 다른 토끼들과 경쟁한다. 누구보다 빨리 늑대에게서 도망칠 필요가 없다. 마지막이 아니라 늑대에게서 도망치는 것이 훨씬 더 중요하다. 마지막에 도망치면 잡아먹힐 것이고, 가장 빨리 도망치면 필요 이상으로 에너지를 소비하게 되어 더 유용한 방향으로 인도될 수 있기 때문이다.
모든 프로그래밍 기술이 마찬가지입니다... 가장 효율적인 방법은 어셈블러로 프로그래밍하는 것이지만 너무 많은 노력이 필요하여 의미가 없습니다. 코드가 그렇게 효율적이지 않더라도 에너지를 더 생산적으로 소비하는 것이 좋습니다. 동일한 시리즈에서 글로벌 액세스가 가능한 Peter의 어레이. 그러나 그것에 대한 액세스는 무엇이 어디에 있는지, 그리고 무엇에 액세스하는 방법을 기억하는 것이 효과적입니다. 너무 많이 필요합니다.
topicstarter의 "핵심"은 엄청난 크기의 문자열 배열이며 이론상으로도 이러한 접근 방식의 효과에 대해 이야기하는 것은 비현실적입니다.
그것은 정말로 문자열의 배열입니까 아니면 비유입니까? 데이터가 mql 문자열(문자열)로 표시되면 실제로 가능성이 없습니다...
조지 머츠 :
그러나 그것에 대한 액세스는 무엇이 어디에 있는지, 그리고 무엇에 액세스하는 방법을 기억하는 것이 효과적입니다. 너무 많이 필요합니다.
"코어"가 이미 준비되면 프레젠테이션 및 정보 액세스의 "서투른" 문제를 모두 해결하는 편리한 인터페이스를 고수하기 위해 비교적 적은 노력을 들이는 것이 가능합니다. 비록 이것이 공허한 대화지만 내가 알기로는 TS는 코드를 공개하지 않았고 광대는 그것이 자연에 존재하는지 전혀 알고 있습니다 :) 아니면 게시 했습니까? 솔직히 38페이지를 다 마스터하진 못했지만
또한 "반자동 장치"에만 적합한 방법은 정의상 가치가 없습니다. 제품 및 프리랜스 시장에서 지역의 제한된 틈새 시장을 점유하는 데 도움이 될 수 있지만
글쎄, 글쎄 ... 감히, 피터.
당신이 "비하적인" 것에 대해서는 옳았지만, 나는 당신이 "사용자를 끌어들이는 것"에 대해 지나치게 자신하고 있다고 생각합니다.
하지만 계속하십시오. 아마도 프로그래밍 방법을 알고 있지만 동시에 "손"을 거래하는 사람이 있을 것입니다.
수동 거래를 위한 잘 알려진 미국 플랫폼이 있다고 생각합니다. 직업적인. 얼마나 많은 사람들이 거기에서 손을 거래합니까? 플랫폼 내에서 작업을 부분적으로 자동화할 수 있는 기회가 있지만 이를 수행할 수 있어야 합니다. API도 있습니다. 하지만 얼마나 많은 사람들이 그것을 마스터할 것인가?
편리한 반자동 기계를 작성하여 고객에게 제공할 수 있습니다. 그리고 그들뿐만이 아닙니다. 수동으로 거래하는 모든 거래자는 작업의 부분 자동화를 제공하고, 테이블에서 시장을 모니터링하고, 대화 상자 를 통해 프로그램과 상호 작용합니다. 시장 이벤트에 대한 메시지를 표시합니다. 글쎄, 어쩌면 내가 뭔가를 모르고 이해하지 못할 수도 있지만 이론상 그렇게?
편리한 반자동 기계를 작성하여 고객에게 제공할 수 있습니다. 그리고 그들뿐만이 아닙니다. 수동으로 거래하는 모든 거래자는 작업의 부분 자동화를 제공하고, 테이블에서 시장을 관찰하고, 대화 상자를 통해 프로그램과 상호 작용합니다. 시장 이벤트에 대한 메시지를 표시합니다. 글쎄, 어쩌면 내가 뭔가를 모르고 이해하지 못할 수도 있지만 이론상 그렇게?
알아낼 수 있는 방법은 한 가지뿐입니다.
이미 무언가를 게시하십시오.
완벽하지 않고 만두가 없으면(필요한 경우 나중에 추가) 사용자의 수요 + 피드백이 이동하는 것을 즉시 볼 수 있고 더 파헤쳐야 할 방향이 더 명확해질 것입니다.
이 작업을 더 빨리 수행할수록 더 많은 시간을 절약할 수 있습니다(더 정확하게 말하면 시간을 덜 잃을 것입니다... :(
내 시간에 그런 조언을 많이 했을 것입니다 :)
글쎄, 글쎄 ... 감히, 피터.
당신이 "비하적인" 것에 대해서는 옳았지만, 나는 당신이 "사용자를 끌어들이는 것"에 대해 지나치게 자신하고 있다고 생각합니다.
하지만 계속하십시오. 아마도 프로그래밍 방법을 알고 있지만 동시에 "손"을 거래하는 사람이 있을 것입니다.
그것은 불가능. 프로그래밍 방법을 아는 사람은 MQL5의 보조자가 될 것이며 MQL5 거래 작업 을 공부하면서 1-2주만 사용할 것입니다.
그리고 반자동의 경우 몇 시간 안에 비디오를 만들어 반자동 모드에서 작동할 수 있는 최신 자동 로봇의 모습을 어드바이저로 보여드리겠습니다.
그리고 이를 위해 복잡한 패널을 발명할 필요가 없지만 모든 사람에게 더 명확하도록 매우 간단하게 만들어야 합니다.
최신 사용자는 Grails 테스트로 인해 마침내 성능이 저하되었습니다. 그들은 자신의 행동에 대해 다소 복잡하고 책임감을 가져야 합니다. 그렇지 않으면 알고리즘 거래의 완전한 저하입니다.
나는 알고리즘 거래의 틈새 시장을 위한 다른 미래를 보지 못합니다. 솔직히 안보여요...
얼마나 많은 파토스 ... 그리고 나는 슬픔의 제기 손을 봅니다 ;)))
Petya, 당신은 메시아의 역할을 정말 좋아합니다.
모두가 타락했습니다... 세상이 향하는 곳... 당신의 임무, 당신의 운명은 타락한 인류를 알고리즘 거래의 밝은 미래로 이끄는 것입니다. 여기 진단이 있습니다. 아픈 머리에서 건강한 사람으로...
Petya, 바보가 되지 마세요.
개인적으로 좋아하지 않는 mql의 OOP에 대해 뭔가가 있습니다. 모든 "빈" 개체는 16바이트를 사용합니다. 플러스 8바이트의 포인터. 데이터를 계산하지 않는 요소 1개당 총 24바이트입니다. 대신 속성 행렬을 만들면 1개의 "빈" 개체 대신 6개의 int를 작성할 수 있습니다. 각 개체에는 문자열을 제외한 거의 모든 것을 저장할 수 있습니다(99%의 경우 시간 또는 가격의 경우 int이면 충분합니다).
음, dynamic_cast 유형을 캐스팅 하는 작업은 속도 측면에서 전혀 저렴하지 않습니다. 따라서 경박함의 출현으로 topikstarter 방법(물론 보지는 않았지만 이론적으로)은 OOP가 있는 아날로그보다 더 빠르게 작동하고 메모리를 덜 차지할 수 있습니다.
Ilya Malev :
따라서 경박함의 출현으로 topikstarter 방법(물론 보지는 않았지만 이론적으로) 은 OOP가 있는 아날로그보다 더 빠르게 작동하고 메모리를 덜 차지할 수 있습니다 .
topicstarter의 "핵심"은 엄청난 크기의 문자열 배열이며 이론상으로도 이러한 접근 방식의 효과에 대해 이야기하는 것은 비현실적입니다.
음, dynamic_cast 유형을 캐스팅 하는 작업은 속도 측면에서 전혀 저렴하지 않습니다. 따라서 경박함의 출현으로 topikstarter 방법(물론 보지는 않았지만 이론적으로)은 OOP가 있는 아날로그보다 더 빠르게 작동하고 메모리를 덜 차지할 수 있습니다.
따라서 아무도 거대한 전역 배열에 대한 직접 액세스가 이러한 모든 인터페이스 종소리와 유형 변환보다 빠르다고 주장하지 않습니다. 이중 디스패칭이 있는 방문자와 같은 디자인 패턴도 기억할 수 있습니다. 거기에는 엄청난 오버헤드가 있습니다.
그러나 이 모든 것이 지원 및 수정의 편의를 제공합니다. 불행히도 프로그래밍 개발의 주류는 오랫동안 정신적 노력을 컴퓨터에 최대한 전달하는 것이었습니다. 산술 진행의 합은 잘 알려진 합 공식을 사용하지 않고 루프를 사용하여 계산된다는 점입니다. 이런 의미에서 나는 사람들이 "비하적"이라는 베드로의 말에 동의합니다.
그러나 슬프게도 선택의 여지가 없습니다. 모든 사람과 "저하"시키거나 너무 빨리하지 않으려 고 노력하거나 절망적으로 뒤에 있습니다. 그리고 당신의 프로그램이 비효율적이라는 사실은 중요하지 않습니다.
여기에서 나는 포식자-피식자 관계에서 생물학의 경쟁과 유사한 것을 봅니다. 실제로 늑대에게서 도망치는 토끼는 늑대와 전혀 경쟁하지 않고 다른 토끼들과 경쟁한다. 누구보다 빨리 늑대에게서 도망칠 필요가 없다. 마지막이 아니라 늑대에게서 도망치는 것이 훨씬 더 중요하다. 마지막에 도망치면 잡아먹힐 것이고, 가장 빨리 도망치면 필요 이상으로 에너지를 소비하게 되어 더 유용한 방향으로 인도될 수 있기 때문이다.
모든 프로그래밍 기술이 마찬가지입니다... 가장 효율적인 방법은 어셈블러로 프로그래밍하는 것이지만 너무 많은 노력이 필요하여 의미가 없습니다. 코드가 그렇게 효율적이지 않더라도 에너지를 더 생산적으로 소비하는 것이 좋습니다. 동일한 시리즈에서 글로벌 액세스가 가능한 Peter의 어레이. 그러나 그것에 대한 액세스는 무엇이 어디에 있는지, 그리고 무엇에 액세스하는 방법을 기억하는 것이 효과적입니다. 너무 많이 필요합니다.
topicstarter의 "핵심"은 엄청난 크기의 문자열 배열이며 이론상으로도 이러한 접근 방식의 효과에 대해 이야기하는 것은 비현실적입니다.
그것은 정말로 문자열의 배열입니까 아니면 비유입니까? 데이터가 mql 문자열(문자열)로 표시되면 실제로 가능성이 없습니다...
그러나 그것에 대한 액세스는 무엇이 어디에 있는지, 그리고 무엇에 액세스하는 방법을 기억하는 것이 효과적입니다. 너무 많이 필요합니다.
"코어"가 이미 준비되면 프레젠테이션 및 정보 액세스의 "서투른" 문제를 모두 해결하는 편리한 인터페이스를 고수하기 위해 비교적 적은 노력을 들이는 것이 가능합니다. 비록 이것이 공허한 대화지만 내가 알기로는 TS는 코드를 공개하지 않았고 광대는 그것이 자연에 존재하는지 전혀 알고 있습니다 :) 아니면 게시 했습니까? 솔직히 38페이지를 다 마스터하진 못했지만
또한 "반자동 장치"에만 적합한 방법은 정의상 가치가 없습니다. 제품 및 프리랜스 시장에서 지역의 제한된 틈새 시장을 점유하는 데 도움이 될 수 있지만