|
PureBytes Links
Trading Reference Links
|
Of all the things, I've seen posted here and elsewhere about system
development this is one of the most insightful. We assume that software
gives us the "right" answer if the data being used is clean. And then we
are willing to put dollars on the line. We all know about coding problems
such as buy on the open instead of buy on the next open. It seems likely
that there are a lot more ways of getting it wrong, both of our own doing
and of Omega/TS's or whatever software. What I do after I have a system
that I am satisfied with is try to reproduce the buys and sells by hand.
Because it's so laborious, I can't easily do every single trade. But I do
enough that I'm satisfied that my logic is the same as TS's logic and that
my math is the same as TS's math. If also gives me a far better feel for
what the system is doing. Reminds me of observations of traders who used to
maintain P&F charts by hand in the days before PC's. When they got
religion, they observed that their feel for what was going on in the market
was less than when they did the plots by hand. I'm not advocating that hand
calcs and plots are the way to go, just observing that there is an important
intangible that is lost.
Thanks for the post, Bob.
Season's best,
Mike
> Very little about how TradeStation really works internally is
> published. I am not even sure the staff now left in the company even
> know...
>
> About the only way to find out if, and how, something works is to run
> tests and see what happens. Users on email lists such as this run
> such tests all the time and share their findings.
>
> Some of the former Omega staff, such as Sam Tennis, who knew how it
> worked in days past, are on this list and sometimes help out.
>
> If you want a "real" programming language with documentation, modern
> debugging facilities, etc., you need to look elsewhere. Frustrating,
> I know, but true.
>
> One wise user once wrote that probably 95% of the programs that
> TradeStation users write do not run the way the user intended and
> they never know it.
>
> Technical integrity has never been a priority with the Omega
> management and probably never will be. Most of us have long-ago given
> up on trying to get fixes out of the company and are just trying to
> get our programs to work the way we want with the software we now
> have.
>
> Bob Fulks
>
>
>
> At 9:04 PM -0600 12/15/01, Mike Eggleston wrote:
>
> >On Sat, 15 Dec 2001, Bob Fulks wrote:
> >
> >> At 5:36 PM -0600 12/15/01, Mike Eggleston wrote:
> >>
> >> >Though what of calculations that are complex and you want to separate
> >> >them for verification and readability?
> >>
> >> We do not seem to be communicating. If you NEVER refer to a variable
> >> using brackets as in
> >>
> >> variable[xxx]
> >>
> >> then TradeStation does not need to save past values. It only needs to
> >> save the single present (current) value.
> >
> >I disagree. If their internal parser is never published, then neither
> >of us can say exactly what their code does. I believe that even if I
> >never use the back-bar-square-brackets that their parser will still
> >save previous values. It is the easiest thing for their programmers
> >to do; do the same thing in all situations. However, if I supply
> >the output value from one function as the input value to the next
> >function, then there is no intermediate variable that gets assigned.
> >
> >> >I would like to tell EL to ignore a specific variable. Possibily
> >> >in the Vars: line there is an extra definition parameter.
> >>
> >> No need for this.
> >
> >The need for this is to have explicite and total control over their
> >parser and to not let their assumptions dictate how my code performs.
> >
> >> If TradeStation sees a reference to a past value using brackets, it
> >> has to save all values back to MaxBarsBack before the CurrentBar. If
> >> no references using the brackets, no need to save the values.
> >
> >Until their parser specifications are published, then this statement
> >cannot be proven.
>
|