|
PureBytes Links
Trading Reference Links
|
Your problem is not a precision problem, but understanding what precision is
when perfortming calculus.
If you have 1000002 $ and if you agree to give me 1000001 $ for EL
consulting ( I will give tou my bank account reference if you want to make
the experience for real), both amounts of money are known with a 7 digit
precision.
After transferring funds, you will still have 1000002 -1000001 US$ = 1 US$
We performed 7 digit precision operation, and the result have 1 digit
precision operation.
No more, no less.
And we never used any computer language, C, VB, EL and so on.
WHERE IS THE BUG ?
Take a chance to read a physics book on measurement basics.
This iu usually one of the first lesson teached.
Sincerely,
Pierre Orphelin
www.sirtrade.com
TradeStation Technologies representative in France
> -----Message d'origine-----
> De : Bengtsson, Mats [mailto:mats.bengtsson@xxxxxxxx]
> Envoye : mercredi 18 juillet 2001 10:46
> A : pierre.orphelin@xxxxxxxxxxxxxx; omega-list@xxxxxxxxxx
> Objet : RE: I think I have to change my opinion from bad
> precision to buggy c alculations
>
>
> 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.
>
|