Which is faster - Floating-Point or Integer arithmetic? - page 3

New comment
 
nicholishen:

That's exactly what I'm doing, which is why I'm a little perplexed that you guys are treating this like a personal attack. This is a scientific discussion about the pros, cons, and specific algorithm application, and as such there should be no feelings or subjective reasoning involved. I didn't include CDouble because that was not where this conversation had veered. The OP had asked what was the best way to round doubles and the CDouble static methods would far outperform converting double to int back to double by a very wide margin.

The only time it would make sense to use the int method is in very unique scenarios where you have +4:1 operations to conversion ratio. Now this is only counting one way. On any given tick you have at the bare minimum convert the bid to int. On a valid signal, the bare-minimum is:

That's a requirement of over 20 additional operations to break-even, and we haven't even begun to talk about the overhead of converting indicator data, existing order data, etc. I can think of only a small minority of situations where that would apply. So the bottom line is this; if you have a unique situation with >4:1 (operation:conversion) and you want to take the extra time to convert the entire EA to int and back then the int method is best. Otherwise, in every other situation another method is best. 

As @Alain Verleyen stated by quoting @whroeder1's well know phrase - there seems to be "no common language to communicate" with you. You keep beating at exactly the same thing over and over, while ignoring the details that we keep providing you, dismissing them as unimportant or irrelevant to the case!

An EA does not simply read quotes and place orders. It does a great deal more which requires calculations to be carried out, and if those can be done in integer arithmetic then it certainly will be more efficient than using floating-point.

Why is it so difficult for you to understand that? It almost seems as if you have never implemented a proper, successful EA in your life, which I would like to believe is not the case!

So please, pause for a moment and consider the possibility that you might be limiting your reasoning about the situation.

 
Fernando Carreiro:

As @Alain Verleyen stated by quoting @whroeder1's well know phrase - there seems to be "no common language to communicate" with you. You keep beating at exactly the same thing over and over, while ignoring the details that we keep providing you, dismissing them as unimportant or irrelevant to the case!

An EA does not simply read quotes and place orders. It does a great deal more which requires calculations to be carried out, and if those can be done in integer arithmetic then it certainly will be more efficient than using floating-point.

Why is it so difficult for you to understand that? It almost seems as if you have never implemented a proper, successful EA in your life, which I would like to believe is not the case!

So please, pause for a moment and consider the possibility that you might be limiting your reasoning about the situation.


Fernando....buddy.... there's no need for the ad hominem commentary. I had assumed that math and science were a universal language, and have done my best to qualify and quantify each scenario. I assert, mathematically, that the only scenario that the <int> conversion rounding method is a preferred choice is >4:1. This means that for every EA that doesn't implement double to int (99%), rounding via int conversion is in fact not the best/most efficient method. That is after-all what this thread is about, rounding lots.

You and I got way off-track into MT4 back-tester optimization strategy which is specifically what this thread is not about.  You already agreed with my math so I have no idea why you are still arguing over this...

There is a time and place for the implementation of different algorithms. You certainly didn't invent using int conversion, but you act like you did and you act like I'm calling your invention crap. That is not the case. In fact I have a data structure that will greatly benefit from using int conversion. I appreciate this meeting of the minds because I learned something, and I appreciate the challenge, but if we are both being intellectually honest - we have to agree with the math.

 
nicholishen:

That's exactly what I'm doing, which is why I'm a little perplexed that you guys are treating this like a personal attack. This is a scientific discussion about the pros, cons, and specific algorithm application, and as such there should be no feelings or subjective reasoning involved. I didn't include CDouble because that was not where this conversation had veered. The OP had asked what was the best way to round doubles and the CDouble static methods would far outperform converting double to int back to double by a very wide margin.

The only time it would make sense to use the int method is in very unique scenarios where you have +4:1 operations to conversion ratio. Now this is only counting one way. On any given tick you have at the bare minimum convert the bid to int. On a valid signal, the bare-minimum is:

That's a requirement of over 20 additional operations to break-even, and we haven't even begun to talk about the overhead of converting indicator data, existing order data, etc. I can think of only a small minority of situations where that would apply. So the bottom line is this; if you have a unique situation with >4:1 (operation:conversion) and you want to take the extra time to convert the entire EA to int and back then the int method is best. Otherwise, in every other situation another method is best. 

Why keeping the CDouble outside ? This discussion is really far from the OP question, the OP didn't talk about using ints either. A scientific discussion should include all invoked options and you wrote CDouble is what you are using. The facts are : CDouble is slower than all other options, by far, and that's why you didn't include it in your test.

It seems you can't admit there are real situations where it's needed, and useful to use ints, and as Fernando said speed is not the only parameter. Yes there is an overhead due to the conversion, and yes arithmetic operation using ints are faster and more precise. How much operations are needed is unclear, from your answer I saw 3+, 4+,and 20...so what is the scientific answer ?

A scientific discussion should provide the facts only, all the facts, then let the reader decides what is better for him.

 
nicholishen: Fernando....buddy.... there's no need for the ad hominem commentary. I had assumed that math and science were a universal language, and have done my best to qualify and quantify each scenario. I assert, mathematically, that the only scenario that the <int> conversion rounding method is a preferred choice is >4:1. This means that for every EA that doesn't implement double to int (99%), rounding via int conversion is in fact not the best/most efficient method. That is after-all what this thread is about, rounding lots.

You and I got way off-track into MT4 back-tester optimization strategy which is specifically what this thread is not about.  You already agreed with my math so I have no idea why you are still arguing over this...

There is a time and place for the implementation of different algorithms. You certainly didn't invent using int conversion, but you act like you did and you act like I'm calling your invention crap. That is not the case. In fact I have a data structure that will greatly benefit from using int conversion. I appreciate this meeting of the minds because I learned something, and I appreciate the challenge, but if we are both being intellectually honest - we have to agree with the math.

I give up!
 
Alain Verleyen:

Why keeping the CDouble outside ? This discussion is really far from the OP question, the OP didn't talk about using ints either. A scientific discussion should include all invoked options and you wrote CDouble is what you are using. The facts are : CDouble is slower than all other options, by far, and that's why you didn't include it in your test.

It seems you can't admit there are real situations where it's needed, and useful to use ints, and as Fernando said speed is not the only parameter. Yes there is an overhead due to the conversion, and yes arithmetic operation using ints are faster and more precise. How much operations are needed is unclear, from your answer I saw 3+, 4+,and 20...so what is the scientific answer ?

A scientific discussion should provide the facts only, all the facts, then let the reader decides what is better for him.


CDouble is a rounding library with an optional wrapper for convenience. Use it or don't, I never claimed it was the most efficient, it's just what I use for convenience because the performance difference is so negligible it doesn't matter. Again, unlike you and Fernando, my development doesn't revolve around optimizing for the MT4 back-tester. CDouble was not apart of the debate so I have no idea why you keep bringing it up.

 
Fernando Carreiro:
I give up!

You give up what??? If my math is wrong then say so. Please stop making this a personal matter.

 
Alain Verleyen:

Why keeping the CDouble outside ? This discussion is really far from the OP question, the OP didn't talk about using ints either. A scientific discussion should include all invoked options and you wrote CDouble is what you are using. The facts are : CDouble is slower than all other options, by far, and that's why you didn't include it in your test.

It seems you can't admit there are real situations where it's needed, and useful to use ints, and as Fernando said speed is not the only parameter. Yes there is an overhead due to the conversion, and yes arithmetic operation using ints are faster and more precise. How much operations are needed is unclear, from your answer I saw 3+, 4+,and 20...so what is the scientific answer ?

A scientific discussion should provide the facts only, all the facts, then let the reader decides what is better for him.


You got me thinking that I might have been incorrect with my calculations and I realized that I was. The result of this test (MT5) are actually >100 comparisons to break-even. 

#include <Arrays\ArrayDouble.mqh>

#define N 100
void OnStart()
{
//---
  
   srand(_RandomSeed);
   int n = (int)pow(10,7);
   double pseudo_bid[4];
   pseudo_bid[0] = 1.23456;
   pseudo_bid[1] = 1.23455;
   pseudo_bid[2] = 1.23454;
   pseudo_bid[3] = 1.23453;
   
   CArrayDouble d;
   Comment(StringFormat("Reserving %d = %s",n,(string)d.Reserve(n)));

   for(int i=0;i<n;i++)
      d.Add(pseudo_bid[rand()%2]);
         
   ulong counter=0;
   ulong ms = GetMicrosecondCount();
   for(int i=0;i<n;i++)
      if(Signal1(d[i]))
         counter++;
   printf("Signal1(double) = %d ms. Counter = %d",(GetMicrosecondCount()-ms)/1000,counter);
   
   counter=0;
   ms = GetMicrosecondCount();
   for(int i=0;i<n;i++)
      if(Signal2(d[i]))
         counter++;
   printf("Signal2(int) = %d ms. Counter = %d",(GetMicrosecondCount()-ms)/1000,counter);
}
//+------------------------------------------------------------------+
bool Signal1(const double bid)
{
   static double last_bid=0.0;
   static double level[2];
   level[0] = 1.23456;
   level[1] = 1.23454;
   
   bool res = true;
   for(int i=0;i<N;i++)
      if((bid >= level[i%2]))
         res&= false;
   
   last_bid = bid;
   return res;
}

bool Signal2(const double bid)
{
   static int last_bid=0;
   static int level[2];
   level[0] = 123456;
   level[1] = 123454;
   
   int bid_int = (int)round(bid/1e-05); 
   
   bool res = true;
   for(int i=0;i<N;i++)
      if((bid_int >= level[i%2]))
         res&= false;
   last_bid = bid_int;
   return res;
}
 
nicholishen:

CDouble is a rounding library with an optional wrapper for convenience. Use it or don't, I never claimed it was the most efficient, it's just what I use for convenience because the performance difference is so negligible it doesn't matter. Again, unlike you and Fernando, my development doesn't revolve around optimizing for the MT4 back-tester. CDouble was not apart of the debate so I have no idea why you keep bringing it up.

Your first post was proposing to the OP to use your library (CDouble), so you bring it in the debate.

Your library contains a Compare method, it's not only a "rounding" library. So I don't see why it could not be included in the tests. 

The discussion is not related to MT4 backtester (this topic is in mql5 section by the way). It's about performance in all cases, and you are the one who initiated the performance discussion.

Then Fernando talked about an other method using ints, he provided results demonstrating his points.

Then you changed the tests and the discussion ! And just reject the usage of ints : "what possible scenario would this ever be implemented into practical use?", you answer was "no practical use !

Practical use ? Wasn't it a "scientific discussion" about price comparison performance ?

The tests demonstrate that if you don't have arithmetic operations to do, the best solution is :

   if(MathAbs(num1-num2) < _Point / 10.0 * 5)

If you have some arithmetic operations to do, using ints become faster after X operations (X depending of the operations).

   int res =  ((int)round(num1 / _Point) - (int)round(num2 / _Point));

Test results on MT5 build 1745 (100 arithmetic operations), method 5 is using CDouble instead of double.

1: 17749 ms for 100000000 iterations

2: 16049 ms for 100000000 iterations

3: 1972 ms for 100000000 iterations

4: 1944 ms for 100000000 iterations

5: 65246 ms for 100000000 iterations

Using ints is 8 times faster. Using CDouble is 4 times slower.

Files:
224626.mq5  4 kb
 
nicholishen: You give up what??? If my math is wrong then say so. Please stop making this a personal matter.

Need I remind you, that you were the one that hijacked this thread and started boasting your performance tests. Your assumption (or math) was incorrect so I did correct it (but you did not agree).

Until that point, no one had suggested using "ints". It was in fact the OP himself that came to that conclusion and decision, and for which I confirmed that I did  it too.

No one spoke about "ints" being faster either until you took it upon yourself to claim that they would slow things down and even started using "longs" instead.

This was never a "personal" matter, as I could care less if you or anyone else uses "ints" or not, but I felt obliged to correct your assumption (or math) of the performance claim that you made.

When I state that "I give up", it is simply a statement of rendition, because even when I do try to correct your "math", you find someway to circumvent it and claim that we are just trying to attack you on some "personal level" instead of on the facts. That certainly is not the mindset of a scientific approach.

Pardon me, but as far as I can see, you are the only one making this a "personal matter"!

So, if you don't like my "I give up" statement; maybe you will prefer this instead - Live long and prosper!

 
nicholishen:

You got me thinking that I might have been incorrect with my calculations and I realized that I was. The result of this test (MT5) are actually >100 comparisons to break-even. 

I am not sure if you do it on purpose or not, hopefully not. Your test has nothing to do with what Fernando explained.

12345678910...13
New comment