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

Re: [GT] Newby installation question

[<oj...@sn...>]

hi, 

works great!

Thanks


> $ sudo apt-get install libstorable-perl
> 
> And you're done, this module is standard in perl 5.8 but packaged
> separately for perl 5.6 ...

Re: [GT] Newby installation question

[Raphael H. <ra...@ge...>]

Le Mon, Mar 17, 2003 at 12:32:02PM +0000, oj...@sn... écrivait:
> My perl knowlege is very poor at this time (but I will change that in the near
> future :-). I adjusted all directories as required or did I forget something?
> 
> My linux distribution is Debian 3.0/testing. 

$ sudo apt-get install libstorable-perl

And you're done, this module is standard in perl 5.8 but packaged
separately for perl 5.6 ...

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

[GT] Newby installation question

[<oj...@sn...>]

Hi,

I'm new to Geniustrader and experienced some problems when installing it. After
stepping through installation process as described I tried to call one of the
examples mentioned. 

The call "ojaeger@psnet:~/Scripts$ ./display_indicator.pl RSI 13000" failed with
 the following output:

Can't locate Storable.pm in @INC (@INC contains: ../.. .. /home/ojaeger
/usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5
/usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1
/usr/local/lib/site_perl .) at ../GT/Serializer/Storable.pm line 13.
BEGIN failed--compilation aborted at ../GT/Serializer/Storable.pm line 13.
Compilation failed in require at ../GT/BackTest/Spool.pm line 10.
BEGIN failed--compilation aborted at ../GT/BackTest/Spool.pm line 10.
Compilation failed in require at ../GT/Report.pm line 11.
BEGIN failed--compilation aborted at ../GT/Report.pm line 11.
Compilation failed in require at ./display_indicator.pl line 17.
BEGIN failed--compilation aborted at ./display_indicator.pl line 17.


My perl knowlege is very poor at this time (but I will change that in the near
future :-). I adjusted all directories as required or did I forget something?

My linux distribution is Debian 3.0/testing. 

When trying to track the error I was wondering why GT:Serializer:Storable.pm
will call "use Storable" within itself. Is it an standard perl module which is
missing?

Can anybody help?

Cheers Olaf

Re: [GT] The func Argument

[Raphael H. <ra...@ge...>]

Le Thu, Feb 27, 2003 at 06:07:32PM +0100, Oliver Bossert écrivait:
> I agree with you. IMO there are three possibilities concerning the us 
> of 'func': First would be the hard way to convert all the indicators 
> at once to Std.vers. 1.0 without the use of 'func', so that it 
> produces no problems with indicators using the converted one .Second 
> we could write in every indicator's init()-function a piece of code 
> that connects 'func' to the coresponding parameter. The last solution 
> would be the one I described in my last mail: to include a version-
> string and to add the 'func' in the new function. 
> What do you think would be the best way to solve the problem?

Really I don't see the problem with $func ... let's just say we don't
use it in new indicators and we continue to support it for indicators
where it is currently used.

I fail to see the need of a complicated transition scheme.

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

[GT] CVS commit in GT/Systems

[GeniusTrader C. r. <ra...@ge...>]

Update of /bourse/cvsroot/GT/Systems
In directory arrakis:/scratch/tmp/cvs-serv23480

Modified Files:
	ADX.pm 
Log Message:
- Make it manage variable parameters.


--- /bourse/cvsroot/GT/Systems/ADX.pm	2003/02/25 17:14:05	1.4
+++ /bourse/cvsroot/GT/Systems/ADX.pm	2003/03/16 20:25:40	1.5
@@ -5,7 +5,7 @@
 # version 2 or (at your option) any later version.
 
 use strict;
-use vars qw(@ISA @NAMES);
+use vars qw(@ISA @NAMES @DEFAULT_ARGS);
 
 use Carp::Datum;
 use GT::Prices;
@@ -13,7 +13,8 @@
 use GT::Indicators::ADX;
 
 @ISA = qw(GT::Systems);
-@NAMES = ("ADX");
+@NAMES = ("ADX[#1]");
+@DEFAULT_ARGS = (14);
 
 =pod
 
@@ -21,37 +22,33 @@
 
 =cut
 
-sub new {
-    my $type = shift;
-    my $class = ref($type) || $type;
-    my $args = shift;
-
-    my $self = { "args" => defined($args) ? $args : [14] };
-
-    return manage_object(\@NAMES, $self, $class, $self->{'args'}, "");
-}
-
 sub initialize {
     my ($self) = @_;
 
-    $self->{'adx'} = GT::Indicators::ADX->new([ $self->{'args'}[0] ]);
-
     $self->{'allow_multiple'} = 0;
-
-    $self->add_indicator_dependency($self->{'adx'}, 2);
 }
 
 sub precalculate_interval {
     DFEATURE my $f;
     my ($self, $calc, $first, $last) = @_;
-    $self->{'adx'}->calculate($calc, $last);
+    if ($self->{'args'}->is_constant()) {
+	my $period = $self->{'args'}->get_arg_constant(1);
+	my $adx = GT::Indicators::ADX->new([$period]);
+	$adx->calculate($calc, $last);
+    }
     return DVOID;
 }
 
 sub long_signal {
     DFEATURE my $f;
     my ($self, $calc, $i) = @_;
-    my $adxname = $self->{'adx'}->get_name;
+
+    my $period = $self->{'args'}->get_arg_values($calc, $i, 1);
+    my $adx = GT::Indicators::ADX->new([$period]);
+    my $adxname = $adx->get_name;
+
+    $self->remove_volatile_dependencies();
+    $self->add_volatile_indicator_dependency($self->{'adx'}, 2);
 
     return DVAL 0 if (!$self->check_dependencies($calc, $i));
 

Re: [GT] Re: Common new in Systems.pm (was: GT/Systems/* obsolete?)

[Raphael H. <ra...@ge...>]

Le Thu, Feb 27, 2003 at 01:33:54PM +0100, Olaf Dietsche écrivait:
> > I wouldn't use "our" since this has been added recently to perl. Better
> > stay with the use vars qw(... @DEFAULT_ARGS) like it's done everywhere
> > else (check I:RSI again for example). 
> 
> According to "Programming Perl", use vars is deprecated.
> "man perltoc" says:
> ...
> vars - Perl pragma to predeclare global variable names (obsolete)
> ...
> 
> So, I guess it's for backwards compatibility.

Oh, I didn't notice that. This is not mentionned in man perldelta or in
the documentation of "our" so it's probably not going to be removed any
time soon.

our is available since perl 5.6 so we can safely use it I guess ... I
take back what I said.

> > Otherwise it looks ok. However with GT::ArgsTree we're trying to make
> > all parameters variable in the sens that they can be an other
> > indicator. For this to work, you have to take special consideration in
> > mind. Instead of using $args->get_arg_constant() you must use
> > $args->get_arg_values() and you can't use at initializa time but at
> > calculation time since you don't know the value of the parameter yet.
> > And because of that you can't use fixed dependencies but you need what I
> > call volatile dependencies.
> >
> > This is not so important right now, but I just wanted to let you know.
> 
> I looked through GT/Indicators/ADX.pm and what I see is, that ADX
> calculates, but doesn't set the values, if args is not constant.

That's wrong. If args is not constant, it doesn't store intermediate
results because they have no meanings since args may change ... however
the last result (the one asked by the calculate call in the first place)
is stored (that's the "or ($i == $n)").

> Furthermore, a variable period could lead to strange results. Think of
> an increasing period length. This could mean you have an indicator
> after 14 periods and then, when the period increases to 21 you would
> have a gap, until you collect enough input values to calculate the
> next data point.

Exactly. That's a new problem that indicators may have to deal with.
Generally I think that indicators must know how to handle "undef" values
for any other indicator used as input.

> I appended a new patch for ADX.pm. Please tell me, if this is what you
> had in mind. One problem I see here is performance, since you create
> an indicator for every calculation.

The indicator objects (like all other objects) are stored in a cache ...
so you don't recreate the same indicator thousand times. But of course
this flexibility includes a performance hit.

Your patch is not ok since it creates the ADX object after the
"dependency check". It should create it before and add the ADX object as
a volatile dependency (and remove the volatile dependency each time of
course). Check the patch that I committed. Also precalculation does
only make sense with a constant argument ... I know it's tricky to
follow all the implications of the "arg can be variable" thing ...

> Another solution could be to retain some sort of a 'rawargs' member,
> which could be fed to the indicator at initialization time. Or maybe a
> clone_argstree() is better? I don't know.

Can you explain a bit more what you had in mind ?

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: [GT] Misc

[Raphael H. <ra...@ge...>]

Le Sun, Feb 23, 2003 at 02:12:59PM +0100, Oliver Bossert écrivait:
> Hi Raphael, 

Hi,

[ I'm replying to old mails ... ]

> But now something completly different. I attached a graphic and the 
> corresponding indicators to this message to calculate a resistance 
> line. I found nowhere a good algorithm to implement this so I wrote 
> my own; maybe you can tell me what you think about it. 
> 
> * First it determines the last X-day maximum (65 days in this case)
> * Second it determines the local maxima (red arrows)
> * It then calculates a linear regression through the maxima
> * Last but not least it calculates the amount the regressionline has 
> to be shifted to avoid touching the maxima
> 
> My interpretation of this calculation would be that the resistance is 
> stronger when the distance between the two lines is small and a high 
> percentage of the tops lies between the two lines. You can see two 
> resistance lines, one in rd for the last day of april and one in blue 
> for the last day of june. 
> 
> .. what do you think about this?

I find your work really interesting and I'd gladly integrate it
once you're happy with it. Just send me the latest version when you're
satisfied... and maybe you'll get some feedback by some other users once
it has been integrated. Several people subscribed recently, probably due
to the publicity we had in Brave Gnu World.

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: [GT] Re: Database sources

[Raphael H. <ra...@ge...>]

Le Wed, Mar 12, 2003 at 08:10:10AM -0800, Ben Hamilton écrivait:
>  I've been able to modify the pg.pm (now mysql.pm). What is the data
> structure used in a standard PostgressSQL database?

There's no standard "data structure". I know that each on does its own
database and so I let people write their own module to access their own
data ... the pg.pm module corresponds to the database that I have on my
computer. It's nothing standard but it's not completely esoteric either.

>  Also, would the group be interested in developing a script that goes
> out to yahoo and grabs quote history?

Nope, this does already exist more or less ... tons of scripts lets you
grab data in ascii file. From there it's easy to integrate them in
your own database.

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: [GT] Candlesticking Indicators

[Raphael H. <ra...@ge...>]

[ Please use only *one* mailing list ]

Le Wed, Mar 12, 2003 at 08:26:15AM -0800, Ben Hamilton écrivait:
>  Is there information on the following?
> 1) Syntax for writing rules/flags/alerts/patterns.
> 2) Has anyone created indicators for candlesticking?
> (http://www.candlecharts.com/)

Have you tried to browse the sources a bit ?

And the documentation at http://www.geniustrader.org/doc/GT/ ?

You'd find this for example :
http://www.geniustrader.org/doc/GT/Signals/Graphical/CandleSticks/

If you want to really use GT, you'll have to read the sources
and become familiar with it because almost everything is doable but
it will need some tweaking, some new modules, etc.

> If there is no documentation I am interested in creating documentation.

There's the documentation of each module, but there's no doc describing
the global point of view, how all the modules cooperate. There's the doc
of some scripts too ...

http://www.geniustrader.org/doc/Scripts/

> If there are no candlestick indicators I am interested in writing some.

There are some but Im' not sure they are really good and I'd appreciate
having more ...

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

[GT] Candlesticking Indicators

[Ben H. <be...@be...>]

Hello,
 I am new to the group so I am sorry if this question has been asked
before (is there an archive I can read?).
 Is there information on the following?
1) Syntax for writing rules/flags/alerts/patterns.
2) Has anyone created indicators for candlesticking?
(http://www.candlecharts.com/)
 
If there is no documentation I am interested in creating documentation.
If there are no candlestick indicators I am interested in writing some.
Thank you in advance,
Ben

RE: [GT] Re: Database sources

[Ben H. <be...@be...>]

Thank you Olf,
 I've been able to modify the pg.pm (now mysql.pm). What is the data
structure used in a standard PostgressSQL database?

 Also, would the group be interested in developing a script that goes
out to yahoo and grabs quote history?
Ben

-----Original Message-----
From: ol...@ol... [mailto:ol...@ol...] 
Sent: Wednesday, March 12, 2003 1:04 AM
To: de...@ge...
Subject: [GT] Re: Database sources


Hi Ben, 

with GT::DB::pg exists an interface to the Postgresql-Database. 

I think it should be quite simple to adapt the code so that is runs with
you mysql-database. The code is quite short and IMO changing the
configurations in the new()-function and replacing the fields with your
names should make it work. 

CU, Olf
 

[GT] [ben@benandcassandra.com: Trade rules and formulas...syntax, functions and assistance]

[Raphael H. <rhe...@hr...>]

Hi ben,

that's the second time you write to dev...@ge...
instead of de...@ge... ... please take care.

I'm forwarding your mail now.

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

[GT] Re: Database sources

[<ol...@ol...>]

Hi Ben, 

with GT::DB::pg exists an interface to the Postgresql-Database. 

I think it should be quite simple to adapt the code so that is runs with
you mysql-database. The code is quite short and IMO changing the
configurations in the new()-function and replacing the fields with your
names should make it work. 

CU, Olf
 

[GT] Database sources

[Ben H. <be...@be...>]

I have a large data set in a MySQL database. Can I use that data
directly from the DBI source?
The data table looks like this:
+-------------------+-------------+------+-----+------------+-------+
| Field             | Type        | Null | Key | Default    | Extra |
+-------------------+-------------+------+-----+------------+-------+
| historyTicker     | varchar(8)  |      | PRI |            |       |
| historyDate       | date        |      | PRI | 0000-00-00 |       |
| historyOpen       | varchar(10) | YES  |     | NULL       |       |
| historyHigh       | varchar(10) | YES  |     | NULL       |       |
| historyLow        | varchar(10) | YES  |     | NULL       |       |
| historyClose      | varchar(10) | YES  |     | NULL       |       |
| historyVolume     | varchar(12) | YES  |     | NULL       |       |
| historyAvgTen     | varchar(10) | YES  |     | NULL       |       |
+-------------------------------------------------------------------+
I'm using MySQL with the perl DBI for storing and accessing data in that
table right now. Any thoughts?

Also, I am new to the list, is there an archive somewhere that I can
read?
Thank you in advance,
Ben

[GT] New broker InteractiveBrokers

[Olaf D. <olaf.dietsche#<lis...@t-...>]

here is the implementation for InteractiveBrokers.

Regards, Olaf.

[GT] Re: Bug in MinInPeriod/MaxInPeriod?

[Olaf D. <olaf.dietsche#<lis...@t-...>]

Raphael Hertzog <ra...@ge...> writes:

> Le Fri, Feb 28, 2003 at 11:18:27AM +0100, Olaf Dietsche écrivait:
>> > In both cases, since @_ is not used later in the function, the patch
>> > changes nothing.
>> 
>> @_ is used three lines below in ->get_arg_values(@_, 2).
>
> Yep, but the @_ is not the @_ of the same sub.
>
>         $self->{'func'} = sub { $self->{'args'}->get_arg_values(@_, 2);	};
>
> It's the @_ of an anonymous subroutine stored in $self->{'func'}. And
> this function receives two parameters needed by get_arg_values. 

Ah, now I see it too. Thanks for the education :-).

Regards, Olaf.

Re: [GT] Re: Bug in MinInPeriod/MaxInPeriod?

[Raphael H. <ra...@ge...>]

Le Fri, Feb 28, 2003 at 11:18:27AM +0100, Olaf Dietsche écrivait:
> > In both cases, since @_ is not used later in the function, the patch
> > changes nothing.
> 
> @_ is used three lines below in ->get_arg_values(@_, 2).

Yep, but the @_ is not the @_ of the same sub.

        $self->{'func'} = sub { $self->{'args'}->get_arg_values(@_, 2);	};

It's the @_ of an anonymous subroutine stored in $self->{'func'}. And
this function receives two parameters needed by get_arg_values. 

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

[GT] Re: Bug in MinInPeriod/MaxInPeriod?

[Olaf D. <olaf.dietsche#<lis...@t-...>]

Raphael Hertzog <ra...@ge...> writes:

> Le Fri, Feb 28, 2003 at 01:32:01AM +0100, Olaf Dietsche écrivait:
>> Maybe the parameter handling in Min/MaxInPeriod is wrong. Would you
>> please take a look at this patch?
>
> In both cases, since @_ is not used later in the function, the patch
> changes nothing.

@_ is used three lines below in ->get_arg_values(@_, 2).

Regards, Olaf.

Re: [GT] Bug in MinInPeriod/MaxInPeriod?

[Raphael H. <ra...@ge...>]

Le Fri, Feb 28, 2003 at 01:32:01AM +0100, Olaf Dietsche écrivait:
> Maybe the parameter handling in Min/MaxInPeriod is wrong. Would you
> please take a look at this patch?

What make you think that something was wrong ?

initialize is always called with $object->initialize which in fact is
Indicator::ObjectPackage::initialize($object). So there's a single
parameter to the initialize function.

my ($self) = @_; is a list assignment where the first element of @_ is
assigned to $self and the others are dropped. The content of @_ is
unchanged.

my $self = shift; has the same result in term of changing the variable
$self but @_ is modified to remove the first value.

In both cases, since @_ is not used later in the function, the patch
changes nothing.

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

[GT] Bug in MinInPeriod/MaxInPeriod?

[Olaf D. <olaf.dietsche#<lis...@t-...>]

Maybe the parameter handling in Min/MaxInPeriod is wrong. Would you
please take a look at this patch?

Regards, Olaf.

[GT] Re: Common new in Systems.pm (was: GT/Systems/* obsolete?)

[Olaf D. <ola...@gm...>]

Olaf Dietsche <olaf.dietsche#lis...@t-...> writes:

> I appended a new patch for ADX.pm. Please tell me, if this is what you

Pulled the trigger too early; here is the promised patch.

Regards, Olaf.

Re: [GT] The func Argument

[Oliver B. <ol...@ol...>]

Hi, 

> Yep. Two Germans and one French... :) I thought that Americans would
> be more interested in trading ... ;-)

We should do more advertisement :)
 
> It could be needed again if we have more complex input streams (like
> series of arrays or vectors ...).
> But I'm a bit unsure about how useful such a feature could be. That's
> why I didn't remove that func stuff yet. Although even if it's not
> useful directly in Indicators it might be of some use somewhere else.

I agree with you. IMO there are three possibilities concerning the us 
of 'func': First would be the hard way to convert all the indicators 
at once to Std.vers. 1.0 without the use of 'func', so that it 
produces no problems with indicators using the converted one .Second 
we could write in every indicator's init()-function a piece of code 
that connects 'func' to the coresponding parameter. The last solution 
would be the one I described in my last mail: to include a version-
string and to add the 'func' in the new function. 
What do you think would be the best way to solve the problem?
 
CU, Olf

[GT] Re: The func Argument

[Olaf D. <olaf.dietsche#<lis...@t-...>]

Raphael Hertzog <rhe...@hr...> writes:

> Le Thu, Feb 27, 2003 at 08:56:03AM +0100, ol...@ol... écrivait:
>> I was very happy to notice that we're now at least three people
>> actively discussing on this list. Welcome, Olaf! :-)

Thanks! :-)

> Yep. Two Germans and one French... :) I thought that Americans would be
> more interested in trading ... ;-)

Maybe they join, when GT reaches a more mature/shrinkwrapped state.
Right now, you need a dedication for trading as well as perl
programming.

Regards, Olaf.

[GT] Re: Common new in Systems.pm (was: GT/Systems/* obsolete?)

[Olaf D. <olaf.dietsche#<lis...@t-...>]

Raphael Hertzog <ra...@ge...> writes:

> Le Wed, Feb 26, 2003 at 05:25:50PM +0100, Olaf Dietsche écrivait:
>> As before, here is the first cut: I copied new() from Indicators.pm to
>> Systems.pm and removed the new() from ADX.pm and added the
>> @DEFAULT_ARGS.
>
> I wouldn't use "our" since this has been added recently to perl. Better
> stay with the use vars qw(... @DEFAULT_ARGS) like it's done everywhere
> else (check I:RSI again for example). 

According to "Programming Perl", use vars is deprecated.
"man perltoc" says:
...
vars - Perl pragma to predeclare global variable names (obsolete)
...

So, I guess it's for backwards compatibility.

>> I'll continue with the rest, when I have either your no or go.
>
> Otherwise it looks ok. However with GT::ArgsTree we're trying to make
> all parameters variable in the sens that they can be an other
> indicator. For this to work, you have to take special consideration in
> mind. Instead of using $args->get_arg_constant() you must use
> $args->get_arg_values() and you can't use at initializa time but at
> calculation time since you don't know the value of the parameter yet.
> And because of that you can't use fixed dependencies but you need what I
> call volatile dependencies.
>
> This is not so important right now, but I just wanted to let you know.

I looked through GT/Indicators/ADX.pm and what I see is, that ADX
calculates, but doesn't set the values, if args is not constant.

Furthermore, a variable period could lead to strange results. Think of
an increasing period length. This could mean you have an indicator
after 14 periods and then, when the period increases to 21 you would
have a gap, until you collect enough input values to calculate the
next data point.

Anyway, I see the potential uses of a variable scheme, but not for all
systems/indicators.

I appended a new patch for ADX.pm. Please tell me, if this is what you
had in mind. One problem I see here is performance, since you create
an indicator for every calculation.

Another solution could be to retain some sort of a 'rawargs' member,
which could be fed to the indicator at initialization time. Or maybe a
clone_argstree() is better? I don't know.

>> If so, some of the system names miss them.
>
> If they have [#*] then it's ok. This is a catchup for all parameters.
> If they have nothing like that but they don't use any parameter, then
> it's ok to. :) Otherwise it's a bug.

I'll look into this too.

Regards, Olaf.

Re: [GT] The func Argument

[Raphael H. <rhe...@hr...>]

Le Thu, Feb 27, 2003 at 08:56:03AM +0100, ol...@ol... écrivait:
> I was very happy to notice that we're now at least three people
> actively discussing on this list. Welcome, Olaf! :-)

Yep. Two Germans and one French... :) I thought that Americans would be
more interested in trading ... ;-)

> I started to convert some more indicators to work within the
> ArgsTree-architecture and to support different sources of data. I'm a
> little bit unsure waht to do with the $self->{'func'}-Function. It is not
> really needed anymore except for compatibility reasons. Instead of
> creating a SMA with a func-parameter you can simply handle the datasource
> as a parameter.

It could be needed again if we have more complex input streams (like
series of arrays or vectors ...).

But I'm a bit unsure about how useful such a feature could be. That's
why I didn't remove that func stuff yet. Although even if it's not
useful directly in Indicators it might be of some use somewhere else.

> BTW: Maybe it would be a good idea to branch a 'stable' version of GT if
> we have finished the complete conversion to ArgsTree :-?

Yep probably. But we can discuss that when we reach that point. :)

Cheers,

PS: I have not forgotten your previous mail, I'm going to answer it
tomorrow probably.
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com