|
PureBytes Links
Trading Reference Links
|
Now you are kidding again, good humor. Paying you for EL consulting must be
considered a bad way to waste money. If I had 1000000000000000000000002$ and
gave you 1$ would have to be considered a bug :-)
I notice you are once again off topic, so you are out of arguments. And that
is natural, it is hard to keep claiming Tradestation has 7 digits precision,
which is better than single precision, and at the same time try to explain
why calculations that come out correct in single precision does not even
come close in Tradestation. One has to be quite stubborn to even try... :-)
Or spending a great amout of arguments trying to explain why 10.3-10.2 comes
out with a rounding error in Tradestation but not in languages (except maybe
fuzzy logic), that utilises the math processor and IEEE storage format. And
still claiming that this is very good, is better than the languages that
deliver the correct results, and that this has something to do with physics
lessons taught at some kind of school. I do not recommend you to read a
whole book, that would be asking too much. Just sit down and think (avoid
fuzzy logic): If one program (Tradestation) arrives at different results
than for example C++ If those results arrived at by this program
(Tradestation) are incorrect due to lack of precision. If the actions
performed by this program (Tradestation) are illogical due to the lack of
precision. If the write protected code delivered by Omega does nothing to
circumvent these numerical errors in indicators? Is it really a good idea to
keep claiming Tradestation has higher precision than what is claimed by C++?
Is it really a good idea to defend Omegas indicator code as logical
according to physics lessons? Is it really a good idea to keep claiming that
this is what should be expected from an expensive calculation program?
Just think, not too hard, just a little. :-)
> -----Original Message-----
> From: pierre.orphelin [mailto:pierre.orphelin@xxxxxxxxxxxxxx]
> Sent: den 18 juli 2001 12:34
> To: omega-list@xxxxxxxxxx
> Subject: RE: I think I have to change my opinion from bad
> precision to buggy c alculations
>
>
> 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.
> >
>
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.
|