|
PureBytes Links
Trading Reference Links
|
At Thu, 02 Mar 2000 05:35:42 -0800, Bill Vedder <bved01@xxxxxxx> wrote:
>Brian is correct. If properly stated, anything should be able to be
>programmed. The "problem" is in properly stating and interpretting the
rules or idea.
> As far as programming the head and shoulders, just because you can't do
it in
>ezl, doesn't mean it can't be done. In fact, it has been done and research
work
>published about it.
The fundamental difficulty, I've found, is what I refer to as the "perception"
problem. Specifically, what do you do in the case in which the trader's
highly profitable perception does not correlate well with the data he says
he is using? Believe me, this is a real problem! What I'm referring to
here is the case in which a trader's *perception changes* such that he interprets
the *exact same* data in two (or more) different ways.
I think that this is what some people refer to as "intuition", but it goes
beyond my concept of "intuition" in that it can change in an *unpredictable*
manner.
A simple example: Trader says, "I would go long here". Programmer asks,
"Why?". Trader gives a long and detailed explanation of 8000 things which
have happened over the course of the last 50 years to lead to this current
long. (No kidding.) Before the trader finishes explaining his current
long, he is saying, "I would sell here." Programmer asks: "Why?" Trader
gives the *exact same* list of 8000 reasons for his current short as he
gave for the long he took a few minutes earlier!
To summarize, programming is a *means*, not an *end*. It is to be used,
*where it makes sense* to use it - specifically, where it reduces work
through automation. If it would be more work to automate a trader's method
than it is to just let the guy trade it, then programming makes no sense.
Also, there is the case of the *randomly changing* trader perception which
is not codable. How do you program to trade the *exact same* data in two
different ways?
Good trading,
OM
|