View Issue Details

IDProjectCategoryView StatusLast Update
0036870FPCRTLpublic2020-04-13 13:33
ReporterErik Rößiger Assigned ToFlorian  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.3.1 
Fixed in Version3.3.1 
Summary0036870: Math unit: MaxSingle is not precisely the maximum positive single point float
DescriptionIn the Math unit of FPC, MaxSingle is defined as follows (line 75):

MaxSingle = 3.4e+38;

Assigning this value to any Single variable outputs the following hexadecimal representation: $7F7F C99E
However, the correct maximum single point precision is defined as $7F7F FFFF.

MaxSingle should be changed to this:

MaxSingle = Single(3.402823466E+38);

The output hexadecimal representation of it gives exactly $7F7F FFFF.
Note the Single() cast, else it will be treated incorrectly.
TagsNo tags attached.
Fixed in Revision44714
FPCOldBugId
FPCTarget-
Attached Files

Activities

Florian

2020-04-11 17:11

administrator   ~0122078

I guess it's due to delphi compability and as it has the value for years now, I propose not to change it and if needed, introduce a new constant for the correct value.

Sven Barth

2020-04-11 19:03

manager   ~0122082

At least in Delphi 10.2 the following code:

var
  s: Single;
  d: Double;
begin
  s := MaxSingle;
  d := MaxDouble;
  Writeln(IntToHex(PLongInt(@s)^, 8));
  Writeln(IntToHex(PInt64(@d)^, 16));
  s := MinSingle;
  d := MinDouble;
  Writeln(IntToHex(PLongInt(@s)^, 8));
  Writeln(IntToHex(PInt64(@d)^, 16));
end.


will print:

7F7FFFFF
7FEFFFFFFFFFFFFF
00800000
0010000000000000


Don't know about older Delphi versions...

Bart Broersma

2020-04-11 23:58

reporter   ~0122087

Delphi 7:
7F7FC99E
7FEE42D130773B76
00000001
0000000000000001

Florian

2020-04-13 10:50

administrator   ~0122112

Fixed, see also https://wiki.freepascal.org/User_Changes_Trunk#Math_Min.2FMaxSingle.2FDouble

Erik Rößiger

2020-04-13 12:06

reporter   ~0122113

Last edited: 2020-04-13 12:16

View 4 revisions

Since constant numbers as such are always taken as Real type, it would be better to have the constant defined with the respective type cast. In the case of MaxSingle that would be:
    MaxSingle = Single(3.402823466E+38);
Else the constant will be rounded differently than it would be for a Single.

What for? If I do use MaxSingle without the explicit typecast to directly to compare it with another Singl, it would always fail the comparison
    someMaxSingleVar = MaxSingle -> False
With the current fix/implementation the numeric value may be correct, but to get the correct bitmask as a Single I must still explicitely typecast it, or assing it to a Single variable beforehand.
    someMaxSingleVar = Single(MaxSingle) -> True
But since it is meant to represent MaxSingle, I expect it to already match precisely Single, and not a Real type. The name does suggest it already.
Same goes for the Double.

Florian

2020-04-13 13:33

administrator   ~0122119

While I understand the reasoning, I think it is too invasive to change the type of the constants. I thought about this but decided against doing so.

Issue History

Date Modified Username Field Change
2020-04-04 12:41 Erik Rößiger New Issue
2020-04-11 17:11 Florian Note Added: 0122078
2020-04-11 19:03 Sven Barth Note Added: 0122082
2020-04-11 23:58 Bart Broersma Note Added: 0122087
2020-04-13 10:50 Florian Assigned To => Florian
2020-04-13 10:50 Florian Status new => resolved
2020-04-13 10:50 Florian Resolution open => fixed
2020-04-13 10:50 Florian Fixed in Version => 3.3.1
2020-04-13 10:50 Florian Fixed in Revision => 44714
2020-04-13 10:50 Florian FPCTarget => -
2020-04-13 10:50 Florian Note Added: 0122112
2020-04-13 12:06 Erik Rößiger Status resolved => feedback
2020-04-13 12:06 Erik Rößiger Resolution fixed => reopened
2020-04-13 12:06 Erik Rößiger Note Added: 0122113
2020-04-13 12:07 Erik Rößiger Note Edited: 0122113 View Revisions
2020-04-13 12:13 Erik Rößiger Note Edited: 0122113 View Revisions
2020-04-13 12:16 Erik Rößiger Note Edited: 0122113 View Revisions
2020-04-13 13:33 Florian Status feedback => resolved
2020-04-13 13:33 Florian Resolution reopened => fixed
2020-04-13 13:33 Florian Note Added: 0122119