Re: Really strange problem, for very bright people

Hi

i need a program with read seriall or paralell port and send to a 
variable

pleas help me.

paydar

bye



--- In [email protected], "Majoros, Endre" 
<emajoros@f...> wrote:
> Hi Steve, 
> 
> I think it can come from the order of evaluation of the expression.
> 
> If you read the Delphi help for extended (it is actually not very 
helpful), you'll see a note on Currency type:
> "Currency is a fixed-point data type that minimizes rounding 
errors in monetary calculations. It is stored as a scaled 64-bit 
integer with the four least-significant digits implicitly 
representing decimal places. When mixed with other real types in 
assignments and expressions, Currency values are automatically 
divided or multiplied by 10000." 
> 
> So actually the Currency type is not a real floating point type, 
but it has fixed number of digits.
> 
> Floating-point (real) arithmetic is necessarily inexact even 
simple-seeming numbers like 1/3 or 0.2 cannot be represented 
exactly. That is why the "printed" value of a variable, or the 
output of a simple calculation, may show an inexact value - 
something like 1.199999997 or 1.200000003 where 1.2 or 1.20 is 
expected. Where exactness is appropriate, either use integral types 
only, or convert by Round, Trunc, etc. to integers. 
> Accuracy and resolution must not be confused. In the case of 
single and double the accuracy should approach the resolution; but 
for the highest resolution case, extended, the accuracy, while 
better than for double will be appreciably less than the resolution. 
Usually. 
> 
> Note that, while A+B = B+A, it may be that A+B+C <> C+B+A, since 
that is a comparison of (A+B)+C & (C+B)+A which may round 
differently. In Javascript IEEE Doubles, X = [0.03+0.03+0.01, 
0.01+0.03+0.03] gives [0.06999999999999999, 0.07].
> 
> Here is a snippet of a Turbo Pascal FAQ:
> 
>  Q: What real numbers types are there? How do I use them?
> 
>  A: I'll only give the very basics, since the information is
> contained in your friendly manuals and this FAQ is not intended to
> replace them! If you have Turbo Pascal 7.0 please see in the
> Language Guide the item on Real Types on pages 28-29 and Chapter 14
> on Using the 80x87. However, the five real types are
>   TYPE       LOW        HIGH      DIGITS   BYTES
>   real     | 2.9e-39    1.7e38   | 11-12  |   6
>   single   | 1.5e-45    3.4e38   |  7-8   |   4
>   double   | 5.0e-324   1.7e308  | 15-16  |   8
>   extended | 3.4e-4932  1.1e4932 | 19-20  |  10
>   comp     | 0.0, 1.0   9.2e18   | 19-20  |   8
> A much better presentation of the table can be found at Dr. John
> Stockton's http://www.merlyn.demon.co.uk/pas-real.htm#FloatTypes
> You'll always have an access to the real type. Using the others 
will
> require appropriate setting the {$N} and the {$E} compiler
> directives. To get more information about them, read the current
> file in the Turbo Pascal IDE (i.e. the editor), move the cursor on
> the directives above, and press Ctrl-F1 to get the TP help. For the
> first select from the list of three the item "$N: Numeric
> Coprocessor Switch".
>    If you have a program where you have user the type real and wish
> to increase the accuracy, you do not need to change every 
occurrence
> of "real". A much quicker method is shown by the small example 
below
>   {$N+} { The Numeric Coprocessor Switch needed for access to four
>           additional real types: Single, Double, Extended, and 
Comp. }
>   {$E-} {The compiler links with smaller floating-point library. It
>          requires that the math coprocessor is available at run 
time. }
>   type real = double;  { ... this is the trick! ...}
>   var a, b : real;
>   begin
>     a := 4.0; b := 7.0;
>     writeln (a/b);
>   end.
> John, quite correctly, comments on 'type real = double': "I don't
> like redefining a standard, though not reserved, identifier - too
> confusing - and prone to error if using Units, since one must 
ensure
> that it applies in every Unit as well." I continue: with this in
> mind, use e.g.
>   {$N+,E+} { Use coprocessor emulation for a change, better
>              generality, slower code. }
>   var a, b : extended;
>   begin
>     a := 4.0; b := 7.0;
>     writeln (a/b);
>   end.
> Also see http://www.merlyn.demon.co.uk/pas-real.htm#Float
> 
> Comments from Osmo Ronkanen: 1) "If you use $N+ and especially if
> you use also $E+, you should not use the real type." 2) "One way is
> to do:
>   {$ifopt n+}
>   type real=double;
>   {$endif}
> That way it compiles on both $N+ and $N- with no compromises."
> 
> And here is a link to the IEEE standard for floating points:
> 
http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html
> 
> Endre
> 
> 
> -----Original Message-----
> From: Stephen Wood [mailto:stephenw@d...]
> Sent: Friday, August 08, 2003 12:08 PM
> To: '[email protected]'
> Subject: RE: [Delphi] Really strange problem, for very bright 
people
> 
> 
> Thanks Jeff,
> 
> What I can't understand is that the calculation actually works 
with the
> other types (extended, double, etc) only if the order is changed, 
so
> therefore rounding issues, and insignificant digits are not the 
problem,
> because the calculation does work....but just in a different order.
> 
> And secondly, how is a developer supposed to understand in what 
order to
> write the calculations, unless the bug actually manifests itself?
> 
> And thirdly, this calculation is used many times with different 
input
> parameters and calculates correctly, but it seems that the bug 
only happens
> when "certain" input values are used....really really weird...
> 
> But thanks anyway!!!
> 
> -----Original Message-----
> From: Jeff Steinkamp - N7YG [mailto:n7yg@e...] 
> Sent: Friday 08 August 2003 09:53
> To: [email protected]
> Subject: RE: [Delphi] Really strange problem, for very bright 
people
> 
> Try this and see what happens
> 
> vary vCalc1,vCalc2,vCalc3 : real;  //works with the single type 
also
>     vCalc11,vCalc21,vCalc31 : real;
>     vCalc111,vCalc211,vCalc311 : real;
> begin
> vCalc1 := (4.328247 * ( 33660 / 1000 ) * 1.06 * 1 * 1 * 1.5 * 
1.035 );
> vCalc11 := ( 1.5 * 1 * ( 33660 / 1000 ) * 4.328247 * 1.06 * 
1.035 );
> vcalc111 := vcalc1-vcalc11;
> 
> vCalc2 := (4.328247 * ( 33660 / 1000 ) * 1.06 * 1 * 1 * 1.5 * 
1.035 );
> vCalc21 := (4.328247 * 1.06 * 1.5 * 1 * ( 33660 / 1000 ) * 1.035 );
> vcalc211 := vcalc2 - vcalc21;
> 
> vCalc3 := (4.328247 * ( 33660 / 1000 ) * 1.06 * 1 * 1 * 1.5 * 
1.035 );
> vcalc31 := (4.328247 * 1.06 * 1.035 * 1.5 * 1 * ( 33660 / 1000 ) );
> vcalc311 := vcalc3 - vcalc31;
> 
> The reason you are not having problems with the Comp and Currency 
type
> is because of rounding of the numbers.  The anomoly you are seeing 
is a
> floating point problem that has been around for years that I am 
aware
> of.  If you break the equation into smaller chucks it works much 
better,
> but if you are looking for extremely small resolution this could 
be a
> problem.
> 
> Jeff Steinkamp
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Stephen Wood [mailto:stephenw@d...] 
> > Sent: 08 August, 2003 00:00
> > To: '[email protected]'
> > Subject: [Delphi] Really strange problem, for very bright people
> > 
> > 
> > Hi all,
> >  
> > I'm looking for some really bright people to help with this 
> > one, because in
> > my entire life, I've never seen something as strange as this.
> >  
> > We have a calculation engine that does a whole whack of 
> > calculations...on we
> > picked up a bug with it. We then stripped down the 
> > calculation to bare bones
> > and were quite amazed at what we found....below is a code 
> > snippet to explain
> > what's happening...
> >  
> > var
> >   vCalc : extended;
> >  
> > vCalc := (4.328247 * ( 33660 / 1000 ) * 1.06 * 1 * 1 * 1.5 * 
> > 1.035 ) - ( 1.5
> > * 1 * ( 33660 / 1000 ) * 4.328247 * 1.06 * 1.035 );
> >  
> > This gives an answer of 2.7755575616e-17
> >  
> > Now do this....
> >  
> > vCalc := (4.328247 * ( 33660 / 1000 ) * 1.06 * 1 * 1 * 1.5 * 
> > 1.035 ) - (
> > 4.328247 * 1.06 * 1.5 * 1 * ( 33660 / 1000 ) * 1.035 );
> >  
> > You'll notice that I just moved the 4.328247 and 1.06 to the 
> > front of the of
> > the second brackets and you get an answer of 1.3877787808e-17
> >  
> > Now try this...
> >  
> > vCalc := (4.328247 * ( 33660 / 1000 ) * 1.06 * 1 * 1 * 1.5 * 
> > 1.035 ) - (
> > 4.328247 * 1.06 * 1.035 * 1.5 * 1 * ( 33660 / 1000 ) );
> >  
> > All I've done now is move the 1.035 after the 1.06 in the 
> > second brackets
> > and I get an answer of 0 (which is actually the correct 
> > answer, which we
> > expected, and which Excel gives us as well)
> >  
> > Just moving the value around in a multiplication calculation 
produces
> > different results....the different results are consistent with 
single,
> > double and extended types, but with comp and currency types, 
> > the calculation
> > is correct every time....
> >  
> > Can anyone explain this?
> >  
> > Thanks
> > Steve
> >  
> > 
> > 
> > [Non-text portions of this message have been removed]
> > 
> > 
> > ------------------------ Yahoo! Groups Sponsor 
> > ---------------------~-->
> > Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or 
Lexmark
> > Printer at Myinks.com. Free s/h on orders $50 or more to the 
> > US & Canada. http://www.c1tracking.com/l.asp?cid=5511
> > http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/i7folB/TM
> > --------------------------------------------------------------
> > -------~->
> > 
> > CodeCoffer - new Delphi code protection Tool!
> > http://www.delphicollection.com/public/CodeCoffer.htm
> > ---------------------------------------------------------------
> > Unsubscribe:[email protected]
> > List owner:[email protected]
> > --------------------------------------------------------------- 
> > 
> > Your use of Yahoo! Groups is subject to 
> > http://docs.yahoo.com/info/terms/ 
> > 
> > 
> > 
> 
> 
> 
> CodeCoffer - new Delphi code protection Tool!
> http://www.delphicollection.com/public/CodeCoffer.htm
> ---------------------------------------------------------------
> Unsubscribe:[email protected]
> List owner:[email protected]
> --------------------------------------------------------------- 
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 
> 
> 
> 
> [Non-text portions of this message have been removed]
> 
> 
> 
> CodeCoffer - new Delphi code protection Tool!
> http://www.delphicollection.com/public/CodeCoffer.htm
> ---------------------------------------------------------------
> Unsubscribe:[email protected]
> List owner:[email protected]
> --------------------------------------------------------------- 
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/i7folB/TM
---------------------------------------------------------------------~->

CodeCoffer - new Delphi code protection Tool!
http://www.delphicollection.com/public/CodeCoffer.htm
---------------------------------------------------------------
Unsubscribe:[email protected]
List owner:[email protected]
--------------------------------------------------------------- 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/