Странный перенос стратегии с WLD в LUA

Внимание

Для участия в обсуждениях и оформления подписки на новые сообщения форума вам необходимо зарегистрироваться.
Главная » Основные форумы » Программирование на языке Lua
Страницы: 1
RSS
Странный перенос стратегии с WLD в LUA
 
#1
20.02.2017 19:24:58
У меня необычный вопрос, при переносе стратегии с WLD в Quik столкнулся с проблемой плавающей запятой.

У вас данные поставляются правильно точно c сотыми. А вот в WLD и  MQL4 цены как то меняются

Вместо:

High: 1152.31
High: 1154.80
High: 1156.48

Выводят:

High: 1152.31005859375
High: 1154.80004882813
High: 1156.48999023438

И даже если сделать вычисление 1156,48 - 1154,80  = 1,68004841515

Мне уточнили (хотя я не уверен) что это происходит из за представления числа с плавающей запятой в двоичном коде. Из-за этой разнице, система перенесённая в Квик, работает иначе и выходит совсем другой результат.. скажите как можно настроить lua в Квике, что бы вычисления с плавающей запятой работало аналогично как и в WLD и  MQL4.

Я конечно сам не уверен что эта за фигня, но я думаю смысл моего вопроса понятен!
 
 
#2
20.02.2017 19:37:28
На смарт лабе обсуждали: http://smart-lab.ru/blog/381848.php#comment6878263
 
 
#3
21.02.2017 15:08:03
Ещё раз сравнил вычисления, разница получается очень большая. Робот на 70% меньше прибыли приносит. Поэтому как переносить на LUA вопрос для меня актуальный!
 
 
#4
21.02.2017 15:13:03
Роман,

Насколько становится понятно, Вам нужно просто округлять значения до нужного количества знаков после запятой.
Есть куча разных способов это сделать и тема уже не раз поднималась на нашем форуме и в интернете.
Также, есть простое правило, сравнивать числа с заданной точностью.

https://forum.quik.ru/messages/forum10/message19982/topic2229/#message19982
 
 
#5
21.02.2017 20:49:59
Sergey , не совсем, скорее на оборот.

В WLD4 цена high храниться в float и будет отражаться как 1152.31005859375, а в LUA  high отражается как 1152.31  из-за этой разницы индикаторы прописанные в LUA будут считаться не как в том же WLD4.

Мне нужно наоборот не округлять, а получтить эту погрешность, что цена не 1152.31 отражалось, а 1152.31005859375, т.е. 1152.31 =>  1152.31005859375!
Понимаете?
 
 
#6
21.02.2017 21:11:54
Я так понял, что нужно перевести в формат float, без отсечения.
 
 
#7
21.02.2017 21:21:37
Цены типа 1152.31005859375 - это фикция. Их не бывает в реальности.

quik показывает реальные цифры. Цены на сделок всегда кратны шагу цены, установленному биржей для каждого инструмента. Для вашего инструмента она скорее всего определена в в 0.01

появление в wld или метатрейдере дополнительных разрядов - это самодеятельность.

поэтому если вашей системе вот эти дополнительные знаки после запятой критически важны - это говорит о неприменимости вашего алгоритма к условиям реальных торгов.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
 
#8
21.02.2017 22:14:45
Это понятно, но в всё там применимо. Вопрос только как в LUA float формат без нормализации перевести 1152.31 => 1152.31005859375
 
 
#9
22.02.2017 06:28:31
В C# я тоже проверил double, получилась как в WLD4, к примеру, вычитаю максимум и максимум вчерашнего дня: (956,8 - 956,74) * 1000 = 599,999999999454 заметьте не 600!

Эксперимент в LUA:

(956,8 - 956,74) * 1000 = 599.99999999945

Но здесь разница в разрядности 11 vs 12.
Сравнил разницу расчётов в WLD4 на делфи и WLD6 на C# - разницы не выявило.

Просто чисто перенося точную копию в LUA некоторых индикаторов с плавающей точкой, они не совпадают, а на разных платформах работают аналогично!
 
 
#10
22.02.2017 20:13:43
Вот специально написал два проекта на C# и LUA вычислял Стохастик на двух языках.

C# и Delphi:
Код
diff: 970,28 - 960 = 10,28
rez: 100 * (967,69 - 960) / 10,28 = 7480,54474708179
 
diff: 970,28 - 961,69 = 8,58999999999992
rez: 100 * (966,4 - 961,69) / 8,58999999999992 = 5483,11990686841
 
diff: 970,28 - 963,7 = 6,57999999999993
rez: 100 * (963,81 - 963,7) / 6,57999999999993 = 167,173252279485
 
diff: 969,51 - 960,99 = 8,51999999999998
rez: 100 * (961,21 - 960,99) / 8,51999999999998 = 258,215962441347

LUA:
Код
diff: 970,28 - 960 = 10,28
rez: 100 * (967,69 - 960) / 10,28 = 7480,54474708118
 
diff: 970,28 - 961,69 = 8,5899999999999
rez: 100 * (966,4 - 961,69) / 8,5899999999999 = 5483,1199068684
 
diff: 970,28 - 963,7 = 6,5799999999999
rez: 100 * (963,81 - 963,7) / 6,57999999999993 = 167,17325227949
 
diff: 969,51 - 960,99 = 8,52
rez: 100 * (961,21 - 960,99) / 8,52 = 258,21596244135

Как видите только на LUA результат другой, так вроде только хвосты меняються, но иногда всплывает существенная разница:

8,51999999999998 vs  8,52, а это возможно может искажать индикатор, особенно который работает с Ceil, Round и основан на десятичных вычеслениях.

Просто возьмите индикаторы написанные на C# и LUA, я думаю вы заметите разницу. Вот как это в LUA править теперь?  
 
 
#11
22.02.2017 21:35:29
А сглаживание rez посмотрите. вообще от болды показывает, не одного правильного результата нет!
 
 
#12
22.02.2017 21:43:14
Я думаю у вас разрешение плавающей на  13 вместо 14 стоит, хотя не уверен!
 
 
#13
28.02.2017 18:50:23
Уважаймые разработчики, ответьте каким образом решить проблему. Повторюс, если к выше предоставленной формуле стохастика применяют несколько подряд сгладиваний, результаты не как не соответствуют действительности которые получаются на остальных языках программирования.
 
 
#14
01.03.2017 09:43:28
Добрый день.
Никакой проблемы не видим, все считается абсолютно одинаково.
 
 
#15
01.03.2017 15:08:39
Michael Bulychev ,    т.е. по вашему 8,51999999999998 это тоже самое что и 8,52?  
 
 
#16
01.03.2017 16:10:50
Или даже так:

8,51999999999998 * 100 = 851,999999999998 равно 8,52 *100 = 852
 
 
#17
01.03.2017 16:16:19
з.ы. просто я попробовал на разных языках и платформах у всех одинаково, а вот у вас на разрядность больше!
 
 
#18
01.03.2017 20:44:02
Вот с сглаживанием пример:
Код
C#:

160830180000: O:959,26: H:960,89 L: 957,81 C: 958,67
diff: (958,67 - 957,62)*100 = 104,999999999995
diff2: (969,97 - 957,62) * 100 = 1235
EMA: 257,182188699083
EMA2: 452,52290535166

LUA QuiK:

160830180000: O:959,26: H:960,89 L: 957,81 C: 958,67
diff: (958,67 - 957,62)*100 = 105
diff2: (969,97 - 957,62) * 100 = 1235
EMA: 257,37233544511
EMA2: 451,97718098301

Ребята, не ужели лентяйничайте прописать, что теперь скажите - вы видите какая разница у вас!
Так что прошу вас предоставить способ решения проблемы, что же получается все написанные индикаторы: косячные!  
 
 
#19
02.03.2017 04:45:55
Добрый день.
https://habrahabr.ru/post/112953/ - тут можно почитать про вычисления с плавающей точкой.
Если хотите сравнить полученные значения в разных языках, то выводите их на печать с одинаковой точностью.
в Lua, например, так:
Код
x=1/3
print(string.format("x = %.15f", x))

выводить 15 знаков после запятой.
 
 
#20
02.03.2017 18:57:10
Цитата
Роман написал:
Или даже так:

8,51999999999998 * 100 = 851,999999999998 равно 8,52 *100 = 852
Цитата
Роман написал:
Michael Bulychev  ,    т.е. по вашему 8,51999999999998 это тоже самое что и 8,52?
Роман,
правильно я вас понял.  Вы утверждаете, что  8,51999999999998 это не 8.52?
-------------------------------
Но если Вы посчитаете погрешность то получите 2.29342E-15.
Потом возьмете справочник по программированию и узнаете, что формат double, который используется в LUA, в МТ4, в WLD позволяет хранить числа с погрешностью 15 десятичных цифр, т е относительная погрешность E-15.
а вот отображение на экране оператором print выполняется в соответствии  с заданным Вами или заданным по умолчанию форматом.
----------------------------------
так в чем у вас проблема?
 
 
#21
02.03.2017 20:00:50
Николай Камынин , я и говорю что в LUA неправильно настроен формат в  МТ4, WLD (Delphi), WLD (С#). да и просто в C# они одни, а в LUA QUIK они другие!
 
 
#22
02.03.2017 20:15:24
print(string.format("x = %.15f", x)) - ну это так заплатка конечно временная, при каждом сложении её ставить. В программе нужно настройку поставить или с общими стандарты откорректировать.
 
 
#23
03.03.2017 19:12:00
Цитата
Роман написал:
print(string.format("x = %.15f", x)) - ну это так заплатка конечно временная, при каждом сложении её ставить. В программе нужно настройку поставить или с общими стандарты откорректировать.
Полагаю, что Вы не поняли.
Есть внутренний формат данных  и внешний.
Внутренний - это то как считается, а внешний - это то как смотрится.
Считается и WLD и в lua и в МТ4 в формате double.
В других языках, например на CИ либо на 64 битной машине можно считать еще в double dlouble формате, будет еще точнее.
А отображение на экране в каждом языке делается, еслм по умолчанию, то  как задумано автором языка.
-----------------------------
Но основная проблема у Вас, по-моему мнению, в том,
что если Ваш робот перестает работать при разности в ценах E-15, то это мертвый робот.
Он  будет сливать депозит на реальном счете.
 
 
#24
04.03.2017 00:59:28
Николай Камынин , при всём уважении я привёл здесь достаточно фактов!  
 
 
#25
05.03.2017 09:07:19
Цитата
Роман написал:
Николай Камынин  , при всём уважении я привёл здесь достаточно фактов!
Вполне допускаю, что примеров достаточно с Вашей точки зрения. так как Вы озабочены этой проблемой.
Но судя по ответам,  проблема либо  не понятна , либо проблемы вообще нет.
Если цель поста - сделать заявление о том, что все у Вас плохо, то цель достигнута.
но полагаю, что вы хотите получить какие-то ответы для решения проблемы. Верно?
Тогда попробуйте объяснить проблему подробнее и понятнее для других, если нужна помощь в ее решении.
 
 
#26
07.03.2017 16:01:09
Николай Камынин , но что здесь не понятного, вы спрашиваете: проблема в том что не правильно считает или отражает, извеняюсь а что будет не правильно считать, то будет правильно отражаться?

Я вам вверху уже пример написал, если не охота самому проверять. Что в Квике в сравнению с остальными языками разная разрядность! и 1 double не равен 1 double. Окей, типа последняя цифра это фигня, не так сильно влияет на расчёт, у вас фигня у меня нет, и ещё раз продемонстрировал что при многократном сглаживании на длинном массиве данных, итоговая цифра вообще меняется!

Ну если вы не видете в этом проблему, то разница в доходности в вашем амиброкере и в Квике, вас не должна волновать в принципе!
 
 
#27
07.03.2017 16:39:46
Решение одно стандартизировать разрядность.
 
 
#28
07.03.2017 18:13:07
Цитата
Роман написал:
Решение одно стандартизировать разрядность.
Ну, во-первых, у меня нет разности доходности в амиброкере и квике.
во-вторых, у меня считает одинаково и в Амиброкере и в квике
В-третьих, я не виноват в том, что Вы воинствующий дилетант.
 
 
 
#29
09.03.2017 18:29:26
Николай, вы хотя бы читаете то что пишите?

Начиная от:
- Вы утверждаете, что 8,51999999999998 это не 8.52?
Ещё бы.
- Вы озабочены этой проблемой.  Но судя по ответам, проблема либо не понятна , либо проблемы вообще нет.
Озабочен что некоторые считают что 8,51999999999998=8.52=true

- В программе нужно настройку поставить или с общими стандарты откорректировать.
- вы хотите получить какие-то ответы для решения проблемы.
- Решение одно стандартизировать разрядность.

Вы что силой внушения пытаетесь решить проблему, даже в школе благородных девиц учат  "воинствующим дилетантам", примеры предоставлять фактическом виде, вот и предоставьте вывод вашего дэбарг кода в опровержение моих фактор, а не рассказывайте что мне кажется, а что нет!
 
 
#30
20.06.2017 21:13:26
Какой накал, какие страсти.
Роман, вам верно подсказали, что перед тем как вести дискуссию, стоит ознакомиться со спецификой хранения чисел с плавающей точкой (стандарт IEEE 754) и со спецификой вывода данных на консоль.

По вашему примеру:  969.51 - 960.99 = 8.519999999999982
этот результат будет одинаков и на Lua, и на PHP, и на Java, и на C, и даже на Javascript..
я, осознавая глупость этого, не поленился и проверил.. мало ли, что бывает..

проблема, которую вы пытаетесь раздуть и возложить на разработчиков Quik -- это никакая не проблема, это ваше непонимание работы языка, и разработчики Quik вообще ни причем..
в lua результат вычисления 969.51 - 960.99 будет как и везде 8.519999999999982
но при простом выводе на консоль через print число будет отформатировано под текущую локаль и округлено до числа знаков после запятой, которое также задается в локали.. потому вы видите 8.52000 и это вас удивляет..
но то, что на консоль вывелось 8.52000 совсем же не значит, что в памяти число такое же.. как, я написал выше, оно равно 8.519999999999982 и именно но используется в расчетах..

плюс ко всему, надо понимать, что числа с плавающей точкой это не точные числа, они имеют погрешность.. но погрешность там порядка 10^-15, что просто ничтожно мало (если вы конечно не работаете с числами в районе нуля)..
 
 
Страницы: 1
Читают тему
Техническая поддержка
+7 383 219 1606
© 2000–2024,
ARQA Technologies
Наверх