Careful with the floats

Help!
1

Its seems that SWI-Prolog and Python have different ideas about floats:

/* Python: https://www.python.org/shell/ */
>>> int(float(30000000000000000000000000))
30000000000000000570425344
>>> int(30000000000000000000000000+0.0)
30000000000000000570425344

/* SWI-Prolog: https://swish.swi-prolog.org/ */
?- X is integer(float(30000000000000000000000000)).
X = 29999999999999996275458048
?- X is integer(30000000000000000000000000+0.0).
X = 29999999999999996275458048
3 Likes
2

This is related to GMP - when converting a GMP integer to a float, the float is apparently always rounded towards zero, even if rounding away from zero would give a closer result. There was an issue about this previously, and it has apparently been fixed for all rounding modes except nearest, which is the default :frowning:

2 Likes
4

Yes, CPython has always used its own custom bigint implementation:

5

And this is why we let client code decide how it wants to handle numbers outside of native-representation ranges :slight_smile:

6

If you use Google protobufs, then you get 64-bit floats and max 64-bit ints.
(Not saying that’s a good choice, but it’s what you get with things like gRPC … I don’t know how widespread it is compared to JSON-oriented RPC)

8

Apologies, I meant “pointer-sized integer”. The point stands.

10

No, I mean pointer-sized. 32-bit code should not be expected to have to deal with 64-bit-large integers and should be able to opt in.

12

I was specifically referring to the Prolog inter-language JSON format from the other thread. If I were making a generic JSON-based communications protocol, I wouldn’t represent anything larger than a signed 32-bit int using JSON-native numbers.

13

(from other thread)

Not gonna continue the discussion on the other thread, it’s beginning to veer off-topic. Yes, I was mistaken about the JS sizes - I was speaking off-the-cuff, I just generally think of JS as not being safe for full 64-bit rep, since that’s a major issue in WebAssembly interop.

15

And if we’re talking about the inter-language JSON interface from the other thread in specific, and not a generic communications protocol, they’re almost certainly going to be using a 64-bit build of swipl, which means that anything 64 bits or below can be represented as native JSON.

(When I say “JSON-native number” I’m not describing the bits but the representation.)

16

Oh btw @j4n_bur53, are you aware you have messaging disabled? I tried to continue the discussion on the other thread in a DM, but it wouldn’t let me send the message.

18

Oh interesting! I hadn’t heard about that.