Testing 'CopyTicks' - page 23
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
It is optimal to download what you need to deep down to yourself once, and then only download new ones from the nearby cache in microseconds.
If you make deep queries every time with failing to disk, then of course it's your own fault.
Can you show me the code for the best way to get the tick history for the first week of September?
Write it yourself, it's not a difficult task.
Query the exact dates and save them to a local array. There is no optimality when working outside the cache. Optimization only makes sense when you download the last 4096 ticks from the cache.
Write it yourself, it's not a difficult task.
Do a query on the exact dates and store in a local array.
This way you cannot know in advance how many ticks there were on the required interval. There is no way to determine the count parameter. Here is the problem.
To pump out ALL the history since the beginning of September, setting count = trillion - you can, of course. Then use binary search to find the end date in the array and truncate.
But this trilliard is not a technical approach at all. Either we need to overload the function with from, to. Or index access to the database.
Optimisation only makes sense when downloading the last 4096 ticks from the cache.
From reference:
Speed output: the terminal stores for each symbol 4096 last ticks in cache for quick access (for symbols with running stack - 65536 ticks)
We will prepare improvements to CopyTicks in the next build:
We will prepare improvements to CopyTicks in the next build:
Thank you!
About fully loaded history from & to, probably, will say zero GetLastError.
Note that now (and with the introduction of the improvements you've outlined) it's extremely difficult to get a tick that was before the from time. Therefore, I propose to make count and negative - a request of ticks not only to future (to the right), but also to past (as at from == 0).
Then it will always be convenient and optimal (your implementation) to query the previous history.
Thank you!
A fully downloaded history from & to would probably be indicated by a zero GetLastError.
Note that now (and with the introduction of the improvements you indicated) it is extremely difficult to get a tick that was before the from time. Therefore, I propose to make count and negative - a request of ticks not only to future (to the right), but also to past (as at from == 0).
Then it will always be convenient and optimal (your implementation) to query the previous history.
It's better to make CopyTicks() overloads the same as for other Copy...() functions.
Then we have to abandon the default count and from.
Why? Using CopyBuffer as an example, we now have this:
intindicator_handle,// indicator handle
intbuffer_num,// buffer number of the indicator
datetimestart_time,//date
intcount,// how manycopy
doublebuffer[]// array, where the data will be copied
);
There is a count and from (start_time).
You suggest to add this:
intindicator_handle,// indicator handle
intbuffer_num,// indicator buffer number
datetimestart_time,// from which date
datetimestop_time,// till what date
doublebuffer[]// array, where the data will be copied
);
So we can copy in both directions, right? Only, instead of datetime - ulong (in microseconds).
I will add this overloading for some other purposes in future:
intCopyBuffer(
intindicator_handle,// indicator handle
intbuffer_num,// indicator buffer number
intstart_pos,//where we start
intcount,// how many we copy
doublebuffer[]// array that will copy data
);
That's all.
Then we will have to abandon default count and from.
Didn't read it carefully at first... Yes, I have to. So what? If developers will expand cache - it will be slower only when loading big enough tick history, and often it's not necessary to do. And for real time loading won't be affected in any way (will be taken from cache).
I think it's much more important to load from date to date, than to try to save the default parameters.