[GT] Re: Re: Re: package Finance::GeniusTrader::DateTime::Day;

[Josef Strobel <josef-strobel AT web.de>]

Why don't we use POSIX and mktime to get the unix time stamp?
I did a quick performance test.


I did some benchmark in Prices.pm.

Sort the prices by date.

=cut
sub sort {
    my ($self) = @_;
    use Benchmark;
    my $t0 = Benchmark->new;
    # ... your code here ...

    my @prices = sort {
  Finance::GeniusTrader::DateTime::map_date_to_time($self->timeframe, $a->[$DATE]) <=>
  Finance::GeniusTrader::DateTime::map_date_to_time($self->timeframe, $b->[$DATE])
    } @{$self->{'prices'}};
    $self->{'prices'} = \
AT
prices;

    my $t1 = Benchmark->new;
    my $td = timediff($t1, $t0);
    open(IN,'>', "/tmp/geniustrader-DEBUG");
    print IN timestr($td);
    close IN;
    #print "the code took:",timestr($td),"\n";
}


And changed timelocal to mktime in package Finance::GeniusTrader::DateTime::Day


use Finance::GeniusTrader::DateTime;
#ALL# use Log::Log4perl qw(:easy);
use Time::Local;
use POSIX;

=head1 Finance::GeniusTrader::DateTime::Day

This module treat dates describing a day. They have the following format :
YYYY-MM-DD

=cut
sub map_date_to_time {
    my ($date) = @_;
    my ($y, $m, $d) = split /-/, $date;
  ($d) = split / /, $d;
    #return timelocal(0, 0, 0, $d, $m - 1, $y - 1900);
    return mktime(0, 0, 0, $d, $m - 1, $y - 1900);
}


Running with timelocal:
time $HOME/eclipse-workspace/geniustrader/script/graphic.pl --file $HOME/eclipse-
workspace/geniustrader/own-scripts/graphic/graphic_examples.conf IBM > foobar.png

real    0m15.139s
user    0m10.557s
sys     0m2.096s

and 3 wallclock secs ( 1.10 usr +  0.66 sys =  1.76 CPU)


Running with mktime:
time $HOME/eclipse-workspace/geniustrader/script/graphic.pl --file $HOME/eclipse-
workspace/geniustrader/own-scripts/graphic/graphic_examples.conf IBM > foobar.png

real    0m11.554s
user    0m8.489s
sys     0m1.104s

and 1 wallclock secs ( 0.38 usr +  0.30 sys =  0.68 CPU)





Am Mittwoch 18 November 2009 schrieb Thomas Weigert:
> This is a complicated problem. On the one hand, speed of time
> conversions during the run is critical, as when time GT maps between
> timeframes or does time comparisons it often invokes this function. On
> the other hand, the fastest time functions don't work for times outside
> of the epoch.
> 
> The conclusion was that the most important need for GT is for market
> data from within the epoch. But the price to be paid is that one cannot
> do long time studies that start for in the past (the future is less of a
> problem due to the lack of market data).
> 
> The best way to handle might be to make the time conversion dependent on
> the time frame. If one works with yearly data, maybe it is ok to use
> slower functions, and typically, when one analyzes the market over 100
> years one probably will use yearly data? But in either way, today you
> need to stick to the epoch.
> 
> Th.
> 
> Chia-liang Kao wrote:
> > Hi Josef,
> >
> > 1960 is before epoch, and time::local wouldn't be able to support
> > that. neither would it support years > 2038.  We'll need to migrate to
> > something like Time::y2038 or DateTime.
> >
> > 2009/11/18 Josef Strobel <josef-strobel
AT
web.de>:
> >> Hi all,
> >>
> >> I tried to load a time series where the start date is before 1960-12-31,
> >> but I always get the following error:
>