To answer the second question: TMF parameters are for numbers only. They are stored in floats and cannot hold a DATE variable in full precision.

The manual says otherwise: Also, 2-minute difference is 0.00138888. If there is any rounding involved internally, downcasting a var to a float, this shouldn't cause difference up in the 3-rd significant digit.

var are being cast to float here.

It is about 44046 days since January 1, 1900, so your date value of 44046.00138888 vs 44046.00000000 requires more significant digits than you suggest.

I meant 3rd decimal digit, sorry.

But this line:
when run in lite-C indeed shows 1:52 min difference after downcasting, but in C++ both values are exactly the same.

The difference is quite significant, how come?

Maybe your recast is incomplete in C++? Declare and initialize a float to the value, and use that instead. Then your floating precision should actually decay.

Also, significant figures are quite relevant:
https://www.geeksforgeeks.org/difference-float-double-c-cpp/

If I declare and initialize a var to a value, and then recast to float and back, I indeed see the difference. Why doesn't it happen if recasting the result of wdate()?

Hi,

is the 2.30.3 release considered to update the running Z Strategies and their parameters?

If yes, the Z7 strategy has some new PDD algorithm, which behaves strange.

This algorithm has opened and saved into „trades.csv“ long and short trades at the same minute bar with the same asset. It happened several times during the back test.

-Z7 behaves strange: it now trades 2 PDD variants with different patterns. But they should normally not trade against each other. We'll look into that.

-Zheka's TMF entered at wrong price: Caused by setting an entry stop, but entering via TMF. Set TradeEntryLimit to 0 before returning 2. This will be fixed in the next update.

Its pretty normal to have some initial Entry, but modified later in a tmf.
I actually needed a 'bracket' order, setting a limit via Entry and then adding a stop in a tmf. Which led to some 'great results' in backtesting, but failed in live.
Would be great if Zorro had a bracket order functionality out of the box.
You mean the entry price will be correct and not 1-tick earlier (without having to set TradeEntryLimit=0 before that)?

No, I meant that you can then have an entry limit and enter via TMF at the same time. Modifying limits or bracket orders have nothing to do with that.