Ошибки, баги, вопросы - страница 2822

Новый комментарий
 
Nikolai Semko:

Только округление не через штатные round(), ceil(), floor() т.к. они тоже возвращают double.

А через эти, тем более они работают быстрее штатных:

Может и быстрее, да только неправильнее.
Передадите в свой ceil что-нибудь вроде 12345.0000000000001 (аналогично вашему примеру), и на выходе можете получить 12346
 
Alexey Navoykov:
Может и быстрее, да только неправильнее.
Передадите в свой ceil что-нибудь вроде 12345.0000000000001 (аналогично вашему примеру), и на выходе можете получить 12346

Вы то сами пробовали?
Попробуйте:

Print(ceil( 12345.0000000000001));
Print(Ceil( 12345.0000000000001));
Print(ceil( 12345.000000000001));
Print(Ceil( 12345.000000000001));

Выход:

2020.08.10 12:03:23.856 ErrorNormalizeDouble (EURUSD,M1)        12345.0
2020.08.10 12:03:23.856 ErrorNormalizeDouble (EURUSD,M1)        12345
2020.08.10 12:03:23.856 ErrorNormalizeDouble (EURUSD,M1)        12346.0
2020.08.10 12:03:23.856 ErrorNormalizeDouble (EURUSD,M1)        12346
должно быть 12346, т.к. это ceil ("Возвращает ближайшее сверху целое числовое значение.")
в первом случае получается 12345, т.к. значимых цифр в типе double 17, а у вас 18
 
Nikolai Semko:

Действительно, нельзя сравнивать double. Просто жёсткое правило.

Конечно, можно и иногда даже нужно сравнивать double напрямую между собой.

Например, при Оптимизации OnTick вызывается иногда триллион раз. Штатный Тестер для того, чтобы понять, исполнять висящий лимитник или нет, делает сравнение текущей соответствующей цены символа и цены лимитника. Делает это для каждой отложки перед каждым OnTick вызовом. Т.е. таких проверок делается десятки и сотни миллиардов раз.

И делается это каждый раз через нормализацию. Так вот - это жуткое расходование вычислительных ресурсов впустую. Т.к. цены и отложенных ордеров и символа предварительно нормализованы. Поэтому могут и должны сравниваться между собой напрямую.

Не на ровном месте MQL-кастомный Тестер уделывает нативный штатный Тестер по производительности.

 

fxsaber:

Конечно, можно и иногда даже нужно сравнивать double напрямую между собой.

Например, при Оптимизации OnTick вызывается иногда триллион раз. Штатный Тестер для того, чтобы понять, исполнять висящий лимитник или нет, делает сравнение текущей соответствующей цены символа и цены лимитника. Делает это для каждой отложки перед каждым OnTick вызовом. Т.е. таких проверок делается десятки и сотни миллиардов раз.

И делается это каждый раз через нормализацию. Так вот - это жуткое расходование вычислительных ресурсов впустую. Т.к. цены и отложенных ордеров и символа предварительно нормализованы. Поэтому могут и должны сравниваться между собой напрямую.

Не на ровном месте MQL-кастомный Тестер уделывает нативный штатный Тестер по производительности.

NormalizeDouble() очень дорогая функция. Поэтому про нее лучше забыть.

Вот скрипт, который демонстрирует разницу между NormalizeDouble() и нормализацию с помощью int:

#define  SIZE 1000000

int Ceil (double x) {return (x-(int)x>0)?(int)x+1:(int)x;}
int Round(double x) {return (x>0)?(int)(x+0.5):(int)(x-0.5);}
int Floor(double x) {return (x>0)?(int)x:((int)x-x>0)?(int)x-1:(int)x;}
//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
   double a[SIZE];
   double s1=0,s2=0, s3=0;
   for (int i=0;i<SIZE;i++)  a[i]=(rand()-16384)/M_PI;
   
   ulong t1=GetMicrosecondCount();
   for (int i=0;i<SIZE;i++) s1+=a[i];
   t1=GetMicrosecondCount()-t1;  
   
   ulong t2=GetMicrosecondCount();
   for (int i=0;i<SIZE;i++) s2+=NormalizeDouble(a[i],5);
   t2=GetMicrosecondCount()-t2; 
   
   ulong t3=GetMicrosecondCount();
   for (int i=0;i<SIZE;i++) s3+=Round(a[i]*100000);
   s3/=100000;
   t3=GetMicrosecondCount()-t3; 
   
   Print("простая сумма                            - " + string(t1)+ " микросекунд, сумма = "+ DoubleToString(s1,18));
   Print("сумма с NormalizeDouble                  - " + string(t2)+ " микросекунд, сумма = "+ DoubleToString(s2,18));
   Print("сумма, нормализированная через int       - " + string(t3)+ " микросекунд, сумма = "+ DoubleToString(s3,18));
  }

результат:

2020.08.10 12:55:30.766 TestSpeedNormalizeDouble (USDCAD,H4)    простая сумма                            - 1394 микросекунд, сумма = 626010.5038610587362201
2020.08.10 12:55:30.766 TestSpeedNormalizeDouble (USDCAD,H4)    сумма с NormalizeDouble                  - 5363 микросекунд, сумма = 626010.5046099795727060
2020.08.10 12:55:30.766 TestSpeedNormalizeDouble (USDCAD,H4)    сумма, нормализированная через int       - 1733 микросекунд, сумма = 626010.5046099999453873
ЗЫ причем нормализация через int получается еще и точнее (это можно увидеть по количеству девяток после последней цифры нормализации - выделено синим.)
 
Nikolai Semko:

NormalizeDouble() очень дорогая функция. Поэтому про нее лучше забыть.

Вот скрипт, который демонстрирует разницу между NormalizeDouble() и нормализацию с помощью int:

результат:

ЗЫ причем нормализация через int получается еще и точнее (это можно увидеть по количеству девяток после последней цифры нормализации - выделено синим.)

а если суммировать не через double, а через long, тогда результат еще более впечатляет, т.к. суммирование через int (умножение и округление с последующим делением итоговой суммы) вычесляется быстрее обычной суммы double.

#define  SIZE 1000000

int Ceil (double x) {return (x-(int)x>0)?(int)x+1:(int)x;}
int Round(double x) {return (x>0)?(int)(x+0.5):(int)(x-0.5);}
int Floor(double x) {return (x>0)?(int)x:((int)x-x>0)?(int)x-1:(int)x;}
//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
   double a[SIZE];
   double s1=0,s2=0, s3=0;
   long s=0;
   for (int i=0;i<SIZE;i++)  a[i]=(rand()-16384)/M_PI;
   
   ulong t1=GetMicrosecondCount();
   for (int i=0;i<SIZE;i++) s1+=a[i];
   t1=GetMicrosecondCount()-t1;  
   
   ulong t2=GetMicrosecondCount();
   for (int i=0;i<SIZE;i++) s2+=NormalizeDouble(a[i],5);
   t2=GetMicrosecondCount()-t2; 
   
   ulong t3=GetMicrosecondCount();
   for (int i=0;i<SIZE;i++) s+=Round(a[i]*100000);
   s3=s/100000.0;
   t3=GetMicrosecondCount()-t3; 
   
   Print("простая сумма                            - " + string(t1)+ " микросекунд, сумма = "+ DoubleToString(s1,18));
   Print("сумма с NormalizeDouble                  - " + string(t2)+ " микросекунд, сумма = "+ DoubleToString(s2,18));
   Print("сумма, нормализированная через int       - " + string(t3)+ " микросекунд, сумма = "+ DoubleToString(s3,18));  
  }

результат:

2020.08.10 13:15:58.982 TestSpeedNormalizeDouble (USDCAD,H4)    простая сумма                            - 1408 микросекунд, сумма = 460384.3207830497995019
2020.08.10 13:15:58.982 TestSpeedNormalizeDouble (USDCAD,H4)    сумма с NormalizeDouble                  - 6277 микросекунд, сумма = 460384.3162300114054233
2020.08.10 13:15:58.982 TestSpeedNormalizeDouble (USDCAD,H4)    сумма, нормализированная через int       - 964 микросекунд,  сумма = 460384.3162299999967218
 
Nikolai Semko:

а если суммировать не через double, а через long, тогда результат еще более впечатляет, т.к. суммирование через int (умножение и округление с последующим делением итоговой суммы) вычесляется быстрее обычной суммы double.

результат:

Decimal для сравнения добавьте.

Ошибся ссылкой, там не полная реализация.

 
fxsaber:

И делается это каждый раз через нормализацию. Так вот - это жуткое расходование вычислительных ресурсов впустую.

Откуда вам это известно?  Ведь даже если цены не нормализованы, то проверка элементарно делается и без всякой нормализации:

 if (fabs(price-limitprice) < ticksize/2)

учитывая, что цены кратны ticksize

 
Nikolai Semko:
ЗЫ причем нормализация через int получается еще и точнее (это можно увидеть по количеству девяток после последней цифры нормализации - выделено синим.)

Тест некорректный.  Почему вы делите на 100000.0 только один раз в конце?  Оно должно выполняться на каждой итерации, и потом суммироваться.  Вот тогда это будет честное сравнение.  А так у вас никакая не нормализация, а вы просто оптимизировали свой тестовый алгоритм. Естественно так будет и быстрее, и точнее (т.к. уменьшается накопленная ошибка)

 
Alexey Navoykov:

Откуда вам это известно?

Потому что можно подать на вход ненормализованные цены Тестеру, и он сработает с ними идентично.

Ведь даже если цены не нормализованы, то проверка элементарно делается и без всякой нормализации

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

Так вот Тестер не сравнивает напрямую. А делает это либо через NormalizeDouble, либо через ticksize, либо еще как-то. Но точно не прямым сравнением даблов. И это совсем нерационально.

 
fxsaber:

Конечно, можно и иногда даже нужно сравнивать double напрямую между собой.

Например, при Оптимизации OnTick вызывается иногда триллион раз. Штатный Тестер для того, чтобы понять, исполнять висящий лимитник или нет, делает сравнение текущей соответствующей цены символа и цены лимитника. Делает это для каждой отложки перед каждым OnTick вызовом. Т.е. таких проверок делается десятки и сотни миллиардов раз.

И делается это каждый раз через нормализацию. Так вот - это жуткое расходование вычислительных ресурсов впустую. Т.к. цены и отложенных ордеров и символа предварительно нормализованы. Поэтому могут и должны сравниваться между собой напрямую.

Не на ровном месте MQL-кастомный Тестер уделывает нативный штатный Тестер по производительности.

решил проверить бредовую версию по быстродействию.
И результат удивил. 
Сравнение даже предварительно нормализованных double происходит в среднем даже более медленее, чем если double сравнивать через эпсилон или через преобразование в int

#define  SIZE 1000000

int Ceil (double x) {return (x-(int)x>0)?(int)x+1:(int)x;}
int Round(double x) {return (x>0)?(int)(x+0.5):(int)(x-0.5);}
int Floor(double x) {return (x>0)?(int)x:((int)x-x>0)?(int)x-1:(int)x;}

bool is_equal(double d1, double d2, double e=0.000000001) {return fabs(d1-d2)<e;}

void OnStart()
  {
   double a[SIZE], a_norm[SIZE];
   int s1=0,s2=0, s3=0;
   for (int i=0;i<SIZE;i++)  {
     a[i]=(rand()-16384)/1641.1452;
     a_norm[i]=NormalizeDouble(a[i],2);
   }
   double test = 1.11;
   
   ulong t1=GetMicrosecondCount();
   for (int i=0;i<SIZE;i++) if (a_norm[i]==test) s1++;
   t1=GetMicrosecondCount()-t1;  
   
   ulong t2=GetMicrosecondCount();
   for (int i=0;i<SIZE;i++) if (is_equal(a[i],test,0.005)) s2++;
   t2=GetMicrosecondCount()-t2; 
   
   ulong t3=GetMicrosecondCount();
   int test_int = test*100;
   for (int i=0;i<SIZE;i++) if (Round(a[i]*100)==test_int) s3++;
   t3=GetMicrosecondCount()-t3; 
   
   
   Print("простое сравнение предварительно нормализированых double - " + string(t1)+ " микросекунд, всего совпадений = "+ string(s1));
   Print("сравнение double через эпсилон                           - " + string(t2)+ " микросекунд, всего совпадений = "+ string(s2));
   Print("сравнение double через преобразование в int              - " + string(t3)+ " микросекунд, всего совпадений = "+ string(s3));  
  }

Результат:

2020.08.10 14:31:39.620 TestCompareDouble (USDCAD,H4)   простое сравнение предварительно нормализированых double - 900  микросекунд, всего совпадений = 486
2020.08.10 14:31:39.620 TestCompareDouble (USDCAD,H4)   сравнение double через эпсилон                           - 723  микросекунд, всего совпадений = 486
2020.08.10 14:31:39.620 TestCompareDouble (USDCAD,H4)   сравнение double через преобразование в int              - 805  микросекунд, всего совпадений = 486
2020.08.10 14:31:42.607 TestCompareDouble (USDCAD,H4)   простое сравнение предварительно нормализированых double - 1533 микросекунд, всего совпадений = 488
2020.08.10 14:31:42.607 TestCompareDouble (USDCAD,H4)   сравнение double через эпсилон                           - 758  микросекунд, всего совпадений = 488
2020.08.10 14:31:42.607 TestCompareDouble (USDCAD,H4)   сравнение double через преобразование в int              - 790  микросекунд, всего совпадений = 488
2020.08.10 14:31:44.638 TestCompareDouble (USDCAD,H4)   простое сравнение предварительно нормализированых double - 986  микросекунд, всего совпадений = 472
2020.08.10 14:31:44.638 TestCompareDouble (USDCAD,H4)   сравнение double через эпсилон                           - 722  микросекунд, всего совпадений = 472
2020.08.10 14:31:44.638 TestCompareDouble (USDCAD,H4)   сравнение double через преобразование в int              - 834  микросекунд, всего совпадений = 472

Не исключаю, что многое зависит от новизны и архитектуры процессора, и у кого-то результат может быть другим.

ЗЫ признаться честно - даже не понимаю, почему так происходит. 
Вроде и оптимизировать при сумме случайных чисел компилятору нечего. За скобки округление не вынесешь.
Вроде сравнение double в процессоре - это одна команда
При варианте сравнения через эпсилон(самый быстрый вариант) все равно происходит операция сравнения двух double, но при этом дополнительно происходит вызов функции с передачей трех параметров и одна операция вычитания.
Неужели производительность операции сравнения двух double зависит от значений самых переменных. Сомневаюсь.
Блин, не понимаю. Помогите пожалуйста - чего я не учел или где я ошибся?

1...281528162817281828192820282128222823282428252826282728282829...3521
Новый комментарий
Причина обращения: