Automatic Magic Number - page 3
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
If you weren't partially closing any orders, you could use the comment to store the originating pair/timeframe info..?
If there are two EAs on the same symbol and timeframe, how do they know which of the historic orders to pick up their respective IDs from?
All this partly depends what information one assumes is guaranteed to be available on re-start. For example, there are some people on this forum who store data along these lines in hidden objects in the chart window. That's not bad, but I'm personally scared by any mechanism which the user can break - without realising how or why.
If there are two EAs on the same symbol and timeframe, how do they know which of the orders to pick up their respective IDs from?
Damn - was that in scope for the project :D
I guess I assumed the EA (if different type or version) would have an identifier in the comments as well :)
-BB-
I can't see how this is possible without either MT4 or the user assigning an ID to each EA. Or, more accurately, I can't see anything which doesn't involve something very nasty such as generating a unique ID and then modifying the EA's .chr file to store the ID as part of the EA's extern parameters.
And, for general entertainment, the following doesn't really advance the discussion in any way, but it replaces the input to the djb2 hash with a value which is guaranteed to be unique (at the cost of requiring DLL calls). I don't know how good djb2 is meant to be on things like GUIDs, but I've just tried generating 1,000,000 IDs without any collisions. But still doesn't solve the restart issue.
I can't see how this is possible without either MT4 or the user assigning an ID to each EA. Or, more accurately, I can't see anything which doesn't involve something very nasty such as generating a unique ID and then modifying the EA's .chr file to store the ID as part of the EA's extern parameters.
>>How would the nth instance of EA p/u it's chartyy.chr file?
.
assuming an instance can actually map it's own .chr file:
if the EA source has: extern int myID = <someCompileTimeVal>;
then any instance seeing <someCompileTimeVal> can assume is 'first time' -> gen it's id -> mod myID line -> create recovery files using myID's uniqueness,...
then on restart detection access it's .chr file to p/u myID which would be master key to allow remap of files...
.
eg:
chart02.chr
<chart>
symbol=EURUSD
period=15
..
..
<expert>
name=LMT 1.8
flags=343
window_num=0
<inputs>
myID=<someCompileTimeVal>
...
</inputs>
</expert>
EOF
Help !!
.
And, for general entertainment, the following doesn't really advance the discussion in any way, but it replaces the input to the djb2 hash with a value which is guaranteed to be unique (at the cost of requiring DLL calls). I don't know how good djb2 is meant to be on things like GUIDs, but I've just tried generating 1,000,000 IDs without any collisions.
I used PsPad ed to suck in the 1mil and did a sort with remove dups ticked.
>>But... HOW did you do this "..without any collisions." detection?
"And, for general entertainment, the following doesn't really advance the discussion in any way, but it replaces the input to the djb2 hash with a value which is guaranteed to be unique (at the cost of requiring DLL calls). I don't know how good djb2 is meant to be on things like GUIDs, but I've just tried generating 1,000,000 IDs without any collisions."
.
FYI, I found collisions in my 1mil calls of the code
sorted EOF
.
sorted + dups removed EOF
>>How would the nth instance of EA p/u it's chartyy.chr file?
.
assuming an instance can actually map it's own .chr file:
if the EA source has: extern int myID = <someCompileTimeVal>;
then any instance seeing <someCompileTimeVal> can assume is 'first time' -> gen it's id -> mod myID line -> create recovery files using myID's uniqueness,...
then on restart detection access it's .chr file to p/u myID which would be master key to allow remap of files...
You're right. I'd forgotten that there's no obvious way for an EA to identify its .chr file if there are multiple EAs for the same symbol and timeframe. I was thinking that it could create a hidden label object containing something like a GUID, and then look for the .chr file which contains the correct value. However, I'm fairly sure that the .chr file isn't updated when a new object is added to the chart.
And there's another problem. I'm pretty sure that MT4 holds the information about the chart in memory, writes to the .chr file when MT4 is closed (or a change is made to the EA's properties), and this would therefore overwrite any changes which the EA itself made to the .chr file while it was running. If you were incredibly brave, you could instead try setting the extern property by simulating keypresses - calling up the properties window, moving to the requisite setting, changing it, pressing Enter etc.
FYI, I found collisions in my 1mil calls of the code
sorted EOF
On re-running it, so did I: 172 collisions in 1,000,000 attempts.
You're right. I'd forgotten that there's no obvious way for an EA to identify its .chr file if there are multiple EAs for the same symbol and timeframe. I was thinking that it could create a hidden label object containing something like a GUID, and then look for the .chr file which contains the correct value. However, I'm fairly sure that the .chr file isn't updated when a new object is added to the chart.
And there's another problem. I'm pretty sure that MT4 holds the information about the chart in memory, writes to the .chr file when MT4 is closed (or a change is made to the EA's properties), and this would therefore overwrite any changes which the EA itself made to the .chr file while it was running. If you were incredibly brave, you could instead try setting the extern property by simulating keypresses - calling up the properties window, moving to the requisite setting, changing it, pressing Enter etc.
I read above -> went off to do some exercise -> and during shower the grey cells shout OBJECT. You kill off .chr route but the two words "label object" prompted that brain outburst :)
So how about it? forgetting for moment about getting 100% waranteed ID. The other part is this recoverable state memory containing an EAs ID.
Well...
1. void vArchiveID (int iID), int iRestoreID () [and int iGetNewID () get to in another post IF this one is ok :]
2. vArchiveID() creates [hidden?] label? object onto EAs state memory chart.
The obj name MUST be same for any calling EA... so .ex4 lib or .mqh lib for (1)
3. CT goes bust or EA goes belly up etc.
4. on restart EA first job is to call iRestoreID() which rets -1 if no obj on chart or the archived ID from previous run.
5. if no ID then calls iGetNewID() then vArchiveID() and presumably sets up [for first time] dump file stuff
6. if ID 'restored' then merrily goes about recovering last state via dump files...
..
What ya think?
[...]
What ya think?
What you're suggesting is - I think - exactly what I was alluding to in my post time-stamped 14:43. The only danger with this route - and the only reason for monkeying with the .chr file directly, in order to set extern properties - is to eliminate the possibility of users accidentally deleting objects from the chart. But even that can be largely overcome by ensuring that the obejct is recreated, if necessary, in deinit().
But BB/CB may regard reliance on the .chr file as unacceptable. They might want something which can be recovered purely from data held off-site (i.e. the trade list held by the broker.)
I'd been away from this thread for a while.
Seems like we're adding some degree of complexity in order to allow recoverability with automated magic numbers yes? Ie. so a dumb piece of re-incarnated code can work out who he was in a past life when all he knows is what he is and where he is. Not necessarily a bad thing. But..
Got me thinking that it would be useful to document (very concisely):
- Criteria for deciding to implement magic numbers
- Criteria for deciding to use automated magic number generation
- Criteria for deciding to implement a persistence layer
- Criteria for deciding upon globals vs. file access for persistence
The reason I suggest this is in order to avoid everyone thinking they have to implement the kitchen sink in their EAs.
Views ?
CB
- I've only got 8 posts left before I take a break for a little while.
yes, well in end, the kitchen sink is most likely on this site, all academic. For me, first priority concern is to have a guaranteed auto[make|acquire] Expert ID. A value which can be used for many purposes.
Having a unique way to access dump files on restart is at best haphazard and in any event, requires users to adhere to a ruleset of EA usage. Many ccy+period+EA instances is not an option.
I was intent on any instance being able to determine who was I prior to restart and that is shown to be unworkable. For my part, I would not trust any user to follow even the most basic ruleset. If I cannot be totally sure of an automatic method, I'd not adopt a halfway house whereby user intervention was required.
.
Using jjc's CoCreateGuid() i/f I'm going to generate enough non-repeating numbers. Enough is subjective but I'm going for many... Coupled with one library code chunk as the resource access server function to the file holding numbers. The amount of numbers will be such that at least 2yrs can go by without ever reusing a number. At such time as EOF is reached, it just wraps around to BOF and continues serving out numbers. My finger in the sky calcs will be based on 10 requestors running 5 days per week and 50 weeks per year where each day any one requestor could require 20 new ID's. This result is then doubled. An absurd amount of numbers - basically 200,000. Yes, stone age functionality but water tight without any necessity of reliance on the terminal in any way beyond the ability to execute my code. Of course one could go on for ages about the ramifications of one, 10 or 100 files and their physical locations and access mechanisms. In the end is far better than my pityful make expert id function and is watertight regards number uniqueness for [in reality] more than 2yrs.
.
CB, 666 must be a chopper pilots lucky number? :\