[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GT] Re: Re: Couple of questions



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.
>
>
>>
>
>