EXP Function

[rnewell]

When I use the EXP function I am getting an Error telling me that my results have two many decimal places.

Is there a work around for this?


P = 20000.
I = 9.67.
N = 60.
J = I / (12 * 100).

M = P * (J / EXP(1 – ( 1 + J), - N)).

Thanks,

 

[Crittar]

Are you sure you have the logic correct?

if you examine the line:

M = P * (J / EXP(1 – ( 1 + J), - N)).

it is equivalent to

M = P * (J / EXP(- J), - N)).

I suspect this is what is causing your problem.

Hope this helps.

 

[Unregistered]

M = P * (J / EXP(1 – ( 1 + J), - N)) is same as
M = P * J * EXP( - J, N).

 

[rnewell]

Thanks, but that still gives the same error message..

Decimal number is too large (536).

 

[Crittar]

I'm not too surprised that the system complains, if you take your original formula and substitute the values you supplied into it you end up with:

M = 20,000 * (.0080583 / -0080583^-60) if you perform the calculation within the bracket you obtain a result of:

4.2207935069343172155510363516765 * 10^125

I suspect therefore there is an error in your formula.

 

[JonMeecham]

Using the other values, N can only be 19.

Since the formula you're doing includes a negative exponential, the number gets very big for large values on N.

e.g.

EXP(1 – ( 1 + J), - N)

> EXP(-0.0080508333, -N)

If N>19 then you get the error.
IF N=9 this value returns
615211032236000160723.11193301485

This looks like a limitation of the Windows API used to calculate these numbers since the Microsoft Calculator return the following for N=20
1.308629545226517573782490800694e-42


I'd suggest that this is a limitation of windows, not Progress.



Jon Meecham

 

[Crittar]

Jon,

I suspect the limitation is in progress:

I am using 9.1c in a chui environment on a compaq gs80 under unix - so I don't touch windows at all. I am still able to replicate rnewell's problem.

enny:

 

[JonMeecham]

I found this list of limits for different data types on the web.


Name Minimum Value Maximum Value Binary Size Precision
(bytes) (significant
digits)

short -32,767 32,767 2
ushort 0 65,535 2
long -2,147,483,647 2,147,483,647 4
ulong 0 4,294,967,295 4
float 10^-37 10^38 4 6**
double 10^-307 10^308 8 15**


Presumable progress uses a float type for decimals.

Hope this helps.

 

[JonMeecham]

Since windows will use e in large numbers

e.g. 1.037648723687423e64

I would suggest that the limitation is with Progress managing the floating decimal point.

I therefore agree with Crittar and retract my earlier accusation against Windows.

Floating point types are specifically designed to be written above as for numbers that large, there is not usually a requirement for accuracy to 64 digits, just to record the fact that the number's decimal point occurs before the 64th digit. This way, less information needs to be stored about large numbers.

Hope this helps you, mewell.