1

Topic: float <-> bigint (ieee-754)

2

Re: float <-> bigint (ieee-754)

Hello, _hum _, you wrote: __> For cross-platform portability it is necessary to use conversion of real numbers in the whole. For this purpose I use code Beej Jorgensen: __> All is good, but it would be desirable to accelerate operation on platforms where there is a built in support ieee-754. __> Somebody similar somewhere met? Do not share references? Very much I advise to understand as as does the code quoted by you, instead of it is thoughtless it  in the project smile (And about that this code irregularly processes some frequent situations, too it it is necessary to read and consider the remark) And on a platform with support ieee-754 it is possible to replace it such: float f = 3.1415926; double d = 3.14159265358979323; uint32_t fi; uint64_t di; memcpy (&fi, &f, sizeof (f)); memcpy (&di, &d, sizeof (d)); (well with all a darkness stipulations about memcpy and orders bit/byte from specified article)

3

Re: float <-> bigint (ieee-754)

Hello, watchmaker, you wrote: W> Hello, _hum _, you wrote: __>> For cross-platform portability it is necessary to use conversion of real numbers in the whole. For this purpose I use code Beej Jorgensen: __>> All is good, but it would be desirable to accelerate operation on platforms where there is a built in support ieee-754. __>> Somebody similar somewhere met? Do not share references? W> very much I advise to understand as as does the code quoted by you, instead of it is thoughtless it  in the project W> (And about that this code irregularly processes some frequent situations, too it it is necessary to read and consider the remark) understand, in such things a heap of nuances therefore even if as a whole it is clear, and you will start to rewrite itself - all the same you will waste time on debugging. As a result - to take already debugged code more effectively. W> and on a platform with support ieee-754 it is possible to replace it such: W> float f = 3.1415926; W> double d = 3.14159265358979323; W> uint32_t fi; W> uint64_t di; W> memcpy (&fi, &f, sizeof (f)); W> memcpy (&di, &d, sizeof (d)); W> (well with all a darkness stipulations about memcpy and orders bit/byte from specified article) here somehow I did not find acknowledgement to that the order of layout of bits of a sign, a mantissa and the order always fixed (besides endian) that is why such approach not seems reliable. + even with function of determination of support ieee-754 nuances any too are, therefore direct recording - brave business. It would be more safe to use all the same access intrinsic functions to a mantissa and the order (they in themselves would define everything that is necessary).

4

Re: float <-> bigint (ieee-754)

Hello, _hum _, you wrote: __> understand, in such things a heap of nuances therefore even if as a whole it is clear, and you will start to rewrite itself - all the same you will waste time on debugging. As a result - to take already debugged code more effectively. Therefore it is simple type variants (int64_t) dval even more reliably. Not clearly, why them not to apply directly. And the source code frankly stupid - same should to be used, for example, CLZ where it is... W>> And on a platform with support ieee-754 it is possible to replace it such: W>> float f = 3.1415926; W>> double d = 3.14159265358979323; W>> uint32_t fi; W>> uint64_t di; W>> memcpy (&fi, &f, sizeof (f)); W>> memcpy (&di, &d, sizeof (d)); W>> (well with all a darkness stipulations about memcpy and orders bit/byte from specified article) __> here somehow I did not find acknowledgement to that the order of layout of bits of a sign, a mantissa and the order always fixed (besides endian) that is why such approach not seems reliable. The fixed. For IEEE754. __> even with function of determination of support ieee-754 nuances any too are I Think, it should be set depending on platform determination. Auto detection can work, but it is necessary to write it.

5

Re: float <-> bigint (ieee-754)

Hello, netch80, you wrote: N> Hello, _hum _, you wrote: __>> understand, in such things a heap of nuances therefore even if as a whole it is clear, and you will start to rewrite itself - all the same you will waste time on debugging. As a result - to take already debugged code more effectively. N> therefore it is simple type variants (int64_t) dval even more reliably. Not clearly, why them not to apply directly. Not absolutely understood that you meant. N> and the source code frankly stupid - same it is necessary not to use, for example, CLZ where it is... As far as I understand, possibility to use CLZ not everywhere is. And the code was written the multiplatform. And why all the same not to use std:: logb, std:: scalbn, std:: frexp? W>>> And on a platform with support ieee-754 it is possible to replace it such: W>>> float f = 3.1415926; W>>> double d = 3.14159265358979323; W>>> uint32_t fi; W>>> uint64_t di; W>>> memcpy (&fi, &f, sizeof (f)); W>>> memcpy (&di, &d, sizeof (d)); W>>> (well with all a darkness stipulations about memcpy and orders bit/byte from specified article) __>> here somehow I did not find acknowledgement to that the order of layout of bits of a sign, a mantissa and the order always fixed (besides endian) that is why such approach not seems reliable. N> fixed. For IEEE754. Well so I also say that did not find, that at its description was told directly about  a sequence. __>> even with function of determination of support ieee-754 nuances any too are N> I Think, it should be set depending on platform determination. N> auto detection can work, but it is necessary to write it. And it again nuances. Therefore it would be desirable to take already ready code. Really anybody with such problems did not face?

6

Re: float <-> bigint (ieee-754)

Hello, _hum _, you wrote: __> as a result - to take already debugged code more effectively. Aha, sensible thought. __> understand, in such things a heap of nuances therefore even if as a whole it is clear, And because of it especially is amazing that you take the code about which even its author writes that it does not consider this most "a heap of nuances" smile

7

Re: float <-> bigint (ieee-754)

Hello, watchmaker, you wrote: W> Hello, _hum _, you wrote: __>> understand, in such things a heap of nuances therefore even if as a whole it is clear, W> And because of it especially is amazing that you take the code about which even its author writes that it does not consider this most "a heap of nuances" there other plan nuances - type the registration of storage qNaN, sNaN,  and so forth for me these nuances are unimportant, because at me, it is considered, such things do not meet.

8

Re: float <-> bigint (ieee-754)

Hello, _hum _, you wrote: N>> Therefore it is simple type variants (int64_t) dval even more reliably. Not clearly, why them not to apply directly. __> not absolutely understood that you meant. In language there is a conversion in the whole. Than it does not approach? N>> and the source code frankly stupid - same it is necessary not to use, for example, CLZ where it is... __> as far as I understand, possibility to use CLZ not everywhere is. And the code was written the multiplatform. And why all the same not to use std:: logb, std:: scalbn, std:: frexp? Perhaps because the code very ancient? These functions are irrespective of IEEE754. __>>> here somehow I did not find acknowledgement to that the order of layout of bits of a sign, a mantissa and the order always fixed (besides endian) that is why such approach not seems reliable. N>> fixed. For IEEE754. __> well so I also say that did not find, that at its description was told directly about  a sequence. In the standard it is written about fixity. Here opened and I read. Sign - MSB, exponent - after it, significand - includes LSB, all continuous.  record in storage in BE/LE/PDP-endian/etc is., but I did not see, that was differently, than the whole are written. __>>> even with function of determination of support ieee-754 nuances any too are N>> I Think, it should be set depending on platform determination. N>> auto detection can work, but it is necessary to write it. __> and it again nuances. Therefore it would be desirable to take already ready code. Really anybody with such problems did not face? Faced. Look glibc. There it is difficult and , but an essence that they define on a target platform that at it (BE/LE, IEEE754 or other...) It is possible to adjust at desire.

9

Re: float <-> bigint (ieee-754)

Hello, netch80, you wrote: N> Hello, _hum _, you wrote: N>>> Therefore it is simple type variants (int64_t) dval even more reliably. Not clearly, why them not to apply directly. __>> not absolutely understood that you meant. N> in language there is a conversion in the whole. Than it does not approach? , you meant it. Then probably, yes provided that the standard guarantees the order of layout of components of number, and that endian at corresponding multi-byte same, as at any others. N>>> and the source code frankly stupid - same it is necessary not to use, for example, CLZ where it is... __>> as far as I understand, possibility to use CLZ not everywhere is. And the code was written the multiplatform. And why all the same not to use std:: logb, std:: scalbn, std:: frexp? N> Perhaps because the code very ancient? These functions are irrespective of IEEE754. So and new you anywhere did not meet? __>>>> here somehow I did not find acknowledgement to that the order of layout of bits of a sign, a mantissa and the order always fixed (besides endian) that is why such approach not seems reliable. N>>> fixed. For IEEE754. __>> well so I also say that did not find, that at its description was told directly about  a sequence. N> in the standard it is written about fixity. Here opened and I read. Sign - MSB, exponent - after it, significand - includes LSB, all continuous. N> Platformennozavisimym is record in storage in BE/LE/PDP-endian/etc., but I did not see, that was differently, than the whole are written. That did not see, does not mean that cannot be __>>>> even with function of determination of support ieee-754 nuances any too is N>>> I Think, it should be set depending on platform determination. N>>> auto detection can work, but it is necessary to write it. __>> and it again nuances. Therefore it would be desirable to take already ready code. Really anybody with such problems did not face? N> Faced. Look glibc. There it is difficult and , but an essence that they define on a target platform that at it (BE/LE, IEEE754 or other...) It is possible to adjust at desire. Thanks, but I meant ready converters, instead of functions of determination of support of the standard by a platform

10

Re: float <-> bigint (ieee-754)

Hello, _hum _, you wrote: N>> In language there is a conversion in the whole. Than it does not approach? __> , you meant it. Then probably, yes provided that the standard guarantees the order of layout of components of number, and that endian at corresponding multi-byte same, as at any others. ... At what here endian and the order byte generally??? In a C, a C ++ it is possible floating to convert in whole, this operation mandatory is in language and is fulfilled in standard and normally enough effective image. Not bit-by-bit, namely on sense of value. Here I also ask - than it is not necessary? N>>>> And the source code frankly stupid - same it is necessary not to use, for example, CLZ where it is... __>>> as far as I understand, possibility to use CLZ not everywhere is. And the code was written the multiplatform. And why all the same not to use std:: logb, std:: scalbn, std:: frexp? N>> Perhaps because the code very ancient? These functions are irrespective of IEEE754. __> so and new you anywhere did not meet? Met. For example, here completely  implementation floating, actual and effective, and also under the liberal license. But there conversion to whole, and frexp I there do not remember everyones, behind them walk in everyones libc. BSD, GNU - already on conditions. N>> in the standard it is written about fixity. Here opened and I read. Sign - MSB, exponent - after it, significand - includes LSB, all continuous. N>> Platformennozavisimym is record in storage in BE/LE/PDP-endian/etc., but I did not see, that was differently, than the whole are written. __> that did not see, does not mean that cannot be On "somewhere can be absolutely differently" practically do not calculate, do not come across yet. Generally there are two typical approaches to . One - for each platform should be a config file and if it is not present - we wash hands;  itself checks on a place and though the word of honor, but guarantees result. The second -  automatically on a place everything that we can, and if somewhere were mistaken - to us tell, and then we finish. You try to go under the first approach? It too a method, without irony. But here authors autotools, for example, write under the second. __>>>>> even with function of determination of support ieee-754 nuances any too are N>>>> I Think, it should be set depending on platform determination. N>>>> auto detection can work, but it is necessary to write it. __>>> and it again nuances. Therefore it would be desirable to take already ready code. Really anybody with such problems did not face? N>> Faced. Look glibc. There it is difficult and , but an essence that they define on a target platform that at it (BE/LE, IEEE754 or other...) It is possible to adjust at desire. __> thanks, but I meant ready converters, instead of functions of determination of support of the standard by a platform Well as already told - behind type operations "to transform  in whole" it behind softfloat-libraries. At  conversion in all whole it source/f $ {ibits} _to _ {i, ui} $ {obits}.c. But they behind themselves pull rounding off functions, jamming shift, etc., it is possible to collect simply all library

11

Re: float <-> bigint (ieee-754)

Hello, netch80, you wrote: N> Hello, _hum _, you wrote: N>>> In language there is a conversion in the whole. Than it does not approach? __>> , you meant it. Then probably, yes provided that the standard guarantees the order of layout of components of number, and that endian at corresponding multi-byte same, as at any others. N> Eee... At what here endian and the order byte generally??? In a C, a C ++ it is possible floating to convert in whole, this operation mandatory is in language and is fulfilled in standard and normally enough effective image. N> not bit-by-bit, namely on sense of value. N> here I also ask - than it is not necessary? Mm... You speak about reinterpret_cast from  in the whole? Type float a = 1; long i = reinterpret_cast <long> (a); unless it is resolved directly? And  unless it will not have problems with strict aliasing semantics? N>>>>> and the source code frankly stupid - same it is necessary not to use, for example, CLZ where it is. . __>>>> as far as I understand, possibility to use CLZ not everywhere is. And the code was written the multiplatform. And why all the same not to use std:: logb, std:: scalbn, std:: frexp? N>>> Perhaps because the code very ancient? These functions are irrespective of IEEE754. __>> so and new you anywhere did not meet? N> met. For example, here completely  implementation floating, actual and effective, and also under the liberal license. But there conversion to whole, and frexp I there do not remember everyones, behind them walk in everyones libc. BSD, GNU - already on conditions. Thanks. But I so understand, it again , instead of with ++. N>>> In the standard it is written about fixity. Here opened and I read. Sign - MSB, exponent - after it, significand - includes LSB, all continuous. N>>> Platformennozavisimym is record in storage in BE/LE/PDP-endian/etc., but I did not see, that was differently, than the whole are written. __>> that did not see, does not mean that cannot be N> On "somewhere can be absolutely differently" practically do not calculate, do not come across yet. Generally there are two typical approaches to . One - for each platform should be a config file and if it is not present - we wash hands;  itself checks on a place and though the word of honor, but guarantees result. The second -  automatically on a place everything that we can, and if somewhere were mistaken - to us tell, and then we finish. You try to go under the first approach? It too a method, without irony. But here authors autotools, for example, write under the second. No, I just want - to use on the second for a maximum standard means of language, on a minimum -  "as on this or that platform to make that or another". To detect support I too I want or standard means of type std:: numeric_limits <type>:: : is_iec559, or relying on  these things with the functions working with floating numbers, type std:: logb, std:: scalbn, std:: frexp.

12

Re: float <-> bigint (ieee-754)

Hello, _hum _, you wrote: I it would rewrite all with usage old kind ldexp/frexp instead of normalization cycles to twist. Well or, if you do not potter with something  Atmel ARM,  representation in the network order byte.

13

Re: float <-> bigint (ieee-754)

Hello, _hum _, you wrote: __> mm... You speak about reinterpret_cast from  in the whole? Type I, apparently, understood. You try to generate number which would be bit representation in the spirit of IEEE754, but  in a type variable int or long. So? If yes, the term "conversion" forced down  with sense (and in that  the code I did not get a grasp so deeply). If yes, reinterpret_cast does not work, absolutely. And here that works is banal memcpy. For more or less modern compilers (gcc> = 4.6, clang> = 3.x) it is the best variant. Certainly, provided that IEEE754 (it is fulfilled, roughly speaking, on 99.99 % of the modern platforms) and the order byte at the whole and real is identical (BE or LE - is fulfilled on 100 %). Anyway it can be tested in real, or at program compilation, or causing it in a test mode, or separate start of units-tests is already to taste. To pick up some the characteristic extreme values (plus-minus a zero, two, minimum and maximum normalized, inf/nan) and to compare bit exhausts. __> unless it is resolved directly? And  unless it will not have problems with strict aliasing semantics? strict aliasing - problems will not be. But problems will be that it simply will not be compiled. It is necessary bit_cast. While it is not present in the standard - memcpy (for described above), through the general union (for older or for ICC; though memcpy too works, was ineffectively, but works). N>> Met. For example, here completely  implementation floating, actual and effective, and also under the liberal license. But there conversion to whole, and frexp I there do not remember everyones, behind them walk in everyones libc. BSD, GNU - already on conditions. __> thanks. But I so understand, it again , instead of with ++. Also what? It is effectively compiled and works. __> is not present, I just want - to use on the second for a maximum standard means of language, on a minimum -  "as on this or that platform to make that or another". To detect support I too I want or standard means of type std:: numeric_limits <type>:: is_iec559, or relying on  these things with the functions working with floating numbers, type std:: logb, std:: scalbn, std:: frexp. As fallback to use such - ok, forward. But as the core - I do not see sense if means for> 99 % of platforms are identical and work.