FION писал (а): 동의합니다. 이것은 기술 사양이 아니라 다소 훈련된 거래자를 위해 설계된 알고리즘입니다.
와... 직접 말씀하셨네요... 프로그래머가 아니라 상인... 그리고 알고리즘이 전혀 아닙니다. 아이디어에 대한 구두 설명일 뿐입니다. 알고리즘은 멀고 TK는 더 멀다. 분명히 이제 프로그래머의 자격은 주로 구두 설명에 따라 프로그램을 작성하는 능력에 의해 결정됩니다. 그리고 고객의 자격도 떨어지고 있습니다.
피온 은 다음과 같이 썼습니다. 처음에는 정확한 형식화로 복잡한 시스템을 구축하려고 시도했지만 경험에 따르면 형식화를 개선하여 시스템을 복잡하게 하면 결과가 향상되지 않습니다. 즉, 원래 아이디어 자체에는 일정한 질적 한계가 있습니다. 이것에서 간단한 결론이 나옵니다. 적시에 실행 불가능한 아이디어를 제거해야합니다.
동의합니다 ... 그러나 이것은 아이디어를 선택하는 기준이 필요합니다. 이 기준은 경험으로 형성됩니다. 그러나 경험은 위험한 것입니다. 아기가 물과 함께 버리게 합니다.
FION писал (а): Программисту для написания кода необходим формализованный алгоритм процесса торговли советника.
Согласен с Вами. Что называется ППКС (подпишусь под каждым словом). Но, увы... То, что Вы описали ниже, не является формализованным алгоритмом. Алгоритмом я считаю такое описание процесса, который сможет выполнить человек, не владеющий предметом. Например, из Вашего описания нужно знать, что такое каналы и как они строятся. Что означает подход цены к границе канала? Разные люди вкладывают в это разный смысл. Для одного подход - это вход в 10-ти пунктовую зону, для другого пересечение, для третьего ещё что-нибудь. К чему мы в итоге приходим? К тому, что программист сам занимается формализацией словесного описания процесса. Результат - неправильная реализация того, что хотел заказчик. Причина - общение на разных языках, вкладывание в одинаковые слова разного смысла. Как этого избежать? Нужно и заказчику и программисту участвовать в процессе формализации, алгоритмизации. Еще лучше обоим разработать свои алгоритмы и сравнить их, найти несоответствия и устранить. За весь мой 15-тилетний программистский опыт у меня был только один заказчик, который пытался разговаривать со мной на понятном мне языке. В ТЗ было всё необходимое: учтены все условия, все формулы, умолчательные значения и прочее. Мне практически ничего было формализовать. Всё уже было сделано. Видимо, это идеал. А реалии таковы, что большинство деталей из заказчика приходится вытягивать , то есть типичный заказчик не заботится о том, что может понадобится программисту для реализации его идеи. Какие цифры, какие графики, таблицы, формулы или просто пояснительные иллюстрации.
대부분의 경우 고객은 이러한 모든 미묘함과 세부 사항에 대해 알지 못합니다. 가능한 모든(다소 실제적인) 옵션을 프로그래밍하고, 옵션을 만들고, 지침을 작성하는 하나의 옵션을 찾았습니다. 훨씬 빠르고 신경이 덜 쓰입니다. ;-)
FION 은 다음과 같이 썼습니다. 동의합니다. 이것은 기술 사양이 아니라 다소 훈련된 거래자를 위해 설계된 알고리즘입니다.
와... 직접 말씀하셨네요... 프로그래머가 아니라 상인... 그리고 알고리즘이 전혀 아닙니다. 아이디어에 대한 구두 설명일 뿐입니다. 알고리즘은 멀고 TK는 더 멀다. 분명히 이제 프로그래머의 자격은 주로 구두 설명에 따라 프로그램을 작성하는 능력에 의해 결정됩니다. 그리고 고객의 자격도 떨어지고 있습니다.
FION 은 다음과 같이 썼습니다. 처음에는 정확한 형식화로 복잡한 시스템을 구축하려고 시도했지만 경험에 따르면 형식화를 개선하여 시스템을 복잡하게 하면 결과가 향상되지 않습니다. 즉, 원래 아이디어 자체에는 일정한 질적 한계가 있습니다. 이것에서 간단한 결론이 나옵니다. 적시에 실행 불가능한 아이디어를 제거해야합니다.
동의합니다 ... 그러나 이것은 아이디어를 선택하는 기준이 필요합니다. 이 기준은 경험으로 형성됩니다. 그러나 경험은 위험한 것입니다. 아기가 물과 함께 버리게 합니다.
또 다른 원칙이 있습니다. 적을수록 좋지만 더 좋습니다 :)) 많은 아이디어에서 익사하고 영원한 학생으로 남을 수 있습니다.
저는 진동 측정을 위한 정밀 전자 장치 개발에 참여했습니다. 따라서 솔루션을 찾는 과정을 상상합니다. 더 좋거나 나쁘게 이해하려면 (경험상) 당장 명확하지 않은 경우 이상하게도 매우 간단한 알고리즘을 시도해야 합니다. 이 같은 것을 예상했지만 챔피언십에서 가장 성공적인 것으로 판명되었습니다.
FION писал (а): .... 이상하게도 매우 간단한 알고리즘이 챔피언십에서 가장 성공적인 것으로 밝혀졌습니다. 비록 나는 이것이 거의 같을 것이라고 예상했지만.
어쨌든 전혀 이상하지 않습니다. 챔피언십은 회복력 있는 전문가를 식별하는 목표를 설정하지 않았습니다. 챔피언십의 목적은 다양한 EA 작가들의 관심을 끌 수 있도록 하는 것입니다. 따라서 그러한 큰 상금. 그리고 이것은 차례로 경험 많은 Expert Advisor 작가뿐만 아니라 갓 구운 작가도 이미 끌어 들였습니다. 그리고 갓 구운 이 빵들이 챔피언십에서 무엇을 원했을까요? 단지 상을 받기 위해서가 아니라 전문가의 회복력을 증명하기 위해서입니다. 따라서 전문가의 단순성과 과도한 위험이 있습니다. 그리고 경험이 있는 전문 작가들은 순진한 사람들입니다. 그들은 아이디어를 위해 싸우고 있습니다. 그들에게 "아름다운"전문가를주십시오 ....
피온 은 다음과 같이 썼습니다. .... 이상하게도 매우 간단한 알고리즘이 챔피언십에서 가장 성공적인 것으로 밝혀졌습니다. 비록 나는 이것이 거의 같을 것이라고 예상했지만.
어쨌든 전혀 이상하지 않습니다. 챔피언십은 회복력 있는 전문가를 식별하는 목표를 설정하지 않았습니다. 챔피언십의 목적은 다양한 EA 작가들의 관심을 끌 수 있도록 하는 것입니다. 따라서 그러한 큰 상금. 그리고 이것은 차례로 경험 많은 Expert Advisor 작가뿐만 아니라 갓 구운 작가도 이미 끌어 들였습니다. 그리고 갓 구운 이 빵들이 챔피언십에서 무엇을 원했을까요? 단지 상을 받기 위해서가 아니라 전문가의 회복력을 증명하기 위해서입니다. 따라서 전문가의 단순성과 과도한 위험이 있습니다. 그리고 경험이 있는 전문 작가들은 순진한 사람들입니다. 그들은 아이디어를 위해 싸우고 있습니다. 그들에게 "아름다운"전문가를주십시오 ....
Sergey와 나는 경고했습니다 - 여기 nizya는 너무 심각합니다 :). 그건 그렇고 - "아름답다 / 아니다"라는 개념은 모두가 자신의 것을 가지고 있습니다. 예를 들어 나에게 이것은 첫 번째 농담이고 두 번째로 많은 녹색 대통령이 있습니다. 따라서 어드바이저는 엄청나게 긴 기간으로 MACD에만 작성되었으며 코드의 오류와 함께 상위 10위권에서 10위권을 떼지 않는 완고한 고집이 있습니다. 전혀 현명하지 않습니다. ...
동의합니다. 이것은 기술 사양이 아니라 다소 훈련된 거래자를 위해 설계된 알고리즘입니다.
처음에는 정확한 형식화로 복잡한 시스템을 구축하려고 시도했지만 경험에 따르면 형식화를 개선하여 시스템을 복잡하게 하면 결과가 향상되지 않습니다. 즉, 원래 아이디어 자체에는 일정한 질적 한계가 있습니다. 이것에서 간단한 결론이 나옵니다. 적시에 실행 불가능한 아이디어를 제거해야합니다.
그러나 원칙은 아이디어가 많을수록 더 좋습니다.
FION писал (а):
Согласен с Вами. Что называется ППКС (подпишусь под каждым словом). Но, увы... То, что Вы описали ниже, не является формализованным алгоритмом. Алгоритмом я считаю такое описание процесса, который сможет выполнить человек, не владеющий предметом. Например, из Вашего описания нужно знать, что такое каналы и как они строятся. Что означает подход цены к границе канала? Разные люди вкладывают в это разный смысл. Для одного подход - это вход в 10-ти пунктовую зону, для другого пересечение, для третьего ещё что-нибудь. К чему мы в итоге приходим? К тому, что программист сам занимается формализацией словесного описания процесса. Результат - неправильная реализация того, что хотел заказчик. Причина - общение на разных языках, вкладывание в одинаковые слова разного смысла. Как этого избежать? Нужно и заказчику и программисту участвовать в процессе формализации, алгоритмизации. Еще лучше обоим разработать свои алгоритмы и сравнить их, найти несоответствия и устранить. За весь мой 15-тилетний программистский опыт у меня был только один заказчик, который пытался разговаривать со мной на понятном мне языке. В ТЗ было всё необходимое: учтены все условия, все формулы, умолчательные значения и прочее. Мне практически ничего было формализовать. Всё уже было сделано. Видимо, это идеал. А реалии таковы, что большинство деталей из заказчика приходится вытягивать , то есть типичный заказчик не заботится о том, что может понадобится программисту для реализации его идеи. Какие цифры, какие графики, таблицы, формулы или просто пояснительные иллюстрации.Программисту для написания кода необходим формализованный алгоритм процесса торговли советника.
대부분의 경우 고객은 이러한 모든 미묘함과 세부 사항에 대해 알지 못합니다. 가능한 모든(다소 실제적인) 옵션을 프로그래밍하고, 옵션을 만들고, 지침을 작성하는 하나의 옵션을 찾았습니다. 훨씬 빠르고 신경이 덜 쓰입니다. ;-)
동의합니다. 이것은 기술 사양이 아니라 다소 훈련된 거래자를 위해 설계된 알고리즘입니다.
처음에는 정확한 형식화로 복잡한 시스템을 구축하려고 시도했지만 경험에 따르면 형식화를 개선하여 시스템을 복잡하게 하면 결과가 향상되지 않습니다. 즉, 원래 아이디어 자체에는 일정한 질적 한계가 있습니다. 이것에서 간단한 결론이 나옵니다. 적시에 실행 불가능한 아이디어를 제거해야합니다.
그러나 원칙은 아이디어가 많을수록 더 좋습니다.
.... 이상하게도 매우 간단한 알고리즘이 챔피언십에서 가장 성공적인 것으로 밝혀졌습니다. 비록 나는 이것이 거의 같을 것이라고 예상했지만.
어쨌든 전혀 이상하지 않습니다.
챔피언십은 회복력 있는 전문가를 식별하는 목표를 설정하지 않았습니다. 챔피언십의 목적은 다양한 EA 작가들의 관심을 끌 수 있도록 하는 것입니다.
따라서 그러한 큰 상금. 그리고 이것은 차례로 경험 많은 Expert Advisor 작가뿐만 아니라 갓 구운 작가도 이미 끌어 들였습니다. 그리고 갓 구운 이 빵들이 챔피언십에서 무엇을 원했을까요? 단지 상을 받기 위해서가 아니라 전문가의 회복력을 증명하기 위해서입니다. 따라서 전문가의 단순성과 과도한 위험이 있습니다.
그리고 경험이 있는 전문 작가들은 순진한 사람들입니다. 그들은 아이디어를 위해 싸우고 있습니다. 그들에게 "아름다운"전문가를주십시오 ....
.... 이상하게도 매우 간단한 알고리즘이 챔피언십에서 가장 성공적인 것으로 밝혀졌습니다. 비록 나는 이것이 거의 같을 것이라고 예상했지만.
어쨌든 전혀 이상하지 않습니다.
챔피언십은 회복력 있는 전문가를 식별하는 목표를 설정하지 않았습니다. 챔피언십의 목적은 다양한 EA 작가들의 관심을 끌 수 있도록 하는 것입니다.
따라서 그러한 큰 상금. 그리고 이것은 차례로 경험 많은 Expert Advisor 작가뿐만 아니라 갓 구운 작가도 이미 끌어 들였습니다. 그리고 갓 구운 이 빵들이 챔피언십에서 무엇을 원했을까요? 단지 상을 받기 위해서가 아니라 전문가의 회복력을 증명하기 위해서입니다. 따라서 전문가의 단순성과 과도한 위험이 있습니다.
그리고 경험이 있는 전문 작가들은 순진한 사람들입니다. 그들은 아이디어를 위해 싸우고 있습니다. 그들에게 "아름다운"전문가를주십시오 ....
마시고 글을 씁니다.
마시고 글을 씁니다.
먹고 무엇을 :)
라이브...
자, 술은 마셔도 글을 못쓰면 예!
그건 그렇고 - "아름답다 / 아니다"라는 개념은 모두가 자신의 것을 가지고 있습니다. 예를 들어 나에게 이것은 첫 번째 농담이고 두 번째로 많은 녹색 대통령이 있습니다. 따라서 어드바이저는 엄청나게 긴 기간으로 MACD에만 작성되었으며 코드의 오류와 함께 상위 10위권에서 10위권을 떼지 않는 완고한 고집이 있습니다. 전혀 현명하지 않습니다. ...
좋아, 나는 떠날거야. 홍수에 대해 사과하지만 여기에서는 모두가 이미 고통을 겪었습니다.