귀하의 개발이 알고리즘 거래 문제를 어떻게 해결할지 확실하지 않습니까? 그리고 이 문제의 본질은 무엇입니까? 나는 이미 이 주제의 앞부분에서 썼습니다. 거래자들에게 가장 중요한 것은 이익이 있을 것이라는 것입니다. 여기에서 질문은 방법론을 사용하여 시장에서 이익을 얻는 방법입니다.
알고리즘 거래의 문제는 거래자의 이익이 아닙니다. 그리고 알고리즘 거래 자체에 대한 열정.
"몇 줄의 코드"로 어떻게 DEVELOPMENT를 얻을 수 있는지 보는 것은 흥미로울 것입니다.
몇 줄의 코드로 이미 가지고 있는 창에서 새 창을 추가할 수 있습니다. 그러나 이것은 내가 TS 리그 시스템에 추가한 500개 이상의 시스템에 해당합니다. 한 줄의 코드만 추가하면 이미 디버그되고, 기록에 대해 테스트되고, 얼마 동안 데모 작업을 하고 있는 완전한 기능의 TS를 전문가에게 추가합니다. 그러나 이것이 "발전"입니까?
제 생각에 "개발"은 제 경우에 새로운 TYPE의 차량을 추가하는 것입니다. 두 달 전에 가격과 이동 평균이 교차하고 채널 경계가 닿는 지점에 항목이 있는 두 가지 유형의 TS에 세 번째 유형을 추가했다고 가정해 보겠습니다.
귀하의 경우 - "개발"은 새로운 유형의 창 또는 컨트롤을 추가하는 것으로 이해합니다. 단 한 줄로 새로운 유형의 컨트롤을 추가할 수 있는지 잘 모르겠습니다. 또한 새로운 복잡한 컨트롤을 추가하는 것만으로도 여러 가지 골칫거리가 생길 것입니다. 이는 접근 방식으로 해결하기가 매우 어렵지만 OOP를 사용하면 훨씬 쉬워질 것입니다. 예를 들어, 엔진에 "그리드"와 같은 제어 기능이 있습니까? Excel 스프레드시트와 같은 것입니까? 열 또는 행 위의 버튼을 클릭하여 정렬할 수 있습니까? 라이브러리에 이러한 컨트롤을 추가하려면 얼마나 많은 노력이 필요합니까?
글쎄, 그것은 내가 예상했던 대답이다. 그런데 왜 마크업 언어를 만들지 않았습니까? 오랫동안 그래픽 작업을 하셨지만 주말에는 언어 작업을 하지 않으셨습니다.)
나에게 이것은 관련이 없지만 뒤에 있는 어셈블러에 컴파일러와 인터프리터가 구현되어 있습니다. 그러나 나는 그것이 당신에게 아무 말도하지 못한다는 것을 두려워합니다.
내가 이해하는 한 귀하의 창은 표준 그래픽 라이브러리를 사용합니다(외관으로 판단).
그래픽 라이브러리를 처음부터 구축하는 데 얼마나 걸릴 것이라고 생각하십니까?
나는 내 자신의 라이브러리를 사용하는데, 기초는 약 한 달 만에 완성되었습니다. 그런 다음 새로운 요구 사항이 나타나면 천천히 발전했습니다. 새 기능은 일반적으로 영업일 기준 1일 이내에 추가되었습니다.
나에게 이것은 관련이 없지만 뒤에 있는 어셈블러에 컴파일러와 인터프리터가 구현되어 있습니다. 그러나 나는 그것이 당신에게 아무 말도하지 못한다는 것을 두려워합니다.
나는 (당신과 달리) 당신의 성취를 과소평가하려고 하지 않습니다. 단순히 다른 경험입니다.
포럼에서 내가 찾은 첫 번째 주제는 MT4에서 비주얼 스튜디오를 만드는 것에 관한 것이었습니다. 이상하지만 수년 동안 목표는 변경되지 않았습니다.
컴파일러와 어셈블러 인터프리터가 아무리 훌륭해도 알고리즘 거래의 문제를 해결하지는 못합니다.
저는 알고리즘 트레이더의 가능성을 확장하는 목표를 세웠습니다. 나는 지난 몇 년 동안 이 목표를 위해 노력해 왔습니다.
그리고 나는 더 이상 OOP를 부정하지 않습니다. 나는 그것이 필요하고 유용하다는 데 동의했습니다.
나는 단지 내 접근 방식으로 달성한 것을 보여주고 싶을 뿐입니다.
나는 (당신과 달리) 당신의 성취를 과소평가하려고 하지 않습니다. 단순히 다른 경험입니다.
포럼에서 내가 찾은 첫 번째 주제는 MT4에서 비주얼 스튜디오를 만드는 것에 관한 것이었습니다. 이상하지만 수년 동안 목표는 변경되지 않았습니다.
컴파일러와 어셈블러 인터프리터가 아무리 훌륭해도 알고리즘 거래의 문제를 해결하지는 못합니다.
저는 알고리즘 트레이더의 가능성을 확장하는 목표를 설정했습니다. 나는 지난 몇 년 동안 이 목표를 위해 노력해 왔습니다.
그리고 나는 더 이상 OOP를 부정하지 않습니다. 나는 그것이 필요하고 유용하다는 데 동의했습니다.
나는 단지 내 접근 방식으로 달성한 것을 보여주고 싶을 뿐입니다.
귀하의 개발이 알고리즘 거래 문제를 어떻게 해결할지 확실하지 않습니까? 그리고 이 문제의 본질은 무엇입니까? 나는 이미이 주제에서 이미 썼습니다. 거래자에게 가장 중요한 것은 이익이 있다는 것입니다. 여기에서 질문은 방법론을 사용하여 시장에서 이익을 얻는 방법입니다.
그래서 Anatoly는 도서관을 만드는 데 1년 반이 걸렸습니다. (Yuri Kulikov는 한 달 밖에 걸리지 않았습니다).
저는 3년 동안 제 그래픽 환경을 만들어 왔습니다. 처음부터 완전히 생성되었습니다. 그들의 코드만 사용합니다. 외부 도움 없이.
Q: 그래픽 라이브러리와 마크업 언어의 차이점은 무엇입니까?
차이점은 다음과 같습니다.
마크업 언어는 사용자에게 필요한 수준을 줄입니다.
대량 분포 를 가능하게 하는 것은 이 속성입니다. Visual Studio는 필요한 사용자 경험 수준을 훨씬 더 낮춥니 다.
그래픽 라이브러리에서 마크업 언어로 가는 것은 멀고도 험난한 길입니다.
그러나 나는 도서관을 만든 적이 없습니다. 처음부터 Visual Studio를 만들었습니다. 그리고 마크업 언어 가 우연히 나왔다 .)
접근 방식 자체도 우연히 발생했습니다. 그것은 문제를 해결해야 할 필요성에 의해 만들어지고 위조되었습니다.
즉, 내 접근 방식은 어떤 교리와 기준에 관계없이 (그것이 옳더라도) 끝없는 인내와 결단의 결과입니다.
이 접근 방식은 프로그램의 빠른 개발에 필요한 것만 통합했습니다.
그리고 3년 만에 이 접근 방식을 사용하여 마크업 언어와 엔진을 만들었습니다. 또한 Vis.Studio의 생성에 접근했습니다.
따라서 접근 방식의 효율성은 의심의 여지가 없습니다. 결국 한 사람을 위해 비현실적인 과제를 해결하려는 시도로 만들어지고 다듬어졌습니다.
귀하의 개발이 알고리즘 거래 문제를 어떻게 해결할지 확실하지 않습니까? 그리고 이 문제의 본질은 무엇입니까? 나는 이미 이 주제의 앞부분에서 썼습니다. 거래자들에게 가장 중요한 것은 이익이 있을 것이라는 것입니다. 여기에서 질문은 방법론을 사용하여 시장에서 이익을 얻는 방법입니다.
알고리즘 거래의 문제는 거래자의 이익이 아닙니다. 그리고 알고리즘 거래 자체에 대한 열정.
귀하의 개발이 알고리즘 거래 문제를 어떻게 해결할지 확실하지 않습니까? 그리고 이 문제의 본질은 무엇입니까?
글쎄요. 여기 그녀가 있습니다:
피터 코노우 :
... 접근 방식을 확인해야 했던 작업의 규모를 간략하게 설명하고 싶습니다.
저것들. 일종의 "대규모" 작업을 생각해 내고(그냥 생각해 냄) 수년 동안 영웅적으로 해결해야 합니다.
컴파일러와 어셈블러 인터프리터가 아무리 훌륭해도 알고리즘 거래의 문제를 해결하지는 못합니다.
저는 알고리즘 트레이더의 가능성을 확장하는 목표를 세웠습니다. 나는 지난 몇 년 동안 이 목표를 위해 노력해 왔습니다.
그리고 대체로 문제가 현실에 존재하는지 아니면 상상 속에만 존재하는지 여부는 중요하지 않습니다. 가장 중요한 것은 수년간 무분별하고 무자비하게 해결하는 것입니다. 글쎄, 다른 사람이 시간을 대량으로 가져와 집에서 먹는다면 어떨까요?
p.s 죄송합니다 피터. 당신은 정말 좋은 사람입니다, 나는 당신을 화나게하고 싶지 않습니다. 그러나 외부의 비판이 필요할 뿐입니다. 나 자신도 비슷한 실수를 저질렀다.
한 가지 구체적인 이유가 있습니다.
프로그램 개발.
....
몇 줄의 코드로 새로운 기능을 추가할 수 있습니다.
내 접근 방식은 이 특정 문제를 해결하는 데 OOP보다 우수합니다.
흠...
"몇 줄의 코드"로 어떻게 DEVELOPMENT를 얻을 수 있는지 보는 것은 흥미로울 것입니다.
몇 줄의 코드로 이미 가지고 있는 창에서 새 창을 추가할 수 있습니다. 그러나 이것은 내가 TS 리그 시스템에 추가한 500개 이상의 시스템에 해당합니다. 한 줄의 코드만 추가하면 이미 디버그되고, 기록에 대해 테스트되고, 얼마 동안 데모 작업을 하고 있는 완전한 기능의 TS를 전문가에게 추가합니다. 그러나 이것이 "발전"입니까?
제 생각에 "개발"은 제 경우에 새로운 TYPE의 차량을 추가하는 것입니다. 두 달 전에 가격과 이동 평균이 교차하고 채널 경계가 닿는 지점에 항목이 있는 두 가지 유형의 TS에 세 번째 유형을 추가했다고 가정해 보겠습니다.
귀하의 경우 - "개발"은 새로운 유형의 창 또는 컨트롤을 추가하는 것으로 이해합니다. 단 한 줄로 새로운 유형의 컨트롤을 추가할 수 있는지 잘 모르겠습니다. 또한 새로운 복잡한 컨트롤을 추가하는 것만으로도 여러 가지 골칫거리가 생길 것입니다. 이는 접근 방식으로 해결하기가 매우 어렵지만 OOP를 사용하면 훨씬 쉬워질 것입니다. 예를 들어, 엔진에 "그리드"와 같은 제어 기능이 있습니까? Excel 스프레드시트와 같은 것입니까? 열 또는 행 위의 버튼을 클릭하여 정렬할 수 있습니까? 라이브러리에 이러한 컨트롤을 추가하려면 얼마나 많은 노력이 필요합니까?
알고리즘 거래의 문제는 거래자의 이익이 아닙니다. 그리고 알고리즘 거래 자체에 대한 열정.
그건 그렇고, Peter, 이 주제는 정확히 제가 "아이디어의 드라마화"라고 부르는 것입니다. 사실, 각색은 생생한 예를 기반으로하지 않고 주로 대화를 기반으로하지만 그럼에도 불구하고 직접 볼 수 있습니다. 주제는 수요가 있습니다.
게다가, 시스템이 OOP를 사용하는 것보다 더 쉽게 제품을 개발 및 복합할 수 있다는 증거가 제시되면(그리드 제어에 대해 기억하십시오) 사용자가 라이브러리를 사용하도록 하는 매우 강력한 주장이 될 것입니다.