테스터 Grail은 무엇입니까? - 페이지 15

 
George Merts :

그리고 모든 곳에서 가상화에 대해...

... 게다가, 이것이 실제로 존재하는지 여부는 불명. 또는 수신 된 "무언가"에 대한 모든 작업 - 완전히 다른 엔티티를 제어합니다. 멋진 것 같아요.

가상화를 모든 곳에서 장려하는 것은 고사하고 부조리의 지점까지 가상화를 가져올 필요가 없습니다.

다음은 실제 생활로 변환된 가상화의 예입니다 .

당신은 소녀 Masha를보고 싶어, 전화, Pasha는 Masha를 대표하기 위해 온다.

여기 실생활에서의 가상화가 있습니다. 이제 내가 당신에게 물어 보자, 이것이 멋진가?

감사합니다.

 
Andrey Kisselyov :

가상화를 모든 곳에서 장려하는 것은 고사하고 부조리의 지점까지 가상화를 가져올 필요가 없습니다.

다음은 실제 생활로 변환된 가상화의 예입니다 .

당신은 소녀 Masha를보고 싶어, 전화, Pasha는 Masha를 대표하기 위해 온다.

여기 실생활에서의 가상화가 있습니다. 이제 내가 당신에게 물어 보자, 이것이 멋진가?

우와! 좋은 예입니다.

"회계 부서의 소녀 Masha를보고 싶습니다. 누가 내 회계 프로그램이 쓰레기를 표시하는지 알려줄 것입니다"라는 요청이 있고 프로그래머 Pasha가 와서 무엇이 잘못되었는지 설명 할 것입니다. Masha가 온다면 덜 기쁠 것입니다. . 아마도 더.

또 다른 점은 필요한 인터페이스를 정확히 요청해야 한다는 것입니다. 물론 섹스가 필요하고 프로그래머 Pasha가 Masha 대신 온다면 불행할 것입니다. 그러나 즉시 불일치를 확인하고 "컴파일 단계에서"라도 간과를 제거합니다.

그리고 물건에 직접 접근할 수 있는 경우 - Masha에게 섹스를 요청함으로써 - Masha 자신과 Masha를 위해 온 배우자로부터 얼굴을 맞을 수 있습니다.

가상화 - 특정 작업을 위해 특정 위치에서 필요한 만큼만 요청을 제한할 수 있습니다. 다른 모든 것은 잘립니다. 그리고 그것은 가능한 많은 실수로부터 당신을 구합니다. 내 생각에 유일한 한계는 이러한 모든 가상 인터페이스를 설계 하는 "오버헤드"입니다. 간단한 지표의 아이디어를 "신속하게" 테스트해야 하는 경우 이러한 모든 OOP 종소리와 휘파람을 차단하는 것은 비합리적입니다.

 
George Merts :

내 생각에 유일한 한계는 이러한 모든 가상 인터페이스를 설계하는 "오버헤드"입니다. 간단한 지표의 아이디어를 "신속하게" 테스트해야 하는 경우 이러한 모든 OOP 종소리와 휘파람을 차단하는 것은 비합리적입니다.

이것이 최적화 중에 테스터 환경에서 모든 Expert Advisor의 작업을 느리게 하는 주요 제한 사항 이라고 생각합니다. Expert Advisors를 많이 최적화하면 최적화 시간이 분명히 늘어납니다. 내가 이미 말했듯이 모든 가상화(프로세서 코어의 OOP 또는 스레드 분할 여부)는 프로그램 실행 시간 을 늘리고 컴퓨터 성능을 저하시킵니다.

OOP는 컴퓨터 성능을 희생시키면서 오로지 프로그래머의 편의를 위해 만들어졌습니다.

감사합니다.

 
Stefan Stoyanov :

두 가지 무료 제품이 있습니다

잠금으로 보호

항상 도움이 되지 않는다


무료 성배 가 없습니까?)) 또는 작업 전략이 있습니까?

 
Andrey Kisselyov :

이것이 최적화 중에 테스터 환경에서 모든 Expert Advisor의 작업을 느리게 하는 주요 제한 사항 이라고 생각합니다. Expert Advisors를 많이 최적화하면 최적화 시간이 분명히 늘어납니다. 내가 이미 말했듯이 모든 가상화(프로세서 코어의 OOP 또는 스레드 분할 여부)는 프로그램 실행 시간 을 늘리고 컴퓨터 성능을 저하시킵니다.

OOP는 컴퓨터 성능을 희생시키면서 오로지 프로그래머의 편의를 위해 만들어졌습니다.

감사합니다.


"느리게"라는 단어는 OOP의 상대방을 어떻게 든 놀라게합니다.)) "지연을 도입하다"라는 문구를 사용하는 것이 좋습니다.

이제 치명적인 질문입니다. 몇 퍼센트입니까? 결국, 1 년 연속으로 포럼 la-la-la에서만 아무도 테스트를 시도하지 않았습니다))

 
George Merts :

괜찮은.

기준점이 필요한 경우 - 이전 단계의 자산입니다. 실제로 고정되지 않은 부동 값입니다. 나는 '현실과의 탈피'를 보지 않고, 오히려 균형이 현실과의 도피를 의미한다고 생각하는 사람들이다. Equity가 1000 인 경우 현재 잔액이 100이고 잔액이 현재 10K 인 경우에도 차이가 없습니다. 이전 단계의 Equity만 900이든 1100이든 역할을 합니다.


부조리의 지점으로 가져옵니다. 일종의 가상화 불합리. ;))))

주위를 둘러보고 가상 클라우드에서 지구로 내려갑니다.

 
George Merts :

우와! 좋은 예입니다.

"회계 부서의 소녀 Masha를보고 싶습니다. 누가 내 회계 프로그램이 쓰레기를 표시하는지 알려줄 것입니다"라는 요청이 있고 프로그래머 Pasha가 와서 무엇이 잘못되었는지 설명 할 것입니다. Masha가 온다면 덜 기쁠 것입니다. . 아마도 더.

또 다른 점은 필요한 인터페이스를 정확히 요청해야 한다는 것입니다. 물론 섹스가 필요하고 프로그래머 Pasha가 Masha 대신 온다면 불행할 것입니다. 그러나 즉시 불일치를 확인하고 "컴파일 단계에서"라도 간과를 제거합니다.

그리고 물건에 직접 접근할 수 있는 경우 - Masha에게 섹스를 요청함으로써 - Masha 자신과 Masha를 위해 온 배우자로부터 얼굴을 맞을 수 있습니다.

가상화 - 특정 작업을 위해 특정 위치에서 필요한 만큼만 요청을 제한할 수 있습니다. 다른 모든 것은 잘립니다. 그리고 그것은 가능한 많은 실수로부터 당신을 구합니다. 내 생각에 유일한 한계는 이러한 모든 가상 인터페이스를 설계하는 "오버헤드"입니다. 간단한 지표의 아이디어를 "신속하게" 테스트해야 하는 경우 이러한 모든 OOP 종소리와 휘파람을 차단하는 것은 비합리적입니다.


분명히, 당신은 여전히 OOP 바늘에 앉을 수 있습니다. 증상은 극도의 가상화, 현실 도피, 현실을 가상으로 대체하는 것입니다.

;)))

 
ivan12347777 :

무료 성배가 없습니까?)) 또는 작업 전략이 있습니까?

아니다

고객들에게 혼란을 주지 않기 위해 시장 에서 성배 를 제거했습니다.

나는 사람들을 속이고 싶지 않다

 
Alexey Volchanskiy :

"느리게"라는 단어는 OOP의 상대방을 어떻게 든 두려워합니다))) "지연을 도입하다"라는 문구를 사용하는 것이 좋습니다.

이제 치명적인 질문입니다. 몇 퍼센트입니까? 결국, 1 년 연속으로 포럼 la-la-la에서만 아무도 테스트를 시도하지 않았습니다))

주변의 모든 것을 가상화하는 것은 연인에게 달려 있습니다. 연속 클래스가 있는 경우 지연이 더 클 가능성이 높으며, 하나의 기능만 가상인 경우에는 더 적습니다. 그러나 사실은 분명할 것입니다.

감사합니다.

 
George Merts :

오! 글쎄, 적어도 당신은 자물쇠가 재발견과 어떻게 다른지 말해 줄 것입니다.

스왑이 없고 EA가 거래되고 있다면 제 생각에는 락킹과 리커버링 TS 사이에 차이가 없습니다.

알려진 차이점이 있습니다. 이것은 두 번째 기회입니다.

잠금 + 주요 위치를 닫으면 주문을 열고 닫는 데 좋은 전략이 있는 경우 수익 확률이 높아집니다.

손절매 로 마감 할 때 기회 없지만 때로는 최선입니다.

일반적 으로 추세를 플랫 명확하게 구분하면 잠금 이 도움이 될 수 있습니다.