Oddly enough I got an issue with float this week, 2 systems are communicating by transmitting float (rather needlessly I would add) and the conversion from float seems to be implemented differently on both systems, resulting in discrepancy sometimes.
This is kind of textbook example of an obvious bug but still surprising when you find it.
Even without conversions floats cause problems. Several years back I was working on a SQL query transpiler, and was getting driven up the wall trying to explain why compiling query 6 from the TPC-H benchmark on some of our backends would agree with Postgres, and disagree on others. Worse, it worked perfectly on the OCaml backend, we used for debugging, but broke on our performance-focused C++ backend.
I must have torn my hair out for nearly a week, but the culprit turned out to be TPC-H's defaults including a subtle and very hidden test for floating point numbers. Q6, with default values plugged in includes the bit:
WHERE l_discount < 0.06+0.01
In the C++ backend (with a standard `float` iirc), 0.06+0.01 != 0.07, and the query result ended up wrong.
Fun times. (I now occasionally toss Q6 in as a test query for my database class. Definitely teaches proper respect for floating point arithmetic :D)
I do not understand what you mean. If you "convert" a float to a float it shouldn't change anything? As long as you keep to floats there should be no problem.
I do not understand why would you ever round trip floats through text. That seems useless? In any case, if you really want to do that then you use a hexadecimal float representation (like C's printf has had the "%a" conversion since forever) , or simply print out the bytes. Representing a float in decimal is absolutely idiotic and the people who commit this atrocity and get into trouble for that have it coming.
> I do not understand why would you ever round trip floats through text.
There are many, many occasions in the real world where this is necessary ... I've dealt with it multiple times. When done carefully and with appropriate knowledge of the underlying systems it's not a problem.
But just because you've never done, that doesn't mean it's the wrong thing to be doing.
> if you really want to do that then you use a hexadecimal float representation
There are combinations of systems where that won't work.
Sometimes when two machines talk to each other there is no reliable way to do so in binary. Different endianness, different internal representation of floats, and so forth.
So converting floats can sometimes be necessary, and that's what we're talking about. Going via human readable text is only one specific example.
> Different endianness, different internal representation of floats, and so forth.
But this has nothing at all to do with floats. If you transmit 16 or 32 bit ints, or any image/video/sound datatype, or even raw bytes, there can be endianness shenanigans. Introducing endianness when talking about floating point numbers is completely offtopic.
It has everything to do with internal representation of data in general, and floats are one specific example that turns up quite regularly. Sometimes one machine has some data, and you need to transfer that to another machine. Sometimes the internal representation of that data will be different. Sometimes you can't simply "send the bits" and have it work.
So in those cases you need to go through an intermediate representation, and then the question of conversion arises.
So sometimes, when sending a float (as a single example) from one machine to another, you have to go through conversions, and one way to do that is to generate a string representation. The point here and in other comments is that many people think this is easy and obvious, but in truth it's hard and full of pitfalls.
You said:
> I do not understand why would you ever round trip floats through text.
I'm trying to explain that. I have some experience of the issues involved, and was trying to share my experience. You are dismissing it, which is entirely your choice, and in that case, my comments are here for others.
That is an extreme edge case. The vast majority of computing happens on x86 and ARM. Unless you're working on an IBM mainframe, you're using a little endian, IEEE float machine.
I have extensive experience of other systems, and for me, with my experience, it's not an extreme edge case.
If for you it is an extreme edge case, then I suggest you put it to one side and hope it never becomes relevant. But if one day you find a bug you can't explain, maybe it will help you.
Unfortunately, JSON doesn't have a mechanism for 100% accuracy in transmitting binary floating point numbers. Everything gets marshaled to decimal float, and then unmarshaled to binary float - even in machine-to-machine communication. That's simply a limitation of the format.
> We are talking about two machines talking to each other.
There are allnkinds of reasons machines talk to each other in human readable formats. APIsare for machine-to-machine communications, and yet APIs that speak JSON or XML are not uncommon.
Consider, system A has a float in memory, and wants to send it to system B. System A has no knowledge of how system B stores floats, whether it's big-endian or little-endian, how many bits of precision it uses, etc.
It might also be that the only method of transmitting information is via a text encoding ... perhaps JSON, perhaps something else.
So system A "prints" the float, converts it to a string, and sends that. It's even useful because it can be inspected "by eye" on the way through.
Now system B receives the string and converts it to a float.
All this sort of thing happens in the real world, and is sometimes dictated by the original designs of the system, and sometimes it's specified by customers that this is how it has to work.
Does that help you to understand the original comment?
You could run into problems with little endians and big endians if you do a binary tranfer or, more likely, have a lossy float->string->float conversion.
Unless you are using an IBM mainframe, Big Endian is all but extinct. Besides, it is about ~10 lines of C to detect endianess and reorder bytes if necessary.
> Besides, it is about ~10 lines of C to detect endianess and reorder bytes if necessary.
Proper code to do this doesn't do any tests. Just grab the bytes from the order of the transfer format (in this case network order) into the order of the abstract machine in C. The compiler will turn that into whatever is needed depending on if it's compiling to a big-endian or little-endian machine and may use byteswap instructions if needed. Having tests in the code is a code smell that creates unchecked paths to the code that are much more likely to be wrong as they are not used most of the time.
There is nothing incorrect about the code I posted - clang will compile it to a single read + bswap just fine. And you don't need to go that far back for your code to not be recognized - GCC 4.9 will produce individual loads and shifts for that too.
The point is that you can't rely on compilers consistently to recognize complex patterns.
Incorrect was too strong but it's a weird pattern to do this with sums. The OR pattern is what is used pretty much everywhere and conveys the intention of the code much more clearly.
And even if the compiler doesn't always optimize ideally my original point still stands. Delegating this to the compiler instead of trying to manually call swap instructions is a much better way of going about it.
Strings have nothing to do with the issue that there is no widespread lossless text exchange format for FP. Instead we round FP numbers while encoding (like "0.3") and then "deround" it while decoding.
(Lossless base10 encoding of 0.3 single precision would be like "10066330*2^-25"..not very readable).
This is kind of textbook example of an obvious bug but still surprising when you find it.