IsInfinity test for Real Type?

[ad1mt]

Is there an IsInfinity test or some other way of detecting overflow for Real Type?

The reason I'm asking is because on 64bit Raspberry Pi, there are problems detecting overflow on the real type, and I'm looking for a workaround.

[Warfley]

Yes

That overflow on floats is quite weird and should basically not happen. What are you doing in your program?

[Thaddy]

The reason I'm asking is because on 64bit Raspberry Pi, there are problems detecting overflow on the real type, and I'm looking for a workaround.

Can you give me an example, because I can't easily reproduce it on 64bit (AARCH64) pies.. And I always have a couple open.
@Warfley it is specific to AARCH64 and weird floating point results were quite common, it is just that I did not encounter them lately.
(It may be because I mask them out...)
https://www.freepascal.org/docs-html/rtl/math/setexceptionmask.html
Btw, for infinity I expect exUnderflow, not exOverflow. That is also for NaN, but I am not quite sure here.
Anyway, see what happens if you mask out both....SetExceptionMask should be your work-around.

If it is related to your last 4.82, I just downloaded that, so I can test.

[ad1mt]

Yes

That overflow on floats is quite weird and should basically not happen. What are you doing in your program?

The infinite test/function is only available for single, double and extended. But not for real type.

I am converting big integers to and from real types, in a platform independent way that will work in any environment. I need reliable trapping of overflow erors, because the big integer values can far exceed the capacity of any real type.

Unfortuately, I've found that FPU exceptions are unreliable on a 64bit Raspberry Pi running Lunix. 32bit Raspberry Pi works fine.

The Free Pascal documentation states that the real type is "platform dependent", so that might be part of the problem.

[Warfley]

The infinite test/function is only available for single, double and extended. But not for real type.

From the documentation: https://www.freepascal.org/docs-html/ref/refsu5.html

The Real native type is processor dependent, but it is either a Single or a Double.

So you can just call IsInfinity, and it will either call the Single or Double variant, depending on your platform.

I am converting big integers to and from real types, in a platform independent way that will work in any environment. I need reliable trapping of overflow erors, because the big integer values can far exceed the capacity of any real type.

I don't think that you are actually talking about overflow here, because Double, the largest Float type available on all systems (there are 80bit Extended, but they are platform dependent) has a maximum value of 1.7*10^308 meaning a value with 308 digits.
The problem you probably have is rather than that imprecision, because as soon as your number has more bits (which are not a 0 tail) than the float mantissa size (23 bit for single, 52 bit for double), you will lose precision on conversion.
But this is easy to figure out:

Code: Pascal  [Select][+][-]

1. function CheckIfBigintFitsReal(AInt: TBigInteger): Boolean; inline;
2. const
3.   { Either 24 if Real = Single, or 53 if Real = Double (0 if neither) }
4.   RealBits = 24*(SizeOf(Real)=SizeOf(Single)) + 53*(SizeOf(Real)=SizeOf(Double));
5. begin
6.   Result:=AInt>=(1 shl RealBits);
7. end;

But my question is, if you are dealing with bigintegers, why do you want to convert them into floats to begin with? Floats aren't really good if you need precise computations

The Free Pascal documentation states that the real type is "platform dependent", so that might be part of the problem.

Yes, Real is an relic you shouldn't use it anymore. Use Double or Extended instead.

[Thaddy]

There is the real48utils unit? But yes, use double instead for most platforms. The real48utils unit is merely a bandage to support old code.
And, as I wrote before, on AARCH64 you probably need to mask some exceptions and handle infinity and NaN in code.
You did not show an example that fails on aarch64 yet...(be it a Pi or Apple M series).
With a good example I can test.