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

RE: I think I have to change my opinion from bad precision to buggy c alculations


  • To: omega-list@xxxxxxxxxx
  • Subject: RE: I think I have to change my opinion from bad precision to buggy c alculations
  • From: Gary Yakhnes <gary@xxxxxxxxx>
  • Date: Wed, 18 Jul 2001 08:13:33 -0700
  • In-reply-to: <200107180452.VAA27160@xxxxxxxxxxxxxx>

PureBytes Links

Trading Reference Links

Hello Pierre Orphelin,

I must admit that you are absolutely correct here and I was wrong.

Thanks for your post.
Gary


>   > > > 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
>
>
>
>
>
>