Home› General
ReportBuilder 22.06 now available including Delphi 12.2 support!
New Blog Posts: Merging Reports - Part 1 and Part 2

math functions return errors after printing a report

rbuserrbuser
edited June 2001 in General
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

Comments

  • digitalmetaphorsdigitalmetaphors
    edited June 2001
    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


    Digital Metaphors Corporation
    http://www.digital-metaphors.com
    info@digital-metaphors.com
  • rbuserrbuser
    edited June 2001
    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
  • digitalmetaphorsdigitalmetaphors
    edited June 2001
    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


    Digital Metaphors Corporation
    http://www.digital-metaphors.com
    info@digital-metaphors.com
  • rbuserrbuser
    edited June 2001

  • rbuserrbuser
    edited June 2001
    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
  • rbuserrbuser
    edited June 2001

  • rbuserrbuser
    edited June 2001
    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.

This discussion has been closed.