Scripts: TickCompressor - page 2

[Stanislav Korotky]

Dark Ryd3r #:
Can it be used for MQLRates too?

No. Besides I think there is no need to compress rates.

[Dark Ryd3r]

Stanislav Korotky #:

No. Besides I think there is no need to compress rates.

i tried. its working

There is need to compress rates because i receive them live from websocket instead of tick

https://www.mql5.com/en/code/38047

[Stanislav Korotky]

Dark Ryd3r #:

i tried. its working

There is need to compress rates because i receive them live from websocket instead of tick

https://www.mql5.com/en/code/38047

Actually, this is another script you crafted yourself, not the tick compressor ;-)

[amrali]

Conversions between double and float DO NOT round-trip, the original ticks will not recovered after decompression.

#include "TickCompressor.mqh"

void OnStart()
  {
   int fails = 0;
   int count = 1000;

// the original ticks
   MqlTick ticks[];
   int copied = CopyTicks(_Symbol,ticks,COPY_TICKS_ALL,0,count);

// compressed ticks
   MqlTickBidAsk tba[];
   TickCompressor::compress(ticks, tba);

// recovered ticks
   MqlTick result[];
   TickCompressor::decompress(tba, result);

   for(int i = 0; i < copied && !IsStopped(); i++)
     {
      // If the original ticks cannot be recovered, this confirms the bug.
      if(result[i].bid != ticks[i].bid
         || result[i].ask != ticks[i].ask)
         fails++;
     }

   printf("Tested %d values",copied);
   printf("TickCompressor failures: %d",fails);
  }

// Tested 1000 values
// TickCompressor failures: 1000

[Stanislav Korotky]

amrali #:

Conversions between double and float DO NOT round-trip, the original ticks will not recovered after decompression.

It depends on price values. This was already discussed above.

Forum on trading, automated trading systems and testing trading strategies

Scripts: TickCompressor

Stanislav Korotky, 2021.03.27 22:44

Yes, this is inevitable side-effect of the compression, based on type size reduction. A citation:

Float values have between 6 and 9 digits of precision, with most float values having at least 7 significant digits. Double values have between 15 and 18 digits of precision, with most double values having at least 16 significant digits 

So, you can't expect from float to restore prices with more than 7 significant digits exactly.

[amrali]

Stanislav Korotky #:

It depends on price values. This was already discussed above.

So, you can't expect from float to restore prices with more than 7 significant digits exactly.

mmm, the prices that I compressed were the terminal prices (3 or 5 digits max).

To demonstrate it better:

void OnStart()
  {
   double price = 1.12345;
   float  packed = (float)price;
   double unpacked = (double)packed;

   Print(price);
   Print(unpacked);
  }

// Output:
// 1.12345
// 1.1234500408172607

So, float type cannot be used to pack / restore prices with 5 or less digits that were originally encoded in double-precision. This conversion causes unrecoverable loss of the mantissa bits.

Edit:

For simple calculations on prices, that may not make much difference at the end.

Thanks Stanislav.

[Stanislav Korotky]

amrali #:

mmm, the prices that I compressed were the terminal prices (3 or 5 digits max).

To demonstrate it better:

So, float type cannot be used to pack / restore prices with 5 or less digits that were originally encoded in double-precision. This conversion causes unrecoverable loss of the mantissa bits.

Edit:

For simple calculations on prices, that may not make much difference at the end.

Thanks Stanislav.

In your example, the restored price normalized to number of digits in price is equal to original value (I hope you do not compare doubles with simple '==' operator? this is a wrong approach).

What you're talking about is the fact that all floating point numbers (including double) are stored with limited precision, so even with double you can get incorrect price after simple arithmetic calculations.

There is no such thing like decimal numeric type (with fixed precision) in MQL5.

[amrali]

Stanislav Korotky #:

In your example, the restored price normalized to number of digits in price is equal to original value (I hope you do not compare doubles with simple '==' operator? this is a wrong approach).

What you're talking about is the fact that all floating point numbers (including double) are stored with limited precision, so even with double you can get incorrect price after simple arithmetic calculations.

There is no such thing like decimal numeric type (with fixed precision) in MQL5.

Thanks for the clarification.