GeniusTrader

Aurimas wrote:
> My support and resistance is based also on trendlines (horizontal only),
> except converted to "indicator" to make better sense using it.
> http://stockcharts.com/school/doku.php?id=chart_school:chart_analysis:support_and_resistan
> 
> also I have read "The Turtle Way" and "How to make money in stocks"
> 
> I found the problem why the support didn't become secondary resistance. But
> I need your help determining if there's anything in Support1 or Support2 ...

task 1 -- look at contents of the prior value stores

ok -- i have to ask

how are you using this perl code bit. the '<STDIN>;' just mystifies me.

if ( $debug ) {
  print STDERR "Resistance is:\t$resistance\n";
  print STDERR "Support is:\t$support\n\n";
  print STDERR "Resists1 are: @resists1\t\t\t";
  print STDERR "Resists2 are: @resists2\n";
  print STDERR "Supports1 are: @supports1\t\t\t";
  print STDERR "Supports2 are: @supports2\n";
	<STDIN>;
}


> I tried using defined but it seems to be working for some other purpose, if
> I try to use (Supports1[0]) then it goes with "uninitialized" messages.
> wouldn't the $num = @supports1; have the uninitialized messages? (just now
> thought about it)
> 
> Anyway, I have attached 2 indicator versions: with calculate only and with
> calculate_interval  because EVEN though I have compared the codes line by
> line there seem to be huge differences between the 2, sometimes SnR_c
> (calculate) goes crazy like in the graph I have attached.

yes. this is a known side-effect with indicators that differ in terms
of calculation when done time period by time period (calculate) versus
done a one time within a loop from $start to $end (calculate_interval).

unfortunately it sometimes isn't even the 'code under development' that
is the problem, but a dependent indicator that's causing the problem.
unfortunately there isn't a good recipe that can be easily demonstrated
how to isolate the problem. time consuming, eye-straining comparison of
 print STDERR Dumper outputs
and a lot of head-ache producing thinking 'what is going on' is the way
i think about it. and the masochist in me just said 'i'll have a look'.

> 
> *"if you agree then you need to have a past value store that
> is ordered by time and level -- you don't really care (thinking out-loud)
> if the prior value was a support or resistance -- just that it
> was the highest most recent level below the current low, for
> a support value. in the case of a resistance value, that it
> was the lowest most recent level above the current high.*"
> 
> I think what you are saying here doesn't go along with a principle that a
> resistance that becomes support because it is crossed can't be used 10 times
> - once it is crossed again - it is deleted. That's what my code does.

humm -- ok. i was just commenting on the one area of the jpm sample plot.
i've yet to read the 'theory' behind horizontal support and resistance, but
still seems to me that 'most recent past time' and 'most recent past level'
must be both evaluated when determining a new lower support or new higher resistance.

> 
> Can you send me the trendlines indicators? As far as I can recall you only
> sent me the Resistance, and was it the same one?

humm -- no, that would require you to install my complete gt source tree and
that is not something you want to undertake if there are already time pressures.

> 
> Damn it, I'm almost out of time:( but I think it's not really about my
> research: the support and resistance indicators could be a good addition to
> GTrader. I would really like to have contributed to Open source code base of
> GT
> 

agreed. what is your major? are you a computer science type, mathematician,
economist or ? can you share an abstract of your research?

< snip >

Aurimas wrote:
<snip>
> Anyway, I have attached 2 indicator versions: with calculate only and with
> calculate_interval  because EVEN though I have compared the codes line by
> line there seem to be huge differences between the 2, sometimes SnR_c
> (calculate) goes crazy like in the graph I have attached.
> 

while perl, the language, would arguably be better with a switch (or case)
control structure it doesn't. but adding it via the perl package is out-of-scope
unless that package is on (or in) the perl prerequisite list. Switch.pm isn't
there for gt. besides it's easy enough to code:

my first cut for

# 		switch ((defined $resists1[0]) + (defined $resists2[0])) {
# 			case 2	{$resistance = ($resists1[0] < $resists2[0]) ? $resists1[0] : $resists2[0];print STDERR "Both are defined\n";}
# 			case 1	{$resistance = ($resists1[0]) ? $resists1[0] : $resists2[0];print STDERR "One is defined\n";}
# 			case 0	{$resistance = $price_r*1.1;print STDERR "10% up price:$resistance\n" if $debug;}
# 		};

is
	if ( defined $resists1[0] && defined $resists2[0] ) {
            # case 2
            $resistance = ( $resists1[0] < $resists2[0] ) ? $resists1[0] : $resists2[0];
            print STDERR "Both are defined\n" if $debug;
        } elsif ( defined $resists1[0] || defined $resists2[0] ) {
            # case 1
            $resistance = ( defined $resists1[0] ) ? $resists1[0] : $resists2[0];
            print STDERR "One is defined\n" if $debug;
        } else {
            # case 0
            $resistance = $price_r * 1.1;
            print STDERR "10% up price:$resistance\n" if $debug;
        }

but now that i understand how switch ... case works i might be inclinded to do
        SWX: { my $case = ( defined $resists1[0] ) + ( defined $resists2[0] );
           if ( $case == 2 ) { ... ; last SWX; }
           if ( $case == 1 ) { ... ; last SWX; }
           if ( $case == 0 ) { ... ; last SWX; }
        } # end SWX


<snip>

ras

Aurimas

what is the symbol(s) for the two chart images?

just so i can target the crazy time periods ...


thanks

ras

Aurimas wrote:
> Here it goes. the files that I used. text inside. check the market2
> 
> On Mon, May 18, 2009 at 9:32 PM, Robert A. Schmied <ras@...> wrote:
> 
> 
>>Aurimas
>>
>>what is the symbol(s) for the two chart images?
>>
>>just so i can target the crazy time periods ...
>>
>>
>>thanks
>>
>>ras
>>
>>
> 
> 

i'm missing something. market2 looks like the dow industrial members
with four omissions?

the two png images, one of which was named snr_calc_beginning_loooong.png.
looks to me like a daily chart but it's too much for my feeble eol system
to handle.

that particular chart is the one that has the 'crazyness' about 2/3s from
the start. (looks like just before a stock split happened). humm that could
be the first att (t) breakup in 1984 ... i don't have data that far back.

just that one symbol would be good ...

ras

Yes I wrote inside spreadsheet what kind of test this was. I'm now testing
the same thing except with ATR_T2.

Could you send me any revision you have made on SnR_c and SnR_ci ?

On Mon, May 18, 2009 at 10:14 PM, Robert A. Schmied <ras@...> wrote:

> Aurimas wrote:
>
>> Here it goes. the files that I used. text inside. check the market2
>>
>> On Mon, May 18, 2009 at 9:32 PM, Robert A. Schmied <ras@...> wrote:
>>
>>
>>  Aurimas
>>>
>>> what is the symbol(s) for the two chart images?
>>>
>>> just so i can target the crazy time periods ...
>>>
>>>
>>> thanks
>>>
>>> ras
>>>
>>>
>>>
>>
>>
> i'm missing something. market2 looks like the dow industrial members
> with four omissions?
>
> the two png images, one of which was named snr_calc_beginning_loooong.png.
> looks to me like a daily chart but it's too much for my feeble eol system
> to handle.
>
> that particular chart is the one that has the 'crazyness' about 2/3s from
> the start. (looks like just before a stock split happened). humm that could
> be the first att (t) breakup in 1984 ... i don't have data that far back.
>
> just that one symbol would be good ...
>
> ras
>
>
>
>
>

Aurimas wrote:
> Yes I wrote inside spreadsheet what kind of test this was.

oh that was the file i couldn't do anything with. guess i could
look at it with hexdump, but it's not that important, unless it
happens again ;-)

 I'm now testing
> the same thing except with ATR_T2.
> 
> Could you send me any revision you have made on SnR_c and SnR_ci ?

files attached -- here are my notes:

after changing out the two instances of switch in each

and disabling debug


%    gdiff -u `! display_indicator.pl --start 1jan09 --end yesterday I:SnR_c JPM ` `! display_indicator.pl --start 1jan09 --end yesterday I:SnR_ci JPM `
display_indicator.pl: interval: 2262 .. 2354

display_indicator.pl: interval: 2262 .. 2354 interval too large
last valid data at 2353
first valid data at 2263
display_indicator.pl: interval: 2263 .. 2353
--- /tmp/bang9360       Mon May 18 14:04:11 2009
+++ /tmp/bang9368       Mon May 18 14:04:12 2009
@@ -1,11 +1,9 @@
-Indicator I:SnR_c has 2 values ... all values selected
-       I:SnR_c/1  <=> Support[10, 7, { I:Prices HIGH}, { I:Prices LOW}]
-       I:SnR_c/2  <=> Resistance[10, 7, { I:Prices HIGH}, { I:Prices LOW}]
+Indicator I:SnR_ci has 2 values ... all values selected
+       I:SnR_ci/1  <=> Support[10, 7, { I:Prices HIGH}, { I:Prices LOW}]
+       I:SnR_ci/2  <=> Resistance[10, 7, { I:Prices HIGH}, { I:Prices LOW}]
 
        timeframe day, time periods 2262 .. 2354
 Calculating all 2 indicators ...
-Support[10, 7, { I:Prices HIGH}, { I:Prices LOW}][2009-01-02] = 28.6500
-Resistance[10, 7, {hi}, {lo}][2009-01-02] = 31.9400
 Support[10, 7, { I:Prices HIGH}, { I:Prices LOW}][2009-01-05] = 28.6500
 Resistance[10, 7, {hi}, {lo}][2009-01-05] = 31.9400
 Support[10, 7, { I:Prices HIGH}, { I:Prices LOW}][2009-01-06] = 28.6500
@@ -188,5 +186,3 @@
 Resistance[10, 7, {hi}, {lo}][2009-05-13] = 38.9400
 Support[10, 7, { I:Prices HIGH}, { I:Prices LOW}][2009-05-14] = 14.9600
 Resistance[10, 7, {hi}, {lo}][2009-05-14] = 38.9400
-Support[10, 7, { I:Prices HIGH}, { I:Prices LOW}][2009-05-15] = 14.9600
-Resistance[10, 7, {hi}, {lo}][2009-05-15] = 38.9400

so I:SnR_c handles the actual first day (time period) 2009-01-02
but I:SnR_ci doesn't

conversely I:SnR_ci handles the actual last day (yesterday is 15may09 when
today is 18may) when I:SnR_c doesn't

so right off there's an off-by-one in some index calculation someplace
not a big big deal, just hard to ferret out

but other than that the data looks identical -- you do know that the
indicator should (i think should is correct) provide both the calculate
and the calculate_indicator methods, especially if there is a performance
gain to be had with the calculate_indicator method.

with just a 30 second side-by-side editor comparison looks to me like
the methods are identical (or nearly so) just with a different name

that isn't what yow really want to do according to thomas weigerts
findings from the indicator cookbook.

tkdiff indicates a couple of aspects of calculate_indicator may
have been attempted.

what i'm considering is firing up acroread with the cookbook and
using snr_c as a the new baseline seeing if i can hack in the
calculate_indicator method using the cookbook methodology

no -- that isn't the current mission

i'm trying to look at contents of the prior value stores
 ... determining if there's anything in Support1 or Support2 ...

humm well
I:Snr_c and I:Snr_ci --start 1jan09 --end yesterday seem identical
over this time period for jpm

graphic.pl --start "2003-09-01" --end="2004-04-30" -timeframe day \
 --add=curve'( I:SnR_c/2, blue)' --add=curve'( I:SnR_c/1, red)' \
 --add=curve'( I:SnR_ci/2, darkblue)' --add=curve'( I:SnR_ci/1, orange)' \
 JPM > /tmp/JPMsnr_c-comp.png

and this seems to validate that

it also corrects the right most support area at the 35.00 value


small (3) sample of
timex graphic.pl --start "2003-09" --end=2009-05 -timeframe week \
 --add=curve'( I:SnR_c/2, blue)' --add=curve'( I:SnR_c/1, red)' \
 JPM > /tmp/JPMsnr_c-comp.png
yields
real        6.06
user        5.61
sys         0.21


same sample size with I:SnR_ci
yields
real        4.10
user        3.69
sys         0.20

so there is a bit of gain with the calc_interval


now lets try to vary the defaults arguments of 10 and 7

don't really understand the purpose for the first two args

note that SnR_c and SnR_ci have very different dependencies
for the 2nd parameter in each of the $self->add_indicator_dependency
statements in the initialize methods.

that looks to be significantly amiss? but i really don't see
it makes a difference, but then i don't know where to look for it.


graphic.pl --start "2003-08-01" --end="2004-05-15" -timeframe day \
--add=curve'( I:SnR_c/2 12 9, blue)' --add=curve'( I:SnR_c/1 12 9, red)' \
--add=curve'( I:SnR_ci/2, darkblue)' --add=curve'( I:SnR_ci/1, orange)' \
--add=curve'( I:SnR_c/2 8 5, darkgreen)' --add=curve'( I:SnR_c/1 8 5, firebrick)'  \
JPM > /tmp/JPMsnr_c-comp.png

graphic.pl --start "2003-08-01" --end="2004-05-15" -timeframe day \
--add=curve'( I:SnR_ci/2 12 9, blue)' --add=curve'( I:SnR_ci/1 12 9, red)' \
--add=curve'( I:SnR_c/2, darkblue)' --add=curve'( I:SnR_c/1, orange)' \
--add=curve'( I:SnR_ci/2 8 5, darkgreen)' --add=curve'( I:SnR_ci/1 8 5, firebrick)'  \
JPM > /tmp/JPMsnr_c-comp.png

i'll just throw these things back over the pond and let you ponder things

aloha

ras


> 
> On Mon, May 18, 2009 at 10:14 PM, Robert A. Schmied <ras@...> wrote:
> 
> 
>>Aurimas wrote:
>>
>>
>>>Here it goes. the files that I used. text inside. check the market2
>>>
>>>On Mon, May 18, 2009 at 9:32 PM, Robert A. Schmied <ras@...> wrote:
>>>
>>>
>>> Aurimas
>>>
>>>>what is the symbol(s) for the two chart images?
>>>>
>>>>just so i can target the crazy time periods ...
>>>>
>>>>
>>>>thanks
>>>>
>>>>ras
>>>>
>>>>
>>>>
>>>
>>>
>>i'm missing something. market2 looks like the dow industrial members
>>with four omissions?
>>
>>the two png images, one of which was named snr_calc_beginning_loooong.png.
>>looks to me like a daily chart but it's too much for my feeble eol system
>>to handle.
>>
>>that particular chart is the one that has the 'crazyness' about 2/3s from
>>the start. (looks like just before a stock split happened). humm that could
>>be the first att (t) breakup in 1984 ... i don't have data that far back.
>>
>>just that one symbol would be good ...
>>
>>ras
>>
>>
>>
>>
>>
> 
>

aurimas


there's still a problem with snr_ci when used in a particular way
(like that done in the basically less than functional testing scheme)

the issue is that it never seems to get properly setup, the results
are then probably prices low for support and prices high for resistance

for example using the testing text based t/data/alcatel.txt data file:
# Results for SnR_ci 
# YYYY-MM-DD	Support[10, 7, { I:Prices HIGH}, { I:Prices LOW}]	Resistance[10, 7, { I:Prices HIGH}, { I:Prices LOW}]
1993-01-04 00:00:00	-         	-         
1993-01-05 00:00:00	-         	-         
1993-01-06 00:00:00	-         	-         
1993-01-07 00:00:00	-         	-         
1993-01-08 00:00:00	-         	-         
1993-01-11 00:00:00	-         	-         
1993-01-12 00:00:00	-         	-         
1993-01-13 00:00:00	-         	-         
1993-01-14 00:00:00	-         	-         
1993-01-15 00:00:00	-         	-         
1993-01-18 00:00:00	-         	-         
1993-01-19 00:00:00	-         	-         
1993-01-20 00:00:00	-         	-         
1993-01-21 00:00:00	-         	-         
1993-01-22 00:00:00	-         	-         
1993-01-25 00:00:00	-         	-         
1993-01-26 00:00:00	-         	-         
1993-01-27 00:00:00	-         	-         
1993-01-28 00:00:00	-         	-         
1993-01-29 00:00:00	17.0956   	20.8947   
1993-02-01 00:00:00	17.1231   	20.9282   
1993-02-02 00:00:00	17.1505   	20.9617   
1993-02-03 00:00:00	17.4524   	21.3307   
1993-02-04 00:00:00	17.6444   	21.5654   
1993-02-05 00:00:00	17.6993   	21.6325   
1993-02-08 00:00:00	17.6993   	21.6325   
1993-02-09 00:00:00	17.6170   	21.5319   
1993-02-10 00:00:00	17.5896   	21.4984   
1993-02-11 00:00:00	17.6444   	21.5654   


i'm looking at it ...

ras

Yes and I wrote previously about other problem, but I think you overlooked
it:

 if ( defined $supports1[0] && defined $supports2[0] ) {
        # case 2
        $support = ( $supports1[0] > $supports2[0] ) ? $supports1[0] :
$supports2[0];
        print STDERR "Both are defined\n" if $debug;
        print STDERR "DAMN!!!!!!!!!!!!\n" if ($resists1[0] == 0) ||
($resists2[0] == 0);
    } elsif ( defined $supports1[0] || defined $supports2[0] ) {
        # case 1
        $support = ( defined $supports1[0] ) ? $supports1[0] :
$supports2[0];
        print STDERR "One is defined\n" if $debug;
    } else {
        # case 0
        $support = $price_r * 0.9;
        print STDERR "10% down price:$support\n" if $debug;
    }

it prints "damn!!!", this means that "difined" isn't a good way to check if
there are supports! .. can you come up with something that is?


On Tue, May 19, 2009 at 8:25 PM, Robert A. Schmied <ras@...> wrote:

> aurimas
>
>
> there's still a problem with snr_ci when used in a particular way
> (like that done in the basically less than functional testing scheme)
>
> the issue is that it never seems to get properly setup, the results
> are then probably prices low for support and prices high for resistance
>
> for example using the testing text based t/data/alcatel.txt data file:
> # Results for SnR_ci # YYYY-MM-DD    Support[10, 7, { I:Prices HIGH}, {
> I:Prices LOW}]       Resistance[10, 7, { I:Prices HIGH}, { I:Prices LOW}]
> 1993-01-04 00:00:00     -               -         1993-01-05 00:00:00     -
>               -         1993-01-06 00:00:00     -               -
> 1993-01-07 00:00:00     -               -         1993-01-08 00:00:00     -
>               -         1993-01-11 00:00:00     -               -
> 1993-01-12 00:00:00     -               -         1993-01-13 00:00:00     -
>               -         1993-01-14 00:00:00     -               -
> 1993-01-15 00:00:00     -               -         1993-01-18 00:00:00     -
>               -         1993-01-19 00:00:00     -               -
> 1993-01-20 00:00:00     -               -         1993-01-21 00:00:00     -
>               -         1993-01-22 00:00:00     -               -
> 1993-01-25 00:00:00     -               -         1993-01-26 00:00:00     -
>               -         1993-01-27 00:00:00     -               -
> 1993-01-28 00:00:00     -               -         1993-01-29 00:00:00
> 17.0956         20.8947   1993-02-01 00:00:00     17.1231         20.9282
> 1993-02-02 00:00:00     17.1505         20.9617   1993-02-03 00:00:00
> 17.4524         21.3307   1993-02-04 00:00:00     17.6444         21.5654
> 1993-02-05 00:00:00     17.6993         21.6325   1993-02-08 00:00:00
> 17.6993         21.6325   1993-02-09 00:00:00     17.6170         21.5319
> 1993-02-10 00:00:00     17.5896         21.4984   1993-02-11 00:00:00
> 17.6444         21.5654
>
> i'm looking at it ...
>
> ras
>
>

Did I mention how lucky I am that you are helping me? Thanks Robert

Moreover, the debuging says:
Both are defined
Use of uninitialized value $resists2[0] in numeric eq (==) at
../GT/Indicators/SnR_c.pm line 247.
DAMN!!!!!!!!!!!!

this means that it passes the "defined" test and yet it's not defined!??


On Tue, May 19, 2009 at 10:46 PM, Aurimas <4urimas@...> wrote:

> Yes and I wrote previously about other problem, but I think you overlooked
> it:
>
>  if ( defined $supports1[0] && defined $supports2[0] ) {
>         # case 2
>         $support = ( $supports1[0] > $supports2[0] ) ? $supports1[0] :
> $supports2[0];
>         print STDERR "Both are defined\n" if $debug;
>         print STDERR "DAMN!!!!!!!!!!!!\n" if ($resists1[0] == 0) ||
> ($resists2[0] == 0);
>     } elsif ( defined $supports1[0] || defined $supports2[0] ) {
>         # case 1
>         $support = ( defined $supports1[0] ) ? $supports1[0] :
> $supports2[0];
>         print STDERR "One is defined\n" if $debug;
>     } else {
>         # case 0
>         $support = $price_r * 0.9;
>         print STDERR "10% down price:$support\n" if $debug;
>     }
>
> it prints "damn!!!", this means that "difined" isn't a good way to check if
> there are supports! .. can you come up with something that is?
>
>
>
> On Tue, May 19, 2009 at 8:25 PM, Robert A. Schmied <ras@...> wrote:
>
>> aurimas
>>
>>
>> there's still a problem with snr_ci when used in a particular way
>> (like that done in the basically less than functional testing scheme)
>>
>> the issue is that it never seems to get properly setup, the results
>> are then probably prices low for support and prices high for resistance
>>
>> for example using the testing text based t/data/alcatel.txt data file:
>> # Results for SnR_ci # YYYY-MM-DD    Support[10, 7, { I:Prices HIGH}, {
>> I:Prices LOW}]       Resistance[10, 7, { I:Prices HIGH}, { I:Prices LOW}]
>> 1993-01-04 00:00:00     -               -         1993-01-05 00:00:00
>> -               -         1993-01-06 00:00:00     -               -
>> 1993-01-07 00:00:00     -               -         1993-01-08 00:00:00     -
>>               -         1993-01-11 00:00:00     -               -
>> 1993-01-12 00:00:00     -               -         1993-01-13 00:00:00     -
>>               -         1993-01-14 00:00:00     -               -
>> 1993-01-15 00:00:00     -               -         1993-01-18 00:00:00     -
>>               -         1993-01-19 00:00:00     -               -
>> 1993-01-20 00:00:00     -               -         1993-01-21 00:00:00     -
>>               -         1993-01-22 00:00:00     -               -
>> 1993-01-25 00:00:00     -               -         1993-01-26 00:00:00     -
>>               -         1993-01-27 00:00:00     -               -
>> 1993-01-28 00:00:00     -               -         1993-01-29 00:00:00
>> 17.0956         20.8947   1993-02-01 00:00:00     17.1231         20.9282
>> 1993-02-02 00:00:00     17.1505         20.9617   1993-02-03 00:00:00
>> 17.4524         21.3307   1993-02-04 00:00:00     17.6444         21.5654
>> 1993-02-05 00:00:00     17.6993         21.6325   1993-02-08 00:00:00
>> 17.6993         21.6325   1993-02-09 00:00:00     17.6170         21.5319
>> 1993-02-10 00:00:00     17.5896         21.4984   1993-02-11 00:00:00
>> 17.6444         21.5654
>>
>> i'm looking at it ...
>>
>> ras
>>
>>
>

Aurimas wrote:
> Did I mention how lucky I am that you are helping me? Thanks Robert

not a problem! like you said 'it would be a good thing to add to gt toolkit'

> 
> Moreover, the debuging says:
> Both are defined
> Use of uninitialized value $resists2[0] in numeric eq (==) at
> ../GT/Indicators/SnR_c.pm line 247.
> DAMN!!!!!!!!!!!!
> 
> this means that it passes the "defined" test and yet it's not defined!??
> 
> 

i'm thinking that perl is helping by creating the array for us but i'm
not yet proven it or found solution ...

ras

Aurimas wrote:
> Did I mention how lucky I am that you are helping me? Thanks Robert
> 
> Moreover, the debuging says:
> Both are defined
> Use of uninitialized value $resists2[0] in numeric eq (==) at
> ../GT/Indicators/SnR_c.pm line 247.
> DAMN!!!!!!!!!!!!
> 
> this means that it passes the "defined" test and yet it's not defined!??
> 
> 
> On Tue, May 19, 2009 at 10:46 PM, Aurimas <4urimas@...> wrote:
> 
> 
>>Yes and I wrote previously about other problem, but I think you overlooked
>>it:
>>
>> if ( defined $supports1[0] && defined $supports2[0] ) {
>>        # case 2
>>        $support = ( $supports1[0] > $supports2[0] ) ? $supports1[0] :
>>$supports2[0];
>>        print STDERR "Both are defined\n" if $debug;
>>        print STDERR "DAMN!!!!!!!!!!!!\n" if ($resists1[0] == 0) ||
                                                ^^^^^^^^^ this cannot be right?
>>($resists2[0] == 0);
   ^^^^^^^^^ this cannot be right?
>>    } elsif ( defined $supports1[0] || defined $supports2[0] ) {
>>        # case 1
>>        $support = ( defined $supports1[0] ) ? $supports1[0] :
>>$supports2[0];
>>        print STDERR "One is defined\n" if $debug;
>>    } else {
>>        # case 0
>>        $support = $price_r * 0.9;
>>        print STDERR "10% down price:$support\n" if $debug;
>>    }
>>
>>it prints "damn!!!", this means that "difined" isn't a good way to check if
>>there are supports! .. can you come up with something that is?
>>
>>
>>
>>On Tue, May 19, 2009 at 8:25 PM, Robert A. Schmied <ras@...> wrote:
>>
>>
>>>aurimas
>>>
>>>
>>>there's still a problem with snr_ci when used in a particular way
>>>(like that done in the basically less than functional testing scheme)
>>>
>>>the issue is that it never seems to get properly setup, the results
>>>are then probably prices low for support and prices high for resistance
>>>
>>>for example using the testing text based t/data/alcatel.txt data file:
>>># Results for SnR_ci # YYYY-MM-DD    Support[10, 7, { I:Prices HIGH}, {
>>>I:Prices LOW}]       Resistance[10, 7, { I:Prices HIGH}, { I:Prices LOW}]
>>>1993-01-04 00:00:00     -               -         1993-01-05 00:00:00
>>>-               -         1993-01-06 00:00:00     -               -
>>>1993-01-07 00:00:00     -               -         1993-01-08 00:00:00     -
>>>              -         1993-01-11 00:00:00     -               -
>>>1993-01-12 00:00:00     -               -         1993-01-13 00:00:00     -
>>>              -         1993-01-14 00:00:00     -               -
>>>1993-01-15 00:00:00     -               -         1993-01-18 00:00:00     -
>>>              -         1993-01-19 00:00:00     -               -
>>>1993-01-20 00:00:00     -               -         1993-01-21 00:00:00     -
>>>              -         1993-01-22 00:00:00     -               -
>>>1993-01-25 00:00:00     -               -         1993-01-26 00:00:00     -
>>>              -         1993-01-27 00:00:00     -               -
>>>1993-01-28 00:00:00     -               -         1993-01-29 00:00:00
>>>17.0956         20.8947   1993-02-01 00:00:00     17.1231         20.9282
>>>1993-02-02 00:00:00     17.1505         20.9617   1993-02-03 00:00:00
>>>17.4524         21.3307   1993-02-04 00:00:00     17.6444         21.5654
>>>1993-02-05 00:00:00     17.6993         21.6325   1993-02-08 00:00:00
>>>17.6993         21.6325   1993-02-09 00:00:00     17.6170         21.5319
>>>1993-02-10 00:00:00     17.5896         21.4984   1993-02-11 00:00:00
>>>17.6444         21.5654
>>>
>>>i'm looking at it ...
>>>
>>>ras
>>>
>>>
>>
>

Oh yes right, I was copypasting. Now we only have

Both are defined
DAMN!!!!!!!!!!!! (damn translated from lithuanian means one of arrays is
empty)

if we try to
        defined $resists1[0];
        defined $resists2[0];

$value = @supports1; #getting the length of array

and testing... will check right now!


On Tue, May 19, 2009 at 11:28 PM, Robert A. Schmied <ras@...> wrote:

> Aurimas wrote:
>
>> Did I mention how lucky I am that you are helping me? Thanks Robert
>>
>> Moreover, the debuging says:
>> Both are defined
>> Use of uninitialized value $resists2[0] in numeric eq (==) at
>> ../GT/Indicators/SnR_c.pm line 247.
>> DAMN!!!!!!!!!!!!
>>
>> this means that it passes the "defined" test and yet it's not defined!??
>>
>>
>> On Tue, May 19, 2009 at 10:46 PM, Aurimas <4urimas@...> wrote:
>>
>>
>>  Yes and I wrote previously about other problem, but I think you
>>> overlooked
>>> it:
>>>
>>> if ( defined $supports1[0] && defined $supports2[0] ) {
>>>       # case 2
>>>       $support = ( $supports1[0] > $supports2[0] ) ? $supports1[0] :
>>> $supports2[0];
>>>       print STDERR "Both are defined\n" if $debug;
>>>       print STDERR "DAMN!!!!!!!!!!!!\n" if ($resists1[0] == 0) ||
>>>
>>                                               ^^^^^^^^^ this cannot be
> right?
>
>> ($resists2[0] == 0);
>>>
>>  ^^^^^^^^^ this cannot be right?
>
>    } elsif ( defined $supports1[0] || defined $supports2[0] ) {
>>>       # case 1
>>>       $support = ( defined $supports1[0] ) ? $supports1[0] :
>>> $supports2[0];
>>>       print STDERR "One is defined\n" if $debug;
>>>   } else {
>>>       # case 0
>>>       $support = $price_r * 0.9;
>>>       print STDERR "10% down price:$support\n" if $debug;
>>>   }
>>>
>>> it prints "damn!!!", this means that "difined" isn't a good way to check
>>> if
>>> there are supports! .. can you come up with something that is?
>>>
>>>
>>>
>>> On Tue, May 19, 2009 at 8:25 PM, Robert A. Schmied <ras@...> wrote:
>>>
>>>
>>>  aurimas
>>>>
>>>>
>>>> there's still a problem with snr_ci when used in a particular way
>>>> (like that done in the basically less than functional testing scheme)
>>>>
>>>> the issue is that it never seems to get properly setup, the results
>>>> are then probably prices low for support and prices high for resistance
>>>>
>>>> for example using the testing text based t/data/alcatel.txt data file:
>>>> # Results for SnR_ci # YYYY-MM-DD    Support[10, 7, { I:Prices HIGH}, {
>>>> I:Prices LOW}]       Resistance[10, 7, { I:Prices HIGH}, { I:Prices
>>>> LOW}]
>>>> 1993-01-04 00:00:00     -               -         1993-01-05 00:00:00
>>>> -               -         1993-01-06 00:00:00     -               -
>>>> 1993-01-07 00:00:00     -               -         1993-01-08 00:00:00
>>>>   -
>>>>             -         1993-01-11 00:00:00     -               -
>>>> 1993-01-12 00:00:00     -               -         1993-01-13 00:00:00
>>>>   -
>>>>             -         1993-01-14 00:00:00     -               -
>>>> 1993-01-15 00:00:00     -               -         1993-01-18 00:00:00
>>>>   -
>>>>             -         1993-01-19 00:00:00     -               -
>>>> 1993-01-20 00:00:00     -               -         1993-01-21 00:00:00
>>>>   -
>>>>             -         1993-01-22 00:00:00     -               -
>>>> 1993-01-25 00:00:00     -               -         1993-01-26 00:00:00
>>>>   -
>>>>             -         1993-01-27 00:00:00     -               -
>>>> 1993-01-28 00:00:00     -               -         1993-01-29 00:00:00
>>>> 17.0956         20.8947   1993-02-01 00:00:00     17.1231
>>>> 20.9282
>>>> 1993-02-02 00:00:00     17.1505         20.9617   1993-02-03 00:00:00
>>>> 17.4524         21.3307   1993-02-04 00:00:00     17.6444
>>>> 21.5654
>>>> 1993-02-05 00:00:00     17.6993         21.6325   1993-02-08 00:00:00
>>>> 17.6993         21.6325   1993-02-09 00:00:00     17.6170
>>>> 21.5319
>>>> 1993-02-10 00:00:00     17.5896         21.4984   1993-02-11 00:00:00
>>>> 17.6444         21.5654
>>>>
>>>> i'm looking at it ...
>>>>
>>>> ras
>>>>
>>>>
>>>>
>>>
>>
>

Aurimas wrote:
> Oh yes right, I was copypasting. Now we only have
> 
> Both are defined
> DAMN!!!!!!!!!!!! (damn translated from lithuanian means one of arrays is
> empty)
> 
> if we try to
>         defined $resists1[0];
>         defined $resists2[0];
> 
> $value = @supports1; #getting the length of array
> 
> and testing... will check right now!
> 


well for an array element with a value of zero still means both the array
as well as that element are defined.

heck even a scalar variable with the value of zero if it happened via an
assignment op is defined methinks ...

%     perl -e 'my $undef_zero; my $def_zero=0; print "undef_zero is \"$undef_zero\"\n" if defined $undef_zero; print "def_zero is $def_zero\n"  if defined $def_zero;'
def_zero is 0


note: the basic logic is working correctly, both are defined, and the larger
is being assigned correctly. the problem as i see it is initial conditions
(well prior conditions, that is values that happened before $first or $i)
are not being set reasonably. this not unusual by the way, happens all the time
with indicators.

question is: should zeros ever be assigned to the indicator outputs support or resistance?

but maybe more importantly, during startup, when $i is very close to $first (for calculate_interval),
or in calculate when the supports and resists arrays are empty, is there some logic
that can be applied to ensure the indicator outputs are 'reasonable'. (i have to admit
i've yet to read the url you sent regarding horizontal resistance and support levels)

example: maybe until the first 10 periods (or whatever the value might be)
the support level is the lowest low observed up to and including this time period
similarly for resistance: the highest high observed up to and including this time period.

here's the scenario: brand new issue just starts trading, there's no way to get data
for prior periods so on first day support is day_low, next day support is lowest of
todays low or yesterdays low, etc. similar logic but with day_high for resistance.
once there are n days of history revert to normal calculation.


ras



> 
> On Tue, May 19, 2009 at 11:28 PM, Robert A. Schmied <ras@...> wrote:
> 
> 
>>Aurimas wrote:
>>
>>
>>>Did I mention how lucky I am that you are helping me? Thanks Robert
>>>
>>>Moreover, the debuging says:
>>>Both are defined
>>>Use of uninitialized value $resists2[0] in numeric eq (==) at
>>>../GT/Indicators/SnR_c.pm line 247.
>>>DAMN!!!!!!!!!!!!
>>>
>>>this means that it passes the "defined" test and yet it's not defined!??
>>>
>>>
>>>On Tue, May 19, 2009 at 10:46 PM, Aurimas <4urimas@...> wrote:
>>>
>>>
>>> Yes and I wrote previously about other problem, but I think you
>>>
>>>>overlooked
>>>>it:
>>>>
>>>>if ( defined $supports1[0] && defined $supports2[0] ) {
>>>>      # case 2
>>>>      $support = ( $supports1[0] > $supports2[0] ) ? $supports1[0] :
>>>>$supports2[0];
>>>>      print STDERR "Both are defined\n" if $debug;
>>>>      print STDERR "DAMN!!!!!!!!!!!!\n" if ($resists1[0] == 0) ||
>>>>
>>>
>>>                                              ^^^^^^^^^ this cannot be
>>
>>right?
>>
>>
>>>($resists2[0] == 0);
>>>
>>> ^^^^^^^^^ this cannot be right?
>>
>>   } elsif ( defined $supports1[0] || defined $supports2[0] ) {
>>
>>>>      # case 1
>>>>      $support = ( defined $supports1[0] ) ? $supports1[0] :
>>>>$supports2[0];
>>>>      print STDERR "One is defined\n" if $debug;
>>>>  } else {
>>>>      # case 0
>>>>      $support = $price_r * 0.9;
>>>>      print STDERR "10% down price:$support\n" if $debug;
>>>>  }
>>>>
>>>>it prints "damn!!!", this means that "difined" isn't a good way to check
>>>>if
>>>>there are supports! .. can you come up with something that is?
>>>>
>>>>
>>>>
>>>>On Tue, May 19, 2009 at 8:25 PM, Robert A. Schmied <ras@...> wrote:
>>>>
>>>>
>>>> aurimas
>>>>
>>>>>
>>>>>there's still a problem with snr_ci when used in a particular way
>>>>>(like that done in the basically less than functional testing scheme)
>>>>>
>>>>>the issue is that it never seems to get properly setup, the results
>>>>>are then probably prices low for support and prices high for resistance
>>>>>
>>>>>for example using the testing text based t/data/alcatel.txt data file:
>>>>># Results for SnR_ci # YYYY-MM-DD    Support[10, 7, { I:Prices HIGH}, {
>>>>>I:Prices LOW}]       Resistance[10, 7, { I:Prices HIGH}, { I:Prices
>>>>>LOW}]
>>>>>1993-01-04 00:00:00     -               -         1993-01-05 00:00:00
>>>>>-               -         1993-01-06 00:00:00     -               -
>>>>>1993-01-07 00:00:00     -               -         1993-01-08 00:00:00
>>>>>  -
>>>>>            -         1993-01-11 00:00:00     -               -
>>>>>1993-01-12 00:00:00     -               -         1993-01-13 00:00:00
>>>>>  -
>>>>>            -         1993-01-14 00:00:00     -               -
>>>>>1993-01-15 00:00:00     -               -         1993-01-18 00:00:00
>>>>>  -
>>>>>            -         1993-01-19 00:00:00     -               -
>>>>>1993-01-20 00:00:00     -               -         1993-01-21 00:00:00
>>>>>  -
>>>>>            -         1993-01-22 00:00:00     -               -
>>>>>1993-01-25 00:00:00     -               -         1993-01-26 00:00:00
>>>>>  -
>>>>>            -         1993-01-27 00:00:00     -               -
>>>>>1993-01-28 00:00:00     -               -         1993-01-29 00:00:00
>>>>>17.0956         20.8947   1993-02-01 00:00:00     17.1231
>>>>>20.9282
>>>>>1993-02-02 00:00:00     17.1505         20.9617   1993-02-03 00:00:00
>>>>>17.4524         21.3307   1993-02-04 00:00:00     17.6444
>>>>>21.5654
>>>>>1993-02-05 00:00:00     17.6993         21.6325   1993-02-08 00:00:00
>>>>>17.6993         21.6325   1993-02-09 00:00:00     17.6170
>>>>>21.5319
>>>>>1993-02-10 00:00:00     17.5896         21.4984   1993-02-11 00:00:00
>>>>>17.6444         21.5654
>>>>>
>>>>>i'm looking at it ...
>>>>>
>>>>>ras
>>>>>
>>>>>
>>>>>
>>>>
>

hmmm ... useless subject line at this point - -I declare you 
each to have won

Please don't do this -- reasonable trimming venues include 
the subject line.

-- Russ herrold

Aurimas wrote:
> nevermind previous post, i had made a stupid mistake.

yea those darn cut+pastos are a real annoyance!

> 
> BUT I have found one mistake, it was your checks of defined on the shifts

humm -- i believe those were added to protect against excessive warnings:
use of uninitialized ... when running with display_indicator.pl

> that control arrays. So now it's doing more of what I want him to do.

if that is the case then i'd say the conditional(s) on these shifts should
never evaluate an element that might be uninitialized.

by now (with all the changes between when these checks were added and now)
that may be the case.

i'll run a test or two in a bit.

ras

> 
> But there's still problem with calculate method (which I need for
> backtesting) it messes things up completely sometimes: it puts resistance
> lower than support and it seems it tests the whole period no matter what
> period I give it to test (because it knows previous supports). how can this
> be?

initial conditions not being set up correctly?

> 
> Now, what should it do ideally is: delete the supports that are, say, 5
> times older than the min/max period length, so that we would have the
> "graphical trend-line drawn by trader" correspond to our indicator. I do
> think that it was possible to have different approach to the problem from
> the beginning, yet considering I am complete novice to perl and GT it is a
> miracle what I wrote.
> 
> Aurimas
> 
> On Wed, May 20, 2009 at 12:33 AM, Robert A. Schmied <ras@...> wrote:
> 
> 

< snip >

Aurimas wrote:
> nevermind previous post, i had made a stupid mistake.
> 
> BUT I have found one mistake, it was your checks of defined on the shifts
> that control arrays. So now it's doing more of what I want him to do.
> 
> But there's still problem with calculate method (which I need for
> backtesting) it messes things up completely sometimes: it puts resistance
> lower than support and it seems it tests the whole period no matter what
> period I give it to test (because it knows previous supports). how can this
> be?
> 
> Now, what should it do ideally is: delete the supports that are, say, 5
> times older than the min/max period length, so that we would have the
> "graphical trend-line drawn by trader" correspond to our indicator. I do
> think that it was possible to have different approach to the problem from
> the beginning, yet considering I am complete novice to perl and GT it is a
> miracle what I wrote.
> 
> Aurimas
> 
> On Wed, May 20, 2009 at 12:33 AM, Robert A. Schmied <ras@...> wrote:
> 
> 

graphic.pl --start "2003-09-01" --end="2004-04-30" -timeframe day --add=curve'( I:SnR_c/2, blue)' --add=curve'( I:SnR_c/1, red)' --add=curve'( I:SnR_ci/2, darkblue)' --add=curve'( I:SnR_ci/1, orange)' JPM > /tmp/JPMsnr_c-comp.png

looks to me like things just went south (bad) again. the far right
support down at 32.25 should be somewhere around 35

the resistance is tracking crazily at high plus 10 % in various places

the plot shows both SnR_c and SnR_ci which coincide exactly.

and yes without those "checks of defined on the shifts that control arrays."
display_indicator.pl yields:

display_indicator.pl -short 35 --start 1jan09 --end yesterday I:SnR_c t
Useless use of defined operator in void context at ../GT/Indicators/SnR_c.pm line 205.
Useless use of defined operator in void context at ../GT/Indicators/SnR_c.pm line 206.
Indicator I:SnR_c has 2 values ... all values selected
        I:SnR_c/1  <=> Support[10, 7, { I:Prices HIGH}, { I:Prices LOW}]
        I:SnR_c/2  <=> Resistance[10, 7, { I:Prices HIGH}, { I:Prices LOW}]

        timeframe day, time periods 2519 .. 2612
Calculating all 2 indicators ...
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_c.pm line 248.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_c.pm line 248.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_c.pm line 248.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_c.pm line 248.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_c.pm line 248.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_c.pm line 248.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_c.pm line 248.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_c.pm line 248.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_c.pm line 248.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_c.pm line 248.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_c.pm line 248.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_c.pm line 248.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_c.pm line 248.
Use of uninitialized value in numeric ne (!=) at ../GT/Indicators/SnR_c.pm line 253.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_c.pm line 248.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_c.pm line 248.


and 

display_indicator.pl -short 35 --start 1jan09 --end yesterday I:SnR_ci t
Useless use of defined operator in void context at ../GT/Indicators/SnR_ci.pm line 194.
Useless use of defined operator in void context at ../GT/Indicators/SnR_ci.pm line 195.
Indicator I:SnR_ci has 2 values ... all values selected
        I:SnR_ci/1  <=> Support[10, 7, { I:Prices HIGH}, { I:Prices LOW}]
        I:SnR_ci/2  <=> Resistance[10, 7, { I:Prices HIGH}, { I:Prices LOW}]

        timeframe day, time periods 2519 .. 2612
Calculating all 2 indicators ...
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_ci.pm line 237.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_ci.pm line 237.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_ci.pm line 237.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_ci.pm line 237.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_ci.pm line 237.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_ci.pm line 237.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_ci.pm line 237.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_ci.pm line 237.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_ci.pm line 237.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_ci.pm line 237.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_ci.pm line 237.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_ci.pm line 237.
Use of uninitialized value in numeric gt (>) at ../GT/Indicators/SnR_ci.pm line 237.
Use of uninitialized value in numeric ne (!=) at ../GT/Indicators/SnR_ci.pm line 242.


Aurimas

bet you figured support and resistance was a trivial problem!
you probably now understand why no one has managed to create a
good general solution for it.

if we step back a bit and try to describe the problem with words and then try
to implement those words with perl and the various gt methods we might make
more progress. it might not be as fast as you'd like or need but ...

i also suggest we limit the indicator to only one of the two values
to simplify the initial frame work and get the essential logic correct.

i'll start using the logic i think you are using, which i may have got wrong.
please cut and paste right into this context or start an entirely new context
with your inputs

... and blank lines indicate i don't know what to fill in



if there is a 'prior support value'
  if 'prior support value' is higher than 'todays low'
    support = 'todays low'
    'prior support value' = support
  else
    support = 'prior support value'
  fi
elsif there is a 'prior resistance value'
  if 'prior resistance value' ...

  else

  fi
elsif ...

else there is no 'prior support value'
  support = 'todays low'
  'prior support value' = support
fi



ras

R P Herrold wrote:
> 
> 
> hmmm ... useless subject line at this point - -I declare you each to 
> have won
> 
> Please don't do this -- reasonable trimming venues include the subject 
> line.
> 
> -- Russ herrold
> 


aloha russ

what element of the email route do you think is responsible for adding
each of the extra Re: strings?

i don't think my sunos mozilla is doing it, but is certainly isn't removing
them either, and i most often forget to even look at the subject line on
a reply. i'll try to remember to delete them when i see them.

if you can identify what might be doing it maybe it can be silenced.

ras