# Get floating point representation in memory **URL:** \ **Category:** Predicate\ **Created:** [March 11, 2020, 3:21am UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992 "2020-03-11T03:21:38Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![swi](https://avatars.discourse-cdn.com/v4/letter/s/51bf81/32.png) [@swi](https://swi-prolog.discourse.group/u/swi)\ **Post date:** [March 11, 2020, 3:21am UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/1 "2020-03-11T03:21:38Z")
Anyone know how to get the exact binary representation of the floating point number in memory, as an integer? For example ```prolog float_memory(0.6,Int), format('~2r',[Int]). ``` would print: ```prolog 0_0111_1110__0011_0011_0011_0011_0011_010 ``` (the underscores (’\_’) are added only to make it easier to read) ---
**Author:** ![Boris](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/boris/32/7486_2.png) [@Boris](https://swi-prolog.discourse.group/u/Boris)\ **Post date:** [March 11, 2020, 7:17am UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/2 "2020-03-11T07:17:12Z")
Until someone else corrects me: The only important question is why? If we forget about the only important question, it seems that the easy way would be to write it in C. The predicate should most probably return the sign, exponent and fraction separately? I also suspect that since the representation in memory might be architecture-dependent, there will be some trickery involved. Which again makes me wonder, why? I might be wrong but I think that SWI-Prolog uses only C `double` floats (so you’ll have a total of 64 bits, not 32). ---
**Author:** ![swi](https://avatars.discourse-cdn.com/v4/letter/s/51bf81/32.png) [@swi](https://swi-prolog.discourse.group/u/swi)\ **Post date:** [March 11, 2020, 9:37am UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/3 "2020-03-11T09:37:05Z")
Thanks Boris. > [@Boris](#): > > The predicate should most probably return the sign, exponent and fraction separately? Yes, that is correct. > [@Boris](#): > > I think that SWI-Prolog uses only C `double` floats double floats is fine. > [@Boris](#): > > The only important question is why? Certain equations involving logarithms can be simplified if a number is expressed as `significand*2^e`; and this is very similar to how floating point numbers are stored in memory in the IEEE-754 standard. UPDATE: to see why this is very useful, look [here](http://gallium.inria.fr/blog/fast-vectorizable-math-approx/). ---
**Author:** ![jamesnvc](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jamesnvc/32/14_2.png) [@jamesnvc](https://swi-prolog.discourse.group/u/jamesnvc)\ **Post date:** [March 11, 2020, 2:10pm UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/4 "2020-03-11T14:10:54Z")
I have some code from my [Msgpack implementation](https://github.com/jamesnvc/msgpack/blob/01624c7ed5a70ff71182921cf3848b5857161fad/prolog/msgpack.pl#L199) that gets a byte representation of a float, which might be useful for you? ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [March 11, 2020, 2:51pm UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/5 "2020-03-11T14:51:07Z")
There is something similar in Jeff Rosenwald’s Google protocol buffer library that is bundled. That is nice for sending floats over a network. With the updates to float arithmetic we could consider adding a predicate that (dis)assembles a float into/from its three parts. No really sure how useful it is in the context of Prolog though. As long as you do arithmetic in Prolog the advantage disappears mostly with the Prolog overhead. If you push arithmetic down to C, LLVM, Cuda, etc. you go outside the Prolog world anyway and thus accessing the float bits is not a problem. I think that Prolog’s good support to facilitate domain specific languages should give a more prominent role in this area, but that still doesn’t answer why you’d want to have access to details from a float … ---
**Author:** ![swi](https://avatars.discourse-cdn.com/v4/letter/s/51bf81/32.png) [@swi](https://swi-prolog.discourse.group/u/swi)\ **Post date:** [March 11, 2020, 4:46pm UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/6 "2020-03-11T16:46:02Z")
> [@jan](#): > > With the updates to float arithmetic we could consider adding a predicate that (dis)assembles a float into/from its three parts. No really sure how useful it is in the context of Prolog though. It is extremely useful in Prolog, because Prolog can be used to derive new algorithms and equations which can then be implemented in C or something else (or the prolog code may output C code directly). I think this would be a good addition, since we already have predicates like `float_fractional_part/1`. > [@jan](#): > > That is nice for sending floats over a network. This would also be another very practical use for such a predicate. ---
**Author:** ![EricGT](https://avatars.discourse-cdn.com/v4/letter/e/f1d935/32.png) [@EricGT](https://swi-prolog.discourse.group/u/EricGT)\ **Post date:** [March 11, 2020, 5:00pm UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/7 "2020-03-11T17:00:36Z")
> [@swi](#): > > It is extremely useful in Prolog, because Prolog can be used to derive new algorithms and equations which can then be implemented in C or something else (or the Prolog code may output C code directly). I have to agree with SWI on this one. One way I think of Prolog is not as a programming language or even a Turing complete programming language but as a language used to research ideas because it is so much more versatile and is one of the few languages that is [homoiconic](https://en.wikipedia.org/wiki/Homoiconicity). Also because Prolog is much more friendly to creating [DSL](https://en.wikipedia.org/wiki/Domain-specific_language) with term rewriting and DCGs, it is one of the first languages I would turn to in order to create and validate a DSL. ---
**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\ **Post date:** [March 13, 2020, 2:28am UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/8 "2020-03-13T02:28:09Z")
Strawman proposal: New builtin arithmetic predicate: `float_value(?F, ?S^E)` At least one of the arguments must be ground, either `F` as a floating point number or `S^E` where `S` and `E` are signed integers. This is not a bit for bit representation of a float, but a slightly higher abstraction (exponent bias mapped to signed `E`, sign and implied significand bit included in `S`). Subnormals might be a bit tricky and we have to decide how to treat NaN’s and infinities. Would something like this satisfy requirements? Counter proposals? Bad idea? ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [March 13, 2020, 9:04am UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/9 "2020-03-13T09:04:55Z")
The C/C++ world has `double frexp(double x, int *exponent)`. I don’t really like the name, but float\_value seems strange as well as the value of a float is, well, the float itself 🙂 I think we also want the base, just to accommodate different bases for the future. So, we have some options - Add _functions_ mantissa, base and exponent - Add a predicate X(?F, ?Mantissa, ?Base, ?Exponent) - Add a predicate Y(?F, ?Mantissa\*Base^Exponent) The first has the big disadvantage that you typically want all three (or 2 if you merely assume the base is 2). The second is most efficient while the 3rd could almost be called float\_value/2 as the arithmetic value of the expressions are equivalent. X could be float\_mantissa\_base\_exp/4. It is a bit long, but it won’t conflict and is immediately clear what it means. Predicates don’t get faster by shortening their name 🙂 while I do not expect code calling this in a lot of places? I guess we can deal with NaN and Inf by copying this value to both the Mantissa and Exponent? ---
**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\ **Post date:** [March 13, 2020, 2:45pm UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/10 "2020-03-13T14:45:38Z")
Supporting base 2 isn’t a problem because it’s just a simple bit mask/copy, but arbitrary bases is more difficult and potentially involves rounding and all that that entails. For a builtin perhaps this should be limited to only bases that are native, i.e. currently 2. More flexible base conversion can be implemented in Prolog. Since `F is mantissa(F)*base(F)^exponent(F)` is true (for reconstructing floats), a purely functional solution is interesting. It allows you to do extraction and calculation (and reconstruction?) in the same `is` evaluation. (Also nicely short-circuits any predicate name discussions.) As suggested, for any float(F): ` inf is mantissa(inf), -inf is mantissa(-inf), nan is mantissa(nan)` `inf is exponent(inf), inf is exponent(-inf), nan is exponent(nan)` `2 is base(F)` (pending some new supported float format) Current `float_overflow` and `float_undefined` flags to control error/continuation value treatment for special values. ---
**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\ **Post date:** [March 13, 2020, 5:08pm UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/12 "2020-03-13T17:08:11Z")
Similar functionality; did you have any use case(s) in mind? Also did you have any particular reason to go with predicates as opposed arithmetic functions, and multi-predicates vs. a single one that produces all the pieces? ---
**Author:** ![swi](https://avatars.discourse-cdn.com/v4/letter/s/51bf81/32.png) [@swi](https://swi-prolog.discourse.group/u/swi)\ **Post date:** [March 13, 2020, 6:25pm UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/14 "2020-03-13T18:25:52Z")
> [@ridgeworks](#): > > For a builtin perhaps this should be limited to only bases that are native, i.e. currently 2. More flexible base conversion can be implemented in Prolog. This would be an acceptable compromise IMHO. > [@jan](#): > > - Add _functions_ mantissa, base and exponent > - Add a predicate X(?F, ?Mantissa, ?Base, ?Exponent) > - Add a predicate Y(?F, ?Mantissa\*Base^Exponent) The second one would be my preference because 1. As you point out, normally you need all three values 2. I don’t see any real value (and it is not as efficient) to express the mantissa/base/exponent as a compound term of the form `M*B^E` All in all, great suggestions! ---
**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\ **Post date:** [March 13, 2020, 8:42pm UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/15 "2020-03-13T20:42:47Z")
> [@anon95304481](#): > > there is no difference between unary evaluable functions and deterministic predicates with mode (+,-) and number arguments Nice. Any n arity predicate can be used as an n-1 arity function assuming the correct instantiation pattern. If I recall, Eclipse has the same model. ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [March 14, 2020, 11:40am UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/16 "2020-03-14T11:40:39Z")
> [@ridgeworks](#): > > As suggested, for any float(F): > ` inf is mantissa(inf), -inf is mantissa(-inf), nan is mantissa(nan)` > `inf is exponent(inf), inf is exponent(-inf), nan is exponent(nan)` > `2 is base(F)` (pending some new supported float format) I think that should be it, except we should name them float\_\* for consistency and possibly use radix rather than base? Which is more popular? ---
**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\ **Post date:** [March 14, 2020, 2:46pm UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/17 "2020-03-14T14:46:20Z")
> [@jan](#): > > I think that should be it, except we should name them float\_\* for consistency and possibly use radix rather than base? Which is more popular? For arithmetic functions I think `float_` is implied, but any predicate names should have the prefix. There’s also something to be said for shorter function names for constructing arithmetic expressions. But it may hinge on whether `F` can be a non-float numeric argument (converted to a float)? In this context, base and radix seem to be used almost interchangeably (from [IEEE 754 - Wikipedia](https://en.wikipedia.org/wiki/IEEE_754) " a base (also called _radix_ ) _b_ …". ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [March 14, 2020, 3:32pm UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/18 "2020-03-14T15:32:39Z")
> [@ridgeworks](#): > > I think `float_` is implied My main motivation is to be consistent with the ISO float\_fractional\_part/1 and float\_integer\_part/1 functions. This would also suggest \_part … Not sure I like that … ---
**Author:** ![swi](https://avatars.discourse-cdn.com/v4/letter/s/51bf81/32.png) [@swi](https://swi-prolog.discourse.group/u/swi)\ **Post date:** [March 14, 2020, 3:59pm UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/19 "2020-03-14T15:59:40Z")
I’ve been thinking that in order to allow these predicates to be used to produce novel algorithms that deal with the float’s memory representation directly in addition to the parts, we could add an extra argument called `Memory` (or something similar). for example: ```prolog float_parts(?F, ?Mantissa, ?Base, ?Exponent, ?Memory) ``` Where `Memory` is the exact memory representation as an `Integer`. This will allow potentially developed algorithms to deal directly with the memory representation (including bias, hidden bit, etc), in addition to the parts (i.e. mantissa, exponent and base). I could surmise that novel algorithms could be developing dealing directly with the memory representation and/or the parts, and it doesn’t cost much to add the extra argument. What do you think? **EDIT** : this exact memory representation is also very useful for implementing serialized bitstreams for network transmission/storage/etc ---
**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\ **Post date:** [March 16, 2020, 7:32pm UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/20 "2020-03-16T19:32:22Z")
If a predicate solution is favoured, is there any reason not to just use the foreign language API for this. Seems like 20 lines of C code would do the job. ---
**Author:** ![swi](https://avatars.discourse-cdn.com/v4/letter/s/51bf81/32.png) [@swi](https://swi-prolog.discourse.group/u/swi)\ **Post date:** [March 16, 2020, 8:45pm UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/21 "2020-03-16T20:45:24Z")
> [@ridgeworks](#): > > Seems like 20 lines of C code would do the job I would say precisely because it is only 20 lines of C code, it should be part of the bultin functionality. The reason is this: The barrier of entry for some mathematician/scientist/physicist who is experimenting with this kind of algorithm in Prolog is not the 20 lines of C code, but having to learn about the FFI API of SWI-Prolog (not to mention the added learning curve of packaging and distributing `.so` files with add-ons). Providing this predicate will eliminate this barrier of entry, and it is not very difficult to provide. I really don’t mind if it is a predicate or a function. ---
**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\ **Post date:** [March 16, 2020, 10:02pm UTC](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992/23 "2020-03-16T22:02:01Z")
> [@swi](#): > > I would say precisely because it is only 20 lines of C code, it should be part of the bultin functionality. And I probably would have said the same thing a month ago, but I don’t think it’s that big a deal, particularly for someone who’s into bit-smashing the internals of floating point numbers. (And this coming from someone with novice-level C skills.) Not my place to say, but if everything that could be done in 20 lines of C were to become a builtin, it would be an even bigger barrier to entry. Prototyping this as a foreign language predicate would be a useful first step in demonstrating its value as a potential builtin. I can’t argue that there aren’t longer term issues with packaging and distribution, but I don’t think we’re there yet. [Next page](https://swi-prolog.discourse.group/t/get-floating-point-representation-in-memory/1992.md?page=2)