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

[GT] Re: Re: Re: Re: Re: Re: Re: Re: SVN Commit r698 - branches/CPAN/script

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

On 08 Aug 2009, at 19:28, Erik Colson wrote:

> The idea is to work in 2 phases:

well I meant 2 release phases here ;)

> 1. Modulify the current scripts without modifying any options, subs  
> etc
> 2. Set up a main script which will call these new modules.
> 3. Release :)
> 4. Unify individual script options to make the whole stuff look  
> integrated.
> 5. Release :)

[GT] Re: Re: Re: Re: Re: Re: Re: SVN Commit r698 - branches/CPAN/script

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

On 08 Aug 2009, at 18:02, Chia-liang Kao wrote:

> as for more general command dispatching stuff, i wrote my new stuff
> that use the GT libraries with MooseX::App::Cmd. Moosifying[1] the
> codebase with more modern practices might be a good direction after we
> have everything integrated to the cpan branch.

Great !

This is going far far beyond my most optimistic plans. Moose is cool.  
Moose is great. Moose is definitely the way to go!

But I can't do that conversion all on my own. So I'm happy, I'm  
enthusiastic that we are now 2 developers willing to work on this side  
of the world !

Note:
If the repo was on git I'd already have a 'Moose' branch ;) as with  
git branching and easy merging and cherry-picking it'd be harmless to  
start working on this.

--
erik

[GT] Re: Re: Re: Re: Re: Re: Re: SVN Commit r698 - branches/CPAN/script

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

On 08 Aug 2009, at 18:00, Chia-liang Kao wrote:

> erik,
>
> actually i have refactoed the CLI handling part of the scripts.  was
> waiting for the cpan branch to settle down a bit to repatch. here's my
> current (old) GT::CLI. feel free to integrate it.

Hi Chia-Lang (or is Kao your first name?),

The idea is to work in 2 phases:
1. Modulify the current scripts without modifying any options, subs etc
2. Set up a main script which will call these new modules.
3. Release :)
4. Unify individual script options to make the whole stuff look  
integrated.
5. Release :)

Your code is part of item 4 I think ;)

--
erik

[GT] Re: Re: Re: Re: Re: Re: Re: Re: SVN Commit r698 - branches/CPAN/script

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

It was a start for extracting duplicated code from some scripts, since
I needed the getopts for my custom scripts but don't want to copy the
code all over.

2009/8/8 Thomas Weigert <we...@ms...>:
> Chia Liang,
>
> I don't understand. What you sent as CLI.pm is not abstracting a common
> functionality for all scripts. Can you explain a little more what you
> intend here?
>
> Thanks, Th.
>
> Chia-liang Kao wrote:
>> erik,
>>
>> actually i have refactoed the CLI handling part of the scripts.  was
>> waiting for the cpan branch to settle down a bit to repatch. here's my
>> current (old) GT::CLI. feel free to integrate it.
>>
>> 2009/8/8 Erik Colson <ec...@ec...>:
>>
>>> On 08 Aug 2009, at 16:16, Thomas Weigert wrote:
>>>
>>>
>>>> So in my opinion, 2 things should now be attempted:
>>>>        • the latest trunk patches should be generated to be applicable to
>>>> the CPAN branch
>>>>
>>> OK to me, as long as revisions don't create/move files in unwanted places.
>>> The actual file hierarchy seems pretty good and might even come over as
>>> 'definitive' to others. Please this is _not_ the case. There are still files
>>> needing to be move / converted etc.
>>>
>>>
>>>>        • the exp enhancements should be turned into patches that can be
>>>> applied to the CPAN branch.
>>>>
>>> Yep, PerlTrader already did a good part of this work and submitted a huge
>>> patch on the list. We definitely should apply this to CPAN branch which will
>>> make CPAN move far-far away from trunk bringing trunk to the state of
>>> obsolete. At this point patches to trunk won't probably be applied to CPAN
>>> anymore.
>>> We'd probably need a list of enhancements/bug fixes in PerlTraders patch.
>>> And probably write a bunch of tests to bring CPAN branch to 'stable' state.
>>> If anyone has time for this, please feel free ;)
>>>
>>> About the scripts:
>>> ==================
>>> I am thinking about writing a 'global' interface script while looking to all
>>> scripts available in the script dir. The real good solution I'm leaning to
>>> is to make the scripts behave as modules which would be called from the
>>> launch script. Aliases will be available for 'old-time' users compatibility
>>> ;)
>>>
>>> This might look strange but is the preferred way for CPAN publication: the
>>> reasons:
>>> - only modules are tested, not scripts.
>>> - everything is kept in place in site_perl hierarchy.
>>>
>>> It might help to think as follows:
>>> In an object oriented way of thinking, all the scripts available are nothing
>>> else than methods of Finance::GeniusTrader. So they should be modules.
>>>
>>> In example you might look at Finance::QuoteDB which does have this kind of
>>> interface.
>>>
>>> regards
>>> --
>>> erik
>>>
>

[GT] Re: Re: Re: Re: Re: Re: Re: SVN Commit r698 - branches/CPAN/script

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

Chia Liang,

I don't understand. What you sent as CLI.pm is not abstracting a common
functionality for all scripts. Can you explain a little more what you
intend here?

Thanks, Th.

Chia-liang Kao wrote:
> erik,
>
> actually i have refactoed the CLI handling part of the scripts.  was
> waiting for the cpan branch to settle down a bit to repatch. here's my
> current (old) GT::CLI. feel free to integrate it.
>
> 2009/8/8 Erik Colson <ec...@ec...>:
>   
>> On 08 Aug 2009, at 16:16, Thomas Weigert wrote:
>>
>>     
>>> So in my opinion, 2 things should now be attempted:
>>>        • the latest trunk patches should be generated to be applicable to
>>> the CPAN branch
>>>       
>> OK to me, as long as revisions don't create/move files in unwanted places.
>> The actual file hierarchy seems pretty good and might even come over as
>> 'definitive' to others. Please this is _not_ the case. There are still files
>> needing to be move / converted etc.
>>
>>     
>>>        • the exp enhancements should be turned into patches that can be
>>> applied to the CPAN branch.
>>>       
>> Yep, PerlTrader already did a good part of this work and submitted a huge
>> patch on the list. We definitely should apply this to CPAN branch which will
>> make CPAN move far-far away from trunk bringing trunk to the state of
>> obsolete. At this point patches to trunk won't probably be applied to CPAN
>> anymore.
>> We'd probably need a list of enhancements/bug fixes in PerlTraders patch.
>> And probably write a bunch of tests to bring CPAN branch to 'stable' state.
>> If anyone has time for this, please feel free ;)
>>
>> About the scripts:
>> ==================
>> I am thinking about writing a 'global' interface script while looking to all
>> scripts available in the script dir. The real good solution I'm leaning to
>> is to make the scripts behave as modules which would be called from the
>> launch script. Aliases will be available for 'old-time' users compatibility
>> ;)
>>
>> This might look strange but is the preferred way for CPAN publication: the
>> reasons:
>> - only modules are tested, not scripts.
>> - everything is kept in place in site_perl hierarchy.
>>
>> It might help to think as follows:
>> In an object oriented way of thinking, all the scripts available are nothing
>> else than methods of Finance::GeniusTrader. So they should be modules.
>>
>> In example you might look at Finance::QuoteDB which does have this kind of
>> interface.
>>
>> regards
>> --
>> erik
>>     

[GT] Re: Re: Re: Re: Re: Re: SVN Commit r698 - branches/CPAN/script

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

as for more general command dispatching stuff, i wrote my new stuff
that use the GT libraries with MooseX::App::Cmd. Moosifying[1] the
codebase with more modern practices might be a good direction after we
have everything integrated to the cpan branch.

[1] moose.perl.org

2009/8/8 Chia-liang Kao <cl...@cl...>:
> erik,
>
> actually i have refactoed the CLI handling part of the scripts.  was
> waiting for the cpan branch to settle down a bit to repatch. here's my
> current (old) GT::CLI. feel free to integrate it.
>
> 2009/8/8 Erik Colson <ec...@ec...>:
>>
>> On 08 Aug 2009, at 16:16, Thomas Weigert wrote:
>>
>>> So in my opinion, 2 things should now be attempted:
>>>        • the latest trunk patches should be generated to be applicable to
>>> the CPAN branch
>>
>> OK to me, as long as revisions don't create/move files in unwanted places.
>> The actual file hierarchy seems pretty good and might even come over as
>> 'definitive' to others. Please this is _not_ the case. There are still files
>> needing to be move / converted etc.
>>
>>>        • the exp enhancements should be turned into patches that can be
>>> applied to the CPAN branch.
>>
>> Yep, PerlTrader already did a good part of this work and submitted a huge
>> patch on the list. We definitely should apply this to CPAN branch which will
>> make CPAN move far-far away from trunk bringing trunk to the state of
>> obsolete. At this point patches to trunk won't probably be applied to CPAN
>> anymore.
>> We'd probably need a list of enhancements/bug fixes in PerlTraders patch.
>> And probably write a bunch of tests to bring CPAN branch to 'stable' state.
>> If anyone has time for this, please feel free ;)
>>
>> About the scripts:
>> ==================
>> I am thinking about writing a 'global' interface script while looking to all
>> scripts available in the script dir. The real good solution I'm leaning to
>> is to make the scripts behave as modules which would be called from the
>> launch script. Aliases will be available for 'old-time' users compatibility
>> ;)
>>
>> This might look strange but is the preferred way for CPAN publication: the
>> reasons:
>> - only modules are tested, not scripts.
>> - everything is kept in place in site_perl hierarchy.
>>
>> It might help to think as follows:
>> In an object oriented way of thinking, all the scripts available are nothing
>> else than methods of Finance::GeniusTrader. So they should be modules.
>>
>> In example you might look at Finance::QuoteDB which does have this kind of
>> interface.
>>
>> regards
>> --
>> erik
>

[GT] Re: Re: Re: Re: Re: Re: SVN Commit r698 - branches/CPAN/script

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

erik,

actually i have refactoed the CLI handling part of the scripts.  was
waiting for the cpan branch to settle down a bit to repatch. here's my
current (old) GT::CLI. feel free to integrate it.

2009/8/8 Erik Colson <ec...@ec...>:
>
> On 08 Aug 2009, at 16:16, Thomas Weigert wrote:
>
>> So in my opinion, 2 things should now be attempted:
>>        • the latest trunk patches should be generated to be applicable to
>> the CPAN branch
>
> OK to me, as long as revisions don't create/move files in unwanted places.
> The actual file hierarchy seems pretty good and might even come over as
> 'definitive' to others. Please this is _not_ the case. There are still files
> needing to be move / converted etc.
>
>>        • the exp enhancements should be turned into patches that can be
>> applied to the CPAN branch.
>
> Yep, PerlTrader already did a good part of this work and submitted a huge
> patch on the list. We definitely should apply this to CPAN branch which will
> make CPAN move far-far away from trunk bringing trunk to the state of
> obsolete. At this point patches to trunk won't probably be applied to CPAN
> anymore.
> We'd probably need a list of enhancements/bug fixes in PerlTraders patch.
> And probably write a bunch of tests to bring CPAN branch to 'stable' state.
> If anyone has time for this, please feel free ;)
>
> About the scripts:
> ==================
> I am thinking about writing a 'global' interface script while looking to all
> scripts available in the script dir. The real good solution I'm leaning to
> is to make the scripts behave as modules which would be called from the
> launch script. Aliases will be available for 'old-time' users compatibility
> ;)
>
> This might look strange but is the preferred way for CPAN publication: the
> reasons:
> - only modules are tested, not scripts.
> - everything is kept in place in site_perl hierarchy.
>
> It might help to think as follows:
> In an object oriented way of thinking, all the scripts available are nothing
> else than methods of Finance::GeniusTrader. So they should be modules.
>
> In example you might look at Finance::QuoteDB which does have this kind of
> interface.
>
> regards
> --
> erik

[GT] Re: Re: Re: Re: Re: Re: SVN Commit r698 - branches/CPAN/script

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

This is a good philosophy, but you will find that these scripts are
really a bunch of separate programs different people have written to do
whatever they need to do with GT. They were very inconsistent, and part
of what I did in exp (some of that is in trunk now but not all) was to
at least give them a consistent API, so that the options meant the same
in all the scripts. I also move some functionality that was differently
duplicated in each of the scripts into modules.

But they are still serving totally different needs, and you will find
that some people only use backtest, while others only use scan, and yet
others don't use any scripts but have their own. Most people do use
graphics.

All that said, I think it is fine to have a module directory where
basically each body of a script is written as a module, and then there
is a single script invoking all. And the aliases for the "oldtimers".


Th.

Erik Colson wrote:
>
> About the scripts:
> ==================
> I am thinking about writing a 'global' interface script while looking
> to all scripts available in the script dir. The real good solution I'm
> leaning to is to make the scripts behave as modules which would be
> called from the launch script. Aliases will be available for
> 'old-time' users compatibility ;)
>
> This might look strange but is the preferred way for CPAN publication:
> the reasons:
> - only modules are tested, not scripts.
> - everything is kept in place in site_perl hierarchy.
>
> It might help to think as follows:
> In an object oriented way of thinking, all the scripts available are
> nothing else than methods of Finance::GeniusTrader. So they should be
> modules.
>
> In example you might look at Finance::QuoteDB which does have this
> kind of interface.
>
>

[GT] Re: Re: Re: Re: Re: SVN Commit r698 - branches/CPAN/script

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

On 08 Aug 2009, at 16:16, Thomas Weigert wrote:

> So in my opinion, 2 things should now be attempted:
> 	• the latest trunk patches should be generated to be applicable to  
> the CPAN branch

OK to me, as long as revisions don't create/move files in unwanted  
places. The actual file hierarchy seems pretty good and might even  
come over as 'definitive' to others. Please this is _not_ the case.  
There are still files needing to be move / converted etc.

> 	• the exp enhancements should be turned into patches that can be  
> applied to the CPAN branch.

Yep, PerlTrader already did a good part of this work and submitted a  
huge patch on the list. We definitely should apply this to CPAN branch  
which will make CPAN move far-far away from trunk bringing trunk to  
the state of obsolete. At this point patches to trunk won't probably  
be applied to CPAN anymore.
We'd probably need a list of enhancements/bug fixes in PerlTraders  
patch. And probably write a bunch of tests to bring CPAN branch to  
'stable' state.
If anyone has time for this, please feel free ;)

About the scripts:
==================
I am thinking about writing a 'global' interface script while looking  
to all scripts available in the script dir. The real good solution I'm  
leaning to is to make the scripts behave as modules which would be  
called from the launch script. Aliases will be available for 'old- 
time' users compatibility ;)

This might look strange but is the preferred way for CPAN publication:  
the reasons:
- only modules are tested, not scripts.
- everything is kept in place in site_perl hierarchy.

It might help to think as follows:
In an object oriented way of thinking, all the scripts available are  
nothing else than methods of Finance::GeniusTrader. So they should be  
modules.

In example you might look at Finance::QuoteDB which does have this  
kind of interface.

regards
--
erik

[GT] Re: Re: Re: Re: SVN Commit r698 - branches/CPAN/script

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=windows-1252"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
So in my opinion, 2 things should now be attempted:<br>
<ul>
  <li>the latest trunk patches should be generated to be applicable to
the CPAN branch</li>
  <li>the exp enhancements should be turned into patches that can be
applied to the CPAN branch.</li>
</ul>
Th.<br>
<br>
Thomas Weigert wrote:
<blockquote cite="mid:4A7...@ms..." type="cite">
  <pre wrap="">My opinion is that it should be the new exp, or bleeding edge, at this
point. If Robert feels comfortable with CPAN, we can move over the trunk
as well.

On exp there is further out development. It would be a shame if the
developers contributing to that cannot benefit from the CPAN features....

Th.

Erik Colson wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">On 08 Aug 2009, at 15:34, Thomas Weigert wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">How are we going to go forward with the CPAN branch?

    • Is this only a "cpanified" version of trunk?
    • Is this a "cpanified" version of exp?
    • Is this the new exp, i.e., the bleeding edge of GT?
    • Is it something else?
Maybe I jumped the gun with checking in this patch. Please comment on
what the CPAN branch should become when it grows up?
      </pre>
    </blockquote>
    <pre wrap="">
I go for "something else" ;)
In my idea, CPAN should replace trunk once it is well packaged and
tested.
So, while in development, it should get patches _only_ for the
CPANification and eventually patches which are also present in trunk
(preferably sequentially).
We are already missing patches from trunk which should probably be
ported to the CPAN-branch as early as possible to make trunk and
CPAN-branch stay as sync as possible.
After merging CPAN to trunk, 'exp' should be formatted to CPAN
hierarchy also.

It's rather painful to think in git while using svn :/ I'm always
afraid merging will become an impossible task as CPAN evolves further
and further away from trunk.

-- 
erik
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
</body>
</html>

[GT] Re: Re: Re: Re: SVN Commit r698 - branches/CPAN/script

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

My opinion is that it should be the new exp, or bleeding edge, at this
point. If Robert feels comfortable with CPAN, we can move over the trunk
as well.

On exp there is further out development. It would be a shame if the
developers contributing to that cannot benefit from the CPAN features....

Th.

Erik Colson wrote:
>
> On 08 Aug 2009, at 15:34, Thomas Weigert wrote:
>
>> How are we going to go forward with the CPAN branch?
>>
>>     • Is this only a "cpanified" version of trunk?
>>     • Is this a "cpanified" version of exp?
>>     • Is this the new exp, i.e., the bleeding edge of GT?
>>     • Is it something else?
>> Maybe I jumped the gun with checking in this patch. Please comment on
>> what the CPAN branch should become when it grows up?
>
>
> I go for "something else" ;)
> In my idea, CPAN should replace trunk once it is well packaged and
> tested.
> So, while in development, it should get patches _only_ for the
> CPANification and eventually patches which are also present in trunk
> (preferably sequentially).
> We are already missing patches from trunk which should probably be
> ported to the CPAN-branch as early as possible to make trunk and
> CPAN-branch stay as sync as possible.
> After merging CPAN to trunk, 'exp' should be formatted to CPAN
> hierarchy also.
>
> It's rather painful to think in git while using svn :/ I'm always
> afraid merging will become an impossible task as CPAN evolves further
> and further away from trunk.
>
> -- 
> erik

[GT] Re: Re: Re: SVN Commit r698 - branches/CPAN/script

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

On 08 Aug 2009, at 15:34, Thomas Weigert wrote:

>>> Author: thomas
>>> Date: 2009-08-08 03:35:44 +0200 (Sat, 08 Aug 2009)
>>> New Revision: 698
>>>
>>> Modified:
>>>   branches/CPAN/script/analyze_backtest.pl
>>>   branches/CPAN/script/backtest.pl
>>>   branches/CPAN/script/manage_portfolio.pl
>>> Log:
>>> Correct scripts using  incorrectly.
>

Hi Thomas,

Coming back on this bug correction,
It should definitely be applied to trunk also.

--
erik

[GT] Re: Re: Re: SVN Commit r698 - branches/CPAN/script

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

On 08 Aug 2009, at 15:34, Thomas Weigert wrote:

> How are we going to go forward with the CPAN branch?
>
> 	• Is this only a "cpanified" version of trunk?
> 	• Is this a "cpanified" version of exp?
> 	• Is this the new exp, i.e., the bleeding edge of GT?
> 	• Is it something else?
> Maybe I jumped the gun with checking in this patch. Please comment  
> on what the CPAN branch should become when it grows up?


I go for "something else" ;)
In my idea, CPAN should replace trunk once it is well packaged and  
tested.
So, while in development, it should get patches _only_ for the  
CPANification and eventually patches which are also present in trunk  
(preferably sequentially).
We are already missing patches from trunk which should probably be  
ported to the CPAN-branch as early as possible to make trunk and CPAN- 
branch stay as sync as possible.
After merging CPAN to trunk, 'exp' should be formatted to CPAN  
hierarchy also.

It's rather painful to think in git while using svn :/ I'm always  
afraid merging will become an impossible task as CPAN evolves further  
and further away from trunk.

--
erik

[GT] Re: Re: SVN Commit r698 - branches/CPAN/script

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
You are raising a good point....<br>
<br>
How are we going to go forward with the CPAN branch?<br>
<br>
<ul>
  <li>Is this only a "cpanified" version of trunk?</li>
  <li>Is this a "cpanified" version of exp?</li>
  <li>Is this the new exp, i.e., the bleeding edge of GT?</li>
  <li>Is it something else?</li>
</ul>
Maybe I jumped the gun with checking in this patch. Please comment on
what the CPAN branch should become when it grows up?<br>
<br>
Thanks, Th.<br>
<br>
Erik Colson wrote:
<blockquote cite="mid:E3C...@ec..."
 type="cite"><br>
On 08 Aug 2009, at 03:35, GeniusTrader SVN wrote:
  <br>
  <br>
  <blockquote type="cite">Author: thomas
    <br>
Date: 2009-08-08 03:35:44 +0200 (Sat, 08 Aug 2009)
    <br>
New Revision: 698
    <br>
    <br>
Modified:
    <br>
&nbsp; branches/CPAN/script/analyze_backtest.pl
    <br>
&nbsp; branches/CPAN/script/backtest.pl
    <br>
&nbsp; branches/CPAN/script/manage_portfolio.pl
    <br>
Log:
    <br>
Correct scripts using&nbsp; incorrectly.
    <br>
  </blockquote>
  <br>
  <br>
Hi Thomas,
  <br>
  <br>
Shouldn't this patch be applied to trunk also ?
  <br>
  <br>
Now we are applying patches not related to the cpan port to the CPAN
branch and already have such patches in trunk which are not applied to
CPAN branch...
  <br>
Does svn allow cherry-picking commits from one branch to another ?
  <br>
  <br>
--
  <br>
erik
  <br>
</blockquote>
</body>
</html>

[GT] Re: SVN Commit r698 - branches/CPAN/script

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

On 08 Aug 2009, at 03:35, GeniusTrader SVN wrote:

> Author: thomas
> Date: 2009-08-08 03:35:44 +0200 (Sat, 08 Aug 2009)
> New Revision: 698
>
> Modified:
>   branches/CPAN/script/analyze_backtest.pl
>   branches/CPAN/script/backtest.pl
>   branches/CPAN/script/manage_portfolio.pl
> Log:
> Correct scripts using  incorrectly.


Hi Thomas,

Shouldn't this patch be applied to trunk also ?

Now we are applying patches not related to the cpan port to the CPAN  
branch and already have such patches in trunk which are not applied to  
CPAN branch...
Does svn allow cherry-picking commits from one branch to another ?

--
erik

[GT] Re: eval bugs [PATCH]

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

On 08 Aug 2009, at 03:30, Gregory Margo wrote:

> After an "eval()", the $@ variable indicates an error.
> However, in three locations, the code tests "@!" instead of "$@".
> I'm not sure what "@!" is supposed to be, but it's not the correct  
> test.
>
> (I found this when "use HTML::Mason;" did not fail as it should have
> since I did not have it installed.)
>
> See attached patch.

don't know about '@!' either. didn't find it in perldoc perlvar.

--
erik

[GT] SVN Commit r698 - branches/CPAN/script

[GeniusTrader S. <ra...@ge...>]

Author: thomas
Date: 2009-08-08 03:35:44 +0200 (Sat, 08 Aug 2009)
New Revision: 698

Modified:
   branches/CPAN/script/analyze_backtest.pl
   branches/CPAN/script/backtest.pl
   branches/CPAN/script/manage_portfolio.pl
Log:
Correct scripts using  incorrectly.

Modified: branches/CPAN/script/analyze_backtest.pl
===================================================================
--- branches/CPAN/script/analyze_backtest.pl	2009-08-07 14:51:06 UTC (rev 697)
+++ branches/CPAN/script/analyze_backtest.pl	2009-08-08 01:35:44 UTC (rev 698)
@@ -83,7 +83,7 @@
 
    my $use = 'use HTML::Mason;use File::Spec;use Cwd;';
    eval $use;
-   die(@!) if(@!);
+   die($@) if($@);
  
    my $output;
    my $l = $spool->list_available_data($set);

Modified: branches/CPAN/script/backtest.pl
===================================================================
--- branches/CPAN/script/backtest.pl	2009-08-07 14:51:06 UTC (rev 697)
+++ branches/CPAN/script/backtest.pl	2009-08-08 01:35:44 UTC (rev 698)
@@ -405,7 +405,7 @@
 
   my $use = 'use HTML::Mason;use File::Spec;use Cwd;';
   eval $use;
-  die(@!) if(@!);
+  die($@) if($@);
 
   my $root = Finance::GeniusTrader::Conf::get('Template::directory');
   $root = File::Spec->rel2abs( cwd() ) if (!defined($root));

Modified: branches/CPAN/script/manage_portfolio.pl
===================================================================
--- branches/CPAN/script/manage_portfolio.pl	2009-08-07 14:51:06 UTC (rev 697)
+++ branches/CPAN/script/manage_portfolio.pl	2009-08-08 01:35:44 UTC (rev 698)
@@ -637,7 +637,7 @@
         my $use = 'use HTML::Mason;use File::Spec;use Cwd;';
 
         eval $use;
-        die(@!) if(@!);
+        die($@) if($@);
 
         my $interp = HTML::Mason::Interp->new( comp_root => $root,
     					       out_method => \$output

[GT] eval bugs [PATCH]

[Gregory M. <gm...@pa...>]

After an "eval()", the $@ variable indicates an error.
However, in three locations, the code tests "@!" instead of "$@".
I'm not sure what "@!" is supposed to be, but it's not the correct test.

(I found this when "use HTML::Mason;" did not fail as it should have
since I did not have it installed.)

See attached patch.
-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Gregory H. Margo
gmargo at yahoo/com, gmail/com, pacbell/net; greg at margofamily/org

[GT] Re: Re: Re: Re: RSI values [PATCH]

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

Yes, was thinking along those lines...
Looks like there is a formula link for Cutlers RSI
http://www.aspenres.com/Documents/AspenGraphics4.0/CutlersRSI.htm
Not sure if this does it or not...will have to have a look. But 5:39pm on a
friday is not the time I think clearest :)




On Fri, Aug 7, 2009 at 5:33 PM, Gregory Margo <gm...@pa...> wrote:

> On Fri, Aug 07, 2009 at 03:24:53PM -0500, Thomas Weigert wrote:
> > Normally, if there are "singularities", by which I mean single value
> > that are unusual because of a mathematical property of the indicator,
> > you could use some internal smoothing, such as use an average of n
> > recent values. The smoothing function could be given as an additional
> > parameter (with a default, of course). Th.
> >
> > Greg Jessup wrote:
> > > This definitely seems logical to me. I have applied the patch to my
> > > local build and it looks fine,.
> > >
> > > However, I'd still like to figure out how yahoo and other charting
> > > sites calculate an RSI for days when there is no Average Loss in the
> > > range.
> > > If you set it to 100 like we are with this patch and you are selling
> > > on this indicator at a certain point..you can potentially miss large
> > > rally, like what would have happened mid July. You would have sold out
> > > because the indicator says 100 when its actually around 65.
>
>
> They probably are not using the simplistic version of RSI that we are.
> There's a lot of detail about a fancier version using exponential moving
> averages in the Wikipedia article.
>
> http://en.wikipedia.org/wiki/Relative_strength_index
>
> --
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Gregory H. Margo
> gmargo at yahoo/com, gmail/com, pacbell/net; greg at margofamily/org
>

[GT] Re: Re: Re: RSI values [PATCH]

[Gregory M. <gm...@pa...>]

On Fri, Aug 07, 2009 at 03:24:53PM -0500, Thomas Weigert wrote:
> Normally, if there are "singularities", by which I mean single value
> that are unusual because of a mathematical property of the indicator,
> you could use some internal smoothing, such as use an average of n
> recent values. The smoothing function could be given as an additional
> parameter (with a default, of course). Th.
> 
> Greg Jessup wrote:
> > This definitely seems logical to me. I have applied the patch to my
> > local build and it looks fine,.
> >
> > However, I'd still like to figure out how yahoo and other charting
> > sites calculate an RSI for days when there is no Average Loss in the
> > range.
> > If you set it to 100 like we are with this patch and you are selling
> > on this indicator at a certain point..you can potentially miss large
> > rally, like what would have happened mid July. You would have sold out
> > because the indicator says 100 when its actually around 65.


They probably are not using the simplistic version of RSI that we are.
There's a lot of detail about a fancier version using exponential moving
averages in the Wikipedia article.

http://en.wikipedia.org/wiki/Relative_strength_index

-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Gregory H. Margo
gmargo at yahoo/com, gmail/com, pacbell/net; greg at margofamily/org

[GT] Re: Re: RSI values [PATCH]

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

Normally, if there are "singularities", by which I mean single value
that are unusual because of a mathematical property of the indicator,
you could use some internal smoothing, such as use an average of n
recent values. The smoothing function could be given as an additional
parameter (with a default, of course). Th.

Greg Jessup wrote:
> This definitely seems logical to me. I have applied the patch to my
> local build and it looks fine,.
>
> However, I'd still like to figure out how yahoo and other charting
> sites calculate an RSI for days when there is no Average Loss in the
> range.
> If you set it to 100 like we are with this patch and you are selling
> on this indicator at a certain point..you can potentially miss large
> rally, like what would have happened mid July. You would have sold out
> because the indicator says 100 when its actually around 65.
>
> I'm still hacking at it, but I do think your patch is better than my
> original.
>
>

[GT] Re: Re: RSI values [PATCH]

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

This definitely seems logical to me. I have applied the patch to my local
build and it looks fine,.

However, I'd still like to figure out how yahoo and other charting sites
calculate an RSI for days when there is no Average Loss in the range.
If you set it to 100 like we are with this patch and you are selling on this
indicator at a certain point..you can potentially miss large rally, like
what would have happened mid July. You would have sold out because the
indicator says 100 when its actually around 65.

I'm still hacking at it, but I do think your patch is better than my
original.

-Greg



On Fri, Aug 7, 2009 at 3:09 PM, Gregory Margo <gm...@pa...> wrote:

> On Thu, Aug 06, 2009 at 12:17:36PM -0400, Greg Jessup wrote:
> > According to the RSI definition if the Average Loss or in our case
> > $sum_of_lost_points is 0...
> > then RSI should be set to 100. Currently we have it going to 1.00
> >
> > so
> > if ($sum_of_lost_points != 0) {
> >        $rs = $sum_of_won_points / $sum_of_lost_points;
> > }
> > should be changed to
> > $rs = (($sum_of_lost_points == 0) ? 100 :
> > $sum_of_won_points/$sum_of_lost_points );
> >
> > -Greg
>
>
> I believe there's a problem with your patch.
> You are changing $rs, not $rsi, so you're still getting the wrong value
> for $rsi.
>
> Also, the original code misses an edge case entirely - the case of both
> $sum_of_won_points and $sum_of_lost_points equal to zero.
> (In this case, zero divided by zero is one, not undefined.)
> This should give an RSI of 50, just as if the won and lost points were
> equal but non-zero.
>
>
>
> I'll attach a patch, but viewing the patch directly makes discussing a
> bit confusing, so I'll lay out both sections here first.
>
> Here's the original code:
>
>    if ($sum_of_lost_points != 0) {
>       $rs = $sum_of_won_points / $sum_of_lost_points;
>    }
>
>    $rsi = 100 - (100 / (1 + $rs));
>
>
> Here's my version that I believe catches all the problems including the
> missing edge case:
>
>    if ($sum_of_lost_points != 0) {
>       $rs = $sum_of_won_points / $sum_of_lost_points;
>       $rsi = 100 - (100 / (1 + $rs));
>    }
>    elsif ($sum_of_won_points == 0) {
>       $rs = 1;
>       $rsi = 100 - (100 / (1 + $rs));
>    }
>    else {
>       # $rs = infinite;
>       $rsi = 100;
>    }
>
>
> The first case is the normal case with lost!=0, which handles any won
> value.
>
> The second case is the lost==0 && won==0 case, which has to come out the
> same as anytime lost==won if they're not zero.
>
> The third case is the lost==0 && won!=0 case.
>
> Note that in the third case, $rsi cannot be properly calculated from the
> formula since $rs whould need to be infinite.
>
> Patch is attached.
>
> --
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Gregory H. Margo
> gmargo at yahoo/com, gmail/com, pacbell/net; greg at margofamily/org
>

[GT] Re: RSI values [PATCH]

[Gregory M. <gm...@pa...>]

On Thu, Aug 06, 2009 at 12:17:36PM -0400, Greg Jessup wrote:
> According to the RSI definition if the Average Loss or in our case
> $sum_of_lost_points is 0...
> then RSI should be set to 100. Currently we have it going to 1.00
> 
> so
> if ($sum_of_lost_points != 0) {
>        $rs = $sum_of_won_points / $sum_of_lost_points;
> }
> should be changed to
> $rs = (($sum_of_lost_points == 0) ? 100 :
> $sum_of_won_points/$sum_of_lost_points );
> 
> -Greg


I believe there's a problem with your patch.
You are changing $rs, not $rsi, so you're still getting the wrong value
for $rsi.

Also, the original code misses an edge case entirely - the case of both
$sum_of_won_points and $sum_of_lost_points equal to zero.
(In this case, zero divided by zero is one, not undefined.)
This should give an RSI of 50, just as if the won and lost points were
equal but non-zero.



I'll attach a patch, but viewing the patch directly makes discussing a
bit confusing, so I'll lay out both sections here first.

Here's the original code:

    if ($sum_of_lost_points != 0) {
       $rs = $sum_of_won_points / $sum_of_lost_points;
    }
    
    $rsi = 100 - (100 / (1 + $rs));


Here's my version that I believe catches all the problems including the
missing edge case:

    if ($sum_of_lost_points != 0) {
       $rs = $sum_of_won_points / $sum_of_lost_points;
       $rsi = 100 - (100 / (1 + $rs));
    }
    elsif ($sum_of_won_points == 0) {
       $rs = 1;
       $rsi = 100 - (100 / (1 + $rs));
    }
    else {
       # $rs = infinite;
       $rsi = 100;
    }


The first case is the normal case with lost!=0, which handles any won value.

The second case is the lost==0 && won==0 case, which has to come out the
same as anytime lost==won if they're not zero.

The third case is the lost==0 && won!=0 case.

Note that in the third case, $rsi cannot be properly calculated from the
formula since $rs whould need to be infinite.

Patch is attached.

-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Gregory H. Margo
gmargo at yahoo/com, gmail/com, pacbell/net; greg at margofamily/org

[GT] Re: Release 0.00_50 uploaded

[Gregory M. <gm...@pa...>]

On Fri, Aug 07, 2009 at 07:26:11PM +0200, Erik Colson wrote:
> hmmm...
>
> I've been reading about tags with svn.
> Seems that creating a tag copies the whole repo to have a snapshot !?
> Damn that's silly. svn really is history compared to git. ( I had to say 
> this loudly ;) )
>
> It seems that svn is more a vcs in the sense of a "reporting tool" and  
> lacks the "working side" like git has it.
>
> Boy, this hurts badly
> --
> erik

Subversion makes "cheap copies" for copy/branch/tag operations.
Check out the "Cheap Copies" paragraph in the subversion book on this
page:

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.using.html

Quoting a bit:

    "When you copy a directory, you don't need to worry about the repository
    growing huge—Subversion doesn't actually duplicate any data. Instead, it
    creates a new directory entry that points to an existing tree. If you're
    an experienced Unix user, you'll recognize this as the same concept
    behind a hard link."


So tag early, tag often!

-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Gregory H. Margo
gmargo at yahoo/com, gmail/com, pacbell/net; greg at margofamily/org

[GT] Re: Re: Re: Re: Re: Re: Release 0.00_50 uploaded

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

Don't worry. Copying the directory is not an expensive operation. I just
want to make sure that we don't create meaningless tags, as they still
clutter up the repository. Th.

Erik Colson wrote:
> hmmm...
>
> I've been reading about tags with svn.
> Seems that creating a tag copies the whole repo to have a snapshot !?
> Damn that's silly. svn really is history compared to git. ( I had to
> say this loudly ;) )
>
> It seems that svn is more a vcs in the sense of a "reporting tool" and
> lacks the "working side" like git has it.
>
> Boy, this hurts badly
> -- 
> erik