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

[GT] Re: EMA incorrect when using --nb-item

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

Nick Fantes Huege wrote:
> Hello Ras,
> 
> Thank you for your answer! Allow me to respectfully disagree with you
> about the use of --nb-items. It seems that its purpose was to limit
> the number of results displayed, not computed.

historically option --nb-items has had a tortured history of purpose, use and
implementation. it is believed that the current implementation is consistent
and applied correctly across all apps that use it. but frankly i don't ever
recall the intent for it to throttle the amount of *output* being one of the
(mis)uses. 

and yet i have found that when used with graphic.pl --nb-item does give
the appearance that that is what it is doing; but looking deeper it is
really limiting the raw input data. the generated chart data just parrots
the input data range, and a plotted ema is wrong due to lack of sufficient input.

(see more about this towards end where you reference http://stockcharts.com)

the current gt truck for display_indicator.pl (perldoc -t display_indicator.pl)
or on-line pod via http://geniustrader.org/doc/Scripts/display_indicator.pl.html)
says this about the analysis range specifier options:

--full, --start=<date>, --end=<date>, --nb-item=<nr>

    Determines the time interval to consider for analysis. In detail:

    --start=2001-1-10, --end=2002-11-17

        The start and end dates considered for analysis. The date needs to be in the format configured in ~/.gt/options and must match the timeframe selected.
    --nb-items=100

        The number of periods to use in the analysis. Default is 200.
    --full

        Consider all available periods.

i submit this is actually how --nb-item is implemented, it is *not* a means
to limit the amount of data being output, but *is* a means to limit the
amount of data being analyzed.

> 
> In Scripts/display_indicator.pl we see the following code:
> 
> if ($last_record) {
>     $full    = 0;
>     $start   = '';
>     $end     = '';
>     $nb_item = 1;
> }
> 
> $last_record is set if we pass the option --last-record.
> 
> In other words, if we want to see only the last record (for example
> the EMA for today) we add --last-record, which sets $nb_item to 1.

well, i think you are reading this code 'out of context'. if this
is the primary basis for your assertion that --nb-items controls the
amount of displayed items then you need to more fully study how the
actual analysis range is determined.

i stand by my assertion that the pod is correct and --nb-items is
used to limit data quantity in the analysis range being considered.

> 
> The above code contradicts with the code in Tools::find_calculator
> where $nb_item clearly trumps $full, but yields to $start and $end,
> and so participates in the computing of the indicator. To my opinion
> this should be fixed, and I don't mind doing it if we agree to it.
> 
> If I'd like to see today's EMA(200) for YHOO, I could use this:
> ./display_indicator.pl --last-record I:EMA YHOO 200
> completely equal to:
> ./display_indicator.pl --nb-item=1 I:EMA YHOO 200
> 
> How is a 200 day moving average going to get computed if we only have
> one day available?

first off, the command

   ./display_indicator.pl --nb-item=1 I:EMA YHOO 200

is wrong, because the --nb-item=1 will eliminate most input data,
but the command

   ./display_indicator.pl --last-record I:EMA YHOO 200

is correct, because it correctly uses the default analysis range,
but only outputs the last record.

that answer should be identical to:

  ./display_indicator.pl I:EMA YHOO 200 | tail -1

and hopefully to:

  ./display_indicator.pl --full I:EMA YHOO 200 | tail -1

as well, but if not the variance should be very small.

> 
> You ask:
> 
>>i'm not sure why you would want to use --nb-item=10 and also use a 60
>>bar time period ema?
> 
> 
> The example was supposed to display the last 10 values of a 60 day

oh! i do now see a bad example in the display_indicator.pl pod too

  ./display_indicator.pl --nb 10 I:EMA IBM 120

if that is the primary cause for your confusion accept that it is
wrong and will be fixed in due course ... suggested examples and
associated explanatory text welcome

> EMA, the same way this chart does:
> http://stockcharts.com/h-sc/ui?s=YHOO&p=D&yr=0&mn=0&dy=10&id=p58199359097

well, a comparable gt command would be
   ./graphic.pl \
     --nb-items=10 \
     --type=candle --volume --title='%n (%c)' \
     --add='curve(I:EMA 60, darkblue)' \
     --add=Text'("EMA 60",2,95,left,center,small,darkblue,arial)' \
     YHOO > graphs/yahoo.nick_nb10.png

but as you correctly note, the plotted ema is invalid, because there's insufficient
data to plot it. in fact i don't think it's possible to plot a chart of this
sort with gt, but if you try:
   ./graphic.pl \
     --type=candle --volume --title='%n (%c)' \
     --add='curve(I:EMA 60, darkblue)' \
     --add=Text'("EMA 60",2,95,left,center,small,darkblue,arial)' \
     YHOO > graphs/yahoo.nick.png

or
   ./graphic.pl \
     --nb-item=120 \
     --type=candle --volume --title='%n (%c)' \
     --add='curve(I:EMA 60, darkblue)' \
     --add=Text'("EMA 60",2,95,left,center,small,darkblue,arial)' \
     YHOO > graphs/yahoo.nick.png

the ema is well formed and consistent with the stockcharts.com example
for the few bars being plotted ...

> 
> I still think that &calculate_interval in EMA.pm must be fixed to set
> --full=1 (or $first = 0) in order to present as accurate moving
> average value as possible. Otherwise any signals that use --nb-item
> are going to be misleading.

ah humm ''signals that use --nb-item''. i'm not sure i fully understanding
what you mean by this. the display_*.pl scripts aren't really there for
'trading or stock analysis purposes' but are tools for developing and trouble
shooting the various sys-sig-indic descriptions used in scan.pl, the backtests
and or graphic.pl. sys-sig-indic description are used by gt to 'program'
how trading system analyses process data objects (see below) to do their
thing.

i may be preaching to the choir here, but gt is heavily object-oriented;
as such, the methods in Indicators as well as those in Signals and Systems
presume a correct input data object to operate on. if the input data object
is wrong then corrections should be made to the method(s) that are creating
the data object not in the methods that are using it. so, in this instance,
if there is a problem with the data object that is being created by the
command

   ./display_indicator.pl --nb 10 I:EMA IBM 120 

then the fault is in Tools::find_calculator and or associated methods and
subroutines including possibly the application script or it's usage. in this
case i submit the command is in error because the purpose of --nb is misunderstood
by the user.

to limit the number of data lines use

  ./display_indicator.pl I:EMA IBM 120 | tail -10

aloha

ras

> 
> Regards,
> Nick
> 

[GT] Re: Re: Re: EMA incorrect when using --nb-item

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

No,

RAS is correct.

--nb_item is used to determine how many data items to consider.
--nb-item, --full, --start, and --end cooperate in determining what
precise period is being considered. This is clearly documented in the
pod of each of the scripts. Last record is special for
display_indicator, as sometimes one wants to retrieve the value of just
the last item.

Regarding your question of the 200 items, gt will load additional data
to satisfies dependencies, should such be available.

Please note that there is a difference between loading data and
considering data during the computation. For example, when using text as
your data source, the full series is always loaded. You can only limit
the data being loaded when you use a data base. There is a different
flag for that; this is not controlled by above.

th.



On 07/21/2010 10:29 PM, Nick Fantes Huege wrote:
> Hello Ras,
>
> Thank you for your answer! Allow me to respectfully disagree with you
> about the use of --nb-items. It seems that its purpose was to limit
> the number of results displayed, not computed.
>
> In Scripts/display_indicator.pl we see the following code:
>
> if ($last_record) {
>     $full    = 0;
>     $start   = '';
>     $end     = '';
>     $nb_item = 1;
> }
>
> $last_record is set if we pass the option --last-record.
>
> In other words, if we want to see only the last record (for example
> the EMA for today) we add --last-record, which sets $nb_item to 1.
>
> The above code contradicts with the code in Tools::find_calculator
> where $nb_item clearly trumps $full, but yields to $start and $end,
> and so participates in the computing of the indicator. To my opinion
> this should be fixed, and I don't mind doing it if we agree to it.
>
> If I'd like to see today's EMA(200) for YHOO, I could use this:
> ./display_indicator.pl --last-record I:EMA YHOO 200
> completely equal to:
> ./display_indicator.pl --nb-item=1 I:EMA YHOO 200
>
> How is a 200 day moving average going to get computed if we only have
> one day available?
>
> You ask:
>   
>> i'm not sure why you would want to use --nb-item=10 and also use a 60
>> bar time period ema?
>>     
> The example was supposed to display the last 10 values of a 60 day
> EMA, the same way this chart does:
> http://stockcharts.com/h-sc/ui?s=YHOO&p=D&yr=0&mn=0&dy=10&id=p58199359097
>
> I still think that &calculate_interval in EMA.pm must be fixed to set
> --full=1 (or $first = 0) in order to present as accurate moving
> average value as possible. Otherwise any signals that use --nb-item
> are going to be misleading.
>
> Regards,
> Nick
>
>   

[GT] Re: Re: EMA incorrect when using --nb-item

[Nick F. H. <nf...@gm...>]

Hello Ras,

Thank you for your answer! Allow me to respectfully disagree with you
about the use of --nb-items. It seems that its purpose was to limit
the number of results displayed, not computed.

In Scripts/display_indicator.pl we see the following code:

if ($last_record) {
    $full    = 0;
    $start   = '';
    $end     = '';
    $nb_item = 1;
}

$last_record is set if we pass the option --last-record.

In other words, if we want to see only the last record (for example
the EMA for today) we add --last-record, which sets $nb_item to 1.

The above code contradicts with the code in Tools::find_calculator
where $nb_item clearly trumps $full, but yields to $start and $end,
and so participates in the computing of the indicator. To my opinion
this should be fixed, and I don't mind doing it if we agree to it.

If I'd like to see today's EMA(200) for YHOO, I could use this:
./display_indicator.pl --last-record I:EMA YHOO 200
completely equal to:
./display_indicator.pl --nb-item=1 I:EMA YHOO 200

How is a 200 day moving average going to get computed if we only have
one day available?

You ask:
> i'm not sure why you would want to use --nb-item=10 and also use a 60
> bar time period ema?

The example was supposed to display the last 10 values of a 60 day
EMA, the same way this chart does:
http://stockcharts.com/h-sc/ui?s=YHOO&p=D&yr=0&mn=0&dy=10&id=p58199359097

I still think that &calculate_interval in EMA.pm must be fixed to set
--full=1 (or $first = 0) in order to present as accurate moving
average value as possible. Otherwise any signals that use --nb-item
are going to be misleading.

Regards,
Nick

[GT] Re: EMA incorrect when using --nb-item

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

Nick Fantes Huege wrote:
> Hello All,
> 
> I don't know if this is intentional, but when calculating EMA (and my
> guess is that the same is true for all other indicators that give more
> wight to the more recent dates) the values produced are incorrect if
> --nb-item is used, or if --start and --end are used.
> 
> Example:
> ./display_indicator.pl --full --nb-item=10 I:EMA YHOO 60
> ...
> ...
> EMA[60, {I:Prices CLOSE}][2010/07/19] = 15.7129
> 15.712 is wrong value for YHOO's EMA for that day.
> 
> After analyzing EMA.pm, it seems the problem is that it does its
> calculations based on the last 10 (or --nb-item) prices.
> A simple fix would be to add $first = 1 inside the
> calculate_interval() subroutine, thus giving it the full range of
> prices to work on.
> 
> Nick
> 

aloha nick

the options -full and -nb-items are thought to be mutually exclusive
(but are not processed that way by the code unfortunately).

generally speaking --full, --start=<date>, --end=<date>, --nb-item=<nr>
are used to set the time period to run the analysis on. by default
(without any of these options) only the most recent 200 bars are used,
which implicitly sets --end.

the analysis range can be controlled by --full (run analysis on every bar
in database), or by using one or two of --start, --end or --nb-item.
in this situation, the total number of bars used would be computed from
the fixed reference, either the explicitly set --start or --end
(either the implicit value or the explicitly set one).

i'm not sure why you would want to use --nb-item=10 and also use a 60
bar time period ema?

as far as your analysis of the GT::Indicators::EMA::calculate_interval
method; it is believed that when passed a valid interval range the computed
ema values are correct. this is implicitly suggesting when used as you
describe, display_indicator.pl is not passing a valid interval range.

ras

[GT] EMA incorrect when using --nb-item

[Nick F. H. <nf...@gm...>]

Hello All,

I don't know if this is intentional, but when calculating EMA (and my
guess is that the same is true for all other indicators that give more
wight to the more recent dates) the values produced are incorrect if
--nb-item is used, or if --start and --end are used.

Example:
./display_indicator.pl --full --nb-item=10 I:EMA YHOO 60
...
...
EMA[60, {I:Prices CLOSE}][2010/07/19] = 15.7129
15.712 is wrong value for YHOO's EMA for that day.

After analyzing EMA.pm, it seems the problem is that it does its
calculations based on the last 10 (or --nb-item) prices.
A simple fix would be to add $first = 1 inside the
calculate_interval() subroutine, thus giving it the full range of
prices to work on.

Nick

[GT] Re: Intraday Signals

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

Yes, most of the GT cli supports --timeframe option. Just need to configure your db to allow multiple timeframes data stored


wi...@op... 說：

>I’m just exploring the possibility if trying out GT.	Before I do a deep-dive
>into the platform, I was wondering if it’s possible to generate signals on
>intraday price movement.  I pretty well versed with linux administration, perl
>and sql.
>
>Regards,
>Bil King

--
Sent from my Android phone with K-9. Please excuse my brevity.

[GT] Re: Archive

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

wi...@op... wrote:
> I'm unable to view the Archive.  It's grayed on my interface.
> 
?

try the home page -- there's a url there at the bottom of the section Mailing lists


http://geniustrader.org/lists/devel/index.html

[GT] Archive

[<wi...@op...>]

I'm unable to view the Archive.  It's grayed on my interface.

[GT] Re: Data Sources

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

wi...@op... wrote:
> Hi All,
> What are some of the more widely implemented data sources?  I currently use a
> charting package from Worden Brothers call TeleChart2007.   I was wondering if
> anyone has it's database for market data feed into GT?
> 
> Regards,
> Bill
> 

[GT] Data Sources

[<wi...@op...>]

Hi All,
What are some of the more widely implemented data sources?  I currently use a
charting package from Worden Brothers call TeleChart2007.   I was wondering if
anyone has it's database for market data feed into GT?

Regards,
Bill

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

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

Hello Thomas,

I havent tested this yet fully.
Will send an email regarding this soon.

Regards,
Sumit.

On Sat, Jan 9, 2010 at 11:00 PM, Thomas Weigert <we...@ms...> wrote:

> Great this worked for you.
>
> If you did something interesting and non-standard, it would be nice if
> you summarized your problems, the changes to the system required to meet
> your need, and some sample results. That would help others and would
> avoid having to go through this email trail again when the next person
> has a similar need. Thanks in advance.
>
> Cheers, Th.
>
> Sumit Sanghai wrote:
> > Thanks everyone for all the help. I've been able to load the data, run
> > indicators, and display them as well.
> >
> >
>

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

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

Great this worked for you.

If you did something interesting and non-standard, it would be nice if
you summarized your problems, the changes to the system required to meet
your need, and some sample results. That would help others and would
avoid having to go through this email trail again when the next person
has a similar need. Thanks in advance.

Cheers, Th.

Sumit Sanghai wrote:
> Thanks everyone for all the help. I've been able to load the data, run
> indicators, and display them as well.
>
>

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

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

>From the manual page for scan.pl

scan.pl will scan all stocks listed in <market file> looking
for the signals indicated in each <system file> performing the analysis
on the specified <date>. A system file must contain one or more description
of GT::Signals or description of GT::Systems. You may list multiple system
files on the command line. In the absence of a file standard input will
be read instead.

This, I believe, will do what you want for identifying the trades.

I am not sure what you mean by "the standard money management stuff". As
I understand your request, you want to go through the markets in your
system and evaluate your system and create a signal for those that meat
your cut off. There would be no money management involved.

Money management comes in when you want to look at a trade over time,
either by backtesting or by executing a system. If you get more
explicit, I can say more....

Th.

Sumit Sanghai wrote:
> Thanks everyone for all the help. I've been able to load the data, run
> indicators, and display them as well.
>
> Had another question. I want to write a "meta portfolio manager" which
> would go through the trades generated by my system on
> all the stocks (instead of just one), and filter trades that are not
> as strong as the others based on certain signals (and also do the
> standard money management stuff on the combined set of trades).
> Is that possible with the current packages?
>
> Regards,
> Sumit.
>
>

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

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

Thanks everyone for all the help. I've been able to load the data, run
indicators, and display them as well.

Had another question. I want to write a "meta portfolio manager" which would
go through the trades generated by my system on
all the stocks (instead of just one), and filter trades that are not as
strong as the others based on certain signals (and also do the standard
money management stuff on the combined set of trades).
Is that possible with the current packages?

Regards,
Sumit.

On Fri, Jan 8, 2010 at 8:52 PM, Thomas Weigert <we...@ms...> wrote:

>  For the gotchas look for calls to GT::Prices::add_prices
>
> Th.
>
>
> Thomas Weigert wrote:
>
> After all this discussion, from the little I can glean about your goals,
> the following is what I would do:
>
> (i) Generalize GT/Prices.pm so that it loads not just the standard
> items, but your additional data also. I would create an option value
> indicating the name and order of the fields (this exists already for the
> standard data) and then load all the items. These would then be in the
> prices array as additional series. You need to double check the
> timeframe conversion of a price series to see whether you need to extend
> them for copying your additional data and be at the lookout for other
> such gotchas.
>
> (ii) Generalize GT/Indicators/Prices.pm so that it allows to access all
> the additional data and load it into the returned series of the
> indicator. This again should take the option and work of that, similar
> to the standard values.
>
> Both of these are straightforward extensions of the existing work (other
> than the looking for the gotchas).
>
> Th.
>
> Sumit Sanghai wrote:
>
>
>  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] Re: Intraday Signals

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

Yes, if you have the data source. You can work in timeframes down to the
minute, albeit you need to be careful with loading that much data.... Th.

wi...@op... wrote:
> I’m just exploring the possibility if trying out GT.	Before I do a deep-dive
> into the platform, I was wondering if it’s possible to generate signals on
> intraday price movement.  I pretty well versed with linux administration, perl
> and sql.
>
> Regards,
> Bil King
>   

[GT] Re: Intraday Signals

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

wi...@op... wrote:
> I’m just exploring the possibility if trying out GT.	Before I do a deep-dive
> into the platform, I was wondering if it’s possible to generate signals on
> intraday price movement.  I pretty well versed with linux administration, perl
> and sql.
> 
> Regards,
> Bil King

aloha bil "willyjk" king

provided you have a source of intraday data you sure can.


ras

[GT] Intraday Signals

[<wi...@op...>]

I’m just exploring the possibility if trying out GT.	Before I do a deep-dive
into the platform, I was wondering if it’s possible to generate signals on
intraday price movement.  I pretty well versed with linux administration, perl
and sql.

Regards,
Bil King

[GT] Re: Re: Couple of questions

[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">
For the gotchas look for calls to GT::Prices::add_prices<br>
<br>
Th.<br>
<br>
Thomas Weigert wrote:
<blockquote cite="mid:4B4...@ms..." type="cite">
  <pre wrap="">After all this discussion, from the little I can glean about your goals,
the following is what I would do:

(i) Generalize GT/Prices.pm so that it loads not just the standard
items, but your additional data also. I would create an option value
indicating the name and order of the fields (this exists already for the
standard data) and then load all the items. These would then be in the
prices array as additional series. You need to double check the
timeframe conversion of a price series to see whether you need to extend
them for copying your additional data and be at the lookout for other
such gotchas.

(ii) Generalize GT/Indicators/Prices.pm so that it allows to access all
the additional data and load it into the returned series of the
indicator. This again should take the option and work of that, similar
to the standard values.

Both of these are straightforward extensions of the existing work (other
than the looking for the gotchas).

Th.

Sumit Sanghai wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
</body>
</html>

[GT] Re: Couple of questions

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

After all this discussion, from the little I can glean about your goals,
the following is what I would do:

(i) Generalize GT/Prices.pm so that it loads not just the standard
items, but your additional data also. I would create an option value
indicating the name and order of the fields (this exists already for the
standard data) and then load all the items. These would then be in the
prices array as additional series. You need to double check the
timeframe conversion of a price series to see whether you need to extend
them for copying your additional data and be at the lookout for other
such gotchas.

(ii) Generalize GT/Indicators/Prices.pm so that it allows to access all
the additional data and load it into the returned series of the
indicator. This again should take the option and work of that, similar
to the standard values.

Both of these are straightforward extensions of the existing work (other
than the looking for the gotchas).

Th.

Sumit Sanghai wrote:
>
> 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] Re: Re: Re: Re: Re: Re: Re: Re: Re: Couple of questions

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

Btw thanks for your prompt replies :)

On Fri, Jan 8, 2010 at 11:46 AM, Sumit Sanghai <sum...@gm...>wrote:

> Got it. Will try this out, and if there's any issue will post again :)
>
> On Fri, Jan 8, 2010 at 11:18 AM, Thomas Weigert <we...@ms...> wrote:
>
>>  At this point it is still not clear to me whether you need to change
>> anything.
>>
>> But without you clearer describing what you are trying to do I cannot
>> comment in more detail. Give an example of how your data set looks like, and
>> what you want to graph. Then it is easier to comment.
>>
>> Let me give you an example. Say you would like to have an additional field
>> in your market called "percentage of shares owned by institutional
>> investors", let's call it INST for short, and you modified your loadtxt
>> function in GT::Prices.pm so that it puts that into another field of the
>> prices array, and you defined a constant $INST to get at that field.
>>
>> If you wanted to work with this additional data item, you just would write
>> an indicator like I:Prices (or edit I:Prices) to keep on additional series,
>> the $INST field. Then you would get at that via {I:Prices INST}. You could
>> just graph that by graphing that indicator, in an additional zone.
>>
>> But that may not be at all what you have in mind. But without knowing more
>> about your application one cannot comment further....
>>
>> Cheers, Th.
>>
>>
>>
>> Say you have
>>
>> Sumit Sanghai wrote:
>>
>> As I had written earlier along with OHLC & volume we have this data about
>> FIIs. (Foreign Institutional Investors).
>> Now, I went through Text.pm and Prices.pm, and I realized that the best
>> thing to
>> (i) read and use this data is to have a Text file where the FII data is
>> the last field (otherwise I will have to change the value of the constants
>> OPEN CLOSE etc).
>>
>>  (ii) But, going through the graphics objects, I realized that they also
>> only display OHLC and volume, so I will have to make changes to them also.
>> And that's what I wanted to know which all objects would I need to change.
>> Just doing a egrep -r "(\$close|CLOSE|OPEN\$open)" GT resulted in too many
>> files.
>>
>>  Regards,
>> Sumit.
>>
>> On Fri, Jan 8, 2010 at 7:41 AM, Thomas Weigert <we...@ms...> wrote:
>>
>>> Sumit,
>>>
>>> first, what do you mean that DB/text contains not only ohlc+volume, but
>>> also some other data? As far as I know, you can only read markets that
>>> have ohlc+volume+date. (Well, you can read anything you want, but the
>>> Prices data structures are set up to hold those things. It is just an
>>> array, so you can actually store whatever you want, but you better know
>>> what you are doing. I have done analysis with reinterpreting the data
>>> and also extended these structures into tables, but I would not
>>> recommend that without you having a very good understanding of GT
>>> inside.)
>>>
>>> So I assume that your "other market" is like the primary market in
>>> having ohlc+volume.
>>>
>>> The GT::Indicators::Prices file I sent out in this thread reads that
>>> other market and converts it to the same time frame as the primary
>>> market. For example, if your primary market is XYZ and your other market
>>> is ABC You can then say
>>> display_indicator.pl I:Prices XYZ CLOSE ABC
>>> and it will actually display the ABC prices, not the XYZ prices as it
>>> would otherwise. Or you can use
>>> {I:Prices CLOSE ABC}
>>> anywhere where you will use prices, and you can use any of the other
>>> LOW, HIGH, VOLUME, etc. also.
>>>
>>> There are no other changes required.
>>>
>>> But maybe you want to do more than just that, in that case, please
>>> explain some more of your application.
>>>
>>> Cheers, Th.
>>>
>>> Sumit Sanghai wrote:
>>> > Hello Thomas,
>>> >
>>> > So does your change work for my use-case (as in the DB/text contains
>>> > not only ohlc, volume but also some other data)?
>>> >
>>> > From what I understand till now, I will have to make changes to
>>> > Prices.pm, Indicator/Prices.pm and Text.pm (because the data is in
>>> text).
>>> > I am unsure as to where all the changes would be required in Graphic
>>> > objects.
>>> >
>>> >
>>>
>>
>>
>

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

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

Got it. Will try this out, and if there's any issue will post again :)

On Fri, Jan 8, 2010 at 11:18 AM, Thomas Weigert <we...@ms...> wrote:

>  At this point it is still not clear to me whether you need to change
> anything.
>
> But without you clearer describing what you are trying to do I cannot
> comment in more detail. Give an example of how your data set looks like, and
> what you want to graph. Then it is easier to comment.
>
> Let me give you an example. Say you would like to have an additional field
> in your market called "percentage of shares owned by institutional
> investors", let's call it INST for short, and you modified your loadtxt
> function in GT::Prices.pm so that it puts that into another field of the
> prices array, and you defined a constant $INST to get at that field.
>
> If you wanted to work with this additional data item, you just would write
> an indicator like I:Prices (or edit I:Prices) to keep on additional series,
> the $INST field. Then you would get at that via {I:Prices INST}. You could
> just graph that by graphing that indicator, in an additional zone.
>
> But that may not be at all what you have in mind. But without knowing more
> about your application one cannot comment further....
>
> Cheers, Th.
>
>
>
> Say you have
>
> Sumit Sanghai wrote:
>
> As I had written earlier along with OHLC & volume we have this data about
> FIIs. (Foreign Institutional Investors).
> Now, I went through Text.pm and Prices.pm, and I realized that the best
> thing to
> (i) read and use this data is to have a Text file where the FII data is the
> last field (otherwise I will have to change the value of the constants OPEN
> CLOSE etc).
>
>  (ii) But, going through the graphics objects, I realized that they also
> only display OHLC and volume, so I will have to make changes to them also.
> And that's what I wanted to know which all objects would I need to change.
> Just doing a egrep -r "(\$close|CLOSE|OPEN\$open)" GT resulted in too many
> files.
>
>  Regards,
> Sumit.
>
> On Fri, Jan 8, 2010 at 7:41 AM, Thomas Weigert <we...@ms...> wrote:
>
>> Sumit,
>>
>> first, what do you mean that DB/text contains not only ohlc+volume, but
>> also some other data? As far as I know, you can only read markets that
>> have ohlc+volume+date. (Well, you can read anything you want, but the
>> Prices data structures are set up to hold those things. It is just an
>> array, so you can actually store whatever you want, but you better know
>> what you are doing. I have done analysis with reinterpreting the data
>> and also extended these structures into tables, but I would not
>> recommend that without you having a very good understanding of GT inside.)
>>
>> So I assume that your "other market" is like the primary market in
>> having ohlc+volume.
>>
>> The GT::Indicators::Prices file I sent out in this thread reads that
>> other market and converts it to the same time frame as the primary
>> market. For example, if your primary market is XYZ and your other market
>> is ABC You can then say
>> display_indicator.pl I:Prices XYZ CLOSE ABC
>> and it will actually display the ABC prices, not the XYZ prices as it
>> would otherwise. Or you can use
>> {I:Prices CLOSE ABC}
>> anywhere where you will use prices, and you can use any of the other
>> LOW, HIGH, VOLUME, etc. also.
>>
>> There are no other changes required.
>>
>> But maybe you want to do more than just that, in that case, please
>> explain some more of your application.
>>
>> Cheers, Th.
>>
>> Sumit Sanghai wrote:
>> > Hello Thomas,
>> >
>> > So does your change work for my use-case (as in the DB/text contains
>> > not only ohlc, volume but also some other data)?
>> >
>> > From what I understand till now, I will have to make changes to
>> > Prices.pm, Indicator/Prices.pm and Text.pm (because the data is in
>> text).
>> > I am unsure as to where all the changes would be required in Graphic
>> > objects.
>> >
>> >
>>
>
>

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

[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">
At this point it is still not clear to me whether you need to change
anything.<br>
<br>
But without you clearer describing what you are trying to do I cannot
comment in more detail. Give an example of how your data set looks
like, and what you want to graph. Then it is easier to comment.<br>
<br>
Let me give you an example. Say you would like to have an additional
field in your market called "percentage of shares owned by
institutional investors", let's call it INST for short, and you
modified your loadtxt function in GT::Prices.pm so that it puts that
into another field of the prices array, and you defined a constant
$INST to get at that field.<br>
<br>
If you wanted to work with this additional data item, you just would
write an indicator like I:Prices (or edit I:Prices) to keep on
additional series, the $INST field. Then you would get at that via
{I:Prices INST}. You could just graph that by graphing that indicator,
in an additional zone.<br>
<br>
But that may not be at all what you have in mind. But without knowing
more about your application one cannot comment further....<br>
<br>
Cheers, Th.<br>
<br>
<br>
<br>
Say you have <br>
<br>
Sumit Sanghai wrote:
<blockquote
 cite="mid:7cf...@ma..."
 type="cite">As I had written earlier along with OHLC &amp; volume we
have this data about FIIs. (Foreign Institutional Investors).
  <div>Now, I went through Text.pm and Prices.pm, and I realized that
the best thing to&nbsp;</div>
  <div>(i) read and use this data is to have a Text file where the FII
data is the last field (otherwise I will have to change the value of
the constants OPEN CLOSE etc).</div>
  <div><br>
  </div>
  <div>(ii) But, going through the graphics objects, I realized that
they also only display OHLC and volume, so I will have to make changes
to them also.</div>
  <div>And that's what I wanted to know which all objects would I need
to change. Just doing a egrep -r "(\$close|CLOSE|OPEN\$open)" GT
resulted in too many files.</div>
  <div><br>
  </div>
  <div>
  <div>Regards,<br>
Sumit.</div>
  <div><br>
  <div class="gmail_quote">On Fri, Jan 8, 2010 at 7:41 AM, Thomas
Weigert <span dir="ltr">&lt;<a moz-do-not-send="true"
 href="mailto:we...@ms...">we...@ms...</a>&gt;</span> wrote:<br>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Sumit,<br>
    <br>
first, what do you mean that DB/text contains not only ohlc+volume, but<br>
also some other data? As far as I know, you can only read markets that<br>
have ohlc+volume+date. (Well, you can read anything you want, but the<br>
Prices data structures are set up to hold those things. It is just an<br>
array, so you can actually store whatever you want, but you better know<br>
what you are doing. I have done analysis with reinterpreting the data<br>
and also extended these structures into tables, but I would not<br>
recommend that without you having a very good understanding of GT
inside.)<br>
    <br>
So I assume that your "other market" is like the primary market in<br>
having ohlc+volume.<br>
    <br>
The GT::Indicators::Prices file I sent out in this thread reads that<br>
other market and converts it to the same time frame as the primary<br>
market. For example, if your primary market is XYZ and your other market<br>
is ABC You can then say<br>
    <a moz-do-not-send="true" href="http://display_indicator.pl"
 target="_blank">display_indicator.pl</a> I:Prices XYZ CLOSE ABC<br>
and it will actually display the ABC prices, not the XYZ prices as it<br>
would otherwise. Or you can use<br>
{I:Prices CLOSE ABC}<br>
anywhere where you will use prices, and you can use any of the other<br>
LOW, HIGH, VOLUME, etc. also.<br>
    <br>
There are no other changes required.<br>
    <br>
But maybe you want to do more than just that, in that case, please<br>
explain some more of your application.<br>
    <br>
Cheers, Th.<br>
    <div>
    <div class="h5"><br>
Sumit Sanghai wrote:<br>
&gt; Hello Thomas,<br>
&gt;<br>
&gt; So does your change work for my use-case (as in the DB/text
contains<br>
&gt; not only ohlc, volume but also some other data)?<br>
&gt;<br>
&gt; From what I understand till now, I will have to make changes to<br>
&gt; Prices.pm, Indicator/Prices.pm and Text.pm (because the data is in
text).<br>
&gt; I am unsure as to where all the changes would be required in
Graphic<br>
&gt; objects.<br>
&gt;<br>
&gt;<br>
    </div>
    </div>
  </blockquote>
  </div>
  <br>
  </div>
  </div>
</blockquote>
</body>
</html>

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

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

As I had written earlier along with OHLC & volume we have this data about
FIIs. (Foreign Institutional Investors).
Now, I went through Text.pm and Prices.pm, and I realized that the best
thing to
(i) read and use this data is to have a Text file where the FII data is the
last field (otherwise I will have to change the value of the constants OPEN
CLOSE etc).

(ii) But, going through the graphics objects, I realized that they also only
display OHLC and volume, so I will have to make changes to them also.
And that's what I wanted to know which all objects would I need to change.
Just doing a egrep -r "(\$close|CLOSE|OPEN\$open)" GT resulted in too many
files.

Regards,
Sumit.

On Fri, Jan 8, 2010 at 7:41 AM, Thomas Weigert <we...@ms...> wrote:

> Sumit,
>
> first, what do you mean that DB/text contains not only ohlc+volume, but
> also some other data? As far as I know, you can only read markets that
> have ohlc+volume+date. (Well, you can read anything you want, but the
> Prices data structures are set up to hold those things. It is just an
> array, so you can actually store whatever you want, but you better know
> what you are doing. I have done analysis with reinterpreting the data
> and also extended these structures into tables, but I would not
> recommend that without you having a very good understanding of GT inside.)
>
> So I assume that your "other market" is like the primary market in
> having ohlc+volume.
>
> The GT::Indicators::Prices file I sent out in this thread reads that
> other market and converts it to the same time frame as the primary
> market. For example, if your primary market is XYZ and your other market
> is ABC You can then say
> display_indicator.pl I:Prices XYZ CLOSE ABC
> and it will actually display the ABC prices, not the XYZ prices as it
> would otherwise. Or you can use
> {I:Prices CLOSE ABC}
> anywhere where you will use prices, and you can use any of the other
> LOW, HIGH, VOLUME, etc. also.
>
> There are no other changes required.
>
> But maybe you want to do more than just that, in that case, please
> explain some more of your application.
>
> Cheers, Th.
>
> Sumit Sanghai wrote:
> > Hello Thomas,
> >
> > So does your change work for my use-case (as in the DB/text contains
> > not only ohlc, volume but also some other data)?
> >
> > From what I understand till now, I will have to make changes to
> > Prices.pm, Indicator/Prices.pm and Text.pm (because the data is in text).
> > I am unsure as to where all the changes would be required in Graphic
> > objects.
> >
> >
>

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

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

Sumit,

first, what do you mean that DB/text contains not only ohlc+volume, but
also some other data? As far as I know, you can only read markets that
have ohlc+volume+date. (Well, you can read anything you want, but the
Prices data structures are set up to hold those things. It is just an
array, so you can actually store whatever you want, but you better know
what you are doing. I have done analysis with reinterpreting the data
and also extended these structures into tables, but I would not
recommend that without you having a very good understanding of GT inside.)

So I assume that your "other market" is like the primary market in
having ohlc+volume.

The GT::Indicators::Prices file I sent out in this thread reads that
other market and converts it to the same time frame as the primary
market. For example, if your primary market is XYZ and your other market
is ABC You can then say
display_indicator.pl I:Prices XYZ CLOSE ABC
and it will actually display the ABC prices, not the XYZ prices as it
would otherwise. Or you can use
{I:Prices CLOSE ABC}
anywhere where you will use prices, and you can use any of the other
LOW, HIGH, VOLUME, etc. also.

There are no other changes required.

But maybe you want to do more than just that, in that case, please
explain some more of your application.

Cheers, Th.

Sumit Sanghai wrote:
> Hello Thomas,
>
> So does your change work for my use-case (as in the DB/text contains
> not only ohlc, volume but also some other data)?
>
> From what I understand till now, I will have to make changes to
> Prices.pm, Indicator/Prices.pm and Text.pm (because the data is in text).
> I am unsure as to where all the changes would be required in Graphic
> objects.
>
>

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

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

Hello Thomas,

So does your change work for my use-case (as in the DB/text contains not
only ohlc, volume but also some other data)?

>From what I understand till now, I will have to make changes to Prices.pm,
Indicator/Prices.pm and Text.pm (because the data is in text).
I am unsure as to where all the changes would be required in Graphic
objects.

Regards,
Sumit.

On Thu, Jan 7, 2010 at 9:10 AM, Thomas Weigert <we...@ms...> wrote:

> 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 ?
> >
> >
>
> package GT::Indicators::Prices;
>
> # Copyright 2000-2003 Raphaël Hertzog
> # This file is distributed under the terms of the General Public License
> # version 2 or (at your option) any later version.
>
> # Standards-Version: 1.0
>
> use strict;
> use vars qw(@ISA @NAMES);
>
> use GT::Indicators;
> use GT::Prices;
> use GT::Eval;
>
> @ISA = qw(GT::Indicators);
> @NAMES = ("Prices[#*]");
>
> =head1 NAME
>
> GT::Indicators::Prices - Return the prices/volume/date of any share
>
> =head1 DESCRIPTION
>
> As you often need the prices while using Generic indicators, this
> modules makes it easy for you to include prices through an indicator:
> {I:Prices OPEN} or {I:Prices LOW 13330}
>
> =head1 PARAMETERS
>
> =over
>
> =item Data
>
> You have to tell in which data you're interested. You have to choose
> between
> OPEN, HIGH, LOW, CLOSE, VOLUME, DATE.
>
> =item Share
>
> If you don't specify a second argument, you will use the data of the share
> that you're working on. But sometimes you may want to use the prices of a
> second share (for comparison, etc). In that case you can specify its code.
>
> =back
>
> =cut
> sub initialize {
>    my $self = shift;
>    my $data = $CLOSE;
>
>    # First parameter: which data
>    if ($self->{'args'}->get_nb_args() > 0) {
>        my $arg = $self->{'args'}->get_arg_constant(1);
>        if ($arg =~ /OPEN|FIRST/i) { $data = $OPEN }
>        elsif ($arg =~ /HIGH/i) { $data = $HIGH }
>        elsif ($arg =~ /LOW/i) { $data = $LOW }
>        elsif ($arg =~ /CLOSE|LAST/i) { $data = $CLOSE }
>        elsif ($arg =~ /VOLUME/i) { $data = $VOLUME }
>        elsif ($arg =~ /DATE/i) { $data = $DATE }
>    }
>
>    # Second parameter: code of the share
>    if ($self->{'args'}->get_nb_args() > 1) {
>        $self->{'use_std_prices'} = 0;
>        my $db = create_db_object();
>        my $q = $db->get_prices($self->{'args'}->get_arg_constant(2));
>        $self->{'special_prices'} = $q;
>    } else {
>        $self->{'use_std_prices'} = 1;
>    }
>
>    # Misc init
>    $self->{'data_ind'} = $data;
> }
>
> sub calculate {
>    my ($self, $calc, $i) = @_;
>
>    return if ($calc->indicators->is_available($self->get_name, $i));
>
>    my $indic = $calc->indicators;
>    my $DATA = $self->{'data_ind'};
>
>    if ($self->{'use_std_prices'}) {
>        $indic->set($self->get_name, $i, $calc->prices->at($i)->[$DATA]);
>    } else {
>        my $prices = $self->{'special_prices'};
>        my $date = $calc->prices->at($i)->[$DATE];
>        # make sure that the timeframe is the same as $calc
>        # Warning: If this object is used for different $calc, we
>        # should keep track of the series in multiple timeframes?
>        if ($prices->{timeframe} != $calc->prices->{timeframe}) {
>            $prices =
> $prices->convert_to_timeframe($calc->prices->{timeframe});
>            $self->{'special_prices'} = $prices;
>        }
>        if ($prices->has_date($date)) {
>            $indic->set($self->get_name, $i,
> $prices->at_date($date)->[$DATA]);
>        }
>    }
> }
>
> 1;
>
>