Вопрос о pt_close и прочих pt

[Олег]

Вот смотрите...
На протяжении всей документации очень широко используются pt_close и прочие pt.
Но ни разу нигде не объясняется,  что это такое и с чем это можно кушать.

Как я понимаю, pt это point.
И как я понимаю, это массив всех значений close, эквивалентное:

Code: [Select]

line[0] = close;

Но почему в документации-то это нигде не прозвучало?!
А может, я вообще неправильно понял, что это такое?

Единственное место во всей документации, где предпринята робкая попытка объяснить, что это такое - это вот это место:



На самом деле, из этого объяснения мне не понятно ровным счетом ничего. Да и ведь это не объяснение вовсе. Здесь речь-то идет совсем о другом. В смысле, не о том, что это такое, а о том, куда это можно вставить

Чтобы выяснить этот вопрос, попробовал поэкспериментировать.
Как всегда разработчики приучают нас к самостоятельности

Выяснил, что это тоже самое,  но все-таки не совсем.

Например, вот такой скрипт

Code: [Select]

#line 0 nodraw
#line 1 solid red
#line 2 solid blue

function calc()
{
line[0] = close;
line[1] = MovAvg(ind_sma, 5, pt_close);
line[2] = MovAvg(ind_sma, 5, line[0]);
}
действительно,  дает нам две совпадающие линии



но в самом начале они все-таки не совпадают



Значит это все-таки не совсем одно и тоже.

А я сейчас занимаюсь тем, что сравниваю результаты работы своих эксельных тестировщиков с этими же самыми тестировщиками, переписанными в скриптах ATF.

Во многих случаях результаты полностью совпадают, но где-то немного отличаются. Чтобы выловить этих блох приходится вникать во все тонкости.

А чтобы вникнуть во все тонкости нужна хорошая документация.

[Олег]

Да уж, как сейчас выяснил опытным путем, это совсем не одно и то же.

До этого делал вот так:

Code: [Select]

line[0] = MovAvg(ind_sma, 5, pt_close);
Сейчас сделал вот так:

Code: [Select]

line[0] = close;
line[1] = MovAvg(ind_sma, PeriodOfSlowMoving, line[0]);
В первом случае, результаты двух тестировщиков не совпадали (хоть и отличались друг от друга не сильно), а во втором случае совпали полностью!

Следовательно, либо это не одно и то же, и так оно и задумано, либо у вас там сидит очень крупный трудноуловимый таракан

[Heller]

Вообще говоря pt_close и close - это одно и то же. Ну вернее как.

pt_close можно в некотором приближении рассматривать как константу. Если копать глубоко она на самом деле не константа, а лексема специального вида, которая синтаксически может быть использована только там, где это указано грамматикой языка. В начале была идея делать ATF именно таким образом для того, чтобы дать как можно меньше синтаксической свободы пользователю и как следствие сделать синтаксис как можно более простым для типичных задач и сдеать более простым нахождение ошибок. (Скажем, если pt_close было бы обычной константой, её можно было бы использовать где угодно, в том числе и ошибочно). Этот подход в целом себя не оправдал, но наложил ряд синтаксических ограничений (таких как необходимость указать для line[j] числовую константу в качестве номера линии). Это будет переделываться, и через какое-то не очень продолжительное время pt_close превратится в обычную числовую константу, но пока это все же не совсем так.

close - это так же лексическая единица своего типа. В некотором приближении она похожа на массив line или linebuffer. В грамматике языка есть разные правила вывода - для лексем типа pt_close (они называются, кстати PRICE_TYPE, отсюда и сокращение) и для лексем типа line[j]. В разных случаях работает один и тот же алгоритм, но только использует разные данные.

По большому счету это все одно и то же - однако в каких-то местах с целью оптимизации, вероятно, это может отражаться на последовательности каких-то расчетов. Конструкции типа MovAvg не рассчитываются по каждому calc-у, они на самом деле могут считаться отдельно до просчета всей истории и потом использоваться. Во всяком случае так это происходит для pt_close, это гораздо более эффективно с вычислительной точки зрения. Я сейчас уже не смогу вспомнить сходу детали как этот механизм работает в других случаях, но его тоже мы будем переделывать, я буду иметь ввиду ваш вопрос - приведу к общему знаменателю, если тут есть действительно какое расхождение, а это не наведенный эффект.

[Олег]

Вообще говоря pt_close и close - это одно и то же. Ну вернее как.

pt_close можно в некотором приближении рассматривать как константу. Если копать глубоко она на самом деле не константа, а лексема специального вида, которая синтаксически может быть использована только там, где это указано грамматикой языка. В начале была идея делать ATF именно таким образом для того, чтобы дать как можно меньше синтаксической свободы пользователю и как следствие сделать синтаксис как можно более простым для типичных задач и сдеать более простым нахождение ошибок. (Скажем, если pt_close было бы обычной константой, её можно было бы использовать где угодно, в том числе и ошибочно). Этот подход в целом себя не оправдал, но наложил ряд синтаксических ограничений (таких как необходимость указать для line числовую константу в качестве номера линии). Это будет переделываться, и через какое-то не очень продолжительное время pt_close превратится в обычную числовую константу, но пока это все же не совсем так.

close - это так же лексическая единица своего типа. В некотором приближении она похожа на массив line или linebuffer. В грамматике языка есть разные правила вывода - для лексем типа pt_close (они называются, кстати PRICE_TYPE, отсюда и сокращение) и для лексем типа line. В разных случаях работает один и тот же алгоритм, но только использует разные данные.

По большому счету это все одно и то же - однако в каких-то местах с целью оптимизации, вероятно, это может отражаться на последовательности каких-то расчетов. Конструкции типа MovAvg не рассчитываются по каждому calc-у, они на самом деле могут считаться отдельно до просчета всей истории и потом использоваться. Во всяком случае так это происходит для pt_close, это гораздо более эффективно с вычислительной точки зрения. Я сейчас уже не смогу вспомнить сходу детали как этот механизм работает в других случаях, но его тоже мы будем переделывать, я буду иметь ввиду ваш вопрос - приведу к общему знаменателю, если тут есть действительно какое расхождение, а это не наведенный эффект.

Спасибо за разъяснение.
Но все-таки, это разъяснение должно присутствовать где-то и в документации тоже.

Хотя, с другой, стороны, я, разумеется, понимаю, что разработка такой сложной системы, какой несомненно является ATF, вовсе не представляет из себя гладкую линию, направленную вверх точно под углом в 45 градусов. Это сложный творческий процесс, в котором по ходу дела возникают и конкурируют между собой разные творческие идеи, а потом эти идеи проходят испытание временем и некоторые из них, по тем или иным соображениям, отсеиваются, а на смену им приходят новые идеи и т.д. до бесконечности
Это я к тому, что я понимаю, что очень трудно добиться того, чтобы документация ВСЕГДА отражала существующее на данный момент положение вещей, но все-таки к этому надо стемиться с максимальным упорством, потому что среднестатистическому пользователю без актуальной документации приходится либо домысливать/угадывать, либо пытаться искать ответы самостоятельно, экспериментируя с простыми скриптами. Это, конечно, полезное занятие, но достаточнотрудоемкое, и не у всех хватает терпения проходить эту суровую школу

...вероятно, это может отражаться на последовательности каких-то расчетов...

"Может отражаться" это слишком мягко сказано

Я сначала сделал 10 линий, четыре первые из которых были:

line[0] = close;
line[1] = high;
line[2] = low;
line[3] = open;

Потом мне понадобилась еще одна линия, я вспомнил про эти pt и решил съэкономить - заменил эти линии этими самыми pt. В результате начал получать в тестировщике неправильные результаты по "чистой прибыли". Потом я догадался выкинуть все эти pt и снова сделать все как было до их использования.

Результат великолепный!
Проанализировал уже 20 фьючерсов параллельно в Эксельном тестировщике и в ATF-ном, и каждый раз "чистая прибыль" совпала со стопроцентной точностью.
Следовательно, теперь я могу быть уверен, что оба тестировщика работают правильно.

И все-таки вам стоило бы выкинуть все эти pt из разъяснений по построению мувингов в документации. Я уж не знаю, баг это или нет, но результаты получаются ошибочные (по "чистой прибыли").

Да вы сами-то попробуйте.
Возмите самого простенького робота, построенного на мувингах SMA, но в одном случае усредняйте по line, а в другом по pt, и погоняйте его на разных исторических данных, и вы получите разные результаты по "чистой прибыли". И хоть эти результаты будут отличаться друг от друга не очень сильно, но они все-таки будут! А это не правильно

[Олег]

Забыл сказать. Берите период усреднения побольше. Ошибки вылезают именно на больших периодах. У меня было 55 и 280.  В обоих случаях были SMA,  построенные по close.
Так вот, 55 работало нормально, а вот 280 дурило.