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

[GT] Re: Re: Re: Re: Couple of questions

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

Sorry, I meant GT::Indicators::Prices

Attached.... Th.

Robert A. Schmied wrote:
> Thomas Weigert wrote:
>> RAS,
>>
>> assuming the "other data" is just another market, all that is required
>> is to use my modified version of GT::Prices. You can then load the other
>
> your version of GT::Prices is on the exp branch, on trunk, or on cpan
> or ?
>
>

[GT] Re: Re: Re: Couple of questions

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

Thomas Weigert wrote:
> RAS,
> 
> assuming the "other data" is just another market, all that is required
> is to use my modified version of GT::Prices. You can then load the other

your version of GT::Prices is on the exp branch, on trunk, or on cpan or ?

> market and use it whereever you would use Prices of the original market.
> When graphing, you can either graph that market instead of the original
> market via Prices, or you can not show the original market via
> --type=none and only graph indicators depending on the alternative
> market. Of course, you cannot use volumes from the alternative market,
> so you need to graph with --novolume.
> 
> I do not think any change to the data sources is required unless you
> need the volume of the other market, or you need to use that other
> market in various timeframes beyond just the timeframe of the primary
> market.
> 
> Th.
> 
> Robert A. Schmied wrote:
> 
>>both GT/Prices.pm and GT/Indicators/Prices.pm will need modification
>>if you want
>>the gt indicators to be able to access this 'other data' in the prices
>>object.
>>naturally whatever database interface module you are using may need
>>alteration
>>or configuration as well.
>>
>>however none of the apps that utilize GT/Graphics/DataSource methods
>>to create and
>>render graphic objects will handle this 'other data' unless you also
>>alter them
>>(the apps) and possibly also implement suitable additional datasource
>>module(s)
>>to support this 'other data'. GT/Graphics/DataSource/Prices.pm and
>>Volume.pm
>>might serve as models for any additional module(s) that might be needed.
>>
>>can we ask the type and the nature of this 'other data'? there may be
>>better
>>alternatives to loading up the prices object with additional data
>>especially
>>if this data isn't of a market dynamic sort.
>>
>>
>>
>>
> 

[GT] Re: Re: Couple of questions

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

RAS,

assuming the "other data" is just another market, all that is required
is to use my modified version of GT::Prices. You can then load the other
market and use it whereever you would use Prices of the original market.
When graphing, you can either graph that market instead of the original
market via Prices, or you can not show the original market via
--type=none and only graph indicators depending on the alternative
market. Of course, you cannot use volumes from the alternative market,
so you need to graph with --novolume.

I do not think any change to the data sources is required unless you
need the volume of the other market, or you need to use that other
market in various timeframes beyond just the timeframe of the primary
market.

Th.

Robert A. Schmied wrote:
> both GT/Prices.pm and GT/Indicators/Prices.pm will need modification
> if you want
> the gt indicators to be able to access this 'other data' in the prices
> object.
> naturally whatever database interface module you are using may need
> alteration
> or configuration as well.
>
> however none of the apps that utilize GT/Graphics/DataSource methods
> to create and
> render graphic objects will handle this 'other data' unless you also
> alter them
> (the apps) and possibly also implement suitable additional datasource
> module(s)
> to support this 'other data'. GT/Graphics/DataSource/Prices.pm and
> Volume.pm
> might serve as models for any additional module(s) that might be needed.
>
> can we ask the type and the nature of this 'other data'? there may be
> better
> alternatives to loading up the prices object with additional data
> especially
> if this data isn't of a market dynamic sort.
>
>
>>
>
>

[GT] Re: Re: Couple of questions

[Sumit S. <sum...@gm...>]

On Wed, Jan 6, 2010 at 9:08 AM, Robert A. Schmied <ra...@ac...> wrote:

> Sumit Sanghai wrote:
>
>> Hello guys,
>>
>> I am trying out GT, and had a few questions.
>>
>> i) I am developing a strategy which apart from the standard volume, and
>> prices requires some other data which I have in my DB.
>> I want these to be loaded into the Prices object, and then used elsewhere.
>> Do I need to make modifications just to Prices.pm to
>> get the data loaded. Or are there other classes which inherently assume
>> that
>> Prices can only contain open, high etc?
>>
>
>
> aloha sumit
>
> both GT/Prices.pm and GT/Indicators/Prices.pm will need modification if you
> want
> the gt indicators to be able to access this 'other data' in the prices
> object.
> naturally whatever database interface module you are using may need
> alteration
> or configuration as well.
>
> however none of the apps that utilize GT/Graphics/DataSource methods to
> create and
> render graphic objects will handle this 'other data' unless you also alter
> them
> (the apps) and possibly also implement suitable additional datasource
> module(s)
> to support this 'other data'. GT/Graphics/DataSource/Prices.pm and
> Volume.pm
> might serve as models for any additional module(s) that might be needed.
>
> can we ask the type and the nature of this 'other data'? there may be
> better
> alternatives to loading up the prices object with additional data
> especially
> if this data isn't of a market dynamic sort.


It's related to daily transactions from FIIs.


>
>
>
>
>>
>> ii) One of the strategies I am testing, requires simultaneous access to
>> quotes from multiple stocks and indices.
>> Any clue where all do I have to make the changes to get such a strategy
>> working.
>> It seems that most of the objects make the assumption that they are only
>> dealing with a single stock.
>> Is there a simple hack which can help me out?
>>
>
>
> as clk pointed out, GT/Indicators/Prices.pm allows access to the prices
> object
> for an alternate 'code', but the timeframe and time period indices for each
> such
> prices object would have to align. however as joao notes,
> GT/Indicators/FromTimeFrame
> might alleviate these time related alignment requirements some. if by
> 'indices'
> you are referring to the gt time period indices of a prices object you will
> have
> to employ GT/Indicators/Generic/PeriodAgo.pm, on the other hand, if
> 'indices' means
> a stock market index like ^DJA or ^HSI just treat them like another stock
> symbol.
>
>
> good luck and keep the list posted on your efforts.
>
> regards
>
> ras
>
>
>
>> Regards,
>> Sumit.
>>
>>
>

[GT] RE: Re: Re: Couple of questions

[Jon E. <fo...@ho...>]

 

 

Odd.

These messages are showing up blank (empty other then header) in my inbox.

I must read them via the list.

 

Jon
 
> Date: Tue, 5 Jan 2010 09:02:31 -0500
> From: we...@ms...
> To: de...@ge...
> Subject: [GT] Re: Re: Couple of questions
> 
 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141665/direct/01/

[GT] Re: Couple of questions

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

Sumit Sanghai wrote:
> Hello guys,
> 
> I am trying out GT, and had a few questions.
> 
> i) I am developing a strategy which apart from the standard volume, and
> prices requires some other data which I have in my DB.
> I want these to be loaded into the Prices object, and then used elsewhere.
> Do I need to make modifications just to Prices.pm to
> get the data loaded. Or are there other classes which inherently assume that
> Prices can only contain open, high etc?


aloha sumit

both GT/Prices.pm and GT/Indicators/Prices.pm will need modification if you want
the gt indicators to be able to access this 'other data' in the prices object.
naturally whatever database interface module you are using may need alteration
or configuration as well.

however none of the apps that utilize GT/Graphics/DataSource methods to create and
render graphic objects will handle this 'other data' unless you also alter them
(the apps) and possibly also implement suitable additional datasource module(s)
to support this 'other data'. GT/Graphics/DataSource/Prices.pm and Volume.pm
might serve as models for any additional module(s) that might be needed.

can we ask the type and the nature of this 'other data'? there may be better
alternatives to loading up the prices object with additional data especially
if this data isn't of a market dynamic sort.


> 
> 
> ii) One of the strategies I am testing, requires simultaneous access to
> quotes from multiple stocks and indices.
> Any clue where all do I have to make the changes to get such a strategy
> working.
> It seems that most of the objects make the assumption that they are only
> dealing with a single stock.
> Is there a simple hack which can help me out?


as clk pointed out, GT/Indicators/Prices.pm allows access to the prices object
for an alternate 'code', but the timeframe and time period indices for each such
prices object would have to align. however as joao notes, GT/Indicators/FromTimeFrame
might alleviate these time related alignment requirements some. if by 'indices'
you are referring to the gt time period indices of a prices object you will have
to employ GT/Indicators/Generic/PeriodAgo.pm, on the other hand, if 'indices' means
a stock market index like ^DJA or ^HSI just treat them like another stock symbol.


good luck and keep the list posted on your efforts.

regards

ras


> 
> Regards,
> Sumit.
> 

[GT] Re: Re: Couple of questions

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

I found below to strong a restriction, so I rewrote I:Prices so that it
converts timeframes from the secondary timeframe to the current
timeframe. There still is the limitation that it allows only one
timeframe, not switching between timeframes (albeit I am not sure
whether this is even possible during the evaluation of an indicator anyway).

Th.

João Costa wrote:
>
>> the I::Prices indicator allows you to reference prices from another
>> symbol.  For example, I wrote p/c ratio values into all of OHLC in a
>> db called FOO-PCR, and use {I:Prices CLOSE FOO-PCR} to refer to it.
>>
>>     
>>
>
>   

[GT] Re: Couple of questions

[João C. <joa...@zo...>]

There is also an I:Fromtimeframe object which is useful for multi
timeframe analysis.

On 05/01/2010, Chia-liang Kao <cl...@cl...> wrote:
> Hi Sumit,
>
> 2010/1/5 Sumit Sanghai <sum...@gm...>:
>> Hello guys,
>> I am trying out GT, and had a few questions.
>> i) I am developing a strategy which apart from the standard volume, and
>> prices requires some other data which I have in my DB.
>> I want these to be loaded into the Prices object, and then used elsewhere.
>> Do I need to make modifications just to Prices.pm to
>> get the data loaded. Or are there other classes which inherently assume
>> that
>> Prices can only contain open, high etc?
>
> the I::Prices indicator allows you to reference prices from another
> symbol.  For example, I wrote p/c ratio values into all of OHLC in a
> db called FOO-PCR, and use {I:Prices CLOSE FOO-PCR} to refer to it.
>
>> ii) One of the strategies I am testing, requires simultaneous access to
>> quotes from multiple stocks and indices.
>> Any clue where all do I have to make the changes to get such a strategy
>> working.
>> It seems that most of the objects make the assumption that they are only
>> dealing with a single stock.
>> Is there a simple hack which can help me out?
>> Regards,
>> Sumit.
>
> This should be the same as above, however i think I::Prices only
> supports different symbols in same timeframe ( and possibly requires
> the data index to be same)
>
> Cheers,
> CLK
>


-- 
----
http://zonalivre.org/

[GT] Re: Couple of questions

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

Hi Sumit,

2010/1/5 Sumit Sanghai <sum...@gm...>:
> Hello guys,
> I am trying out GT, and had a few questions.
> i) I am developing a strategy which apart from the standard volume, and
> prices requires some other data which I have in my DB.
> I want these to be loaded into the Prices object, and then used elsewhere.
> Do I need to make modifications just to Prices.pm to
> get the data loaded. Or are there other classes which inherently assume that
> Prices can only contain open, high etc?

the I::Prices indicator allows you to reference prices from another
symbol.  For example, I wrote p/c ratio values into all of OHLC in a
db called FOO-PCR, and use {I:Prices CLOSE FOO-PCR} to refer to it.

> ii) One of the strategies I am testing, requires simultaneous access to
> quotes from multiple stocks and indices.
> Any clue where all do I have to make the changes to get such a strategy
> working.
> It seems that most of the objects make the assumption that they are only
> dealing with a single stock.
> Is there a simple hack which can help me out?
> Regards,
> Sumit.

This should be the same as above, however i think I::Prices only
supports different symbols in same timeframe ( and possibly requires
the data index to be same)

Cheers,
CLK

[GT] Couple of questions

[Sumit S. <sum...@gm...>]

Hello guys,

I am trying out GT, and had a few questions.

i) I am developing a strategy which apart from the standard volume, and
prices requires some other data which I have in my DB.
I want these to be loaded into the Prices object, and then used elsewhere.
Do I need to make modifications just to Prices.pm to
get the data loaded. Or are there other classes which inherently assume that
Prices can only contain open, high etc?


ii) One of the strategies I am testing, requires simultaneous access to
quotes from multiple stocks and indices.
Any clue where all do I have to make the changes to get such a strategy
working.
It seems that most of the objects make the assumption that they are only
dealing with a single stock.
Is there a simple hack which can help me out?

Regards,
Sumit.

[GT] Generate Orders For Next Day

[Greg J. <gr...@gr...>]

I am looking to use some logic to generate limit orders for the next trading
day. Does anyone currently do this? And if so, how do you do it? Do you have
a custom script? Can anyone offer an example script, very basic of how this
could be done?

-Greg

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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
GT uses currently<br>
<br>
Date::Manip<br>
Date::Calc<br>
Time::Local<br>
<br>
Josef Strobel wrote:
<blockquote cite="mid:200...@we..."
 type="cite">
  <pre wrap="">I didn't find any other time or date packaged used... Did i miss something?

Am Mittwoch 18 November 2009 schrieben Sie:
  </pre>
  <blockquote type="cite">
    <pre wrap="">I would suggest also to validate the other date and time packages
used.... Th.

Josef Strobel wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">Hi Thomas,

I will have a look at it. There are just a few files which depend on
epoch. So it would be relative simple to write some patches, but I never
did benchmark testing in perl before and I couldn't test
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
</body>
</html>

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

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

Josef Strobel wrote:
> Hi ras and all,
> 
> For getting the right time zone POSIX has the functions tzname and tzset.
> http://perldoc.perl.org/POSIX.html
> http://www.opengroup.org/onlinepubs/009695399/functions/mktime.html
> http://www.opengroup.org/onlinepubs/009695399/functions/tzset.html
> So you can set it to GMT, CST ..., to everything you need. So what problem ocurred to joao costa?

hey Josef

check the devel archive around the date 24may2005 oops how the heck
did i munge 06/11/05 into 24may2005!!???  the subject of the thread is
[GT] Support for tick data and another DateTime bug

in early '05 joao was implementing the tick time frame -- lots of good
info to be found thereabouts.

as for the use of posix::mktime(...) and family, i'm in favor, but it
needs to be correctly implemented and integrated. i just wanted to point
out that it was used early on but was backed out because it caused a
problem or appeared to do so (e.g. wasn't correctly implemented and integrated ...)

aloha

ras


> 
> Best regards
> Josef
> 
> 
> #!/usr/bin/perl
> 
> use POSIX;
> 
> print localtime() . "\n";
> my $unixtime = POSIX::mktime(0, 0, 0, $mday, $mon, $year - 1900);
> print $unixtime ."\n";
> 
> 
> ($std, $dst) = POSIX::tzname();
> print "std $std\n";
> print "dst $dst\n";
> 
> $ENV{'TZ'} = '';
> POSIX::tzset();
> print "New time/date: " . localtime() . "\n";
> 
> ($std, $dst) = POSIX::tzname();
> print "std $std\n";
> print "dst $dst\n";
> 
> $ENV{'TZ'} = 'CST+06CDT';
> POSIX::tzset();
> print "New time/date: " . localtime() . "\n";
> 
> ($std, $dst) = POSIX::tzname();
> print "std $std\n";
> print "dst $dst\n";
> 
> 
> 
> 
> 
> Am Mittwoch 18 November 2009 schrieb Robert A. Schmied:
> 
>>josef et al
>>
>>change history can sometimes be helpful to avoid repeating the same
>> mistakes again and again.
>>
>>way way way back (24may2005) the methods 'map_date_to_time' called from
>> gt::datetime used to use posix::mktime(...) but that was changed when joao
>> costa found that "Posix::mktime returns GMT, while localtime returns,
>> well, local time" and that could (did, in fact) lead to conversion errors.
>> so the calls Posix::mktime(...)
>>were changed to
>> timelocal(...)
>>
>>when one uses only an end-of-day (eod) database and doesn't use sub eod
>> timeframes this issue isn't a concern (at least i've not encountered it
>> and have not reverted to timelocal(...)).
>>
>>i suspect the correct place to implement whatever fix is needed is where
>> the date-time value is first encountered. whether this is in the
>> gt::datetime package or some place else isn't something i've looked at
>> yet.
>>
>>
>>as to the issue of dates outside of the range 1970 .. 2038, is that really
>> much of a concern? from strictly an investing investors' viewpoint
>> something that happened over a few years ago isn't likely too relevant
>> now, certainly 30 years of history is adequate for investing purposes, but
>> maybe not for investing research. as for the upper end, it's still far
>> enough in the future so it isn't going to be a problem any time soon, and
>> by then the solution will likely be trivial.
>>
>>as an aside, i note for users of flat file based prices data that gt
>> doesn't provide a way to limit the data read from these files (via the
>> $max_loaded_items argument and database $limit variable), but instead will
>> load the entire file. as these files increase in size (with lots of unused
>> data) the result is slower load times, longer processing times and higher
>> memory requirements than would be case for the same data set loaded from
>> one of the sql based database engines.
>>
>>
>>aloha
>>
>>ras
>>
> 
> 

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

[Josef S. <jos...@we...>]

Hi ras and all,

For getting the right time zone POSIX has the functions tzname and tzset.
http://perldoc.perl.org/POSIX.html
http://www.opengroup.org/onlinepubs/009695399/functions/mktime.html
http://www.opengroup.org/onlinepubs/009695399/functions/tzset.html
So you can set it to GMT, CST ..., to everything you need. So what problem ocurred to joao costa?

Best regards
Josef


#!/usr/bin/perl

use POSIX;

print localtime() . "\n";
my $unixtime = POSIX::mktime(0, 0, 0, $mday, $mon, $year - 1900);
print $unixtime ."\n";


($std, $dst) = POSIX::tzname();
print "std $std\n";
print "dst $dst\n";

$ENV{'TZ'} = '';
POSIX::tzset();
print "New time/date: " . localtime() . "\n";

($std, $dst) = POSIX::tzname();
print "std $std\n";
print "dst $dst\n";

$ENV{'TZ'} = 'CST+06CDT';
POSIX::tzset();
print "New time/date: " . localtime() . "\n";

($std, $dst) = POSIX::tzname();
print "std $std\n";
print "dst $dst\n";





Am Mittwoch 18 November 2009 schrieb Robert A. Schmied:
> 
> josef et al
> 
> change history can sometimes be helpful to avoid repeating the same
>  mistakes again and again.
> 
> way way way back (24may2005) the methods 'map_date_to_time' called from
>  gt::datetime used to use posix::mktime(...) but that was changed when joao
>  costa found that "Posix::mktime returns GMT, while localtime returns,
>  well, local time" and that could (did, in fact) lead to conversion errors.
>  so the calls Posix::mktime(...)
> were changed to
>  timelocal(...)
> 
> when one uses only an end-of-day (eod) database and doesn't use sub eod
>  timeframes this issue isn't a concern (at least i've not encountered it
>  and have not reverted to timelocal(...)).
> 
> i suspect the correct place to implement whatever fix is needed is where
>  the date-time value is first encountered. whether this is in the
>  gt::datetime package or some place else isn't something i've looked at
>  yet.
> 
> 
> as to the issue of dates outside of the range 1970 .. 2038, is that really
>  much of a concern? from strictly an investing investors' viewpoint
>  something that happened over a few years ago isn't likely too relevant
>  now, certainly 30 years of history is adequate for investing purposes, but
>  maybe not for investing research. as for the upper end, it's still far
>  enough in the future so it isn't going to be a problem any time soon, and
>  by then the solution will likely be trivial.
> 
> as an aside, i note for users of flat file based prices data that gt
>  doesn't provide a way to limit the data read from these files (via the
>  $max_loaded_items argument and database $limit variable), but instead will
>  load the entire file. as these files increase in size (with lots of unused
>  data) the result is slower load times, longer processing times and higher
>  memory requirements than would be case for the same data set loaded from
>  one of the sql based database engines.
> 
> 
> aloha
> 
> ras
> 

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

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

Josef Strobel wrote:
> 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:
> 
> my time series:
> 
> 1960-01-25,56.78,56.78,56.78,56.78,2790000,56.78
> 1960-01-22,57.38,57.38,57.38,57.38,2690000,57.38
> 1960-01-21,57.21,57.21,57.21,57.21,2700000,57.21
> 1960-01-20,57.07,57.07,57.07,57.07,2720000,57.07
> 1960-01-19,57.27,57.27,57.27,57.27,3100000,57.27
> 1960-01-18,57.89,57.89,57.89,57.89,3020000,57.89
> 1960-01-15,58.38,58.38,58.38,58.38,3400000,58.38
> 1960-01-14,58.40,58.40,58.40,58.40,3560000,58.40
> 1960-01-13,58.08,58.08,58.08,58.08,3470000,58.08
> 1960-01-12,58.41,58.41,58.41,58.41,3760000,58.41
> 1960-01-11,58.77,58.77,58.77,58.77,3470000,58.77
> 1960-01-08,59.50,59.50,59.50,59.50,3290000,59.50
> 1960-01-07,59.69,59.69,59.69,59.69,3310000,59.69
> 1960-01-06,60.13,60.13,60.13,60.13,3730000,60.13
> 1960-01-05,60.39,60.39,60.39,60.39,3710000,60.39
> 1960-01-04,59.91,59.91,59.91,59.91,3990000,59.91
> 1959-12-31,59.89,59.89,59.89,59.89,3810000,59.89
> 
> 
> $HOME/eclipse-workspace/geniustrader/script/graphic.pl --file $HOME/eclipse-
> workspace/geniustrader/own-scripts/graphic/graphic_examples.conf ^GSPC > foobar.png
> Day too big - 32871 > 24853
> Cannot handle date (0, 0, 0, 31, 11, 2059) at /home/josef/cpan/Finance/GeniusTrader/DateTime/Day.pm 
> line 24
> 
> 
> When I remove the last line in my time series it worked, so I looked in 
> Finance::GeniusTrader::DateTime::Day and took a look to the function timelocal from Time::Local.
> 
> I wrote a small script time-date-test.pl. It should test all dates from 1900-01-01 to 2039-01-01, 
> but it fails from 1938-01-17.
> 
> #!/usr/bin/perl
> 
> use warnings;
> use strict;
> use Time::Local;
> use Date::Calc qw( Delta_Days Add_Delta_Days );
> 
> # sub from package Finance::GeniusTrader::DateTime::Day;
> sub map_date_to_time {
>     my ($date) = @_;
>     my ($y, $m, $d) = split /-/, $date;
>                 ($d) = split / /, $d;
>                 print $d . "," . ($m - 1) . "," . ($y - 1900) . "\n";
>     print timelocal(0, 0, 0, $d, $m - 1, $y - 1900) . "\n";
> }
> 
> 
> 
> my @start = (1900,1,1);
> my @stop  = (2039,01,01);
> 
> my $j = Delta_Days(@start,@stop);
> 
> for (my $i = 0; $i <= $j; $i++ )
> {
>     my ($year,$month,$day) = Add_Delta_Days(@start,$i);
>     printf("%4d/%02d/%02d\n", $year,$month,$day);
>     &map_date_to_time("$year-$month-$day");
> }
> 
> 
> So what is timelocal doing?
> 
> 
> Best regards
> Josef


josef et al

change history can sometimes be helpful to avoid repeating the same mistakes again
and again.

way way way back (24may2005) the methods 'map_date_to_time' called from gt::datetime
used to use posix::mktime(...) but that was changed when joao costa found that
  "Posix::mktime returns GMT, while localtime returns, well, local time"
and that could (did, in fact) lead to conversion errors. so the calls
  Posix::mktime(...)
were changed to
 timelocal(...)

when one uses only an end-of-day (eod) database and doesn't use sub eod timeframes
this issue isn't a concern (at least i've not encountered it and have not reverted
to timelocal(...)).

i suspect the correct place to implement whatever fix is needed is where the
date-time value is first encountered. whether this is in the gt::datetime package
or some place else isn't something i've looked at yet.


as to the issue of dates outside of the range 1970 .. 2038, is that really much
of a concern? from strictly an investing investors' viewpoint something that happened
over a few years ago isn't likely too relevant now, certainly 30 years of history
is adequate for investing purposes, but maybe not for investing research. as for
the upper end, it's still far enough in the future so it isn't going to be a
problem any time soon, and by then the solution will likely be trivial.

as an aside, i note for users of flat file based prices data that gt doesn't
provide a way to limit the data read from these files (via the $max_loaded_items
argument and database $limit variable), but instead will load the entire file.
as these files increase in size (with lots of unused data) the result is slower
load times, longer processing times and higher memory requirements than would
be case for the same data set loaded from one of the sql based database engines.


aloha

ras

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

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

Joseph,

it would be great if you were to study all places we depend on the epoch
and put an experiment together to determine whether we can swap out the
time handling for something that performs well while at the same time
giving us a wider range of dates.

Th.

Josef Strobel wrote:
> 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.
>
>
>   

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

[Josef S. <jos...@we...>]

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'} = \@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 <jos...@we...>:
> >> 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:
> 

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

[Josef S. <jos...@we...>]

My perl version is v5.8.8 built for i686-linux. Can someone who uses perl version v.5.10.1 test 
http://search.cpan.org/~dapm/perl-5.10.1/lib/Time/localtime.pm. Perhaps it really works out of the 
box :)


Am Mittwoch 18 November 2009 schrieb Chia-liang Kao:
> Actually, perl 5.10's core time functions already supports 64bits, so
> it might worth to take a quick look to see if time::local magically
> works with 5.10.
> 
> 2009/11/18 Chia-liang Kao <cl...@cl...>:
> > 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 <jos...@we...>:
> >> 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:
> >>
> >> my time series:
> >>
> >> 1960-01-25,56.78,56.78,56.78,56.78,2790000,56.78
> >> 1960-01-22,57.38,57.38,57.38,57.38,2690000,57.38
> >> 1960-01-21,57.21,57.21,57.21,57.21,2700000,57.21
> >> 1960-01-20,57.07,57.07,57.07,57.07,2720000,57.07
> >> 1960-01-19,57.27,57.27,57.27,57.27,3100000,57.27
> >> 1960-01-18,57.89,57.89,57.89,57.89,3020000,57.89
> >> 1960-01-15,58.38,58.38,58.38,58.38,3400000,58.38
> >> 1960-01-14,58.40,58.40,58.40,58.40,3560000,58.40
> >> 1960-01-13,58.08,58.08,58.08,58.08,3470000,58.08
> >> 1960-01-12,58.41,58.41,58.41,58.41,3760000,58.41
> >> 1960-01-11,58.77,58.77,58.77,58.77,3470000,58.77
> >> 1960-01-08,59.50,59.50,59.50,59.50,3290000,59.50
> >> 1960-01-07,59.69,59.69,59.69,59.69,3310000,59.69
> >> 1960-01-06,60.13,60.13,60.13,60.13,3730000,60.13
> >> 1960-01-05,60.39,60.39,60.39,60.39,3710000,60.39
> >> 1960-01-04,59.91,59.91,59.91,59.91,3990000,59.91
> >> 1959-12-31,59.89,59.89,59.89,59.89,3810000,59.89
> >>
> >>
> >> $HOME/eclipse-workspace/geniustrader/script/graphic.pl --file
> >> $HOME/eclipse-
> >> workspace/geniustrader/own-scripts/graphic/graphic_examples.conf ^GSPC >
> >> foobar.png Day too big - 32871 > 24853
> >> Cannot handle date (0, 0, 0, 31, 11, 2059) at
> >> /home/josef/cpan/Finance/GeniusTrader/DateTime/Day.pm line 24
> >>
> >>
> >> When I remove the last line in my time series it worked, so I looked in
> >> Finance::GeniusTrader::DateTime::Day and took a look to the function
> >> timelocal from Time::Local.
> >>
> >> I wrote a small script time-date-test.pl. It should test all dates from
> >> 1900-01-01 to 2039-01-01, but it fails from 1938-01-17.
> >>
> >> #!/usr/bin/perl
> >>
> >> use warnings;
> >> use strict;
> >> use Time::Local;
> >> use Date::Calc qw( Delta_Days Add_Delta_Days );
> >>
> >> # sub from package Finance::GeniusTrader::DateTime::Day;
> >> sub map_date_to_time {
> >>    my ($date) = @_;
> >>    my ($y, $m, $d) = split /-/, $date;
> >>                ($d) = split / /, $d;
> >>                print $d . "," . ($m - 1) . "," . ($y - 1900) . "\n";
> >>    print timelocal(0, 0, 0, $d, $m - 1, $y - 1900) . "\n";
> >> }
> >>
> >>
> >>
> >> my @start = (1900,1,1);
> >> my @stop  = (2039,01,01);
> >>
> >> my $j = Delta_Days(@start,@stop);
> >>
> >> for (my $i = 0; $i <= $j; $i++ )
> >> {
> >>    my ($year,$month,$day) = Add_Delta_Days(@start,$i);
> >>    printf("%4d/%02d/%02d\n", $year,$month,$day);
> >>    &map_date_to_time("$year-$month-$day");
> >> }
> >>
> >>
> >> So what is timelocal doing?
> >>
> >>
> >> Best regards
> >> Josef
> 

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

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

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 <jos...@we...>:
>   
>> 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:
>>
>>
>>     

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

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

from Time::Local:

Negative Epoch Values

Negative epoch (time_t) values are not officially supported by the
POSIX standards, so this module's tests do not test them. On some
systems, they are known not to work. These include MacOS (pre-OSX) and
Win32.

On systems which do support negative epoch values, this module should
be able to cope with dates before the start of the epoch, down the
minimum value of time_t for the system.

2009/11/18 Josef Strobel <jos...@we...>:
> Hi,
>
> Its actually a 32bit integer problem. Epoch started 1970-01-01 so problems wit 32bit integers are
> before 1901-12-13 and after 2038-01-19, but there shouldn't be problems in this time frame.
>
> http://en.wikipedia.org/wiki/Unix_time
> The standard Unix time_t (data type representing a point in time) is a signed integer data type,
> traditionally of 32 bits (but see below), directly encoding the Unix time number as described in the
> preceding section. Being 32 bits (of which one bit is the sign bit) means that it covers a range of
> about 136 years in total. The minimum representable time is 1901-12-13, and the maximum
> representable time is 2038-01-19. At 03:14:07 UTC 2038-01-19 this representation overflows. This
> milestone is anticipated with a mixture of amusement and dread;
>
>
> Am Mittwoch 18 November 2009 schrieb Chia-liang Kao:
>> 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 <jos...@we...>:
>> > 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:
>> >
>> > my time series:
>> >
>> > 1960-01-25,56.78,56.78,56.78,56.78,2790000,56.78
>> > 1960-01-22,57.38,57.38,57.38,57.38,2690000,57.38
>> > 1960-01-21,57.21,57.21,57.21,57.21,2700000,57.21
>> > 1960-01-20,57.07,57.07,57.07,57.07,2720000,57.07
>> > 1960-01-19,57.27,57.27,57.27,57.27,3100000,57.27
>> > 1960-01-18,57.89,57.89,57.89,57.89,3020000,57.89
>> > 1960-01-15,58.38,58.38,58.38,58.38,3400000,58.38
>> > 1960-01-14,58.40,58.40,58.40,58.40,3560000,58.40
>> > 1960-01-13,58.08,58.08,58.08,58.08,3470000,58.08
>> > 1960-01-12,58.41,58.41,58.41,58.41,3760000,58.41
>> > 1960-01-11,58.77,58.77,58.77,58.77,3470000,58.77
>> > 1960-01-08,59.50,59.50,59.50,59.50,3290000,59.50
>> > 1960-01-07,59.69,59.69,59.69,59.69,3310000,59.69
>> > 1960-01-06,60.13,60.13,60.13,60.13,3730000,60.13
>> > 1960-01-05,60.39,60.39,60.39,60.39,3710000,60.39
>> > 1960-01-04,59.91,59.91,59.91,59.91,3990000,59.91
>> > 1959-12-31,59.89,59.89,59.89,59.89,3810000,59.89
>> >
>> >
>> > $HOME/eclipse-workspace/geniustrader/script/graphic.pl --file
>> > $HOME/eclipse-
>> > workspace/geniustrader/own-scripts/graphic/graphic_examples.conf ^GSPC >
>> > foobar.png Day too big - 32871 > 24853
>> > Cannot handle date (0, 0, 0, 31, 11, 2059) at
>> > /home/josef/cpan/Finance/GeniusTrader/DateTime/Day.pm line 24
>> >
>> >
>> > When I remove the last line in my time series it worked, so I looked in
>> > Finance::GeniusTrader::DateTime::Day and took a look to the function
>> > timelocal from Time::Local.
>> >
>> > I wrote a small script time-date-test.pl. It should test all dates from
>> > 1900-01-01 to 2039-01-01, but it fails from 1938-01-17.
>> >
>> > #!/usr/bin/perl
>> >
>> > use warnings;
>> > use strict;
>> > use Time::Local;
>> > use Date::Calc qw( Delta_Days Add_Delta_Days );
>> >
>> > # sub from package Finance::GeniusTrader::DateTime::Day;
>> > sub map_date_to_time {
>> >    my ($date) = @_;
>> >    my ($y, $m, $d) = split /-/, $date;
>> >                ($d) = split / /, $d;
>> >                print $d . "," . ($m - 1) . "," . ($y - 1900) . "\n";
>> >    print timelocal(0, 0, 0, $d, $m - 1, $y - 1900) . "\n";
>> > }
>> >
>> >
>> >
>> > my @start = (1900,1,1);
>> > my @stop  = (2039,01,01);
>> >
>> > my $j = Delta_Days(@start,@stop);
>> >
>> > for (my $i = 0; $i <= $j; $i++ )
>> > {
>> >    my ($year,$month,$day) = Add_Delta_Days(@start,$i);
>> >    printf("%4d/%02d/%02d\n", $year,$month,$day);
>> >    &map_date_to_time("$year-$month-$day");
>> > }
>> >
>> >
>> > So what is timelocal doing?
>> >
>> >
>> > Best regards
>> > Josef
>>
>

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

[Josef S. <jos...@we...>]

Hi,

Its actually a 32bit integer problem. Epoch started 1970-01-01 so problems wit 32bit integers are 
before 1901-12-13 and after 2038-01-19, but there shouldn't be problems in this time frame.

http://en.wikipedia.org/wiki/Unix_time
The standard Unix time_t (data type representing a point in time) is a signed integer data type, 
traditionally of 32 bits (but see below), directly encoding the Unix time number as described in the 
preceding section. Being 32 bits (of which one bit is the sign bit) means that it covers a range of 
about 136 years in total. The minimum representable time is 1901-12-13, and the maximum 
representable time is 2038-01-19. At 03:14:07 UTC 2038-01-19 this representation overflows. This 
milestone is anticipated with a mixture of amusement and dread;


Am Mittwoch 18 November 2009 schrieb Chia-liang Kao:
> 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 <jos...@we...>:
> > 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:
> >
> > my time series:
> >
> > 1960-01-25,56.78,56.78,56.78,56.78,2790000,56.78
> > 1960-01-22,57.38,57.38,57.38,57.38,2690000,57.38
> > 1960-01-21,57.21,57.21,57.21,57.21,2700000,57.21
> > 1960-01-20,57.07,57.07,57.07,57.07,2720000,57.07
> > 1960-01-19,57.27,57.27,57.27,57.27,3100000,57.27
> > 1960-01-18,57.89,57.89,57.89,57.89,3020000,57.89
> > 1960-01-15,58.38,58.38,58.38,58.38,3400000,58.38
> > 1960-01-14,58.40,58.40,58.40,58.40,3560000,58.40
> > 1960-01-13,58.08,58.08,58.08,58.08,3470000,58.08
> > 1960-01-12,58.41,58.41,58.41,58.41,3760000,58.41
> > 1960-01-11,58.77,58.77,58.77,58.77,3470000,58.77
> > 1960-01-08,59.50,59.50,59.50,59.50,3290000,59.50
> > 1960-01-07,59.69,59.69,59.69,59.69,3310000,59.69
> > 1960-01-06,60.13,60.13,60.13,60.13,3730000,60.13
> > 1960-01-05,60.39,60.39,60.39,60.39,3710000,60.39
> > 1960-01-04,59.91,59.91,59.91,59.91,3990000,59.91
> > 1959-12-31,59.89,59.89,59.89,59.89,3810000,59.89
> >
> >
> > $HOME/eclipse-workspace/geniustrader/script/graphic.pl --file
> > $HOME/eclipse-
> > workspace/geniustrader/own-scripts/graphic/graphic_examples.conf ^GSPC >
> > foobar.png Day too big - 32871 > 24853
> > Cannot handle date (0, 0, 0, 31, 11, 2059) at
> > /home/josef/cpan/Finance/GeniusTrader/DateTime/Day.pm line 24
> >
> >
> > When I remove the last line in my time series it worked, so I looked in
> > Finance::GeniusTrader::DateTime::Day and took a look to the function
> > timelocal from Time::Local.
> >
> > I wrote a small script time-date-test.pl. It should test all dates from
> > 1900-01-01 to 2039-01-01, but it fails from 1938-01-17.
> >
> > #!/usr/bin/perl
> >
> > use warnings;
> > use strict;
> > use Time::Local;
> > use Date::Calc qw( Delta_Days Add_Delta_Days );
> >
> > # sub from package Finance::GeniusTrader::DateTime::Day;
> > sub map_date_to_time {
> >    my ($date) = @_;
> >    my ($y, $m, $d) = split /-/, $date;
> >                ($d) = split / /, $d;
> >                print $d . "," . ($m - 1) . "," . ($y - 1900) . "\n";
> >    print timelocal(0, 0, 0, $d, $m - 1, $y - 1900) . "\n";
> > }
> >
> >
> >
> > my @start = (1900,1,1);
> > my @stop  = (2039,01,01);
> >
> > my $j = Delta_Days(@start,@stop);
> >
> > for (my $i = 0; $i <= $j; $i++ )
> > {
> >    my ($year,$month,$day) = Add_Delta_Days(@start,$i);
> >    printf("%4d/%02d/%02d\n", $year,$month,$day);
> >    &map_date_to_time("$year-$month-$day");
> > }
> >
> >
> > So what is timelocal doing?
> >
> >
> > Best regards
> > Josef
> 

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

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

Actually, perl 5.10's core time functions already supports 64bits, so
it might worth to take a quick look to see if time::local magically
works with 5.10.

2009/11/18 Chia-liang Kao <cl...@cl...>:
> 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 <jos...@we...>:
>> 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:
>>
>> my time series:
>>
>> 1960-01-25,56.78,56.78,56.78,56.78,2790000,56.78
>> 1960-01-22,57.38,57.38,57.38,57.38,2690000,57.38
>> 1960-01-21,57.21,57.21,57.21,57.21,2700000,57.21
>> 1960-01-20,57.07,57.07,57.07,57.07,2720000,57.07
>> 1960-01-19,57.27,57.27,57.27,57.27,3100000,57.27
>> 1960-01-18,57.89,57.89,57.89,57.89,3020000,57.89
>> 1960-01-15,58.38,58.38,58.38,58.38,3400000,58.38
>> 1960-01-14,58.40,58.40,58.40,58.40,3560000,58.40
>> 1960-01-13,58.08,58.08,58.08,58.08,3470000,58.08
>> 1960-01-12,58.41,58.41,58.41,58.41,3760000,58.41
>> 1960-01-11,58.77,58.77,58.77,58.77,3470000,58.77
>> 1960-01-08,59.50,59.50,59.50,59.50,3290000,59.50
>> 1960-01-07,59.69,59.69,59.69,59.69,3310000,59.69
>> 1960-01-06,60.13,60.13,60.13,60.13,3730000,60.13
>> 1960-01-05,60.39,60.39,60.39,60.39,3710000,60.39
>> 1960-01-04,59.91,59.91,59.91,59.91,3990000,59.91
>> 1959-12-31,59.89,59.89,59.89,59.89,3810000,59.89
>>
>>
>> $HOME/eclipse-workspace/geniustrader/script/graphic.pl --file $HOME/eclipse-
>> workspace/geniustrader/own-scripts/graphic/graphic_examples.conf ^GSPC > foobar.png
>> Day too big - 32871 > 24853
>> Cannot handle date (0, 0, 0, 31, 11, 2059) at /home/josef/cpan/Finance/GeniusTrader/DateTime/Day.pm
>> line 24
>>
>>
>> When I remove the last line in my time series it worked, so I looked in
>> Finance::GeniusTrader::DateTime::Day and took a look to the function timelocal from Time::Local.
>>
>> I wrote a small script time-date-test.pl. It should test all dates from 1900-01-01 to 2039-01-01,
>> but it fails from 1938-01-17.
>>
>> #!/usr/bin/perl
>>
>> use warnings;
>> use strict;
>> use Time::Local;
>> use Date::Calc qw( Delta_Days Add_Delta_Days );
>>
>> # sub from package Finance::GeniusTrader::DateTime::Day;
>> sub map_date_to_time {
>>    my ($date) = @_;
>>    my ($y, $m, $d) = split /-/, $date;
>>                ($d) = split / /, $d;
>>                print $d . "," . ($m - 1) . "," . ($y - 1900) . "\n";
>>    print timelocal(0, 0, 0, $d, $m - 1, $y - 1900) . "\n";
>> }
>>
>>
>>
>> my @start = (1900,1,1);
>> my @stop  = (2039,01,01);
>>
>> my $j = Delta_Days(@start,@stop);
>>
>> for (my $i = 0; $i <= $j; $i++ )
>> {
>>    my ($year,$month,$day) = Add_Delta_Days(@start,$i);
>>    printf("%4d/%02d/%02d\n", $year,$month,$day);
>>    &map_date_to_time("$year-$month-$day");
>> }
>>
>>
>> So what is timelocal doing?
>>
>>
>> Best regards
>> Josef
>>
>

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

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

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 <jos...@we...>:
> 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:
>
> my time series:
>
> 1960-01-25,56.78,56.78,56.78,56.78,2790000,56.78
> 1960-01-22,57.38,57.38,57.38,57.38,2690000,57.38
> 1960-01-21,57.21,57.21,57.21,57.21,2700000,57.21
> 1960-01-20,57.07,57.07,57.07,57.07,2720000,57.07
> 1960-01-19,57.27,57.27,57.27,57.27,3100000,57.27
> 1960-01-18,57.89,57.89,57.89,57.89,3020000,57.89
> 1960-01-15,58.38,58.38,58.38,58.38,3400000,58.38
> 1960-01-14,58.40,58.40,58.40,58.40,3560000,58.40
> 1960-01-13,58.08,58.08,58.08,58.08,3470000,58.08
> 1960-01-12,58.41,58.41,58.41,58.41,3760000,58.41
> 1960-01-11,58.77,58.77,58.77,58.77,3470000,58.77
> 1960-01-08,59.50,59.50,59.50,59.50,3290000,59.50
> 1960-01-07,59.69,59.69,59.69,59.69,3310000,59.69
> 1960-01-06,60.13,60.13,60.13,60.13,3730000,60.13
> 1960-01-05,60.39,60.39,60.39,60.39,3710000,60.39
> 1960-01-04,59.91,59.91,59.91,59.91,3990000,59.91
> 1959-12-31,59.89,59.89,59.89,59.89,3810000,59.89
>
>
> $HOME/eclipse-workspace/geniustrader/script/graphic.pl --file $HOME/eclipse-
> workspace/geniustrader/own-scripts/graphic/graphic_examples.conf ^GSPC > foobar.png
> Day too big - 32871 > 24853
> Cannot handle date (0, 0, 0, 31, 11, 2059) at /home/josef/cpan/Finance/GeniusTrader/DateTime/Day.pm
> line 24
>
>
> When I remove the last line in my time series it worked, so I looked in
> Finance::GeniusTrader::DateTime::Day and took a look to the function timelocal from Time::Local.
>
> I wrote a small script time-date-test.pl. It should test all dates from 1900-01-01 to 2039-01-01,
> but it fails from 1938-01-17.
>
> #!/usr/bin/perl
>
> use warnings;
> use strict;
> use Time::Local;
> use Date::Calc qw( Delta_Days Add_Delta_Days );
>
> # sub from package Finance::GeniusTrader::DateTime::Day;
> sub map_date_to_time {
>    my ($date) = @_;
>    my ($y, $m, $d) = split /-/, $date;
>                ($d) = split / /, $d;
>                print $d . "," . ($m - 1) . "," . ($y - 1900) . "\n";
>    print timelocal(0, 0, 0, $d, $m - 1, $y - 1900) . "\n";
> }
>
>
>
> my @start = (1900,1,1);
> my @stop  = (2039,01,01);
>
> my $j = Delta_Days(@start,@stop);
>
> for (my $i = 0; $i <= $j; $i++ )
> {
>    my ($year,$month,$day) = Add_Delta_Days(@start,$i);
>    printf("%4d/%02d/%02d\n", $year,$month,$day);
>    &map_date_to_time("$year-$month-$day");
> }
>
>
> So what is timelocal doing?
>
>
> Best regards
> Josef
>

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

[Josef S. <jos...@we...>]

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:

my time series:

1960-01-25,56.78,56.78,56.78,56.78,2790000,56.78
1960-01-22,57.38,57.38,57.38,57.38,2690000,57.38
1960-01-21,57.21,57.21,57.21,57.21,2700000,57.21
1960-01-20,57.07,57.07,57.07,57.07,2720000,57.07
1960-01-19,57.27,57.27,57.27,57.27,3100000,57.27
1960-01-18,57.89,57.89,57.89,57.89,3020000,57.89
1960-01-15,58.38,58.38,58.38,58.38,3400000,58.38
1960-01-14,58.40,58.40,58.40,58.40,3560000,58.40
1960-01-13,58.08,58.08,58.08,58.08,3470000,58.08
1960-01-12,58.41,58.41,58.41,58.41,3760000,58.41
1960-01-11,58.77,58.77,58.77,58.77,3470000,58.77
1960-01-08,59.50,59.50,59.50,59.50,3290000,59.50
1960-01-07,59.69,59.69,59.69,59.69,3310000,59.69
1960-01-06,60.13,60.13,60.13,60.13,3730000,60.13
1960-01-05,60.39,60.39,60.39,60.39,3710000,60.39
1960-01-04,59.91,59.91,59.91,59.91,3990000,59.91
1959-12-31,59.89,59.89,59.89,59.89,3810000,59.89


$HOME/eclipse-workspace/geniustrader/script/graphic.pl --file $HOME/eclipse-
workspace/geniustrader/own-scripts/graphic/graphic_examples.conf ^GSPC > foobar.png
Day too big - 32871 > 24853
Cannot handle date (0, 0, 0, 31, 11, 2059) at /home/josef/cpan/Finance/GeniusTrader/DateTime/Day.pm 
line 24


When I remove the last line in my time series it worked, so I looked in 
Finance::GeniusTrader::DateTime::Day and took a look to the function timelocal from Time::Local.

I wrote a small script time-date-test.pl. It should test all dates from 1900-01-01 to 2039-01-01, 
but it fails from 1938-01-17.

#!/usr/bin/perl

use warnings;
use strict;
use Time::Local;
use Date::Calc qw( Delta_Days Add_Delta_Days );

# sub from package Finance::GeniusTrader::DateTime::Day;
sub map_date_to_time {
    my ($date) = @_;
    my ($y, $m, $d) = split /-/, $date;
                ($d) = split / /, $d;
                print $d . "," . ($m - 1) . "," . ($y - 1900) . "\n";
    print timelocal(0, 0, 0, $d, $m - 1, $y - 1900) . "\n";
}



my @start = (1900,1,1);
my @stop  = (2039,01,01);

my $j = Delta_Days(@start,@stop);

for (my $i = 0; $i <= $j; $i++ )
{
    my ($year,$month,$day) = Add_Delta_Days(@start,$i);
    printf("%4d/%02d/%02d\n", $year,$month,$day);
    &map_date_to_time("$year-$month-$day");
}


So what is timelocal doing?


Best regards
Josef

[GT] Re: Re: Re: Interactive SVG GT chart

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

Thmoas,

Yes, it already does so (only when loading more data though).  the
demo gives you the view from 1998 to 2009 with 300 bars loaded, and if
you scroll to somewhere early 2009, you will see the bars reloaded
(slowly) with a vertical rescale.

gtchart.js has the zone objects taking care of the scaling and
translation, so i believe if you just hack the resize function (which
sets ymax/ymin) and call it every time when scrolling (or at the end
of continuous scroll, for usability) and apply them with
this.blanket.attr(), it should do what you want.

One thing to note that, if you are already familiar with the GT
graphical objects, the zones in gtchart.js does the scaling and
translation transparently, so your objects (curve, rect) just need to
use the y-value (price, or whatever calculated values) as-is, which is
a lot more pleasant to work with.

Jon, would you like to hack on this instead of fighting with buysellarrows? ;)

2009/11/17 Thomas Weigert <we...@ms...>:
> Chia Liang,
>
> pretty cool.... this would be a great addition to GT. Sure beats the
> charts I render statically from the png created by graphics.pl, once you
> add scales etc. Can svg dynamically resize the vertical scales as you
> render which would be nice when scrolling as the market changes (make
> vertical scale cover the lowest and highest bar in view)?
>
> Th.
>
> Chia-liang Kao wrote:
>> In case you are curious about this new chart thingy, i setup a demo at
>> http://home.clkao.org:3997/d/TX/day
>>
>>
>>
>