Re: [GT] BuySellArrow misnomer

["Robert A. Schmied" <ras AT acm.org>]

Weigert, Thomas wrote:
> Please see below....
>
>
> > -----Original Message-----
> > From: Robert A. Schmied [mailto:ras
AT
acm.org]
> > Sent: Wednesday, June 11, 2008 1:43 AM
> > To: devel
AT
geniustrader.org
> > Subject: Re: [GT] BuySellArrow misnomer
> >
> >
> > maybe a corrective action is called for (one or more of)
>
>
> The most important thing is that users don't get confused between the
> "Buy/Sell" that, say, backtest.pl, would propose, vs. the "Buy/Sell" in
> graphics.pl. These arrows are still very useful.

ras assigned d) and e) to these th alternatives
d)  > Personally, what I would have done is give BuySellArrow two signals as
   > arguments, rather than a SY. That way, it is clear that it just pictures
   > the output of these signals. The SY just is a holder for these two
   > signals and serves not much further purpose.
i'm thinking a signal can be in a given state for long periods of time
whereas the SY buy-sell (technically long-short) signals are one time events
(yes they can fire every time period but they are one shot per time period events)

>
e)  > The other option would be to change terminology and not call the
   > SystemManager object a SY. 

well the change in e) is on the face is a rather large undertaking, akin
to the tail, in this case a script, wagging the dog, which of course is the
bulk of the gt system. doing that would probable require a major version
number bump.

d) may be the more correct solution, unless the implementor actually
intended to mark long and short system signals. it may pose the largest
amount of effort and some breakage risk.

c) also might be what the implementor had in mind, but was unaware that a
buy or sell in a system description is really a position opening either
long or short and to close a position requires a close strategy description.
probably large amount of effort and some breakage risk.

a) the least amount of work and least breakage risk.

b) lives with the basic flaw, that being passing a system description, would
require little effort and poses not much, but some breakage risk. should
probably be done along with a) just so everyone knows the limitations.

unless the implementor speaks up we may never know what the actual intent was.


ras

> > a) more clearly explain it in the graphic.pl pod
> > b) change directive to LongShortArrows (but still accept BuySellArrows
> >   but depreciate it by removing the pod references)
> >   naturally that implies a name change to
> > GT/Graphics/Object/BuySellArrows
> >   too.
> > c) correct BuySellArrows by requiring a system description that
> > includes a close strategy (will that work now if the argument is
>
> such?)
>
> I think this will involve much more evaluation, in a sense, one has to
> run the core of backtest.pl then.
>
>
> > d) other to be determined
> >
> > humm -- does VotingLine work similarly?
>
>
> Yes, same issue for voting line.
>
>
> > ras