[ARCHIVE]Any rookie question, so as not to clutter up the forum. Professionals, don't pass it by. Can't go anywhere without you - 5. - page 389
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
Unfortunately, the 1minutes are gone again altogether, only there on the chart, and in the logbook it's scribbling every tenth of a second:
15:55:39 Memory handler: cannot allocate 206924212 bytes of memory
15:55:39 HistoryBase: not enough memory 'EURUSD1' [4702734 bars]
15:55:39 Memory handler: cannot allocate 206924212 bytes of memory
15:55:39 HistoryBase: not enough memory 'EURUSD1' [4702734 bars]
15:55:39 Memory handler: cannot allocate 206924212 bytes of memory
15:55:39 HistoryBase: not enough memory 'EURUSD1' [4702734 bars]
500й!
Testing from the 168th century BC? :)
Testing from the 168th century BC? :)
1) Problem : each script (EA) must be aware of the presence of all the others.
2) Problem : if there is a failure, the globals from the failed one will hang unoccupied and the queue will get stuck.
3) Solution :
Each exp organizes 1 globalka with name - common prefix + window handle + symbol. value of the globalka is the time of last tick on that instrument. 2 common global with its own handle (after working it writes its own handle into it or clears it if it is the oldest)
The queue is arranged in ascending order (handles), the most senior sets the second globale to zero
in each exp, we create three arrays (for lack of structures) - symbol/handle/last access time/last tick time.
all EXPs keep track of (last access time/last tick time) for all of them and as soon as they are different (one of EXPs fails) both globals of the failed EXP are deleted and it is considered inactive. its cells in the arrays are deleted (the array is rebuilt).
queue is restored
this will actually be done by the EA standing on the most active chart (frequent ticks).
when deinitialized normally, each expo will clean up after itself.
max skip - one tick.
ZS. and in general it's better to make one multicurrency
That's roughly what I have done for AIASM complex, to be able to run multiple instances, but it's all in a DLL. This DLL is unloadable.
Of course, we should make one EA for trading to avoid troubles with synchronization.
Will it be correct?
I am not good at English, if something is wrong, please excuse me. We obtain the speed in pips per minute and the acceleration in pips per minute. Or am I wrong?
Oh, I forgot to explain. Since Δt=1, I didn't divide by one, I thought that was clear.
Yes, it's always one, because the other thing is that if you work not with M1 TF, but with ticks, then yes - from bin to bin Δt will be variable.I think I understand. MACD is a delta of two averages, so the velocity will be average, not true. One may perceive it as an attempt to introduce the SI system into the analysis in order to systematise it and make it more comprehensible.
Why did you mention MACD right away? It jumped right over without explaining it. The approach must immediately be scientific. I.e. without analysis/synthesis you cannot. There is no point in dealing with the price it is too complex. You can't just analyse it like that. A spectral analysis is needed. I.e. decomposition into simpler components. The simplest component is a sine wave.
What will we get if we take the derivative of the price (after all, the price itself is already the time price velocity)? What do we get? It is hardly usable.
What do we get if we take the derivative of the sine? Cosine, of course. I.e. we get the lead of 90 degrees.
Anyway, MACD is one of the most important built-in indicators. It is a band-pass filter. It shows the rate of the average price of a small period relative to the spectral slice, which is determined by a larger period. The interest lies in the set of such continuous slices. That is, the spectrum. Of course, then synthesis... If you have eyes, you can see a lot of interesting things in the picture.
I might be a little disappointed. The filtering methods that are included are nowhere near good enough. It's a complete misunderstanding, not filters. You need proper filters with steep fronts.
Junko, you're a d-i-B*&*%#o^i=d. How could you get so stupid? You don't even have the brains to understand the problem. It's no use even talking to you. You don't get it at all. But the position you take ... like you know and understand everything, but you do not know and do not understand anything, coding at the level of a nubo-lamer kindergartener. And your understanding of everything is at the same level. But your ego...
Junko, they even explain it to you and you don't even get it, it's like brain paralysis.
You haven't even attempted to tell me about your thread merger thing. Everything I've read from you before is a flawed algorithm. No point in wasting your time on it.
It also seems to me that you are unable to find common resources and that is why you are slowing down the threads. This is the wrong approach. Flows cannot be slowed down and queued. This is also a rule. You should allocate a common resource or resources and arrange synchronous access to them with minimal access time. Let me remind you that organization of atomic access is synchronization. Otherwise you are getting annoyed every time.
You're one to talk. I've seen your code... It's like kindergarten... :-((
Zhunko:
Emotions again? Work on your psyche. Told you what exercises to do. Practice them.You haven't made any attempt yet to talk about your thread-combining fiddle. Everything I've read from you before is a flawed algorithm. There is no point in wasting your time on it.
It also seems to me that you are unable to find common resources and that is why you are slowing down the threads. This is the wrong approach. Flows cannot be slowed down and queued. This is also a rule. You should allocate a shared resource or resources and arrange synchronous access to them with minimal access time. Let me remind you that organization of atomic access is synchronization. Otherwise you are getting annoyed every time.
You're one to talk. I've seen your code... It's like kindergarten... :-((
Go see a doctor, get your delusions of grandeur treated.
If I don't, go ahead and do your amateur cycling.
I don't have a problem with merging threads. Try to reread it again, maybe you'll get it, though it's unlikely. You are messing with threads because you don't realize that you still don't have enough atomic access. It's the second day and you still can't get it.
You also think... You're not imagining things, you're delusional.
Once again, providing atomic access is not providing a queue. You're totally jammed, alley!
Stop acting like a guru!
Go and see a doctor and get your delusions of grandeur treated, you fucking underachiever.
If I don't tell you, go back to your amateur cycling.
I don't have a problem with merging threads. Try rereading it again, maybe you'll get it, though it's unlikely.
You also think... You're not imagining things, but you're delirious.
Let me remind you once again - providing atomic access is not a queue. You're totally jammed, alley!
Stop acting like a guru!
I've understood long ago that atomic access doesn't provide your queue :-)). But it does provide a queue, as the system will use it. That's enough for synchronisation.
You should write in such a way, that the order of queue processing is not important.
You're one to talk. Saw your code... It's kindergarten... :-((
Once again a big round of applause! Congratulations on another glitch. This code has not been published anywhere.
I figured out long ago that atomic access doesn't provide your queue :-)) But it does provide a queue, as the system will post it. It's enough for synchronization.
You should write it in such a way, that the order of queue processing is not important.
You do not provide it either, just do not understand it.
That atomic access doesn't provide your queue, I figured it out a long time ago :-)) But it does provide a queue, as the system will post it. It's enough for synchronization.
You should write it so that the order of queue processing is unimportant.
You really have a brain paralysis, or lack of some part of it. We've already said that the system doesn't know which thread was really processed and which was idle. But you're the only one who doesn't get what you're talking about and won't))))))))
Besides, judging by your messages you have a problem of providing shared access to one resource and consecutive processing of several threads.
You don't have it either, only you can't figure it out.
Look at the log. It's all processed.
Look it up yourself, but apparently not by sight. Consistency is provided purely by chance from the fact that the processor has a high speed and from the fact that it's running a bunch of other Windows tasks in parallel.
Just looking at that log is where I started.