Canvas is cool! - page 17
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
Morphometric analysis - analysis of killed cells. First we kill them, then we put them under the microscope.
Morphometrics (Greek: morphe form + ...metry)
That's it. Enough of this cluttering up the subject.
Double int is twice as fast as double
You don't realise the scale and you're not doing the tests correctly in microsynthetics, not considering the implications of running not 30 assembly functions but an array of 50k-100k instructions.
Refute every point I made above in my original reply.
You don't realise the scale and are incorrectly running tests in microsynthetics, not considering the consequences of running not 30 assembler functions but an array of 50k-100k instructions.
Refute each of my points above in your original reply.
Refuted that point (albeit with primitive actions on every tick)
Forum on trading, automated trading systems and trading strategy testing
Canvas is awesome!
Renat Fatkhullin, 2019.01.15 22:37
Taking into account 64 bit code and our compiler we must forget about integer in task class based on double calculations...
The tester is based on double calculations. And there are so many of them on every tick that even an empty run goes at 7 million ticks per second.
You may write a simulator with more complicated actions on each tick. But the basis of the Tester is the comparison of the current tick price with the order price, which makes the codes higher. This assertion is not made out of a vacuum. I have posted reproducible measurements and calculation alternatives in the public domain.
Disproved this point (albeit by primitive actions on each tick)
The tester is based on double calculations. And there are so many of them on each tick that even an empty run goes at a rate of 7 million ticks per second.
It's possible to write a simulator with more complicated actions on every tick. But the basis of the Tester is comparing the current tick price with the order price, which is what makes the codes roughly higher.
Refute this:
Every point, please.
Keep in mind that even one point 4 or 5 is enough to merge the idea of integer acceleration.
I'm not talking about the fact that the tester is not for(i=0;i<limit;i++ ) { }
But I can also point out that one cannot hope to preserve the results of local microcode optimization in integer operations. Sometimes it is enough to add a harmless string into a loop and lose speed by tens of percents. And if you turn to real tasks when the code is bloated with real work, all the comparisons go to hell there.
Refute this:
Every point, please.
Bear in mind that even one point 4 or 5 is enough to merge the idea of integer acceleration.
The aim was to show that there are problems that can still be solved in integers in order to speed up. A Tester like this is not universal, as it doesn't fit at least point 5.
As for the first four points, the problems are far-fetched. Since the speed of the Tester is only needed during Optimisation. It's only converting ticks once for the whole bunch of passes.
The aim was to show that there are problems which can still be solved in integers in order to speed up. Such a Tester is not universal, as it does not fit at least point 5.
As for the first four points, the problems are far-fetched. Since the speed of the Tester is only needed during Optimisation. It converts ticks only once for the whole bunch of passes.
That is, neither points 4 nor 5 are refuted.
And even the conversion you want to save, which immediately increases the time cost by several times. Yes, at times, including the conversion memory. I thought you were suggesting that the entire platform should be converted to int64 prices to get rid of conversions.
Even theoretically there is no profit from migration to int for 10 years already.I'm not talking about how a tester is not for(i=0;i<limit;i++ ) { }
If it's about a tester without a timer, it's proven that a tester is for by ticks.
If it's about a tester without a timer, it's proven that a tester is for ticks.
This is not a tester, but a fake one. Without indicators, without profits or anything at all. But with a constant risk of integer overflow.
It does not even make sense to discuss it.
And again:
But I can also point out that you can't hope to save local microcode optimization results in integer operations.
Sometimes it is enough to add a harmless string into a loop and lose tens of percent of speed. And if you turn to real tasks when the code swells with real work, all the comparisons go to hell there.
So neither point 4 nor 5 is refuted.
And you even want to save the conversion, which immediately multiplies the time spent. Yes, at times, including the conversion memory. I thought you were suggesting to switch the whole platform to int64 prices to get rid of conversions.
It seems to be a misunderstanding of what I was talking about. I was talking about an example of a private Tester problem, where integer prices can give a gain in certain situations. The universal case was not in mind. That's why my Tester, to which I gave a link above, is implemented on dubs, since it's universal.
Even theoretically there is no gain from going to int for 10 years now.
Can't agree 100% of the time.
It's not a tester, it's a knock-off. With no indicators, no profits, and nothing at all. But with a constant risk of integer overflow.
This is an add-on for your tester, which makes a full pass with all trades and profits, without any changes in the code of any Expert Advisor (with any indicators). But it does it faster than the regular Tester. All reproducible proofs have been given. People from the resource have verified these assertions.