geniustrader-devel — participate in geniustrader development, ask for help, suggest improvements, etc

[GT] Using DB::module Text options and data representation with graphic.pl

[Evgeny S. <shr...@gm...>]

Hi folks!



First of all I want to say that I am very glad to discover such a
comprehensive project and express my admiration to all who took a part of
it! It seems that is just what I've been looking for! :)



I was going through the documentation for few days right now and I even
made some progress.

However I encountered few problems (I'm sure there will be more.. :) ) so I
thought maybe I could find some help here..


I have stocks end-of-day data which is saved in text files per stock
symbol, for example: MSFT.txt, GOOG.txt ...

Hence I decided (at least on the first stages) to use the DB::module Text.


   1. The format of the text files I have is slightly different from the
   source data I found on site so I made all relevant configuration in the
   ~/.gt/options file including setting the following parameters:
   DB::text::directory
   DB::text::marker
   DB::text::header_lines
   DB::text::format
   DB::text::datetime
   DB::text::open
   DB::text::low
   DB::text::high
   DB::text::close
   DB::text::volume

   Then I tried to do some tests with *graphic.pl*, and got some pretty
   reasonable output with one text files but got the following error while
   trying it with another file (with exactly similar format):

   *evgeny@evgeny-desktop:~/workspace/market/gt/GT$ graphic.pl --file
   screenshot_1.gconf --out 'Screenshot 5.png' IBMREV*
   *Day too big - 33604 > 24853*

   I tried to figure out what was causing this error but with no luck.


   2. When I was looking at the graph which I *did *succeed to plot (using
   different stock file), I noticed 3 things:
   2.1  I do not see the whole time period but the last 6 months. How can I
   change that?
   2.2  I understand that graph appearance can be configured in the *
   screenshot_1.gconf* file but I could not find where this file is located
   or should be located?
   2.3  I see that the data was automatically represented in daily
   resolution. Is there a way to show weekly/monthly candles?

   3. I realized that in order for all scripts to work properly the data in
   the text files must go from the oldest records on top of the file and the
   newest at the bottom.However my files are order is exactly reversed. Of
   course I can write some simple script to reverse the order of the records
   in the files but I wonder if there is some configuration which could be
   changed to achieve that?



I hope that's not too much questions to ask for the first timer.

I will be very thankful for any help!


Thanks in advance!


-- 
Best regards,
Eugene S

Re: [GT] Question about http://www.geniustrader.org

[Robert A. S. <ra...@ac...>]

Vadim Drabkin wrote:
> Hello.
> I am wondering if its possible to create with your software images of
> charts of different technical indicators in an automatic way.
> 
> In other words, I have all the relevant trading data and I need to create
> images of charts of EUR/USD with bollinger bands and then of GBP/USD with
> Aroon Oscillator and upload
> those images on my website.
> 
> Thanks a lot.
> Vadim.
> 

aloha vadim

the answer is yes absolutely.

the gt command line application script to do this is 'graphic.pl'.
detailed usage is available on-line via the web-site under 'documentation'.
it may be a little 'out-of-date' for current documentation of any gt
application script or gt toolkit module use a perl pod view such as
'perldoc'. for example
  %  cd $HOME/GT/Scripts
  %  perldoc -t graphic.pl

the key to doing this will be the 'graphic config file' you create that
contains the appropriate 'graphic directives' that specify the sys-sig-indic
descriptions in order to render the chart image you want. see the 'screenshots'
page for specific examples on how to do this.

depending on the type of access you have to your website graphic.pl might
be able to write the image file there directly (if the website is an nfs
mount or similar) or you might have to develop a wrapper script (perl or
shell) to do the upload.

on the other hand if the web-site host can run the gt toolkit directly
you can probably develop appropriate cgi like programming on a webpage
that runs the 'graphic.pl' on demand.

if by automatic you mean periodically without direct user involvement
use 'cron'.

best of luck

aloha

ras

[GT] Question about http://www.geniustrader.org

[Vadim D. <dva...@gm...>]

Hello.
I am wondering if its possible to create with your software images of
charts of different technical indicators in an automatic way.

In other words, I have all the relevant trading data and I need to create
images of charts of EUR/USD with bollinger bands and then of GBP/USD with
Aroon Oscillator and upload
those images on my website.

Thanks a lot.
Vadim.

Re: [GT] interactive charting with TradeSpring::Chart

[Chia-liang K. <cl...@cl...>]

Hi,

There are three parts:

TradeSpring itself is like GT, for developing strategies.  You can use
existing GT indicators and expressions, but it makes it easier to
write stateful indicators.  it provides backtest with simulation from
bars in the GT database, or tick data in FITF format.  You can also
run the strategy live against properly configured TradeSpring::Broker.
 see xt/CB0.pm for strategy example.

TradeSpring::Broker handles actual broker communication. it does come
with a dummy local broker for simulation.

TradeSpring::Chart is the UI for displaying TradeSpring indicators
(and thus GT indicators). it was originally written because the graph
generated by gt for large data set is too hard to read and to be
useful.  later i added some manual trading ui on the chart, but it's
currently not enabled in the released code.
The charting part is probably what's most immediately useful for
people already using gt, so i didn't mention the other two in the
original message, which might also require a bit more effort setting
up.  there's another not-yet-released component "PAGM" that works as
price aggregation service (you'll see both TradeSpring and
TradeSpring::Chart have some references to it), which is required for
running live trading and live charting.

Cheers,
CLK

2011/10/2 Roman Peniaev <r.p...@gm...>:
>
> Hi.
>
> Could you please describe tradespring toolkit in details?
>
> Thanks.
>
> --
> Roman
>
> 01.10.2011, в 21:20, Chia-liang Kao написал(а):
>
>> Hi all,
>>
>> I just pushed my charting toolkit to github:
>> https://github.com/tradespring/TradeSpring-Chart
>>
>> this is just a quick note for the adventurous ones, as there hasn't
>> been much documentation yet. but getting it to with your existing gt
>> db should be pretty simple, following the instructions in README.
>>
>> the charts are interactive, it scales when you zoom into particular
>> periods of time, and it shows you the data pointed by your mouse.  you
>> can't add indicators with the ui yet, but it's not hard to do so.
>>
>> you do need a websocket and svg capable browser to view it. let me
>> know if you run into any issue getting it up and running.
>>
>> Cheers,
>> CLK
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy2
>
>

Re: [GT] interactive charting with TradeSpring::Chart

[Roman P. <r.p...@gm...>]

Hi.

Could you please describe tradespring toolkit in details?

Thanks.

--
Roman 

01.10.2011, в 21:20, Chia-liang Kao написал(а):

> Hi all,
> 
> I just pushed my charting toolkit to github:
> https://github.com/tradespring/TradeSpring-Chart
> 
> this is just a quick note for the adventurous ones, as there hasn't
> been much documentation yet. but getting it to with your existing gt
> db should be pretty simple, following the instructions in README.
> 
> the charts are interactive, it scales when you zoom into particular
> periods of time, and it shows you the data pointed by your mouse.  you
> can't add indicators with the ui yet, but it's not hard to do so.
> 
> you do need a websocket and svg capable browser to view it. let me
> know if you run into any issue getting it up and running.
> 
> Cheers,
> CLK
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2

[GT] interactive charting with TradeSpring::Chart

[Chia-liang K. <cl...@cl...>]

Hi all,

I just pushed my charting toolkit to github:
https://github.com/tradespring/TradeSpring-Chart

this is just a quick note for the adventurous ones, as there hasn't
been much documentation yet. but getting it to with your existing gt
db should be pretty simple, following the instructions in README.

the charts are interactive, it scales when you zoom into particular
periods of time, and it shows you the data pointed by your mouse.  you
can't add indicators with the ui yet, but it's not hard to do so.

you do need a websocket and svg capable browser to view it. let me
know if you run into any issue getting it up and running.

Cheers,
CLK

Re: [GT] Couple of patches

[Thomas W. <we...@ms...>]

On the exp branch we performed a number of changes to make the scripts
more compatible (e.g., using the same arguments and the same style of
interaction) as well as performing bug fixes. As the name says, it also
has some newer features (experimental).

Unfortunately, the exp branch was never merged back into the main line
and lives on separately.

In my own use, I run a combination of main line and exp.

Best regards, Th.

On 08/09/2011 02:21 PM, System Trader wrote:
>
> Also is it possible to explain what's on the 'exp' branch?  Is it more
> bug fixes?
>
>

Re: [GT] Couple of patches

[Eric L. <eri...@gm...>]

Hi Nick

I am totaly agree with you.
Why not commit ras hack?

Eric
Le 9 août 2011 08:22, "System Trader" <sys...@gm...> a écrit :
> Makes sense, thanks for pointing out the tests. These will be good to use
> when adding new modules.
>
> So basically you are saying there is a set of 'ras hacks' that is not
> committed to the tree that fixes some of the issues. Why not commit these
> to the tree? You mention there was some difficulty? I would be happy to
> help with the merge effort if you think it is worthwhile, or help work
> through some of the main problems.
>
> Also is it possible to explain what's on the 'exp' branch? Is it more bug
> fixes?
>
> Thanks,
>
> Nick
>
> On Sun, Aug 7, 2011 at 3:50 PM, Robert A. Schmied <ra...@ac...> wrote:
>
>> nick, gt'ers
>>
>> the basic gt toolkit testing framework (is that the correct term)
>> that i've cobbled together to-date for GT::SY objects and methods
>> is as follows:
>>
>> #!/bin/bash -- # perl, to stop looping
>> # the following must be on two lines
>> eval 'exec perl -S $0 ${1+"$@"}'
>> if 0;
>>
>> #
>> # $Id$
>>
>> use Test::More;
>> use Test::Differences;
>> use Data::Dumper;
>>
>> use lib '..';
>> use GT::Conf;
>> use GT::Eval;
>> use GT::DateTime;
>>
>> my $opt_file = '../GT/t/options';
>> my $timeframe = $DAY;
>>
>> # sample database first date = 1993-01-04
>> # last date = 2002-10-04
>> # number entries = 2425
>> my $code = 13000; # sample database first date=1993-01-04
>> my $mid_date = '1998-01-02';
>>
>> GT::Conf::clear();
>> GT::Conf::load( "$opt_file" );
>>
>> my @object_types = ();
>> #
>> # to autogenerate the object_types list:
>> # ../GT/t/signals.t
>>
>> my @files = `find ../GT/Signals -name "\*.pm"`;
>>
>> foreach ( @files ) {
>> s/\.\.\///;
>> s/\//::/g;
>> s/\.pm//;
>>
>> # these are known to need parameters
>> # or are known to be learning, practice, or experimental modules
>> # or have other problems
>> #
>> # they should really be placed in either a TODO or SKIP block
>> next if (
>> m@GT::Signals::Prices::TDLow@ ||
>> m@GT::Signals::Prices::TDHi+@ ||
>> # m@GT::Signals::@ ||
>> # m@GT::Signals::@ ||
>> m@ conditional terminating line @
>> );
>> push @object_types, $_;
>>
>> #print STDERR "module $_\n";
>>
>> }
>>
>> plan tests => scalar @object_types * 4;
>>
>> foreach ( @object_types ) {
>> next if m/^(;|#)/;
>>
>> s/^GT:://;
>> chomp;
>> my $obj = $_;
>>
>> # don't bother creating objects from master templates
>> next if m/^Signals$/;
>>
>> print STDERR "\t-->working object $_\n";
>>
>> my $o = create_standard_object( $obj );
>> isa_ok
>> ( $o, "GT::$obj",
>> "create_standard_object( \"GT::$obj\" )\nreturned an object\t\t" );
>>
>> can_ok ( $o, 'initialize' );
>> can_ok ( $o, 'detect' );
>> can_ok ( $o, 'detect_interval' );
>>
>> print STDERR "\n";
>>
>> }
>>
>>
>>
>>
>> and for GT:I objects and methods
>>
>> #!/bin/bash -- # perl, to stop looping
>> # the following must be on two lines
>> eval 'exec perl -S $0 ${1+"$@"}'
>> if 0;
>>
>> #
>> # $Id$
>>
>> use Test::More;
>> use Test::Differences;
>> use Data::Dumper;
>>
>> use lib '..';
>> use GT::Conf;
>> use GT::Eval;
>> use GT::DateTime;
>>
>> my $opt_file = '../GT/t/options';
>> my $timeframe = $DAY;
>>
>> # sample database first date = 1993-01-04
>> # last date = 2002-10-04
>> # number entries = 2425
>> my $code = 13000; # sample database first date=1993-01-04
>> my $mid_date = '1998-01-02';
>>
>> GT::Conf::clear();
>> GT::Conf::load( "$opt_file" );
>>
>> my @object_types = ();
>> #
>> # to autogenerate the object_types list:
>> #
>> my @files = `find ../GT/Indicators -name "\*.pm"`;
>> foreach ( @files ) {
>> s/\.\.\///;
>> s/\//::/g;
>> s/\.pm//;
>>
>> #
>> # these are known to need parameters
>> # or are known to be learning, practice, or experimental modules
>> # or have other problems
>> #
>> # and as a result are explicitly skipped if encountered
>> #
>> # they should really be placed in either a TODO or SKIP block
>> #
>> next if (
>> m@GT::Indicators::**BPCorrelation@ ||
>> m@GT::Indicators::MASS@ ||
>> m@GT::Indicators::BBBandwidth@ ||
>> m@GT::Indicators::TDLineMax@ ||
>> m@GT::Indicators::TDLineMin@ ||
>> m@GT::Indicators::Test@ ||
>> m@GT::Indicators::TEST@ ||
>> m@GT::Indicators::STO-merge@ ||
>> m@GT::Indicators::DSS_dbs@ ||
>> m@GT::Indicators::ADX_tw_exp@ ||
>> m@GT::Indicators::olfs_VIDYA@ ||
>> m@GT::Indicators::TDLineMinO@ ||
>> m@GT::Indicators::Generic::**mymaxinperiod@ ||
>> m@GT::Indicators::pm_12oct_**HLCVolatility@ ||
>> m@GT::Indicators::TDsupport@ ||
>> m@GT::Indicators::SnR_devel_**hist::@ ||
>> m@GT::Indicators::SnR@ ||
>> m@GT::Indicators::SnR_h@ ||
>> m@GT::Indicators::Generic::**MaxInPeriod_clk@ ||
>> m@GT::Indicators::Generic::**MinInPeriod_clk@ ||
>> m@GT::Indicators::STO_a@ ||
>> m@GT::Indicators::STO_b@ ||
>> m@GT::Indicators::STO_foobar@ ||
>> #m@GT::Indicators::STOkw@ ||
>> # m@GT::Indicators::@ ||
>> # m@GT::Indicators::@ ||
>> m@ conditional terminating line @
>> );
>> push @object_types, $_;
>> }
>>
>> plan tests => scalar @object_types * 5;
>>
>> foreach ( @object_types ) {
>> next if m/^(;|#)/;
>>
>> s/^GT:://;
>> chomp;
>> my $obj = $_;
>>
>> # don't bother creating objects from master templates
>> next if m/^Indicators$/;
>>
>> my $indic_obj = create_standard_object( $obj );
>> isa_ok
>> ( $indic_obj, "GT::$obj",
>> "create_standard_object( \"GT::$obj\" )\nreturned an object\t\t" );
>>
>> can_ok ( $indic_obj, 'initialize' );
>> can_ok ( $indic_obj, 'calculate_all' );
>> can_ok ( $indic_obj, 'calculate_interval' );
>> can_ok ( $indic_obj, 'calculate' );
>>
>> }
>>
>>
>> these scripts are located in the gt hierachy at GT/t and at least in
>> my way of doing things can be run with cwd being the gt Scripts dir.
>>
>> as you can see these tests do very little (nothing) with arguments or
>> parameters, but are helpful to ensure the minimal methods are present.
>> they might be useful if someone is interested in extending them.
>>
>> i've also been told the horrible shebang construct fails on linux, but
>> prefer it or #!/usr/bin/env perl to one with a fixed perl path.
>>
>> i've got similar hacks for some of the other gt modules. my complete
>> gt ras hack is available on request in the form of three tarballs.
>> please note it isn't practical to attempt to merge it with any known
>> branch of gt as others who have tried will attest, that includes me.
>> so if you are at all interested you need to consider it an alternate gt.
>>
>>
>> aloha
>>
>> ras
>>

Re: [GT] Couple of patches (crash problem)

[Robert A. S. <ra...@ac...>]

System Trader wrote:
> Thanks for the help... replies inline
> 
> On Mon, Aug 8, 2011 at 2:43 PM, Robert A. Schmied <ra...@ac...> wrote:
> 
> 
>>System Trader wrote:
>>
>>
>>>Hi all,
>>>
>>>I was firing this software up and messing around with it using the
>>>following
>>>test system:
>>>
>>>Aliases::Global::Williams    SY:Generic {S:Generic:Above {I:WilliamsR}
>>>-20}
>>>{S:Generic:Below {I:WilliamsR} -80}|CS:OppositeSignal
>>>
>>>(yeah this one is not going to make anybody rich :)
>>>
>>
>>aloha nick
>>
>>after monkeying around with gts innards via my posted test hacks and
>>getting
>>nothing of useful insight i came back to this posting and looked at your
>>trading system sys-sig-indic description in more detail and i'm now more
>>confused and concerned ... note -- it's is possible i've completely missed
>>your forest with my trees, so if that's the case please show me the light
>>...
>>
>>1) CS:OppositeSignal has never worked well at least from my prospective ...
>> make the effort to craft specific closing rules for long and short
>>positions
>> independent of the take position rules.
>>
> 
> 
> Do you mean that it never worked well for trading, or never worked well
> code-wise?  My goal (it will be tough) is to develop a simple grammar for
> sys-sig-indic that can be used for optimization.

trading wise -- while it seems intuitive that a 'go long' signal should also
signify 'close short' it doesn't appear to work well in practice.

it might be fine as the last resort close strat, but as the only close strat
it tends to give any gains back before closing the position.

> 
> 
> 
>>2) below you indicate Williams%R indicator was not setting a dependency of
>>the
>> number of days (time-periods) supplied as arguments.  however, none of the
>> williams%R indicator sys-sig-indic descriptions shown in the trading
>>system
>> pass any arguments to the williams%R indicator -- the values -20 and -80
>> are arguments for the signals S:G:Above and S:G:Below respectively.
>>
> 
> 
> I guess I was talking about even the 'default' arguments passed to
> Williams%R -- in this case I was not passing any arguments and getting the
> crash, as the default number of days is 14:

oh -- a crash. that isn't good, you didn't mention that before

i'm not able to dup that here with the trunk head using backtest.pl
as shown below.

can you provide 'everything' you used to generate that crash?
  1) the complete command line
  2) your options file
  3) a minimal subset of the code price data that results in crash
  4) textual description of crash (simple -- is perl just dieing
     or are you getting a *nix crash and core dump)
  5) all the terminal error data
  6) perl version (perl -v)
  7) anything else you think might help me attempt to duplicate ...

thanks

  
> 
> @DEFAULT_ARGS = (14, "{I:Prices HIGH}", "{I:Prices LOW}", "{I:Prices
> CLOSE}");
> 
> but, anyway it looks like you fixed it in the 'ras hacks'... would like to
> get a copy of those :)
> 
> 
>  to pass args to the williams%R indicator they go within the indicator {}
> 
>>eg {I:WilliamsR 20}
>>
>>the sys-sig-indic description development and diagnostic scripts
>>display_*.pl can be used to gain more insight into crafting
>>sys-sig-indic descriptions
>>
>>(note -- these are using gt trunk head)
>>looking at the 'go long' signal 'S:Generic:Above {I:WilliamsR} -20'
>>  ras [ 1356 ] %    display_signal.pl  --start 2011-06-01  S:G:Above T '
>>{I:WilliamsR} -20 '
>>Testing signal Above[{I:WilliamsR 14 {I:Prices HIGH} {I:Prices LOW}
>>{I:Prices CLOSE}}, -20] ...
>>Above[{I:WilliamsR 14 {I:Prices HIGH} {I:Prices LOW} {I:Prices CLOSE}},
>>-20][2011-06-01] = no
>>Above[{I:WilliamsR 14 {I:Prices HIGH} {I:Prices LOW} {I:Prices CLOSE}},
>>-20][2011-06-02] = no
>>
>>and passing a time-period argument
>> ras [ 1357 ] %    display_signal.pl  --start 2011-06-01  S:G:Above T '
>>{I:WilliamsR 7 } -20 '
>>Testing signal Above[{I:WilliamsR 7 {I:Prices HIGH} {I:Prices LOW}
>>{I:Prices CLOSE}}, -20] ...
>>Above[{I:WilliamsR 7 {I:Prices HIGH} {I:Prices LOW} {I:Prices CLOSE}},
>>-20][2011-06-01] = no
>>Above[{I:WilliamsR 7 {I:Prices HIGH} {I:Prices LOW} {I:Prices CLOSE}},
>>-20][2011-06-02] = no
>>
>>
>>since you are creating an alias you can take advantage of the positional
>>argument replacement feature gt provides:
>>
>>Aliases::Global::Williams[]     SY:Generic {S:Generic:Above {I:WilliamsR
>>#1} #2}
>> {S:Generic:Below {I:WilliamsR #3} #4}|CS:OppositeSignal
>>
>>and use it like this Williams[22,-20,22,-80]
>>
>>for example:
>>  % backtest.pl --timeframe day -graph="nick_sys.png" --display-trades
>>'Williams[22,-20,22,-80]' T
>>
>>
>>
>>hope this and my other postings have helped. feel free to query me on
>>anythings that still confuse ...
>>
>>aloha
>>
>>ras
>>
>>
>>
>>note -- i checked the trunk head version of I:Williams%R and it seems to
>>work
>>correctly as is (reading/setting time-period argument as indicated above
>>and below)
>>
>>the default case:
>>  ras [ 1355 ] %    display_indicator.pl  --start 2011-06-29 I:WilliamsR
>>T
>>Calculating indicator WilliamsPercentR[14] ...
>>WilliamsPercentR[14][2011-06-**29] = -9.91735537190064
>>WilliamsPercentR[14][2011-06-**30] = -6.76691729323308
>>WilliamsPercentR[14][2011-07-**01] = -3.20512820512825
>>WilliamsPercentR[14][2011-07-**05] = -9.31677018633554
>>.
>>.
>>.
>>
>>passing time-period value '7'
>>ras [ 1354 ] %    display_indicator.pl  --start 2011-06-29 I:WilliamsR   T
>>7
>>Calculating indicator WilliamsPercentR[7] ...
>>WilliamsPercentR[7] [2011-06-29] = -11.0091743119264
>>WilliamsPercentR[7] [2011-06-30] = -7.4380165289256
>>WilliamsPercentR[7] [2011-07-01] = -3.47222222222227
>>WilliamsPercentR[7] [2011-07-05] = -11.1940298507464
>>
>>
>>and the equivalent ras hack versions (display_indicator.pl is also
>>different)
>>default:
>>ras [ 1347 ] %     display_indicator.pl  --start 2011-06-29 I:WilliamsR
>>t
>>Indicator I:WilliamsR has 1 value ... all values selected
>>      I:WilliamsR/1  <=> WilliamsPercentR[14]
>>pre check dates: $start=2011-06-29  $end=
>>calculator indexes: $first=3146 $last=3173
>>post check dates: $start=2011-06-29 00:00:00 <=> $first=3146
>>                $end  = <=> $last =3173
>>
>>      timeframe day, time periods 3146 .. 3173
>>Calculating indicator ...
>>doin' the 99: $ival=99, $nb_val=1
>>but now: $ival=0, $nb_val=1
>>
>>indicator name "WilliamsPercentR[14]"
>>interval: 3146 .. 3173
>>WilliamsPercentR[14][2011-06-**29] = -9.9174
>>WilliamsPercentR[14][2011-06-**30] = -6.7669
>>WilliamsPercentR[14][2011-07-**01] = -3.2051
>>WilliamsPercentR[14][2011-07-**05] = -9.3168
>>.
>>.
>>.
>>
>>passing time-period value '7'
>>ras [ 1348 ] %      display_indicator.pl  --start 2011-06-29 I:WilliamsR
>>t 7
>>Indicator I:WilliamsR has 1 value ... all values selected
>>      I:WilliamsR/1  <=> WilliamsPercentR[7]
>>pre check dates: $start=2011-06-29  $end=
>>calculator indexes: $first=3146 $last=3173
>>post check dates: $start=2011-06-29 00:00:00 <=> $first=3146
>>                $end  = <=> $last =3173
>>
>>      timeframe day, time periods 3146 .. 3173
>>Calculating indicator ...
>>doin' the 99: $ival=99, $nb_val=1
>>but now: $ival=0, $nb_val=1
>>
>>indicator name "WilliamsPercentR[7]"
>>interval: 3146 .. 3173
>>WilliamsPercentR[7] [2011-06-29] = -11.0092
>>WilliamsPercentR[7] [2011-06-30] = -7.4380
>>WilliamsPercentR[7] [2011-07-01] = -3.4722
>>WilliamsPercentR[7] [2011-07-05] = -11.1940
>>.
>>.
>>.
>>
>>
>>
>>>and found a few small issues.  Of course this is my first time around the
>>>code so grains of salt apply...but was wondering if these patches would
>>>help:
>>>
>>>(1) The Williams%R indicator was not setting a dependency of the number of
>>>days supplied as arguments (I noticed most of the others doing similar
>>>things would either do the below or add the dependency through
>>>add_prices_dependency()).   If this code was not added, there would be an
>>>error:  "Modification of non-creatable array value attempted, subscript -2
>>>at ../GT/CacheValues.pm line 58."
>>>
>>>Index: trunk/GT/Indicators/WilliamsR.**pm
>>>==============================**==============================**=======
>>>--- trunk/GT/Indicators/WilliamsR.**pm    (revision 710)
>>>+++ trunk/GT/Indicators/WilliamsR.**pm    (working copy)
>>>@@ -56,8 +56,8 @@
>>>    $self->{'max'} = GT::Indicators::Generic::**MaxInPeriod->new([
>>>$self->{'args'}->get_arg_**names(1),
>>>                                 $self->{'args'}->get_arg_**names(2)] );
>>>
>>>-    $self->add_indicator_**dependency($self->{'min'}, 1);
>>>-    $self->add_indicator_**dependency($self->{'max'}, 1);
>>>+    $self->add_indicator_**dependency($self->{'min'},
>>>$self->{'args'}->get_arg_**names(1) + 1);
>>>+    $self->add_indicator_**dependency($self->{'max'},
>>>$self->{'args'}->get_arg_**names(1) + 1);
>>> }
>>>
>>> =head2 GT::Indicators::Williams%R::**calculate($calc, $day)
>>>
>>>
>>>(2) The below patch was required when the args to the 'Generic' signal are
>>>not defined during the ramp-up periods (i.e. when $i = 0, 1, 2, etc.).
>>>Otherwise there are a multitude of warnings such as:  "Use of
>>>uninitialized
>>>value in numeric eq (==) at ../GT/Systems/Generic.pm line 92."
>>>
>>>
>>>Index: trunk/GT/Systems/Generic.pm
>>>==============================**==============================**=======
>>>--- trunk/GT/Systems/Generic.pm    (revision 710)
>>>+++ trunk/GT/Systems/Generic.pm    (working copy)
>>>@@ -88,8 +88,9 @@
>>>    my ($self, $calc, $i) = @_;
>>>
>>>    return 0 if (! $self->check_dependencies($**calc, $i));
>>>-
>>>-    if ( $self->{'args'}->get_arg_**values($calc, $i, 1) == 1 )
>>>+
>>>+    if ( defined($self->{'args'}->get_**arg_values($calc, $i, 1)) &&
>>>+     $self->{'args'}->get_arg_**values($calc, $i, 1) == 1 )
>>>    {
>>>    return 1;
>>>    }
>>>@@ -102,6 +103,7 @@
>>>    return 0 if (! $self->check_dependencies($**calc, $i));
>>>
>>>    if ( $self->{'args'}->get_nb_args() >= 2 &&
>>>+     defined($self->{'args'}->get_**arg_values($calc, $i, 2)) &&
>>>     $self->{'args'}->get_arg_**values($calc, $i, 2) == 1 )
>>>    {
>>>    return 1;
>>>
>>>
>>>Nick
>>>
>>>
>>>
>>>------------------------------**------------------------------**
>>>------------
>>>
>>>------------------------------**------------------------------**
>>>------------------
>>>BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
>>>The must-attend event for mobile developers. Connect with experts. Get
>>>tools for creating Super Apps. See the latest technologies.
>>>Sessions, hands-on labs, demos & much more. Register early & save!
>>>http://p.sf.net/sfu/rim-**blackberry-1<http://p.sf.net/sfu/rim-blackberry-1>
>>>
>>
> 

Re: [GT] Couple of patches

[System T. <sys...@gm...>]

Makes sense, thanks for pointing out the tests.  These will be good to use
when adding new modules.

So basically you are saying there is a set of 'ras hacks' that is not
committed to the tree that fixes some of the issues.   Why not commit these
to the tree?  You mention there was some difficulty?  I would be happy to
help with the merge effort if you think it is worthwhile, or help work
through some of the main problems.

Also is it possible to explain what's on the 'exp' branch?  Is it more bug
fixes?

Thanks,

Nick

On Sun, Aug 7, 2011 at 3:50 PM, Robert A. Schmied <ra...@ac...> wrote:

> nick, gt'ers
>
> the basic gt toolkit testing framework (is that the correct term)
> that i've cobbled together to-date for GT::SY objects and methods
> is as follows:
>
> #!/bin/bash -- # perl, to stop looping
> # the following must be on two lines
> eval 'exec perl -S $0 ${1+"$@"}'
> if 0;
>
> #
> # $Id$
>
> use Test::More;
> use Test::Differences;
> use Data::Dumper;
>
> use lib '..';
> use GT::Conf;
> use GT::Eval;
> use GT::DateTime;
>
> my $opt_file = '../GT/t/options';
> my $timeframe = $DAY;
>
> # sample database first date = 1993-01-04
> #                 last date  = 2002-10-04
> #                 number entries = 2425
> my $code = 13000;    # sample database first date=1993-01-04
> my $mid_date = '1998-01-02';
>
> GT::Conf::clear();
> GT::Conf::load( "$opt_file" );
>
> my @object_types = ();
> #
> # to autogenerate the object_types list:
> # ../GT/t/signals.t
>
> my @files = `find ../GT/Signals -name "\*.pm"`;
>
> foreach ( @files ) {
>  s/\.\.\///;
>  s/\//::/g;
>  s/\.pm//;
>
>  # these are known to need parameters
>  # or are known to be learning, practice, or experimental modules
>  # or have other problems
>  #
>  # they should really be placed in either a TODO or SKIP block
>  next if (
>   m@GT::Signals::Prices::TDLow@ ||
>   m@GT::Signals::Prices::TDHi+@ ||
>   # m@GT::Signals::@ ||
>   # m@GT::Signals::@ ||
>   m@ conditional terminating line @
>  );
>  push @object_types, $_;
>
> #print STDERR "module $_\n";
>
> }
>
> plan tests => scalar @object_types * 4;
>
> foreach ( @object_types ) {
>   next if m/^(;|#)/;
>
>   s/^GT:://;
>   chomp;
>   my $obj = $_;
>
>   # don't bother creating objects from master templates
>   next if m/^Signals$/;
>
> print STDERR "\t-->working object $_\n";
>
>   my $o = create_standard_object( $obj );
>   isa_ok
>    ( $o, "GT::$obj",
>     "create_standard_object(    \"GT::$obj\" )\nreturned an object\t\t" );
>
>   can_ok ( $o, 'initialize' );
>   can_ok ( $o, 'detect' );
>   can_ok ( $o, 'detect_interval' );
>
> print STDERR "\n";
>
> }
>
>
>
>
> and for GT:I objects and methods
>
> #!/bin/bash -- # perl, to stop looping
> # the following must be on two lines
> eval 'exec perl -S $0 ${1+"$@"}'
> if 0;
>
> #
> # $Id$
>
> use Test::More;
> use Test::Differences;
> use Data::Dumper;
>
> use lib '..';
> use GT::Conf;
> use GT::Eval;
> use GT::DateTime;
>
> my $opt_file = '../GT/t/options';
> my $timeframe = $DAY;
>
> # sample database first date = 1993-01-04
> #                 last date  = 2002-10-04
> #                 number entries = 2425
> my $code = 13000;    # sample database first date=1993-01-04
> my $mid_date = '1998-01-02';
>
> GT::Conf::clear();
> GT::Conf::load( "$opt_file" );
>
> my @object_types = ();
> #
> # to autogenerate the object_types list:
> #
> my @files = `find ../GT/Indicators -name "\*.pm"`;
>  foreach ( @files ) {
>   s/\.\.\///;
>   s/\//::/g;
>   s/\.pm//;
>
>   #
>   # these are known to need parameters
>   # or are known to be learning, practice, or experimental modules
>   # or have other problems
>   #
>   # and as a result are explicitly skipped if encountered
>   #
>   # they should really be placed in either a TODO or SKIP block
>   #
>   next if (
>     m@GT::Indicators::**BPCorrelation@ ||
>     m@GT::Indicators::MASS@ ||
>     m@GT::Indicators::BBBandwidth@ ||
>     m@GT::Indicators::TDLineMax@ ||
>     m@GT::Indicators::TDLineMin@ ||
>     m@GT::Indicators::Test@ ||
>     m@GT::Indicators::TEST@ ||
>     m@GT::Indicators::STO-merge@ ||
>     m@GT::Indicators::DSS_dbs@ ||
>     m@GT::Indicators::ADX_tw_exp@ ||
>     m@GT::Indicators::olfs_VIDYA@ ||
>     m@GT::Indicators::TDLineMinO@ ||
>     m@GT::Indicators::Generic::**mymaxinperiod@ ||
>     m@GT::Indicators::pm_12oct_**HLCVolatility@ ||
>     m@GT::Indicators::TDsupport@ ||
>     m@GT::Indicators::SnR_devel_**hist::@ ||
>     m@GT::Indicators::SnR@ ||
>     m@GT::Indicators::SnR_h@ ||
>     m@GT::Indicators::Generic::**MaxInPeriod_clk@ ||
>     m@GT::Indicators::Generic::**MinInPeriod_clk@ ||
>     m@GT::Indicators::STO_a@ ||
>     m@GT::Indicators::STO_b@ ||
>     m@GT::Indicators::STO_foobar@ ||
>     #m@GT::Indicators::STOkw@ ||
>     # m@GT::Indicators::@ ||
>     # m@GT::Indicators::@ ||
>     m@ conditional terminating line @
>   );
>   push @object_types, $_;
>  }
>
> plan tests => scalar @object_types * 5;
>
> foreach ( @object_types ) {
>   next if m/^(;|#)/;
>
>   s/^GT:://;
>   chomp;
>   my $obj = $_;
>
>   # don't bother creating objects from master templates
>   next if m/^Indicators$/;
>
>   my $indic_obj = create_standard_object( $obj );
>   isa_ok
>    ( $indic_obj, "GT::$obj",
>     "create_standard_object(    \"GT::$obj\" )\nreturned an object\t\t" );
>
>   can_ok ( $indic_obj, 'initialize' );
>   can_ok ( $indic_obj, 'calculate_all' );
>   can_ok ( $indic_obj, 'calculate_interval' );
>   can_ok ( $indic_obj, 'calculate' );
>
> }
>
>
> these scripts are located in the gt hierachy at GT/t and at least in
> my way of doing things can be run with cwd being the gt Scripts dir.
>
> as you can see these tests do very little (nothing) with arguments or
> parameters, but are helpful to ensure the minimal methods are present.
> they might be useful if someone is interested in extending them.
>
> i've also been told the horrible shebang construct fails on linux, but
> prefer it or #!/usr/bin/env perl to one with a fixed perl path.
>
> i've got similar hacks for some of the other gt modules. my complete
> gt ras hack is available on request in the form of three tarballs.
> please note it isn't practical to attempt to merge it with any known
> branch of gt as others who have tried will attest, that includes me.
> so if you are at all interested you need to consider it an alternate gt.
>
>
> aloha
>
> ras
>

Re: [GT] Couple of patches

[Robert A. S. <ra...@ac...>]

nick, gt'ers

the basic gt toolkit testing framework (is that the correct term)
that i've cobbled together to-date for GT::SY objects and methods
is as follows:

#!/bin/bash -- # perl, to stop looping
# the following must be on two lines
eval 'exec perl -S $0 ${1+"$@"}'
 if 0;

#
# $Id$

use Test::More;
use Test::Differences;
use Data::Dumper;

use lib '..';
use GT::Conf;
use GT::Eval;
use GT::DateTime;

my $opt_file = '../GT/t/options';
my $timeframe = $DAY;

# sample database first date = 1993-01-04
#                 last date  = 2002-10-04
#                 number entries = 2425
my $code = 13000;    # sample database first date=1993-01-04
my $mid_date = '1998-01-02';

GT::Conf::clear();
GT::Conf::load( "$opt_file" );

my @object_types = ();
#
# to autogenerate the object_types list:
# ../GT/t/signals.t

my @files = `find ../GT/Signals -name "\*.pm"`;

foreach ( @files ) {
  s/\.\.\///;
  s/\//::/g;
  s/\.pm//;

  # these are known to need parameters
  # or are known to be learning, practice, or experimental modules
  # or have other problems
  #
  # they should really be placed in either a TODO or SKIP block
  next if (
    m@GT::Signals::Prices::TDLow@ ||
    m@GT::Signals::Prices::TDHi+@ ||
    # m@GT::Signals::@ ||
    # m@GT::Signals::@ ||
    m@ conditional terminating line @
  );
  push @object_types, $_;

#print STDERR "module $_\n";

}

plan tests => scalar @object_types * 4;

foreach ( @object_types ) {
    next if m/^(;|#)/;

    s/^GT:://;
    chomp;
    my $obj = $_;

    # don't bother creating objects from master templates
    next if m/^Signals$/;

print STDERR "\t-->working object $_\n";

    my $o = create_standard_object( $obj );
    isa_ok
     ( $o, "GT::$obj",
      "create_standard_object(    \"GT::$obj\" )\nreturned an object\t\t" );

    can_ok ( $o, 'initialize' );
    can_ok ( $o, 'detect' );
    can_ok ( $o, 'detect_interval' );

print STDERR "\n";

}




and for GT:I objects and methods

#!/bin/bash -- # perl, to stop looping
# the following must be on two lines
eval 'exec perl -S $0 ${1+"$@"}'
 if 0;

#
# $Id$

use Test::More;
use Test::Differences;
use Data::Dumper;

use lib '..';
use GT::Conf;
use GT::Eval;
use GT::DateTime;

my $opt_file = '../GT/t/options';
my $timeframe = $DAY;

# sample database first date = 1993-01-04
#                 last date  = 2002-10-04
#                 number entries = 2425
my $code = 13000;    # sample database first date=1993-01-04
my $mid_date = '1998-01-02';

GT::Conf::clear();
GT::Conf::load( "$opt_file" );

my @object_types = ();
#
# to autogenerate the object_types list:
#
my @files = `find ../GT/Indicators -name "\*.pm"`;
  foreach ( @files ) {
    s/\.\.\///;
    s/\//::/g;
    s/\.pm//;

    #
    # these are known to need parameters
    # or are known to be learning, practice, or experimental modules
    # or have other problems
    #
    # and as a result are explicitly skipped if encountered
    #
    # they should really be placed in either a TODO or SKIP block
    #
    next if (
      m@GT::Indicators::BPCorrelation@ ||
      m@GT::Indicators::MASS@ ||
      m@GT::Indicators::BBBandwidth@ ||
      m@GT::Indicators::TDLineMax@ ||
      m@GT::Indicators::TDLineMin@ ||
      m@GT::Indicators::Test@ ||
      m@GT::Indicators::TEST@ ||
      m@GT::Indicators::STO-merge@ ||
      m@GT::Indicators::DSS_dbs@ ||
      m@GT::Indicators::ADX_tw_exp@ ||
      m@GT::Indicators::olfs_VIDYA@ ||
      m@GT::Indicators::TDLineMinO@ ||
      m@GT::Indicators::Generic::mymaxinperiod@ ||
      m@GT::Indicators::pm_12oct_HLCVolatility@ ||
      m@GT::Indicators::TDsupport@ ||
      m@GT::Indicators::SnR_devel_hist::@ ||
      m@GT::Indicators::SnR@ ||
      m@GT::Indicators::SnR_h@ ||
      m@GT::Indicators::Generic::MaxInPeriod_clk@ ||
      m@GT::Indicators::Generic::MinInPeriod_clk@ ||
      m@GT::Indicators::STO_a@ ||
      m@GT::Indicators::STO_b@ ||
      m@GT::Indicators::STO_foobar@ ||
      #m@GT::Indicators::STOkw@ ||
      # m@GT::Indicators::@ ||
      # m@GT::Indicators::@ ||
      m@ conditional terminating line @
    );
    push @object_types, $_;
  }

plan tests => scalar @object_types * 5;

foreach ( @object_types ) {
    next if m/^(;|#)/;

    s/^GT:://;
    chomp;
    my $obj = $_;

    # don't bother creating objects from master templates
    next if m/^Indicators$/;

    my $indic_obj = create_standard_object( $obj );
    isa_ok
     ( $indic_obj, "GT::$obj",
      "create_standard_object(    \"GT::$obj\" )\nreturned an object\t\t" );

    can_ok ( $indic_obj, 'initialize' );
    can_ok ( $indic_obj, 'calculate_all' );
    can_ok ( $indic_obj, 'calculate_interval' );
    can_ok ( $indic_obj, 'calculate' );

}


these scripts are located in the gt hierachy at GT/t and at least in
my way of doing things can be run with cwd being the gt Scripts dir.

as you can see these tests do very little (nothing) with arguments or
parameters, but are helpful to ensure the minimal methods are present.
they might be useful if someone is interested in extending them.

i've also been told the horrible shebang construct fails on linux, but
prefer it or #!/usr/bin/env perl to one with a fixed perl path.

i've got similar hacks for some of the other gt modules. my complete
gt ras hack is available on request in the form of three tarballs.
please note it isn't practical to attempt to merge it with any known
branch of gt as others who have tried will attest, that includes me.
so if you are at all interested you need to consider it an alternate gt.


aloha

ras

Re: [GT] Couple of patches (SY::Generic module)

[Robert A. S. <ra...@ac...>]

System Trader wrote:
> Hi all,
> 
> I was firing this software up and messing around with it using the following
> test system:
> 
> Aliases::Global::Williams    SY:Generic {S:Generic:Above {I:WilliamsR} -20}
> {S:Generic:Below {I:WilliamsR} -80}|CS:OppositeSignal
> 
> (yeah this one is not going to make anybody rich :)
> 
> and found a few small issues.  Of course this is my first time around the
> code so grains of salt apply...but was wondering if these patches would
> help:
> 
> (1) The Williams%R indicator was not setting a dependency of the number of
> days supplied as arguments (I noticed most of the others doing similar
> things would either do the below or add the dependency through
> add_prices_dependency()).   If this code was not added, there would be an
> error:  "Modification of non-creatable array value attempted, subscript -2
> at ../GT/CacheValues.pm line 58."
> 
> Index: trunk/GT/Indicators/WilliamsR.pm
> ===================================================================
> --- trunk/GT/Indicators/WilliamsR.pm    (revision 710)
> +++ trunk/GT/Indicators/WilliamsR.pm    (working copy)
> @@ -56,8 +56,8 @@
>      $self->{'max'} = GT::Indicators::Generic::MaxInPeriod->new([
> $self->{'args'}->get_arg_names(1),
>                                   $self->{'args'}->get_arg_names(2)] );
> 
> -    $self->add_indicator_dependency($self->{'min'}, 1);
> -    $self->add_indicator_dependency($self->{'max'}, 1);
> +    $self->add_indicator_dependency($self->{'min'},
> $self->{'args'}->get_arg_names(1) + 1);
> +    $self->add_indicator_dependency($self->{'max'},
> $self->{'args'}->get_arg_names(1) + 1);
>  }
> 
>  =head2 GT::Indicators::Williams%R::calculate($calc, $day)
> 
> 
> (2) The below patch was required when the args to the 'Generic' signal are
> not defined during the ramp-up periods (i.e. when $i = 0, 1, 2, etc.).
> Otherwise there are a multitude of warnings such as:  "Use of uninitialized
> value in numeric eq (==) at ../GT/Systems/Generic.pm line 92."
> 
> 
> Index: trunk/GT/Systems/Generic.pm
> ===================================================================
> --- trunk/GT/Systems/Generic.pm    (revision 710)
> +++ trunk/GT/Systems/Generic.pm    (working copy)
> @@ -88,8 +88,9 @@
>      my ($self, $calc, $i) = @_;
> 
>      return 0 if (! $self->check_dependencies($calc, $i));
> -
> -    if ( $self->{'args'}->get_arg_values($calc, $i, 1) == 1 )
> +
> +    if ( defined($self->{'args'}->get_arg_values($calc, $i, 1)) &&
> +     $self->{'args'}->get_arg_values($calc, $i, 1) == 1 )
>      {
>      return 1;
>      }
> @@ -102,6 +103,7 @@
>      return 0 if (! $self->check_dependencies($calc, $i));
> 
>      if ( $self->{'args'}->get_nb_args() >= 2 &&
> +     defined($self->{'args'}->get_arg_values($calc, $i, 2)) &&
>       $self->{'args'}->get_arg_values($calc, $i, 2) == 1 )
>      {
>      return 1;

aloha nick

for the ras hack Systems/Generic.pm i've got:


sub long_signal {
    my ($self, $calc, $i) = @_;
    
    return 0 unless $self->check_dependencies($calc, $i);

    my $av1 = $self->{'args'}->get_arg_values($calc, $i, 1);
    return 0 if ! defined $av1 || $av1 <= 0;
    return 1;
}

sub short_signal {
    my ($self, $calc, $i) = @_;
    
    return 0 unless $self->check_dependencies($calc, $i);

    return 0 unless $self->{'args'}->get_nb_args() >= 2;
    my $av2 = $self->{'args'}->get_arg_values($calc, $i, 2);
    return 0 if ! defined $av2 || $av2 <= 0;
    return 1;
}

with a change log entry from 2009/12/26: improved long/short_signal detection logic to avoid annoying warning messages


aloha

ras



> 
> 
> Nick
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts. 
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1

Re: [GT] Couple of patches (WilliamsR)

[Robert A. S. <ra...@ac...>]

System Trader wrote:
> Hi all,
> 
> I was firing this software up and messing around with it using the following
> test system:
> 
> Aliases::Global::Williams    SY:Generic {S:Generic:Above {I:WilliamsR} -20}
> {S:Generic:Below {I:WilliamsR} -80}|CS:OppositeSignal
> 
> (yeah this one is not going to make anybody rich :)
> 
> and found a few small issues.  Of course this is my first time around the
> code so grains of salt apply...but was wondering if these patches would
> help:
> 
> (1) The Williams%R indicator was not setting a dependency of the number of
> days supplied as arguments (I noticed most of the others doing similar
> things would either do the below or add the dependency through
> add_prices_dependency()).   If this code was not added, there would be an
> error:  "Modification of non-creatable array value attempted, subscript -2
> at ../GT/CacheValues.pm line 58."
> 
> Index: trunk/GT/Indicators/WilliamsR.pm
> ===================================================================
> --- trunk/GT/Indicators/WilliamsR.pm    (revision 710)
> +++ trunk/GT/Indicators/WilliamsR.pm    (working copy)
> @@ -56,8 +56,8 @@
>      $self->{'max'} = GT::Indicators::Generic::MaxInPeriod->new([
> $self->{'args'}->get_arg_names(1),
>                                   $self->{'args'}->get_arg_names(2)] );
> 
> -    $self->add_indicator_dependency($self->{'min'}, 1);
> -    $self->add_indicator_dependency($self->{'max'}, 1);
> +    $self->add_indicator_dependency($self->{'min'},
> $self->{'args'}->get_arg_names(1) + 1);
> +    $self->add_indicator_dependency($self->{'max'},
> $self->{'args'}->get_arg_names(1) + 1);
>  }
> 
>  =head2 GT::Indicators::Williams%R::calculate($calc, $day)

aloha nick (aka 'system trader')

thanks for the above patch for the WilliamsR indicator module.

in my ras hack for this module i have the following two statements
which differ from those you propose. plus the third statement shown
below which isn't in your patch or the trunk version.

    $self->add_indicator_dependency($self->{'min'}, $self->{'args'}->get_arg_names(1));
    $self->add_indicator_dependency($self->{'max'}, $self->{'args'}->get_arg_names(1));
    $self->add_arg_dependency(4, 1);

unfortunately i've got nothing that documents why/how/who suggested them.
it is unlikely i can up with them on my own -- possibly they stem from the
thomas weigert exp branch or ???

without some additional research and or testing method i'm not sure which
might be the most correct solution ...

anyone want to propose a test methodology that tests explicitly for sys-sig-indic
parameter passing?


aloha

ras

ps -- i will deal with the systems module patch in a separate post -- ras

> 
> 
> (2) The below patch was required when the args to the 'Generic' signal are
> not defined during the ramp-up periods (i.e. when $i = 0, 1, 2, etc.).
> Otherwise there are a multitude of warnings such as:  "Use of uninitialized
> value in numeric eq (==) at ../GT/Systems/Generic.pm line 92."
> 
> 
> Index: trunk/GT/Systems/Generic.pm
> ===================================================================
> --- trunk/GT/Systems/Generic.pm    (revision 710)
> +++ trunk/GT/Systems/Generic.pm    (working copy)
> @@ -88,8 +88,9 @@
>      my ($self, $calc, $i) = @_;
> 
>      return 0 if (! $self->check_dependencies($calc, $i));
> -
> -    if ( $self->{'args'}->get_arg_values($calc, $i, 1) == 1 )
> +
> +    if ( defined($self->{'args'}->get_arg_values($calc, $i, 1)) &&
> +     $self->{'args'}->get_arg_values($calc, $i, 1) == 1 )
>      {
>      return 1;
>      }
> @@ -102,6 +103,7 @@
>      return 0 if (! $self->check_dependencies($calc, $i));
> 
>      if ( $self->{'args'}->get_nb_args() >= 2 &&
> +     defined($self->{'args'}->get_arg_values($calc, $i, 2)) &&
>       $self->{'args'}->get_arg_values($calc, $i, 2) == 1 )
>      {
>      return 1;
> 
> 
> Nick
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts. 
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1

[GT] Couple of patches

[System T. <sys...@gm...>]

Hi all,

I was firing this software up and messing around with it using the following
test system:

Aliases::Global::Williams    SY:Generic {S:Generic:Above {I:WilliamsR} -20}
{S:Generic:Below {I:WilliamsR} -80}|CS:OppositeSignal

(yeah this one is not going to make anybody rich :)

and found a few small issues.  Of course this is my first time around the
code so grains of salt apply...but was wondering if these patches would
help:

(1) The Williams%R indicator was not setting a dependency of the number of
days supplied as arguments (I noticed most of the others doing similar
things would either do the below or add the dependency through
add_prices_dependency()).   If this code was not added, there would be an
error:  "Modification of non-creatable array value attempted, subscript -2
at ../GT/CacheValues.pm line 58."

Index: trunk/GT/Indicators/WilliamsR.pm
===================================================================
--- trunk/GT/Indicators/WilliamsR.pm    (revision 710)
+++ trunk/GT/Indicators/WilliamsR.pm    (working copy)
@@ -56,8 +56,8 @@
     $self->{'max'} = GT::Indicators::Generic::MaxInPeriod->new([
$self->{'args'}->get_arg_names(1),
                                  $self->{'args'}->get_arg_names(2)] );

-    $self->add_indicator_dependency($self->{'min'}, 1);
-    $self->add_indicator_dependency($self->{'max'}, 1);
+    $self->add_indicator_dependency($self->{'min'},
$self->{'args'}->get_arg_names(1) + 1);
+    $self->add_indicator_dependency($self->{'max'},
$self->{'args'}->get_arg_names(1) + 1);
 }

 =head2 GT::Indicators::Williams%R::calculate($calc, $day)


(2) The below patch was required when the args to the 'Generic' signal are
not defined during the ramp-up periods (i.e. when $i = 0, 1, 2, etc.).
Otherwise there are a multitude of warnings such as:  "Use of uninitialized
value in numeric eq (==) at ../GT/Systems/Generic.pm line 92."


Index: trunk/GT/Systems/Generic.pm
===================================================================
--- trunk/GT/Systems/Generic.pm    (revision 710)
+++ trunk/GT/Systems/Generic.pm    (working copy)
@@ -88,8 +88,9 @@
     my ($self, $calc, $i) = @_;

     return 0 if (! $self->check_dependencies($calc, $i));
-
-    if ( $self->{'args'}->get_arg_values($calc, $i, 1) == 1 )
+
+    if ( defined($self->{'args'}->get_arg_values($calc, $i, 1)) &&
+     $self->{'args'}->get_arg_values($calc, $i, 1) == 1 )
     {
     return 1;
     }
@@ -102,6 +103,7 @@
     return 0 if (! $self->check_dependencies($calc, $i));

     if ( $self->{'args'}->get_nb_args() >= 2 &&
+     defined($self->{'args'}->get_arg_values($calc, $i, 2)) &&
      $self->{'args'}->get_arg_values($calc, $i, 2) == 1 )
     {
     return 1;


Nick

Re: [GT] Mac OS porting

[Mark M. <ma...@gm...>]

Nicely timed question! I actuallt have it running fine on OSX. I set it up
about a year ago. Let me poke around for my notes, but I don't think it was
hard.

Mark

On May 20, 2011 3:38 AM, "Erik Colson" <ec...@ec...> wrote:


On 18 May 2011, at 20:34, Eugene Shklyar wrote:

> How hard to port GT on Mac OS?
Ehlo,

I'm using GT on MacOSX 10.6.
Not hard at all ;)
I would recommend you to not use MacOSX system perl. Install one in your
home directory then you should be fine..

best
--
erik
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay

Re: [GT] Mac OS porting

[Erik C. <ec...@ec...>]

On 18 May 2011, at 20:34, Eugene Shklyar wrote:

> How hard to port GT on Mac OS?

Ehlo,

I'm using GT on MacOSX 10.6.
Not hard at all ;)
I would recommend you to not use MacOSX system perl. Install one in your home directory then you should be fine..

best
--
erik

Re: [GT] Mac OS porting

[Robert A. S. <ra...@ac...>]

Eugene Shklyar wrote:
> Hi,
> 
> How hard to port GT on Mac OS?

aloha eugene

that isn't a question that has come up recently, but i seem to recall
someone using gt on a mac in the distant past.

i'll go out on the limb, turn around and start chopping on the branch
and say 'trivial' but then quickly add this caveat: gt depends on a lot
of perl modules and those require a couple of c-libraries. if you can
satisfy the perl module dependencies then gt should work just fine
out of the tarball.

speaking of tarballs -- make sure you download from the svn repo
either via a repo clone or tarballs (http://geniustrader.org/development.html).
use either the main trunk head (recommended) or the exp branch head;
the others, including the tarball downloads on the main sourceforge
web-page are unsupported and obsolete.

[see the ps and attached file too]
look over the dependencies list (http://geniustrader.org) the
first time tutorial and especially the user guide and make sure
your mac has the needed perl modules. you should be able to get
them from cpan if they aren't already installed.

likely the largest issue will be the c library for gd. note there are
two things needed for gd; the c library, libgd and the gd perl module GD.pm.
the alternative graphics package is svg, but that isn't as well developed
in gt since i'm unable to get it fully functional on my antique os.

what sort of stock prices data base are you planning on using?
beancounter is end-of-day only and is perl so should be ok on the mac,
with anything else you are sort-of on your own, but i'm sure the
mac will support any reasonable scheme you want to implement.

yell if you run into a problem you can't solve and we will try to
give you a hand.

aloha

ras


ps -- eugene, i've attached an experimental perl script that will check
your system for the perl prerequisites that gt depends on. it only
requires the perl module Module::Build.
you can run it from a command line like this
  $ perl Build.PL
or if it's execute bit is set and you have /usr/bin/env
  $ Build.PL
i'd appreciate any feedback on this script so i can continue to evaluate
it's usefulness ... feel free to email me directly the complete output
from any runs you do with it. thanks -- ras

> 
> ---
> Regards,
> 
> Eugene Shklyar

<snip>

[GT] Mac OS porting

[Eugene S. <shk...@gm...>]

Hi,

How hard to port GT on Mac OS?

---
Regards,

Eugene Shklyar
617-510-6176

[GT] exp branch

[Erik C. <ec...@ec...>]

hi,

any reason why GT/Graphics/Object/Trades.pm is only in trunk and not in exp ?

best
--
erik

Re: [GT] Display indicator with different tameframe

[Robert A. S. <ra...@ac...>]

Eric Lemesre wrote:
> Hello,
> 
> it is possible to calculate an indicator on a timeframe (week) and to use it
> on another timeframe (day)?
> exemple :
> build a signal with
>  if I:G:Eval 100 * {I:Generic:Divide {I:Generic:Diff {I:TMA 30}}
> {I:Generic:PeriodAgo 1 {I:TMA 30}}} >= 0.25 of CAC 40  (with timeframe week)
> detect signal bullish with candle configuration for day timeframe

eric

if this 

display_indicator.pl --start 2010-04-04 --end 2011-04-22 \
--timeframe day \
I:G:If  ALU \
'{ I:G:Eval {I:G:Eval 100 * { I:G:Eval { I:G:Divide {I:G:Diff {I:TMA 30 {I:Prices CLOSE}} 1} {I:G:PeriodAgo 1 {I:TMA 30 {I:Prices CLOSE}}} } } } \
 >= {I:G:Eval 0.25 * {I:FromTimeframe {I:Prices CLOSE} week 0}}} \
     {I:G:Eval sprintf qq/yes/} \
     {I:G:Eval sprintf qq/no/} \
}' >&  el_di4.log

is more what you are wanting/expecting then a version of the signal
for it is below.

note that on a limited spot check of about 15 symbols only alu actually
trips the signal -- twice: once late sep 2010 and again in mid feb 2011.

don't know if this means it's a good signal or not, but those are my findings.

display_signal.pl --start 2010-04-04 --end 2011-04-22 \
 --timeframe day  \
S:G:StillTrue  ALU  \
 ' { S:Generic:Above { \
    I:G:Eval 100 * { I:G:Eval { I:G:Divide {I:G:Diff {I:TMA 30 {I:Prices CLOSE}} 1} {I:G:PeriodAgo 1 {I:TMA 30 {I:Prices CLOSE}}}}}} \
    {I:G:Eval 0.25 * {I:FromTimeframe {I:Prices CLOSE} week 0}} \
    } \
    {S:Generic:CrossOverDown { \
      I:G:Eval 100 * { I:G:Eval { I:G:Divide {I:G:Diff {I:TMA 30 {I:Prices CLOSE}} 1} {I:G:PeriodAgo 1 {I:TMA 30 {I:Prices CLOSE}}}}}} \
      {I:G:Eval 0.20 * {I:FromTimeframe {I:Prices CLOSE} week 0}} \
    } \
'  >&  el_si.log



aloha

ras

> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Fulfilling the Lean Software Promise
> Lean software platforms are now widely adopted and the benefits have been 
> demonstrated beyond question. Learn why your peers are replacing JEE 
> containers with lightweight application servers - and what you can gain 
> from the move. http://p.sf.net/sfu/vmware-sfemails

Re: [GT] Display indicator with different tameframe

[Robert A. S. <ra...@ac...>]

Eric Lemesre wrote:
> Hello,
> 
> it is possible to calculate an indicator on a timeframe (week) and to use it
> on another timeframe (day)?
> exemple :
> build a signal with
>  if I:G:Eval 100 * {I:Generic:Divide {I:Generic:Diff {I:TMA 30}}
> {I:Generic:PeriodAgo 1 {I:TMA 30}}} >= 0.25 of CAC 40  (with timeframe week)
> detect signal bullish with candle configuration for day timeframe

eric

i don't understand the math you are attempting in the above.
i don't have symbol CAC_40 so i used to ALU (in USD) instead
maybe the DJI would have been a better selection?

display_indicator.pl --start 2011-04-04 --end 2011-04-22 \
 --timeframe day \
 I:G:Eval  ALU \
'100 * { I:G:Eval { I:G:Divide {I:G:Diff {I:TMA 30 {I:Prices CLOSE}} 1} {I:G:PeriodAgo 1 {I:TMA 30 {I:Prices CLOSE}}} } } \
 '
works, yields small reals in range from 0.3 to 0.6

  display_indicator.pl --start 2011-04-04 --end 2011-04-22 \
 --timeframe day I:FromTimeframe  ALU \
' {I:Prices CLOSE} week 0' 

also works, yielding the weekly values in range from, 5.7 to 6.14 (usd)

but i don't understand the next step in the formula -- sys-sig-indics like the
following all lead to a 'missing operator expected error' with the intermediate
results as shown (using the ras-hack gt toolkit and display_indicator.pl)

 display_indicator.pl --start 2011-04-04 --end 2011-04-22 \
 --timeframe day \
 I:G:Eval  ALU \
'{ I:G:Eval 100 * { I:G:Eval { I:G:Divide {I:G:Diff {I:TMA 30 {I:Prices CLOSE}} 1} {I:G:PeriodAgo 1 {I:TMA 30 {I:Prices CLOSE}}} } } \
   {I:FromTimeframe {I:Prices CLOSE} week 0} }  >= 0.25 \
 '
.
.
.
indicator name "Eval[{I:G:Eval 100 * {I:G:Eval {I:G:Divide {I:G:Diff {I:TMA 30 {I:Prices CLOSE}} 1} {I:G:PeriodAgo 1 {I:TMA 30 {I:Prices CLOSE}}}}} {I:FromTimeframe {I:Prices CLOSE} week 0}}, >=, 0.25]"
Number found where operator expected at (eval 45) line 1, near "0.00363130711164181 5.73"
        (Missing operator before  5.73?)
syntax error at (eval 45) line 1, near "0.00363130711164181 5.73"
 :  100 * 0.00363130711164181 5.73 at ../GT/Indicators/Generic/Eval.pm line 114.

so the question is: what math or comparison is needed with respect to the
">= 0.25 of CAC 40  (with timeframe week)" component

maybe this is more what you are wanting -- note it's still and indicator
not a signal ...

display_indicator.pl --start 2010-04-04 --end 2011-04-22 \
 --timeframe day \
 I:G:If  ALU \
'{ I:G:Eval {I:G:Eval 100 * { I:G:Eval { I:G:Divide {I:G:Diff {I:TMA 30 {I:Prices CLOSE}} 1} {I:G:PeriodAgo 1 {I:TMA 30 {I:Prices CLOSE}}} } } } \
  >= {I:G:Eval 0.25 * {I:FromTimeframe {I:Prices CLOSE} week 0}}} \
      {I:G:Eval sprintf qq/yes/} \
      {I:G:Eval sprintf qq/no/} \
 }' >&  el_di4.log

aloha

ras

> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Fulfilling the Lean Software Promise
> Lean software platforms are now widely adopted and the benefits have been 
> demonstrated beyond question. Learn why your peers are replacing JEE 
> containers with lightweight application servers - and what you can gain 
> from the move. http://p.sf.net/sfu/vmware-sfemails

Re: [GT] Display Complexe indicator

[Eric L. <eri...@gm...>]

Hi ras

Thanks for your reponse.

Eric Lemesre
de mon Nexus One
Le 24 avr. 2011 01:16, "Robert A. Schmied" <ra...@ac...> a écrit :
> Eric Lemesre wrote:
>> Hi ras,
>>
>> It works !!
>> Thank but with this part of code you can have 2 form :
>> % display_indicator.pl I:Generic:Divide --start date --end date T
>> '{I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}'
>> and this form
>> %display_indicator.pl --start date --end date "{I:Generic:Divide
>> {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}}" T
>>
>> in bash { is significant but
>> exactly the same indicator as for signal.
>> I am afraid to have work for nothing ;-)
>
> i'm not sure i understand what you mean here, but the various shells
> treat quotes, variable/macro expansions and escapes in various ways.
>
> the csh (which isn't the best selection (also might include the zsh and
> tcsh), but that shell is what i was weened on so i just keep using it)
> considers the single quote (') to mean don't look into this argument
> at all, just pass it to the command intact. the double quote (") allows
> the shell to parse the argument and expand things it (the shell) thinks
> are meant for it to mess with; things like shell variables and environment
> variables, shell filename metachars like *? and shell macros like {}.
>
> methinks the bash uses very similar conventions.
>
> now, if for some reason you want to use the double quote (") to enclose
> the argument you can use the 'escape the next char only' escape method
> which requires the char '\' to immediately preceed the shell metachar
> like this:
> % display_indicator.pl I:Generic:Divide --start date --end date T
> "\{I:Generic:Diff \{I:EMA 30\}\} ..."
>
> but unless you type a whole lot better than me that gets problematic
> not to mention unusable in a cut+paste mode trying to define and prove
> a particular sys-sig-indic description.
>
> aloha
>
> ras
>
> ps -- looking at your 2nd example again but ignoring the double quotes:
>
>> %display_indicator.pl --start date --end date "{I:Generic:Divide
>> {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}}" T
>
> the way display_indicator.pl works it to take an indicator, a symbol
> any parameters for the indicator plus various coomand options and
> return the results. the important thing to understand is in this
sys-sig-indic
>
> {I:Generic:Divide {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1
{I:EMA 30}}}}
>
> the indicator is I:Generic:Divide and the rest of the stuff are
> parameters for that indicator, so for the display_*.pl commands
> the sys-sig-indic must be broken into bits and pieces.
>
> the ras-hack gt toolkit and display_indicator.pl yields the following:
>
> ras [ 9106 ] % display_indicator.pl --start 1mar11 --end yesterday \
> 'I:Generic:Divide {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1
{I:EMA 30}}}' ALU
> display_indicator.pl: warning: humm i read indicator_name as
"I:Generic:Divide {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA
30}}}"
> unfortunately i really don't want the indicator to include curly brackets
({})
> or the complete word Indicator. (I:<indicator_module>) is all i want.
>
> i'm going to continue, but i don't think you will be getting much further
>
> for reference <indicator_module> is typically:
> I:RSI, I:BOL, I:CMO, I:MACD, I:AROON, etc
> list the directory ../GT/Indicators for a complete list
>
> display_indicator.pl: cso: error: failed to create following standard obj:
> "use GT::Indicators::Generic::Divide {Indicators::Generic::Diff
{Indicators::EMA 30}} {Indicators::Generic::PeriodAgo 1 {Indicators::EMA
30}}};
> $object = GT::Indicators::Generic::Divide {Indicators::Generic::Diff
{Indicators::EMA 30}} {Indicators::Generic::PeriodAgo 1 {Indicators::EMA
30}}}->new();"
>
> the perl error: syntax error at (eval 15) line 1, near "use
GT::Indicators::Generic::Divide {"
>
> on the other hand
>
> ras [ 9107 ] % display_indicator.pl --start 1mar11 --end yesterday \
> I:Generic:Divide ALU '{I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1
{I:EMA 30}}}'
> Indicator I:Generic:Divide has 1 value ... all values selected
> I:Generic:Divide/1 <=> Divide[{I:G:Diff {I:EMA 30 {I:Prices CLOSE}} 1},
{I:G:PeriodAgo 1 {I:EMA 30 {I:Prices CLOSE}}}, }]
> pre check dates: $start=2011-03-01 $end=2011-04-22
> calculator indexes: $first=1067 $last=1104
> post check dates: $start=2011-03-01 00:00:00 <=> $first=1067
> $end =2011-04-22 00:00:00 <=> $last =1104
>
> timeframe day, time periods 1067 .. 1104
> Calculating indicator ...
> doin' the 99: $ival=99, $nb_val=1
> but now: $ival=0, $nb_val=1
>
> indicator name "Divide[{I:G:Diff {I:EMA 30 {I:Prices CLOSE}} 1},
{I:G:PeriodAgo 1 {I:EMA 30 {I:Prices CLOSE}}}, }]"
> interval: 1067 .. 1104
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-01] = 0.0119
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-02] = 0.0210
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-03] = 0.0211
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-04] = 0.0239
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-07] = 0.0201
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-08] = 0.0180
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-09] = 0.0136
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-10] = 0.0100
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-11] = 0.0119
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-14] = 0.0108
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-15] = 0.0084
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-16] = 0.0052
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-17] = 0.0051
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-18] = 0.0053
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-21] = 0.0075
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-22] = 0.0048
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-23] = 0.0050
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-24] = 0.0072
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-25] = 0.0068
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-28] = 0.0126
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-29] = 0.0112
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-30] = 0.0096
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-03-31] = 0.0101
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-04-01] = 0.0095
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-04-04] = 0.0088
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-04-05] = 0.0095
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-04-06] = 0.0072
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-04-07] = 0.0057
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-04-08] = 0.0054
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-04-11] = 0.0035
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-04-12] = 0.0037
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-04-13] = 0.0085
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-04-14] = 0.0070
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-04-15] = 0.0062
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-04-18] = 0.0027
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-04-19] = 0.0032
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-04-20] = 0.0069
> Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}},
}][2011-04-21] = 0.0070
>
>
>
> and lastly using my not quite trunk head version of the toolkit and
display_indicator.pl
> i'm getting these results:
>
> ras [ 9111 ] % display_indicator.pl --start 1mar11 --end yesterday \
> 'I:Generic:Divide {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1
{I:EMA 30}}}' ALU
> syntax error at (eval 5) line 1, near "use GT::Indicators::Generic::Divide
{"
>
> twok:(Scripts)-ras [ 9112 ] % display_indicator.pl --start 1mar11 --end
yesterday \
> '{I:Generic:Divide {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1
{I:EMA 30}}}}' ALU
> syntax error at (eval 5) line 1, near "use GT::{"
>
> hope this helps!?
>
> -- ras
>
>>
>> Eric
>>
>> 2011/4/23 Robert A. Schmied <ra...@ac...>
>>
>>>aloha eric
>>>
>>>while i don't really think this is the primary purpose for
>>>or of the display_*.pl scripts it can be done sorta kinda
>>>like this:
>>>
>>> % display_indicator.pl I:Generic:Divide --start date --end date
>>> T '{I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}'
>>>
>>>note in csh the '{' is significant and therefore must be escaped.
>>>
>>>
>>>if you cannot get this to work post a note of what you tried
>>>and i'll review etc.
>>>
>>>aloha
>>>
>>>ras
>>>
>>>
>>>Eric Lemesre wrote:
>>>
>>>>Hello,
>>>>
>>>>How can i display complexe indicator like
>>>>{I:Generic:Divide {I:Generic:Diff {I:EMA 30}}
>>>> {I:Generic:PeriodAgo 1 {I:EMA 30}}
>>>> }
>>>>
>>>>With the script display_indicator.pl ?
>>>>
>>>>I found a part of code to do this in
>>>>GT::Graphics::DataSource::GenericIndicatorResults
>>>>
>>>># Create the indicator according to the arguments
>>>>my $indicator_module = shift || pod2usage(verbose => 2);
>>>>my $code = shift || pod2usage(verbose => 2);
>>>>my $indicator; # if it a complexe indicator
>>>>
>>>># a complexe indicator ave { and }
>>>>if ($indicator_module =~ m/.*\{.*\}.*/) {
>>>>
>>>> # remove the last '}'
>>>> if (substr($indicator_module,length($indicator_module)-1,1) eq "}") {
>>>> $indicator_module =
>>>>substr($indicator_module,1,length($indicator_module)-2);
>>>> }
>>>> $indicator_module =~ /[\s|\{]*(.*)$/;
>>>>
>>>> my @function = split(/\s+/,$1);
>>>> $indicator = create_standard_object(@function);
>>>>
>>>>} else {
>>>> $indicator = create_standard_object("$indicator_module",@ARGV);
>>>>}
>>>>
>>>>With this code we can do this :
>>>>./Scripts/display_indicator.pl --nb-item 25 --timeframe week "{I:G:Eval
>>>
>>>100
>>>
>>>>* {I:Generic:Divide {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1
>>>>{I:EMA 30}} }" AC
>>>>
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>
>>>
>>>------------------------------------------------------------------------------
>>>
>>>>Fulfilling the Lean Software Promise
>>>>Lean software platforms are now widely adopted and the benefits have
been
>>>>demonstrated beyond question. Learn why your peers are replacing JEE
>>>>containers with lightweight application servers - and what you can gain
>>>>from the move. http://p.sf.net/sfu/vmware-sfemails
>>>
>>>
>>>
>>>------------------------------------------------------------------------------
>>>Fulfilling the Lean Software Promise
>>>Lean software platforms are now widely adopted and the benefits have been
>>>demonstrated beyond question. Learn why your peers are replacing JEE
>>>containers with lightweight application servers - and what you can gain
>>>from the move. http://p.sf.net/sfu/vmware-sfemails
>>>
>>
>>
>>
>>
>
>
>
------------------------------------------------------------------------------
> Fulfilling the Lean Software Promise
> Lean software platforms are now widely adopted and the benefits have been
> demonstrated beyond question. Learn why your peers are replacing JEE
> containers with lightweight application servers - and what you can gain
> from the move. http://p.sf.net/sfu/vmware-sfemails

Re: [GT] Display indicator with different tameframe

[Robert A. S. <ra...@ac...>]

Eric Lemesre wrote:
> Hello,
> 
> it is possible to calculate an indicator on a timeframe (week) and to use it
> on another timeframe (day)?
> exemple :
> build a signal with
>  if I:G:Eval 100 * {I:Generic:Divide {I:Generic:Diff {I:TMA 30}}
> {I:Generic:PeriodAgo 1 {I:TMA 30}}} >= 0.25 of CAC 40  (with timeframe week)
> detect signal bullish with candle configuration for day timeframe

take a look at I:FromTimeframe and maybe I:Prices which when passed a
symbol argument allows you to override the 'current' symbol with another
just for this data series.

just a note: i've come to believe that the gt sys-sig-indic scheme needs
to some how add the dimension of time into signals so it is actually possible
to define a complex signal that considers time as part of its basic processing.
another related? issue is the relative nature of time period arguments in the
sys-sig-indic descriptions. by relative i mean they are 'fixed' to the time
frame setting being used at the moment, thus an otherwise identical sys-sig-indic
description needs different period argument values for 'day', 'week' and 'month'
time frames.

aloha

ras

ps -- i don't really understand your example description -- best i can
figure is a signal something like this:


 S:G \
  { I:G:If \
    { I:G:Eval 100 * \
      { I:G:Divide {I:G:Diff {I:TMA 30}} \
                 {I:Generic:PeriodAgo 1 {I:TMA 30}} \
      } \
    } \
  { I:FromTimeframe {I:Prices CLOSE} week 40 } \
 0.25 \
 } \

but that doesn't quite work in display_signal.pl ...

-- ras


> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Fulfilling the Lean Software Promise
> Lean software platforms are now widely adopted and the benefits have been 
> demonstrated beyond question. Learn why your peers are replacing JEE 
> containers with lightweight application servers - and what you can gain 
> from the move. http://p.sf.net/sfu/vmware-sfemails

Re: [GT] Display Complexe indicator

[Robert A. S. <ra...@ac...>]

Eric Lemesre wrote:
> Hi ras,
> 
> It works !!
> Thank but with this part of code you can have 2 form :
> % display_indicator.pl I:Generic:Divide --start date --end date  T
> '{I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}'
> and this form
> %display_indicator.pl --start date --end date "{I:Generic:Divide
> {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}}" T
> 
> in bash { is significant but
> exactly the same indicator as for signal.
> I am afraid to have work for nothing ;-)

i'm not sure i understand what you mean here, but the various shells
treat quotes, variable/macro expansions and escapes in various ways.

the csh (which isn't the best selection (also might include the zsh and
tcsh), but that shell is what i was weened on so i just keep using it)
considers the single quote (') to mean don't look into this argument
at all, just pass it to the command intact. the double quote (") allows
the shell to parse the argument and expand things it (the shell) thinks
are meant for it to mess with; things like shell variables and environment
variables, shell filename metachars like *? and shell macros like {}.

methinks the bash uses very similar conventions.

now, if for some reason you want to use the double quote (") to enclose
the argument you can use the 'escape the next char only' escape method
which requires the char '\' to immediately preceed the shell metachar
like this:
  % display_indicator.pl I:Generic:Divide --start date --end date  T
 "\{I:Generic:Diff \{I:EMA 30\}\} ..."

but unless you type a whole lot better than me that gets problematic
not to mention unusable in a cut+paste mode trying to define and prove
a particular sys-sig-indic description.

aloha

ras

ps -- looking at your 2nd example again but ignoring the double quotes:

> %display_indicator.pl --start date --end date "{I:Generic:Divide
> {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}}" T

the way display_indicator.pl works it to take an indicator, a symbol
any parameters for the indicator plus various coomand options and
return the results. the important thing to understand is in this sys-sig-indic

   {I:Generic:Divide {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}}

the indicator is I:Generic:Divide and the rest of the stuff are
parameters for that indicator, so for the display_*.pl commands
the sys-sig-indic must be broken into bits and pieces.

the ras-hack gt toolkit and display_indicator.pl yields the following:

ras [ 9106 ] %    display_indicator.pl --start 1mar11 --end yesterday \
  'I:Generic:Divide {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}' ALU
display_indicator.pl: warning: humm i read indicator_name as "I:Generic:Divide {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}"
unfortunately i really don't want the indicator to include curly brackets ({})
or the complete word Indicator. (I:<indicator_module>) is all i want.

i'm going to continue, but i don't think you will be getting much further

for reference <indicator_module> is typically:
I:RSI, I:BOL, I:CMO, I:MACD, I:AROON, etc
list the directory ../GT/Indicators for a complete list

display_indicator.pl: cso: error: failed to create following standard obj:
"use GT::Indicators::Generic::Divide {Indicators::Generic::Diff {Indicators::EMA 30}} {Indicators::Generic::PeriodAgo 1 {Indicators::EMA 30}}};
$object = GT::Indicators::Generic::Divide {Indicators::Generic::Diff {Indicators::EMA 30}} {Indicators::Generic::PeriodAgo 1 {Indicators::EMA 30}}}->new();"

the perl error: syntax error at (eval 15) line 1, near "use GT::Indicators::Generic::Divide {"

on the other hand 

ras [ 9107 ] %    display_indicator.pl --start 1mar11 --end yesterday \
 I:Generic:Divide  ALU '{I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}'
Indicator I:Generic:Divide has 1 value ... all values selected
        I:Generic:Divide/1  <=> Divide[{I:G:Diff {I:EMA 30 {I:Prices CLOSE}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {I:Prices CLOSE}}}, }]
pre check dates: $start=2011-03-01  $end=2011-04-22
calculator indexes: $first=1067 $last=1104
post check dates: $start=2011-03-01 00:00:00 <=> $first=1067
                  $end  =2011-04-22 00:00:00 <=> $last =1104

        timeframe day, time periods 1067 .. 1104
Calculating indicator ...
doin' the 99: $ival=99, $nb_val=1
but now: $ival=0, $nb_val=1

indicator name "Divide[{I:G:Diff {I:EMA 30 {I:Prices CLOSE}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {I:Prices CLOSE}}}, }]"
interval: 1067 .. 1104
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-01] = 0.0119
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-02] = 0.0210
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-03] = 0.0211
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-04] = 0.0239
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-07] = 0.0201
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-08] = 0.0180
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-09] = 0.0136
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-10] = 0.0100
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-11] = 0.0119
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-14] = 0.0108
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-15] = 0.0084
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-16] = 0.0052
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-17] = 0.0051
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-18] = 0.0053
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-21] = 0.0075
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-22] = 0.0048
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-23] = 0.0050
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-24] = 0.0072
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-25] = 0.0068
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-28] = 0.0126
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-29] = 0.0112
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-30] = 0.0096
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-03-31] = 0.0101
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-04-01] = 0.0095
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-04-04] = 0.0088
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-04-05] = 0.0095
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-04-06] = 0.0072
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-04-07] = 0.0057
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-04-08] = 0.0054
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-04-11] = 0.0035
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-04-12] = 0.0037
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-04-13] = 0.0085
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-04-14] = 0.0070
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-04-15] = 0.0062
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-04-18] = 0.0027
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-04-19] = 0.0032
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-04-20] = 0.0069
Divide[{I:G:Diff {I:EMA 30 {cl}} 1}, {I:G:PeriodAgo 1 {I:EMA 30 {cl}}}, }][2011-04-21] = 0.0070



and lastly using my not quite trunk head version of the toolkit and display_indicator.pl
i'm getting these results:

ras [ 9111 ] %    display_indicator.pl --start 1mar11 --end yesterday \
  'I:Generic:Divide {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}' ALU
syntax error at (eval 5) line 1, near "use GT::Indicators::Generic::Divide {"

twok:(Scripts)-ras [ 9112 ] %    display_indicator.pl --start 1mar11 --end yesterday \
  '{I:Generic:Divide {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}}' ALU
syntax error at (eval 5) line 1, near "use GT::{"

hope this helps!?

-- ras

> 
> Eric
> 
> 2011/4/23 Robert A. Schmied <ra...@ac...>
> 
>>aloha eric
>>
>>while i don't really think this is the primary purpose for
>>or of the display_*.pl scripts it can be done sorta kinda
>>like this:
>>
>> % display_indicator.pl I:Generic:Divide --start date --end date
>> T '{I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}'
>>
>>note in csh the '{' is significant and therefore must be escaped.
>>
>>
>>if you cannot get this to work post a note of what you tried
>>and i'll review etc.
>>
>>aloha
>>
>>ras
>>
>>
>>Eric Lemesre wrote:
>>
>>>Hello,
>>>
>>>How can i display complexe indicator like
>>>{I:Generic:Divide {I:Generic:Diff {I:EMA 30}}
>>>          {I:Generic:PeriodAgo 1 {I:EMA 30}}
>>>        }
>>>
>>>With the script display_indicator.pl ?
>>>
>>>I found a part of code to do this in
>>>GT::Graphics::DataSource::GenericIndicatorResults
>>>
>>># Create the indicator according to the arguments
>>>my $indicator_module = shift || pod2usage(verbose => 2);
>>>my $code = shift || pod2usage(verbose => 2);
>>>my $indicator;   # if it a complexe indicator
>>>
>>># a complexe indicator ave { and }
>>>if ($indicator_module =~ m/.*\{.*\}.*/) {
>>>
>>>   # remove the last '}'
>>>    if (substr($indicator_module,length($indicator_module)-1,1) eq "}") {
>>>        $indicator_module =
>>>substr($indicator_module,1,length($indicator_module)-2);
>>>    }
>>>    $indicator_module =~ /[\s|\{]*(.*)$/;
>>>
>>>    my @function = split(/\s+/,$1);
>>>    $indicator = create_standard_object(@function);
>>>
>>>} else {
>>>    $indicator = create_standard_object("$indicator_module",@ARGV);
>>>}
>>>
>>>With this code we can do this :
>>>./Scripts/display_indicator.pl --nb-item 25 --timeframe week "{I:G:Eval
>>
>>100
>>
>>>* {I:Generic:Divide {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1
>>>{I:EMA 30}} }" AC
>>>
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>
>>
>>------------------------------------------------------------------------------
>>
>>>Fulfilling the Lean Software Promise
>>>Lean software platforms are now widely adopted and the benefits have been
>>>demonstrated beyond question. Learn why your peers are replacing JEE
>>>containers with lightweight application servers - and what you can gain
>>>from the move. http://p.sf.net/sfu/vmware-sfemails
>>
>>
>>
>>------------------------------------------------------------------------------
>>Fulfilling the Lean Software Promise
>>Lean software platforms are now widely adopted and the benefits have been
>>demonstrated beyond question. Learn why your peers are replacing JEE
>>containers with lightweight application servers - and what you can gain
>>from the move. http://p.sf.net/sfu/vmware-sfemails
>>
> 
> 
> 
> 

[GT] Display indicator with different tameframe

[Eric L. <eri...@gm...>]

Hello,

it is possible to calculate an indicator on a timeframe (week) and to use it
on another timeframe (day)?
exemple :
build a signal with
 if I:G:Eval 100 * {I:Generic:Divide {I:Generic:Diff {I:TMA 30}}
{I:Generic:PeriodAgo 1 {I:TMA 30}}} >= 0.25 of CAC 40  (with timeframe week)
detect signal bullish with candle configuration for day timeframe


-- 
Cordialement
Eric Lemesre