A little surprised :) Thought I'd share and ask a NOT rhetorical question. - page 21
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
It's easy to jump from one failed statement to another.
When you have a processor with rational data types and when another set of SSExxx commands can handle them faster than double, then you can bring rational numbers to the discussion about speeding up calculations. When you publish tests of SMA calculation with different methods and show winning over double, then it will be a speech of practice.
In the meantime, the original statement about acceleration of real mathematical calculations by switching to integers has failed.
You what?! I haven't jumped ANYTHING. If you only read half of it. Alas. I've said about rational fractions about twenty times. But until I pointed out that it's fractions, no one understood. :) I'm telling you, it's funny. Alas. :(
:) Failed - I was talking about whole numbers and the concept of POINT, and a point is the denominator always. 13000 points if a point equals 10000 - then the value is = 13000/10000 = 1.3 :)
What are you doing?! I haven't jumped anywhere. If you only read half of it. I'm sorry. I've told you about rational cisterns twenty times already. But until I pointed out that it's fractions, no one understood. :) I'm telling you, it's ridiculous. Alas. :(
:) Failed - I was talking about whole numbers and the concept of POINT, and a point is the denominator always. 13000 points if a point equals 10000 - then the value is = 13000/10000 = 1.3 :)
You propose to process three 8-byte longs (integer part + denominator + numerator) instead of 8-byte double. And if you start cutting the longs into something shorter, you'll get an overflow in quite adequate calculations.
Even three ints and those are more than one take.
You propose to process three 8-byte longs (integer part + denominator + numerator) instead of 8-byte double. And if you start cutting the longs to something shorter, you will get an overflow in quite adequate calculations.
You've chosen the worst way to implement it. Given what you've told me, it doesn't add up. Which one of us knows better?
There's a number in kilometres - it's int32 And it doesn't need anything else. You just don't have to add it up with a value in another dimension. :) If you want more precision than kilometres, go to nanometers. :) And store them as a whole number. :)
TheXpert:
And secondly, I highly doubt that arithmetic with double is slower than with rational numbers.
Wapchet slower. But he provided us with wrong link.
1. The implementation in BOOST normalizes the ration numbers at each operation with them. This does not have to be done on every one, for it is expensive. Better to do it only when there is a real threat of denominator overflow.
2. Reduction to a common denominator (more precisely, the calculation of the largest common divisor) is not done there by the fastest algorithm. By far the fastest.
With correction, he's right about speed of rational numbers.
I'd have them in mql, if arithmetic operations reloading were available. Without it my syntax would be very tedious (functional), so forget about it... С++ :-)
--
But it would be really cool if there were support at the processor level...
Wapchetta slower. Only the link he gave was wrong.
1. The implementation in BOOST normalizes the ration numbers at every operation on them. You don't have to do it on every one, because it's expensive. Better to do it only when there is a real threat of denominator overflow.
2. Reduction to a common denominator (more precisely, the calculation of the largest common divisor) is not done there by the fastest algorithm. By far there is a faster one.
With that said, he's right about the speed of rati. numbers.
I'd have them in mql, if arithmetic operations reloading were available. Without it I'd get very tedious syntax (functional), so forget about it... С++ :-)
--
But it would be really cool if there were support at CPU level...
The arithmetic itself is slower because we still have to handle floating point (that's if we compare pure double and long arithmetic), if we convert doubles to integer arithmetic we lose. Recurrent NOD calculation alone would require log(N) operations, not to mention the fact that each multiplication operation would require if to check for overflow. Then 4 more divisions (two by NOD and to extract integer part and fractional remainder).
On top of that, you'd still need to allocate more memory to store all this nonsense than you'd need for the take.
Wapchet slower. Only the link he cited was unfortunate.
Proof? You're certainly more authoritative in my eyes than the original writer, but that's a strong statement.
Therefore I would like to see comparative tests.
The arithmetic itself is slower because it still has to handle the floating point (that's if you compare pure double and long arithmetic),
1. If you convert the doubles to integer arithmetic, you lose.
2. the recurrent NOD calculation alone would require log(N) operations, not to mention the fact that
3. Each multiplication operation will require if to check for overflow.
4. Then 4 more divisions (two by NOD and to extract integer part and fractional remainder).
5. Plus on top of all this you will still need to allocate more memory to store all this nonsense than you need for the take.
1. this is a one-time operation for each take. The loss is insignificant, then the gains are solid. :) I assume the original quotient is logarithmed once and converted to integer representation.
2. this is correct. Although it's fast, because there is a fast algorithm that uses bit shifts.
3. no more than overflow checks.
4. the integer part does not need to be allocated at all. the fraction is stored as a pair of longs. and if possible, as a pair of ints.
5. Exactly the same amount if stored as a pair of longs, and half as much in the case where there are enough ints (it depends on the algorithm's requirements).
If we consider that the main memory consumer is a quote, then with integer representation the gain in space is undeniable.
While the main point is not in memory saving, but in acceleration. This is much more important.
--
The problem with Academician is not that he is wrong. It's that he's making others look wrong.
That's what irritates those present and rejects healthy ideas... Along with the dirty water... :(
Therefore, I would like to see comparative tests.
I'll give it a try. On mql5, if it comes to that... :)
I just need some time. I would have to write a library.
I'll give it a try. In mql5, if it comes to that... :)
What for? C++ is accepted.
The problem with the academic is not that he is wrong. It's that he's making others look wrong.
The problem is that he thinks he is smarter than others and constantly tries to make a fool of someone else.
And he screws up. In some places, a lot.
The problem with the academic is not that he is wrong. It's that he makes others look wrong.
This is what irritates those present and rejects healthy ideas... Along with the dirty water... :(
I don't get in anyone's head. But I am inverted. :) Who's been calling for advice on "should I go with the theme?" :)
And then I'm the one who's the one who's the one... :) Well, don't come to me.
What's the difference in general? What's there to discuss? IMHO - everything remains at the same embryonic level as it was. So there's no problem with me - it's like I don't exist. :)