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)

l_discount is not a monetary (fixed precision) type? It appears it ought to be, but I see now that is another can of worms ...

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.

Round-tripping floats through text is much, much harder to do than it sounds - you need to make sure you get all the decimal digits, and round in the correct way. e.g. https://randomascii.wordpress.com/2012/02/11/they-sure-look-...

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.

JSON? Human-readable representations in general?

> Representing a float in decimal is absolutely idiotic

Other way round: humans like decimal arithmetic, and will accept binary floating point as an intermediate representation.

We are talking about two machines talking to each other. Correctness is more important than human readability for bytes on a wire.

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.

It's part of the reason I developed Concise Encoding: https://github.com/kstenerud/concise-encoding/#example which allows hex float notation when you need to be exact.

> Unfortunately, JSON doesn't have a mechanism for 100% accuracy in transmitting binary floating point numbers.

If it was just inaccurate! It cannot even deal with straightforward floats like inf, nan, or minus zero!

> 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.

Not to flog unnecessarily an expired equine, you say:

> C's printf has had the "%a" conversion since forever

That turns out not to be the case. Would you care to guess:

* Which year it was first introduced?

* Which year it became wide-spread?

* When I started programming?

* How old some of the systems are in which I still work?

I don't understand your confusion.

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.

> and may use byteswap instructions if needed

Or it may not because often compilers fail to make simple optimizations:

https://godbolt.org/z/NAt3uX

It does fine if you actually write the correct code :)

https://godbolt.org/z/qpLeWP

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.

That seems to be more a problem of strings that of floats, then.

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).

> the issue that there is no widespread lossless text exchange format for FP.

If you have to use strings as the intermediate representation (why?) Then printf("%x") and scanf("%x") is perfectly lossless and widespread.

The only thing that's lossy is converting floats to decimal point numbers, which is absolutely silly if it's just two machines communicating.

It's not clear what 'conversion' is referring to here. Do you mean the communication is using a decimal representation (like JSON)?