|
PureBytes Links
Trading Reference Links
|
Oh my oh my, you spend a lot of words trying to explain why it should not
work. You do not spend one single second realising that in fact it works in
other engines than Tradestation, engines claiming to have less precision
than Tradestations incorrect claim. You spend a lot of words explaining why
this should be incorrectly represented in a computer. But you know very
little of what you are speaking so much about. It does work, not in
Tradestation but in single precision. It should work, the numbers should be
represented fully, they should and they do in real single precision
implementations (bet you have no clue how numbers are stored in a computer).
If you knew anything about it you would instead be amased over why
Tradestation has an implementation that loses the accuracy when single
precision does not.
Let us try the "impossible example" which is of course impossible on the
Tradestation engine only, and run it on something which has full 6 digits of
precision, you know, single precision in C++. Is the below code example
impossible to C++? No, it works. Does C++ use the math functions in the
processor chip? Yes, it does. So probably it works in VB as well, I have not
tested. Anyhow: Below is the code I tested, which does the comparison
perfectly well.
float should=0;
float think=0;
float Value1 =(float) 10.3 - (float) 10.2;
float Value2 =(float) 10.2 - (float) 10.1;
if (Value1>Value2) {
should=1;
}
if (Value2>Value1) {
think=1;
}
What comes up? Well what should be expected is what comes up.
Value1=0.100000, Value2=0.100000, should=0, think=0. With 6 digits of
precision, like in C++, no errors does pop up in this example. This example
only produces errors in Tradestation, due to its very suspect math engine
and below 6 digits of precision. Only Pierre would have the drive to defend
this bug as being a correct way to do things. This example should not have
been impossible in Tradestation, it should have worked, the bug ought to be
corrected by Omega. In spite of all your unknowledgeable words about
precision, the fact is that this example works in single precision, this
example should work in single precision, this example produces errors in
Tradestation alone, maybe it would have on a sinclair calculator from 1973
as well. You make it sound like you knew something about theory on computer
numbers with all your words, but you do not, you are just spending a great
number of words trying to avoid to realise that Tradestation does not
represent these numbers correctly, numbers that are fully possible to
represent without precision loss in a single precision environment. Omega
should at least provide us with the same precision as single precision math
does. The previous example I sent out was the same thing, it works perfectly
well in single precision, but it does not work in Tradestations buggy
implementation of math. Tradestation precision is not 7 digits, not 6
digits, it is worse than 6 digits precision, else the number should have
worked as well as 6 digit precision does.
You claim that you are teaching physics on some kind of school. If you had a
test on your students on 10.3-10.2 and they started to rewrite it like
"10.31-10.19" (still correct to 3 digits precision). Would you consider them
still dealing with the original task? Well if they were employed by Omega, I
bet you would. But there is no reason to rewrite the values to other values
as long as they can be represented fully in the available representation.
This is what Tradestation does, a little more subtle but still it does this
buggy rewrite without reason. And it does not do it because the numbers can
not be represented in single precision, it does it because Tradestations
math implementation is buggy and a lot worse than single precision.
There are people out there coding stuff in other engines than C++. VB,
Fortran, ... Could we have a little test here, could those people try and
see if you could find any math engine besides Tradestation that fails at
this test? Just code the test and see if it works, and report it in mail.
Does VB make the example work? Does Fortran make the example work, does Perl
make the example work, and so on...
> -----Original Message-----
> From: pierre.orphelin [mailto:pierre.orphelin@xxxxxxxxxxxxxx]
> Sent: den 18 juli 2001 01:38
> To: omega-list@xxxxxxxxxx
> Subject: RE: I think I have to change my opinion from bad
> precision to buggy c alculations
>
>
>
> > > > Hello Pierre Orphelin,
> > > >
> > > > Let's imagine for a moment that no such terrible things
> as "errors
> > > > over bars", "double precision" and "epsilon" are exist. To do
> > > > this let's look at the simple Indicator with Single precision,
> > > > Single bar (lastbaronchart) and hopefully no "epsilon"
> (whatever
> > > > it is):
> > > >
> > > > {########################################}
> > > > If LastBarOnChart Then Begin
> > > > Value1 = 10.3 - 10.2;
> > > > Value2 = 10.2 - 10.1;
> > > > If Value1 > Value2 Then Value3 = 1 Else Value3=0;
> > > > plot1 (Value3);
> > > > End;
> > > > {########################################}
> > > >
>
> Here is an other misunderstanding of Float 7 digits precision
>
> If LastBarOnChart Then Begin
> Value1 = 10.3 - 10.2;
> Value2 = 10.2 - 10.1;
> If Value1 > Value2 Then Value3 = 1 Else Value3=0;
> plot1 (Value3);
> messagelog(value1:15:15,value2:15:15);
> End;
>
> Produces:
>
> 0.100000000000000 //
> 0.099999400000000 //
> Precision is impossible to determine // Precison is
> obviously 5
> digits
> ( 5 assumed, cannot be more)
>
> Is it a bug? NO.
>
> Value1 = 10.3 - 10.2 contains two numbers with 7 digits
> precision 10.3 is stored as 10.30000xxxx 10.2 is stored as
> 10.20000xxxx where xxx is unknown to Float precision and
> will produce garbage after 7th digit,
>
> When difference is calculated it is performed on 7 digit - 7 digits
> BUT:
> 10.y - 10.z will produce 00.[y-z]. -y=3, z=2
> So the 2 digits are lost in the difference because 10 -10 =
> 00, and only beacuqse of that. What remains is 5 digit and
> is conform to the original initial Float precision.
>
> There is no bug at all, only a special case where the
> difference of two very close numbers remove the 2 digits to the left.
>
> The only solution is to have more than a float to store
> numbers, but even a double will lose the 2 digits of the
> original double precision. So this kind of operation will
> always lose precision in terms of digits, but not in
> intriinsic precision ( the precision of the difference is ONE
> digit in this case = 0.1)
>
> And again, the difference here is far beyond the THREE
> digits precision of the original numbers.
>
> 'Cannot undestand why you focus on such stupid things that
> are only logic and does not involve any form of bug. You
> will have the same problem using C or anything you want with
> 7 digits float precision.
>
> Sincerely,
>
> Pierre Orphelin
> www.sirtrade.com
> TradeStation Technologies representative in France
>
>
This message contains information that may be privileged or confidential and is the property of the Cap Gemini Ernst & Young Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
|