Invalid Floating point operation using round(double) in Delphi - delphi

I am using Delphi 7, where I have variable v: double which is set to value 5,5889002873e+22 .
CurrencyDecimals is 2
When I use round(v), I get this error:
Invalid Floating point operation
It is not clear to me why it happens because range of double is exponent -308 to +308 . How to perform the rounding to be correct?

Result of Round is integer variable (help)
function Round(X: Real): Int64;
but Int64 type cannot contain values more than 2^63 - 1 (about 9*10^18), so
If the rounded value of X is not within the Int64 range, a run-time error is generated
What is a purpose of this rounding?

Related

How to convert a floating point number to a string with max. 2 decimal digits in Delphi

How can I convert a floating point number to a string with a maximum of 2 decimal digits in Delphi7?
I've tried using:
FloatToStrF(Query.FieldByName('Quantity').AsFloat, ffGeneral, 18, 2, FS);
But with the above, sometimes more than 2 decimal digits are given back, ie. the result is: 15,60000009
Use ffFixed instead of ffGeneral.
ffGeneral ignores the Decimal parameter.
When you use ffGeneral, the 18 is saying that you want 18 significant decimal digits. The routine will then express that number in the shortest manner, using scientific notation if necessary. The 2 is ignored.
When you use ffFixed, you are saying you want 2 digits after the decimal point.
If you are wondering about why you sometimes get values that seem to be imprecise, there is much to be found on this site and others that will explain how floating-point numbers work.
In this case, AsFloat is returning a double, which like (most) other floating-point formats, stores its value in binary. In the same way that 1/3 cannot be written in decimal with finite digits, neither can 15.6 be represented in binary in a finite number of bits. The system chooses the closest possible value that can be stored in a double. The exact value, in decimal, is:
15.5999999999999996447286321199499070644378662109375
If you had asked for 16 digits of precision, the value would've been rounded off to 15.6. But you asked for 18 digits, so you get 15.5999999999999996.
If you really mean what you write (MAX 2 decimal digits) and does not mean ALWAYS 2 decimal digits, then the two code snippets in the comments won't give you want you asked for (they will return a string that ALWAYS has two decimal digits, ie. ONE is returned as "1.00" (or "1,00" for Format depending on your decimal point).
If you truly want an option with MAX 2 decimal digits, you'll have to do a little post-processing of the returned string.
FUNCTION FloatToStrMaxDecimals(F : Extended ; MaxDecimals : BYTE) : STRING;
BEGIN
Result:=Format('%.'+IntToStr(MaxDecimals)+'f',[F]);
WHILE Result[LENGTH(Result)]='0' DO DELETE(Result,LENGTH(Result),1);
IF Result[LENGTH(Result)] IN ['.',','] THEN DELETE(Result,LENGTH(Result),1)
END;
An alternative (and probably faster) implementation could be:
FUNCTION FloatToStrMaxDecimals(F : Extended ; MaxDecimals : BYTE) : STRING;
BEGIN
Result:=Format('%.'+IntToStr(MaxDecimals)+'f',[F]);
WHILE Result[LENGTH(Result)]='0' DO SetLength(Result,PRED(LENGTH(Result)));
IF Result[LENGTH(Result)] IN ['.',','] THEN SetLength(Result,PRED(LENGTH(Result)))
END;
This function will return a floating point number with MAX the number of specified decimal digits, ie. one half with MAX 2 digits will return "0.5" and one third with MAX 2 decimal digits will return "0.33" and two thirds with MAX 2 decimal digits will return "0.67". TEN with MAX 2 decimal digits will return "10".
The final IF statement should really test for the proper decimal point, but I don't think any value other than period or comma is possible, and if one of these are left as the last character in the string after having stripped all zeroes from the end, then it MUST be a decimal point.
Also note, that this code assumes that strings are indexed with 1 for the first character, as it always is in Delphi 7. If you need this code for the mobile compilers in newer Delphi versions, you'll need to update the code. I'll leave that exercise up to the reader :-).
i use this function in my application:
function sclCurrencyND(Const F: Currency; GlobalDegit: word = 2): Currency;
var R: Real; Fact: Currency;
begin
Fact:= power(10, GlobalDegit);
Result:= int(F*Fact)/Fact;
end;

Wrong value calculated by Delphi

I have a record declared as
T3DVector = record
X,Y,Z: Integer;
end;
One variable V of type T3DVector holds:
V.X= -25052
V.Y= 34165
V.Z= 37730
I then try to the following line. D is declared as Double.
D:= (V.X*V.X) + (V.Y*V.Y) + (V.Z*V.Z);
The return value is: -1076564467 (0xFFFFFFFFBFD4EE0D)
The following code should be equivalent:
D:= (V.X*V.X);
D:= D + (V.Y*V.Y);
D:= D + (V.Z*V.Z);
But this,however, returns 3218402829 (0x00000000BFD4EE0D), which actually is the correct value.
By looking at the high bits, I thought this was an overflow problem. When I turned on overflow checking, the first line halted with the exception "Integer overflow". This is even more confusing to me because D is Double, and I am only storing values into D
Can anyone clarify please ?
The target of an assignment statement has no bearing on how the right side is evaluated. On the right side, all you have are of type Integer, so the expression is evaluated as that type.
If you want the right side evaluated as some other type, then at least one operand must have that type. You witnessed this when you broke the statement into multiple steps, incorporating D into the right side of the expression. The value of V.Y * V.Y is still evaluated as type Integer, but the result is promoted to have type Double so that it matches the type of the other operand in the addition term (D).
The fact that D is a double doesn't affect the type of X, Y and Z. Those are Integers, and are apparently not large enough to store the squares of such large numbers, and their multiplication is what overflows. Why don't you declare them as doubles, too?

Big number and lost of precision

I do this operation and I want result without exponents :
main(){
var result = ((1.1+2)+3.14+4+(5+6+7)+(8+9+10)*4267387833344334647677634)/2*553344300034334349999000;
print(result); // With exponent
print(result.toInt()); // Full number ?
}
And it print
3.18780189038289e+49
31878018903828901761984975061078744643351263313920
But the toInt() result is wrong, the good result is 31878018903828899277492024491376690701584023926880 . It check it with groovy (web) console.
How can I do to have my int full number ?
As in result there are double literals, the result type is double.
In Dart a double is a :
64-bit (double-precision) floating-point numbers, as specified by the IEEE 754 standard
This is why you lose precision.
You can see the lost of precision with the following code :
final bignum = 31878018903828899277492024491376690701584023926880;
print(bignum);
// displays 31878018903828899277492024491376690701584023926880
print(bignum.toDouble().toInt());
// displays 31878018903828901761984975061078744643351263313920
This lost of precision is not specific to Dart, for instance 31878018903828899277492024491376690701584023926880.0 and 31878018903828901761984975061078744643351263313920.0 are equal in Java.
The groovy web console gives you the right result because AFAICT groovy literals with decimal points are instantiated as java.math.BigDecimal by default.
Finally there is an open issue on Decimal data type you can star and until decimals are natively supported, you can use my decimal package;

Objective C ceil returns wrong value

NSLog(#"CEIL %f",ceil(2/3));
should return 1. However, it shows:
CEIL 0.000000
Why and how to fix that problem? I use ceil([myNSArray count]/3) and it returns 0 when array count is 2.
The same rules as C apply: 2 and 3 are ints, so 2/3 is an integer divide. Integer division truncates so 2/3 produces the integer 0. That integer 0 will then be cast to a double precision float for the call to ceil, but ceil(0) is 0.
Changing the code to:
NSLog(#"CEIL %f",ceil(2.0/3.0));
Will display the result you're expecting. Adding the decimal point causes the constants to be recognised as double precision floating point numbers (and 2.0f is how you'd type a single precision floating point number).
Maudicus' solution works because (float)2/3 casts the integer 2 to a float and C's promotion rules mean that it'll promote the denominator to floating point in order to divide a floating point number by an integer, giving a floating point result.
So, your current statement ceil([myNSArray count]/3) should be changed to either:
([myNSArray count] + 2)/3 // no floating point involved
Or:
ceil((float)[myNSArray count]/3) // arguably more explicit
2/3 evaluates to 0 unless you cast it to a float.
So, you have to be careful with your values being turned to int's before you want.
float decValue = (float) 2/3;
NSLog(#"CEIL %f",ceil(decValue));
==>
CEIL 1.000000
For you array example
float decValue = (float) [myNSArray count]/3;
NSLog(#"CEIL %f",ceil(decValue));
It probably evaluates 2 and 3 as integers (as they are, obviously), evaluates the result (which is 0), and then converts it to float or double (which is also 0.00000). The easiest way to fix it is to type either 2.0f/3, 2/3.0f, or 2.0f/3.0f, (or without "f" if you wish, whatever you like more ;) ).
Hope it helps

Set a Currency value to NAN, INF or -INF?

i want to test some code to make sure it handles NAN, INF and -INF inputs properly.
i know there exists functions that return NAN, INF and -INF, but as a Double:
unit IEEE754;
...
function NAN: Double;
function PositiveInfinity: Double;
function NegativeInfinity: Double;
Except in my case i need to test when a Currency is one of these three edge-case values. Unfortunatly you cannot convert any of these to a Double:
Test(NAN);
procedure Test(const Value: Currency);
...
There's an EInvalidOp Invalid floating point operation exception when converting a Double NAN to a Currency.
Is it possible to assign a NAN to a Currency?
Perhaps, rather than it being possible to assign a NAN to a Currency, it is instead not possible - and i can just ignore this edge case.
Can i ignore this edge case?
Is it possible to "Set a Currency value to NAN, INF or -INF?"
{ David Heffernan says it's impossible for a currency to contain INF,-INF or NAN.
So there's no need to test for it.
http://stackoverflow.com/questions/7096966/set-a-currency-value-to-nan-inf-or-inf
//Handle NaN, where exponent is -32767
test(NAN, 'NAN');
//Handle +inf, where exponent is 32767 and Negative is true
test(PositiveInfinity, 'INF');
//Handle -inf, where expondent is 32767 and Negative is true
test(NegativeInfinity, '-INF');
}
Currency is not an IEEE754 float type and does not have NAN or INF values.
The documentation explains that Currency is implemented as a 64 bit integer with implicit scale of 10000 and that the range of possible values is -922337203685477.5808 to 922337203685477.5807. Since this covers the full range of a 64 bit integer it follows that there are no bit patterns available for sentinel values like NAN or INF.

Resources