3 ms·

No, I’m not. In the applications IEEE754 was developed to support through standardization, being able to represent 14.7 exactly is simply unimportant.

shadowgovt 3y ago
... unless I have $14.70 in my bank account, and some naif was handed the job of writing the code to track that and didn't know about the non-intuitive consequences of relying on the IEEE floating point standard. Then its limitations suddenly become very meaningful to me or my financial institution.
- sfpotter 3y ago
  I guess you're right. We should throw the baby out with the bathwater because a bank hired a crappy engineer. There is no other solution to this problem.
  - shadowgovt 3y ago
    I don't think anyone's calling for that. I think they are commenting on the fact that floating-point is an excellent tool for a special case of computing (a tool which has some significant drawbacks if the representation is treated as equivalent to another representation) and most languages we use make it frighteningly easy to slip-slide from one representation to the other without noticing when they are, in fact, extremely different representations of numbers and numerical computation.
    - sfpotter 3y ago
      It isn't frightening if you've been properly trained and understand how your tools work. The onus is on the bank to train its employees to use the proper number type for money. I have no problem with languages having first-class support for big integers, arbitrary precision floating point numbers, arbitrary precision rationals, etc. The more representations the merrier, provided they have an efficient implementation. Having programming languages where floating point types are first class, unboxed types is extremely important for anyone who writes software which crunches numbers. I would say this is more important than providing training wheels for inexperienced programmers.
      - shadowgovt 3y ago
        It's not so much that floating point needs to be boxed as that all-too-many languages allow smooth (read "sloppy") casting from float to int and back, often with semantics that are unclear to the developer and require esoteric memorization. In 5 seconds or less, can you say whether 1.0/4 will be 0.25 or 0 for every language you use regularly? Most developers can't, and most languages make statements like that trivial (and worse, it far more often shows up as "x/y" for x and y of types that need to be looked up to know what the evaluated type will be). There's a reason C++, for example, has the MISRA rules about avoiding implicit coercions (because even though what happens is [generally] well-defined, enough code in the wild has been broken for developers mis-remembering or mis-applying the rules that explicit casts are highly recommended for high-reliability code).
        sfpotter 3y ago
        OK, I get the point you’re trying to make now. The languages I work with most often in decreasing order of frequency are: C, Python, C++, Fortran, MATLAB, and Julia. I don’t regularly cause problems for myself by running afoul of implicit casting rules, but I also spend all day writing numerical software. I can see that it can cause problems for other people who don’t spend as much time dealing with IEEE754. There are definitely days where I feel like an OCaml-like level of casting pedantry would be nice, and other days I feel like it would be exhausting and make my code harder to read. I’ve never written a big piece of code in a language that required explicit casts for everything. I’m open to it. I would say that unsigned integers cause me the most problems of any numeric type, but not so many problems that I’m looking to change languages. If I worked in a different field it’d be a different story I’m sure.
        sfpotter 3y ago
        By the way, I had a chance to check: and I was right with my guess. All six of those languages evaluate 1.0/4 to 0.25, exactly as expected. It might have taken me 30 seconds or so to form my answer ;-) but that time was mostly spent parsing your question. What languages don't evaluate 1.0/4 to 0.25? I checked OCaml (exception), node (0.25), Lua (0.25), Swift (0.25), sbcl (0.25), ... and then I got bored. To me the expected behavior should be something like: for a binop between a float and an int, promote the int to float and do the floating point operation. Obviously there are corner cases here...

shadowgovt 3y ago

... unless I have $14.70 in my bank account, and some naif was handed the job of writing the code to track that and didn't know about the non-intuitive consequences of relying on the IEEE floating point standard. Then its limitations suddenly become very meaningful to me or my financial institution.

sfpotter 3y ago
I guess you're right. We should throw the baby out with the bathwater because a bank hired a crappy engineer. There is no other solution to this problem.
- shadowgovt 3y ago
  I don't think anyone's calling for that. I think they are commenting on the fact that floating-point is an excellent tool for a special case of computing (a tool which has some significant drawbacks if the representation is treated as equivalent to another representation) and most languages we use make it frighteningly easy to slip-slide from one representation to the other without noticing when they are, in fact, extremely different representations of numbers and numerical computation.
  - sfpotter 3y ago
    It isn't frightening if you've been properly trained and understand how your tools work. The onus is on the bank to train its employees to use the proper number type for money. I have no problem with languages having first-class support for big integers, arbitrary precision floating point numbers, arbitrary precision rationals, etc. The more representations the merrier, provided they have an efficient implementation. Having programming languages where floating point types are first class, unboxed types is extremely important for anyone who writes software which crunches numbers. I would say this is more important than providing training wheels for inexperienced programmers.
    - shadowgovt 3y ago
      It's not so much that floating point needs to be boxed as that all-too-many languages allow smooth (read "sloppy") casting from float to int and back, often with semantics that are unclear to the developer and require esoteric memorization. In 5 seconds or less, can you say whether 1.0/4 will be 0.25 or 0 for every language you use regularly? Most developers can't, and most languages make statements like that trivial (and worse, it far more often shows up as "x/y" for x and y of types that need to be looked up to know what the evaluated type will be). There's a reason C++, for example, has the MISRA rules about avoiding implicit coercions (because even though what happens is [generally] well-defined, enough code in the wild has been broken for developers mis-remembering or mis-applying the rules that explicit casts are highly recommended for high-reliability code).
      - sfpotter 3y ago
        OK, I get the point you’re trying to make now. The languages I work with most often in decreasing order of frequency are: C, Python, C++, Fortran, MATLAB, and Julia. I don’t regularly cause problems for myself by running afoul of implicit casting rules, but I also spend all day writing numerical software. I can see that it can cause problems for other people who don’t spend as much time dealing with IEEE754. There are definitely days where I feel like an OCaml-like level of casting pedantry would be nice, and other days I feel like it would be exhausting and make my code harder to read. I’ve never written a big piece of code in a language that required explicit casts for everything. I’m open to it. I would say that unsigned integers cause me the most problems of any numeric type, but not so many problems that I’m looking to change languages. If I worked in a different field it’d be a different story I’m sure.
      - sfpotter 3y ago
        By the way, I had a chance to check: and I was right with my guess. All six of those languages evaluate 1.0/4 to 0.25, exactly as expected. It might have taken me 30 seconds or so to form my answer ;-) but that time was mostly spent parsing your question. What languages don't evaluate 1.0/4 to 0.25? I checked OCaml (exception), node (0.25), Lua (0.25), Swift (0.25), sbcl (0.25), ... and then I got bored. To me the expected behavior should be something like: for a binop between a float and an int, promote the int to float and do the floating point operation. Obviously there are corner cases here...