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

Re: calculation of price/frequency distributions


  • To: Carroll Slemaker <omega-list@xxxxxxxxxx
  • Subject: Re: calculation of price/frequency distributions
  • From: Howard Jackson <hrjf4@xxxxxxxxx>
  • Date: Tue, 27 Jul 1999 12:53:29 -0700

PureBytes Links

Trading Reference Links

So if we were speaking about applying an study in a
daily bar (it really applies to all bars) you want
variables to keep the values they have on every tick?
What would happen if I wrote
   value1[1]
Would this be one tick or one bar? would we keep
results of all functions for every tick as well? how
are you going to calculate a 10 day average using the
function 
   average(value1, 10)
If the value1[1] is one tick an not one day?

As far as I understand, things make sense as they are.
Its just we are missing multidata charts that include
tick charts so we can refer to one tick and one day
ago in one study. 

H

--- Carroll Slemaker <cslemaker1@xxxxxxxx> wrote:
> Thanks for the reply.  I must respectfully disagree,
> however, with your
> statement that this kluge is the only thing that can
> allow real-time results
> to match historical results.  First of all, this
> kluge does  NOT  cause ALL
> real-time results to match historical results as
> many on this list have
> often complained.  The only way to guarantee such
> consistency would be for
> the historical run ALSO to use the tick data.  And
> if the tick data have not
> been saved, then one must face the consequence that
> it is logically
> impossible to duplicate real-time results, in all
> cases, using abbreviated
> data.
> 
> Actually, the best solution would be to provide the
> user with two types of
> variables and let the user decide which behavior he
> desires.  But,
> especially in the absence of documentation of this
> "feature", a programmer
> has the right to expect that a variable will retain
> its value until he, the
> programmer, decides to change it.
> 
> Regards,
> Carroll Slemaker
> 
> 
> ----- Original Message -----
> From: Howard Jackson <hrjf4@xxxxxxxxx>
> To: Carroll Slemaker <cslemaker1@xxxxxxxx>; Tim
> McCaughey <TimM@xxxxxxxxxx>;
> <omega-list@xxxxxxxxxx>
> Sent: Tuesday, July 27, 1999 11:22 AM
> Subject: Re: calculation of price/frequency
> distributions
> 
> <snip>
> >
> > and Carrol, that 'kludge' is the only thing that
> can
> > allow indicators that are updating real time to
> match
> > historical results. As far as i am concerned it
> works
> > fine and it is very consistent with the rest of
> the
> > program's behaviour... what it seems like you want
> is
> > the never-implemented mutliple data charts with
> tick
> > bars... something that should have been out a long
> > time ago.
> >
> > H
> >
> > --- Carroll Slemaker <cslemaker1@xxxxxxxx> wrote:
> > > Unless they have fixed this since I last tested
> it
> > > long ago (not likely,
> > > since Omega considered it a "feature"), you will
> not
> > > be able to do this.
> > > From your description of the problem it seems
> that
> > > you want to collect data
> > > on a tick-by-tick basis (increase a tick counter
> for
> > > each possible price
> > > when a tick occurs at that price).  I assume
> that it
> > > is still not possible
> > > to attach an indicator or system to a tick
> chart, or
> > > to produce a
> > > multi-symbol tick chart.  If this assumption is
> now
> > > wrong, please disregard
> > > the following.
> > >
> > > Unfortunately, EL "variables" behave like no
> > > variables in any programming
> > > language you have ever seen.  In a reasonable
> > > language, once you set a
> > > variable to a value, it retains that value until
> you
> > > set it to a different
> > > value.  But not Omega's EL - that is, not if you
> are
> > > updating these
> > > variables in a time-bar chart on a tick-by-tick
> > > basis.  A variable WILL
> > > update correctly on each tick, but at the end of
> the
> > > bar's time slot the
> > > value will be "restored" to some prior value and
> > > there is no way for you to
> > > inhibit this "feature".  This was actually a
> kluge,
> > > undocumented, to cause a
> > > real-time run to match results of a run on
> > > historical data where only bar
> > > values are considered, not individual ticks.
> > >
> > > Carroll Slemaker
> 
> 
>