A little surprised :) Thought I'd share and ask a NOT rhetorical question. - page 22

New comment
 
MetaDriver:

1. this is a one-off operation for each take. The loss is insignificant, then solid gains. :) I assume that 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... :(

Vladimir, aren't you confused? What you have described is low-level arithmetic double and fleet, the same arithmetic that "Academician" proposes to introduce requires (even without allocation of a whole part) at least two mantis for storage.

Well, where's the economy in that? 8 bytes for the double and 2*4 bytes for the int.

At best you will come to the result that is already implemented.

 
Urain:

Vladimir, aren't you confused? What you described is a low-level arithmetic of double and fleet, the same arithmetic that "Akademik" proposes to introduce requires (even without the allocation of an integer part) at least two mantis for storage.

So where's the saving in that. 8 bytes for the double and 2*4 bytes for the int.

At best you will come to the result that is already implemented.

So store all the points ( denominators) of one-dimensional quantities in the same place - they are the same. :)

Create a type - a value in one tenth of a point and that's it. And store this denominator separately.

 
MetaDriver:

I'll try it. On mql5, if you want... :)

I just need time. I will have to write a library.

I tried it once, there's no candy, it's just a waste of time.

Decompose the double into a binary number, and represent it as two ints and you will realize that everything you describe is already implemented in double arithmetic.

Only arithmetic is implemented at a low level, and you'll do it at a higher level, so you will lose performance and memory.

 

My five cents.

Whole numbers are a more natural way of presenting quote information. After all, it is impossible for a number of points not to be an integer. Storing such numbers is more economical, and therefore the download speed at the disk-memory and memory-processor levels is higher. Algorithms are much faster than real number algorithms, and SSE batch operations are out of competition. But, there is a big problem with integers - only counting people can work with them. And of course, the terminal must have asm support. For the mass consumer MQ these numbers are not suitable.


By the way, the problem of overflow checking is implemented at the hardware interrupts level, there's nothing wrong with it, on the contrary, people thought about it long ago when processors were created. In principle there is a lot of ways and tricks of programming of integer algorithms, but all this, I repeat, is not for mass user.


I don't see what the argument is about. Can you create a faster testing/optimization algorithm than you have in the tester? You can, but it won't be a universal algorithm that will live in a greenhouse in the presence of the author - very few people need such a thing - it's not a mass product. For this reason, statements in the spirit of "mine is faster" can only be seen as evidence of incomparability and lack of understanding of the fact that you can't compare incomparable.

 
Urain:

I tried it once, there's no candy, it's just a waste of time.

Decompose the double into a binary number, and represent it as two ints and you will realize that everything you describe is already implemented in double arithmetic.

ZZY Only arithmetic is implemented at a low level, and you'll do it at a higher level, where you'll lose performance and memory.

"If I don't catch up, I'll keep warm", as the cock chasing the hen used to say... :)

In fact, I've been thinking about it for a long time, it's probably time to give it a try.

 
MetaDriver:

"If I don't catch up, I'll keep warm", as the rooster said, chasing the hen... :)

In fact, I've been thinking about it for a while now, so I think it's time to give it a try.

Recursive NOD algorithm to give?
 
TheXpert:

What for? C++ is accepted.

I'll have a look. I have to feel it first. I'm curious about it myself.
 
Urain:
Do you want a recursive NOD algorithm?
If with bit shifts, go ahead. If with modulo division, don't.
 
MetaDriver:
If it's with bit shifts, go ahead. If with division by modulo, then don't.

Are you going to divide one (not necessarily a multiple of 2) number by another (not necessarily a multiple of 2) number using a bit shift?

Okay, I'll throw in what I've got, and then you can decide for yourself whether you need it or not.

//+------------------------------------------------------------------+
long GreatestCommonDivisor(long v0,long v1)
  {
   return(GCD(fmax(fabs(v0),fabs(v1)),fmin(fabs(v0),fabs(v1))));
  }
//+------------------------------------------------------------------+
long GCD(long max,long min)
  {
   if(min>0)return(GCD(min,max%min));
   else return(max);
  }
//+------------------------------------------------------------------+
 
DDFedor:
The smiley faces in your future posts will be cut out. Keep that in mind.

Thanks for admitting it - you cut emoticons, but who deletes whole posts?

On a side note, Academic, I think it's great that you have a so-called "calculator", but i would like to ask whether you can automatically optimise it during trading?

1...1516171819202122232425
New comment