Decimal Calculations? 5

[Glenn9999]

(More of a poll)

I was looking at some old code, and was wondering something. How do people that read this forum typically handle their decimal calculations when it comes to Delphi apps (or the companies they've worked in)?

1. FP types (single, double, real, currency, etc)?
2. Calling other apps to do them / Using other languages?
3. Fixed-point integer arithmetic coded in Delphi?
4. I/we don't do decimal calculations routinely?

 

[Griffyn]

I use Double when needed, and only when needed.

I've often considered doing faux floats using Integers and formatting the output with a decimal point, but it creates confusing code and business apps rarely do enough work (in my experience) to require the tiny bit of extra speed this approach may bring. Plus, if you store faux floats in a database, it gets very confusing when you need to access that data outside of your application.

 

[sggaunt]

Used Extended types when we were asked to provide a utility that could present values in IEEE format.
I a wrote a set of functions to do that.
It uses IntPower and Ldexp from the Delphi Math Library which are mostly inline assembler (I don't know if this make any difference to accuracy), Extensive tests showed the functions to be more than accurate enough for the application.
But nothing else where 'real' types might be a problem.


Steve: NMNF.

 

[Stretchwickster]

In most applications I've written (many of them being engineering applications), I've used Double when I required a reasonable amount of precision, otherwise Single usually sufficed. In one piece of legacy software I've worked on, Fortran was used as the calculation engine with Delphi as a front-end.

Clive

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"To err is human, but to really foul things up you need a computer." (Paul Ehrlich)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get the best answers from this forum see: faq102-5096

 

[roo0047]

I use both Double and Currency. When outputting to strings, I always specify my precision with a format statement. Example:

result:= format('%4.2f', [x])

Roo
Delphi Rules!

 

[AP81]

Single, or double (if more precision is required).

Extended when perfoming rounding with a large number of decimal places.

 

[Glenn9999]

Okay, so most here tend to do more calculations of a more scientific nature than a business nature?

I've often considered doing faux floats using Integers and formatting the output with a decimal point, but it creates confusing code and business apps rarely do enough work (in my experience) to require the tiny bit of extra speed this approach may bring.

The reason I asked this was out of curiousity regarding a piece of code I recently came across again. I ended up writing a unit which does this (using Comp/Int64) because I was running into accuracy problems (namely rounding limitations) using the floating-point values on a couple of things. The second thing worked out for using this code, although I did try to work it out using the Delphi FP values.

Mainly, I was just curious if people habitually run into those same problems, or if it was not much of a concern in general.

 

[harebrain]

Hmm, business apps. The tendency there is, in my experience, to do the calculating in a database stored procedure. The numeric data types in SQL Server and Oracle, for instance, are richer and the accuracy is predictable/definable.

 

[AP81]

I did some work with the Quickbooks SDK and it took me a day to work out why some of my dollar values were out by a cent. Some of these dollar values in Quickbooks had up to 15 decimal places (I don't know why).

At first I thought I had made calculation errors with adding GST, but in the end it came down to the precision of a double and rounding. All the problems went away when I changed from Double to Extended.

 

[DjangMan]

I recently did some work on detecting oil and gas wells within a five mile radius of a given lat/long coordinate. Someone else did the hard math but for speed sake I ran a process to convert all of my long/lat coordinates into integers. Too many rads and pi and allowances for the curvature in the earth's surface in the equations for my taste. I was paranoid about having to determine why a well should have been detected and wasn't so I converted it all to nice square integers.

As an aside the Accpac Plus database used a form of BCD - it stored all numbers as integers in either 4, 6 or 8 bytes and the last byte determined the number of decimal placed.