math functions return errors after printing a report

rbuser

Hi,

I use "extended"-type variables in my application to calculate a lot of
power(x,y) using the math-libraries. All's functioning fine....until I print
a report using Reportbuilder (enterprise V5.0). After that the power(x,y)
returns slightly different results, and sometimes even "invalid floating
point operation" on very easy and very valid power(x,y) calculations.

The problem is resolved by using "double"-types in stead of
"extended"-types.

Are you aware of this problem ? It only occurs after printing a report, so I
dare to say it ther must be happening something in Reportbuilder

Regards

Leon Bemmelmans

digitalmetaphors

Are you saying that a Delphi variable declared as type Extended, when raised
to a power yields a different result than when a TppVariable of type
Extended and having the same value is raised to the same power? I just
tried this with D5 and RB 5.56, and both calculations result in the same
value. Don't use a Delphi variable to perform calculations for a report-
use a TppVariable, because you can control the timing of the variable's
calculation. Can you give us a demo project that describes this problem and
send it to support@digital-metaphors.com


Cheers,

Jim Bennett
Digital Metaphors

rbuser

Well,

it's not so easy to reproduce the problem in a small application, so sending
al little demo will be almost impossible.

The problem is more complex. I only use calculations in my project, not in
the report. But after I ran the report once my calculations are changed. It
seems as if the extra 2 bytes of the extended type are causing the trouble,
sometimes set to zero and sometimes not. I wonder if you use a statement or
compiler directive in Reportbuilder that changes the behaviour of extended
types.

It could be a coincident also, a flaw of Delphi5 or Pentium II (The problem
seems to be machine-dependant) in some situations (large, complex
application). Using "double" instead of "extended" resolved the problem, but
I don't like this solution.

Leon

digitalmetaphors

We do not perform any changes to the beahvior of the extended type. I just
searched all of our source for extended and didn't see anything that would
change the extended behavior for the extended type. RB relies on Delphi to
handle extended type numbers. The Delphi help warns about the use of
extended on multiple platforms, if that is of any consolation.


Cheers,

Jim Bennett
Digital Metaphors

rbuser

rbuser

Bruce,

I couldn't find the thread you are talking about, but does this also give a
possible answer to the question why using "double-precision" in stead of
"extended" resolved te problem ?

Leon

rbuser

rbuser

Hi,

extended is a special pascal typ. You use it for high precission. Now accross
platforms and processors (hardware) IEEE defines to use the double data type.
Simple date/math function use standard features. And therefore you can get
errors with extended. Not all what is possible was implemented for the extended
data type.

Hard and Software producer support the double datatype. With extended you are
at your own risk.

enjoy,
Ron.