double dblChange = ((double) change)/ 10000.0d;
(It's a percent calc so it should really be /100 not /10000)
I now realize, running on "1 minute tick data simulated" for this MC doesn't really make as much sense because then we are modifying every single m1 OHLC by up to x%/100 . There may also be rounding problems when an m1 bar which only moves one or two points tries to get modified by a small percent. Using evey tick precision will have even greater problems. But what if we want to make % changes to the main time-frame instead of m1 or each tick?
When running on "this timeframe only" this MC test makes more sense because now it should be literally changing the OHLC of the main timeframe by up to x% or x/100. But because of my "hack" running on "this timeframe only" is actually changing up to x%/100 or x/10000. It's way too small! The current workaround is of course to add two zeroes. For instance, if you want to change OHLC prices by up to 40% on the main timeframe then you would set the precision to "this timeframe only" and set the "max change price" variable to 4000.
I propose a change to the code as follows:
double dblChange = ((double) change)/ 100.0d;
and also perhaps a recommendation to use the "this timeframe only" precision for this test or a warning that unexpected results could happen if using higher precisions.
Status changed from New to Waiting for information
As for higher precisions - you can modify the constants in initSettings(), check the original RandomizeHistoryData snippet.
I haven't changed anything in initSettings() in this new snippet.
Cheers, Bentra
Status changed from Waiting for information to Fixed