Disliked{quote} I got the same errors some time ago. Try this : Error 1 => i found that this is not missing of database, but there was mql error at my scripts . try to print out the error message at some points of your script to catch where is actually the problem exist Error 5 => you tried to access database with different access type (Select/Delete/Update) at the same time. I got this problem as i tried to UPDATE data i got from SELECT query. Solution : i used "sqlite_free_query (handle); " before i call Update query ...Ignored
Fractals, ZZ & the Pissing Dog
- #791
- Jul 15, 2014 7:12pm Jul 15, 2014 7:12pm
{quote} Thanks for pointing these posts elen. I try to make changes to smallcat's indicator at post #1. Still trying to build historical data (csv) based on this, will post the result later .... edit: I use MT4 standard Zigzag & fractal indicator, not the "custome Zigzag" that smallcat used. {image} {file}
Why you "add" a fractal at zz end using indicator (not in your algo), while GG, Carl and others do not do it, they just assume there is a fractal there (including zero fractal), and make calculation about it in their algo ....
At realtime, fractal is late (2 bars late - and if we do calculation at the beginning of the each bar, then it will be 3 bars late ...), and we are trying to predict where fractal will appear (zz end point), BEFORE it is really appear .....
Before i got answer from Carl, i had the same thought with you, but I re-read the thread again, and make a note on these ....
Hm .... i need much more time to re-read this and old thread .....
At post #786 :
{quote} elen,For the historical building of the database, you should never "ADD" any fractals. Zigzags will ALWAYS start with a fractal and end with a fractal... PERIOD. I don't care what MT4 shows you. The MT4 fractal indicator is sometimes wrong, especially when two bars have the same high/low price.For real-time analysis for your zigzags: in real-time, zigzags may re-paint highs or lows. So GG says, if you have a high zigzag indicated, his algorithm will not consider it a confirmed zigzag until lower HIGH fractal has occurred.Carl
{quote} jackprobe, You cannot wait for your first fractal (real-time)... it would be 2 bars late. If you have a completed bottom zigzag (or signal), you must tell your algo that there is a "1" fractal. See, your database contains completed zigzags with at least one fractal. So if, in real-time, you don't have any fractals, you have to fool the algo into thinking that there is a fractal. Then, if length matches, you go on into the "next bar" probability. Carl
At post #671 :
{quote} Mr_You, My algo does not relies on ZZ end-point at all. Only case that I look for ZZ and its "confirming" fractal are in cases where swing predicted mark (arrow) is much different from "real" ZZ mark AND the current leg is not finished its predicted next mark. In those case the mark (arrow) stays where it was but predictions starts over from actual ZZ end-point. If the "error" prediction occurs after the new leg is already marked, the algo simply continues as is. G.
Guys, To answer, directly and indirectly, many related questions & PM's: At the end of each ZZ leg there is a fractal. We start counting the first fractal AFTER that one (not including the fractal at the end of previous leg). Our historical database INCLUDES the last fractal in its next ZZ fractal pattern. So, our search for "next bar in opposite direction" should include one more fractal that didn't reveal itself in real-time. Does that makes sense? Ahhha factor? ;-} G. EDIT: To elaborate - if probabilities shows pattern of 4 fractals and you already...
{quote} Hallo Pedma, Why you "add" a fractal at zz end using indicator (not in your algo), while GG, Carl and others do not do it, they just assume there is a fractal there (including zero fractal), and make calculation about it in their algo .... At realtime, fractal is late (2 bars late - and if we do calculation at the beginning of the each bar, then it will be 3 bars late ...), and we are trying to predict where fractal will appear (zz end point), BEFORE it is really appear ..... Before i got answer from Carl, i had the same thought with you,...
Simple ... i just try to create as much information as possible through this indicator, this will save my time on creating historical database ....
I know that this indicator is for HISTORICAL purposes only (it will lag about 3 candles, not for real time using). For real time zz end point prediction or simulation (year 2013), it must be done via algo ..... but at least i can save time, and it is easier for me to check the accurate data for my database.
Honestly, nothing special actually ...
Good friends are more valuable than gold ...
- #797
- Jul 28, 2014 4:24pm Jul 28, 2014 4:24pm
I'm still working on it. Did think long and hard, devised a new approach, implementation is next, we'll see how it's going to turn out. Before that let me show to those who's interested a few pics of length normalization results. It made so much sense to me, but after seeing the chart... 
Very similar to standard length results.
Very similar to standard length results.
- #798
- Jul 29, 2014 1:33pm Jul 29, 2014 1:33pm
I'm still working on it. Did think long and hard, devised a new approach, implementation is next, we'll see how it's going to turn out. Before that let me show to those who's interested a few pics of length normalization results. It made so much sense to me, but after seeing the chart...
How do you make your dll to connect to database? Can you give me link how to create that dll?
Thanks
Similarity can change your life !
- #799
- Jul 29, 2014 4:51pm Jul 29, 2014 4:51pm
{quote} Hi candero, How do you make your dll to connect to database? Can you give me link how to create that dll? Thanks
I'm using no dll's, the algo is pure brainchild of mine, indi by Candero
so to speak.
- #800
- Jul 29, 2014 8:45pm Jul 29, 2014 8:45pm
{quote} Dll what?
Similarity can change your life !