오류, 버그, 질문 - 페이지 681

 
Renat :
어떻게 든 당신은 논의하고 있습니다.

매우 드문(0%에 가까운) 경우에 대해 추가 막대 특성을 계산하는 데 시간을 소비하는 것을 두려워하지만 100%의 경우에 많은 데이터를 준비하고 속도를 늦추고 메모리를 몇 배 더 많이 사용하도록 기꺼이 요구합니다.

어떤 사람들은 해충에 대해 이야기할 때이므로 벽에 기대어 자살하라는 아름다운 조언을 체계적으로 제공합니다.

이러한 종류의 전략가는 즉시 볼 수 있습니다.

이 주제에 대한 내 모든 게시물과 몇 가지 이전 게시물을 주의 깊게 분석한 다음 프랙탈에 그래픽 TA 표시 의 다중 시간 프레임 표시기를 사용하면 즉시 이 주제에 대해 나와 논쟁하고 싶은 느낌이 들 것입니다. 얼음물. 그러나 문제는 표시기가 완전히 최적화되지 않았으며(이 주제와 관련이 없음) 기능적으로 제자리에 추가되지 않는다는 것입니다. 그렇기 때문에 릴리스를 마무리하고 업로드하는 것이 아니라 말도 안되는 일에 리소스를 사용합니다.

거기에 그래픽 개체 - 돌파구. 그리고 그들은 또한 청소해야합니다 ... 충분한 문제가 있습니다.

 
이것은 특별한 경우입니다.
 
Renat :
이것은 특별한 경우입니다.
그들은 손으로 거래하는 모든 사람들보다 라이브 자동 태깅을 조금 덜 원합니다. 오실레이터, 이동 평균 등에 MTS/ATS를 쓰는 사람은 누구나 스스로 작성하게 하면 "저 선에서" 자동 거래를 위해 이 표시기를 조정하지만 MQL 자체에는 선이 표시되지 않습니다. 여기서 다시 해야 합니다. 직접 면적 측정에 물고 빗변에서 뿌리를 뽑고 Gann Grid 의 제곱 행렬을 채우고 그러한 지표에 Expert Advisor를 설정하십시오. 그러면 일반적으로 리소스에 작별 인사를 할 수 있습니다. 여기에서는 16 Gig조차도 조롱처럼 보일 것입니다.
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы объектов / Типы объектов
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы объектов / Типы объектов
  • www.mql5.com
Стандартные константы, перечисления и структуры / Константы объектов / Типы объектов - Документация по MQL5
 
Yedelkin :

투표가 진행된다고 들었습니다 :)

아니면 벽에 기대어 죽이세요 :)
 

모든 것이 한때 사적이었고, 발명가-발견가의 머리에 있는 첫 번째 아이디어는 사적인 것으로 그에게만 내포되어 있었습니다. 그런 다음 수요가 증가하고 확산되었으며 ... 기본적으로 시스템 도구로 내장되기 시작했습니다. 익숙한가요?

그렇지 않으면 아무 것도 어떤 것으로 발전하지 않을 것입니다 ...

[삭제]  
abolk :
아니면 벽에 기대어 죽이세요 :)

이것은 더 가능성이 높은 결과입니다.

그리고 내 질문에 답이 없을 것 같아서 SD에 써야 할 것 같아요... :(

 
MetaDriver :

2. 나는 보았다. 그래서 무엇? 놓친 바가 많습니까? 나는 이것에 대한 환상이 없습니다. 요청이 있습니다. 전혀 독창적이지 않으며 결코 "예외적으로 사적인" 것이 아닙니다. 즉: 터미널 제조업체가 지원하는 견적에 대한 자동(!!) 액세스(및 표시!) 모드(포함, 예, 예! 낮음=종가=[ 비어 있지 않은 이전 막대 의 종가 ]}. 이것이 인기있는 모드라고 생각하십니까 ? 아니면 내가 큰 원본 입니까? 솔직히 말해, 레나트. 오른손을 왼쪽 심장에 놓으십시오.

내 경험에 따르면 공허함을 채우는 것은 말도 안되는 자기기만이며, 이 채워진 역사를 얻는 즉시 즉시 드러날 것입니다.

이 질문은 지난 10년 동안 여러 번 제기되었습니다.

 
x100intraday :
그들은 손으로 거래하는 모든 사람들보다 라이브 자동 태깅을 조금 덜 원합니다. 오실레이터, 이동 평균 등에 MTS/ATS를 쓰는 사람은 누구나 스스로 작성하게 하면 "저 선에서" 자동 거래를 위해 이 표시기를 조정하지만 MQL 자체에는 선이 표시되지 않습니다. 여기서 다시 해야 합니다. 직접 면적 측정에 물고 빗변에서 뿌리를 뽑고 Gann Grid 의 제곱 행렬을 채우고 그러한 지표에 Expert Advisor를 설정하십시오. 그러면 일반적으로 리소스에 작별 인사를 할 수 있습니다. 여기에서는 16 Gig조차도 조롱처럼 보일 것입니다.

즉, 당신은 행복이 올 것이라고 믿으면서 당신의 결정에 대한 무거운 사전 계산 상태를 우리에게 전가하기를 원합니다.

즉, 결과적으로 100 %의 경우 터미널 성능을 망치고 훨씬 더 많은 메모리를 소비한다는 사실의 결과를 평가하지도 않습니다. 이것은 나쁜 조언입니다.

복잡한 결정을 내리는 경우 알고리즘 방식을 사용하여 각 경우의 계산량 을 줄이고 정면으로 문제를 해결하려고 하지 마십시오. 필요한 데이터가 있는 캐시의 백그라운드 준비를 사용합니다.

 
Renat :

즉, 당신은 행복이 올 것이라고 믿으면서 당신의 결정에 대한 무거운 사전 계산 상태를 우리에게 전가하기를 원합니다.

즉, 결과적으로 100 %의 경우 터미널 성능을 망치고 훨씬 더 많은 메모리를 소비한다는 사실의 결과를 평가하지도 않습니다. 이것은 나쁜 조언입니다.

복잡한 결정을 내리는 경우 알고리즘 방식을 사용하여 각 경우의 계산량 을 줄이고 정면으로 문제를 해결하려고 하지 마십시오. 필요한 데이터가 있는 캐시의 백그라운드 준비를 사용합니다.

물론 캐시는 RAM이 아닌 디스크에 있어야 합니다. 그것은 파일 읽기/쓰기 작업입니까? 그러나 먼저 터미널을 희생하여 데이터베이스에 exact_times[] 값을 추가하는 것보다 더 편리하지 않습니다. 좋은 개발 환경은 각 사용자가 스스로 개발할 수 있는 기성 도구를 모든 사용자에게 제공해야 하지만 각 사용자에게 동일한 작업을 개별적으로 부담시키는 것은 무자비합니다. 이것은 특수성에 관한 것입니다. 특별함도 없고 기대하지도 않은 환상이다. 나 자신은 합리화 제안과 새로운 아이디어의 도입 때문에 포럼에 있고 이미 내장된 기능에 대해 질문하기 위해서만 포럼에 있습니다(원하는 경우 스스로 도움말을 공부할 수 있음). 그리고 두 번째로 MQL 코더에 의한 분석의 부조리를 상기시키고 싶습니다. 이것은 아카이브에서 정확히 선택된 하나의 파일을 추출하는 것이 아니라 하나의 특정 파일을 위해 전체 아카이브를 발굴하는 것을 연상시킵니다. 극한 상황의 정확한 시간을 미리 계산하면 의심할 여지 없이 시간과 기계 자원이 필요하지만! 우리의 독립적인 분석에 더 적은 리소스가 사용됩니다. 뭔가 C가 MQL보다 조금 더 빨리 작동한다고 알려줍니다... 추측인가요 사실인가요? 그리고 가장 끔찍한 것은 현재 표시된 개체의 상태, 즉 부분적인 재계산의 관련성을 주기적으로 확인하는 것입니다. 이를 피하려면 캐시에서 이전에 계산된 데이터를 가져와야 하지만 이것은 이미 이전 "첫 번째"에서 가져온 것입니다.
 
결국 이것은 터미널에 기능으로 내장되어 터미널이 막대의 정확한 시간을 계산할지 여부를 선택적으로 선택할 수 있습니다. 이것은 표준 관행이며 사용자가 정확도와 시간 중에서 선택하도록 합니다. 글쎄요, MQL 프로그래머가 추가 막대 속성의 사전 계산을 터미널 개발자의 어깨로 옮기겠다고 제안하는 것은 이상하고 심각하지 않습니다. 물론 우리도 많이 할 수 있지만 객관적이 되도록 터미널 개발자와 MQL 프로그래머 간의 역할을 명확하게 보고 분배해야 합니다.