3 ms·

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.

enriquto 6y ago
That seems to be more a problem of strings that of floats, then.
- rini17 6y ago
  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).
  - dahfizz 6y ago
    > 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.
dahfizz 6y ago
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.
- pedrocr 6y ago
  > 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.
  - account42 6y ago
    > and may use byteswap instructions if needed Or it may not because often compilers fail to make simple optimizations: https://godbolt.org/z/NAt3uX https://godbolt.org/z/NAt3uX
    - pedrocr 6y ago
      It does fine if you actually write the correct code :) https://godbolt.org/z/qpLeWP https://godbolt.org/z/qpLeWP
      - account42 6y ago
        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.
        pedrocr 6y ago
        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.

enriquto 6y ago

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

rini17 6y ago
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).
- dahfizz 6y ago
  > 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.

dahfizz 6y ago

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.

pedrocr 6y ago
> 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.
- account42 6y ago
  > and may use byteswap instructions if needed Or it may not because often compilers fail to make simple optimizations: https://godbolt.org/z/NAt3uX https://godbolt.org/z/NAt3uX
  - pedrocr 6y ago
    It does fine if you actually write the correct code :) https://godbolt.org/z/qpLeWP https://godbolt.org/z/qpLeWP
    - account42 6y ago
      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.
      - pedrocr 6y ago
        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.