6 ms·

That is not a floating point bug. That is a programmer who doesn't grok floating point. edit: Also, I am only allowed to say this if OP is a guy. If OP is a gi

That is not a floating point bug. That is a programmer who doesn't grok floating point. edit: Also, I am only allowed to say this if OP is a guy. If OP is a girl and she gets insulted, I'll be hearing about it on the HN front page for days.

lclarkmichalek 14y ago
Why the sexism? Seems rather uncalled for.
- monochromatic 14y ago
  Pointing out a difference between the sexes isn't sexist. What I was referencing was this: http://news.ycombinator.com/item?id=5106767 http://news.ycombinator.com/item?id=5106767 And of course all the follow-on white-knighting that shitted up the HN front page for days afterward.
  - scott_s 14y ago
    Comparing the two situations is absurd. First, myself and several others in the thread did not realize the author behind that post was a woman until reading the comments. This was well after I had upvoted the article, and decided it was worth discussing. Second, that was a situation where someone said "what you made is crap." You are saying, "you don't understand floating point," which the author clearly cops to. And, to that point, I'm surprised there are several comments in this thread that say "the bug is in your code, not with floating point" when it was clear to me that this author knew that, he was just playing with words in his title.
    - MikeDucker 14y ago
      I'm glad one person appreciates my main sin is ban punnery, with a minor in forgetting floating point gotchas. I feel like someone who just told an anecdote about a time they slipped over whilst running and now everyone assumes they never knew how to walk.
  - lclarkmichalek 14y ago
    Oh, I didn't realize that the person who wrote that was female. It seemed to me that most people were just criticizing people who mock other's work. On "white knights": is it not pretty sexist and also an ad hominem to accuse anyone who argues the point of a female to be a white knight?
    - monochromatic 14y ago
      Arguably, they're the ones being sexist (coming to the defense of a lady where they wouldn't do so for a man), and I'm just pointing it out. It's only sexist if I'm wrong, which I don't think I am.
      - deleted 14y ago
        [deleted]
MikeDucker 14y ago
I never suggested this was a bug in how floating point works. I only meant I had a bug and it was due to my use of floats and how it bit me in the ass :) I am still a little surprised (but not that surprised) that essentially 4.0 * 0.1 (and then later) / 0.1 didn't end up with a value that cast to int as 4. Sure I shouldn't make such presumptions, but if you wrote float floaty_var = 4.f; int inty_var = floaty_var; You would generally expect that inty_var would equal 4 and not 3. I have no idea if the IEEE standards mean that it will or it probably will or it very well might not. In my experience it always has, which is quite different from any certainty that 0.4 / 0.1 will cast to an int value of 4, but that's what happened when I tested with variables in a simple function, just not in the situation that led to my issue. Either way I'm well aware it was a PEBCAK, even if my semi-pun blog post title might have suggested otherwise ;)
- CurtHagenlocher 14y ago
  Computer math is not math. You can't generally assume that (a * b) / b will produce a. With floating-point, you have representational issues, and will all types you can get overflow.
  - MikeDucker 14y ago
    I have certainly not had a bug that so plainly highlights this before. If it had been a bug about a more complex calculation than ( 4.0 * 0.1 ) / 0.1 I wouldn't have thought it worth mentioning. The fact that calc generally does result in a number that casts to 4 made it more interesting to me that in at least one case it didn't. I guess it was some state of the FPU (possibly) that gave a different result when there was sufficient time between the mult and the div. I will probably never know.
    - acqq 14y ago
      There's no "some state in the FPU" every partial result is repesented in 64 bits if you use doubles or in 32 bits if you use floats. Nothing is hidden "somewhere." It's especially nothing to "never know," every step can be followed exactly as long as you step through the assembly code or simply imagine that every partial result must also be represented as the FP number as specified not as you'd wish it to be. And don't think in decimal while you do the steps.

lclarkmichalek 14y ago

Why the sexism? Seems rather uncalled for.

monochromatic 14y ago
Pointing out a difference between the sexes isn't sexist. What I was referencing was this: http://news.ycombinator.com/item?id=5106767 http://news.ycombinator.com/item?id=5106767 And of course all the follow-on white-knighting that shitted up the HN front page for days afterward.
- scott_s 14y ago
  Comparing the two situations is absurd. First, myself and several others in the thread did not realize the author behind that post was a woman until reading the comments. This was well after I had upvoted the article, and decided it was worth discussing. Second, that was a situation where someone said "what you made is crap." You are saying, "you don't understand floating point," which the author clearly cops to. And, to that point, I'm surprised there are several comments in this thread that say "the bug is in your code, not with floating point" when it was clear to me that this author knew that, he was just playing with words in his title.
  - MikeDucker 14y ago
    I'm glad one person appreciates my main sin is ban punnery, with a minor in forgetting floating point gotchas. I feel like someone who just told an anecdote about a time they slipped over whilst running and now everyone assumes they never knew how to walk.
- lclarkmichalek 14y ago
  Oh, I didn't realize that the person who wrote that was female. It seemed to me that most people were just criticizing people who mock other's work. On "white knights": is it not pretty sexist and also an ad hominem to accuse anyone who argues the point of a female to be a white knight?
  - monochromatic 14y ago
    Arguably, they're the ones being sexist (coming to the defense of a lady where they wouldn't do so for a man), and I'm just pointing it out. It's only sexist if I'm wrong, which I don't think I am.
    - deleted 14y ago
      [deleted]

MikeDucker 14y ago

I never suggested this was a bug in how floating point works. I only meant I had a bug and it was due to my use of floats and how it bit me in the ass :) I am still a little surprised (but not that surprised) that essentially 4.0 * 0.1 (and then later) / 0.1 didn't end up with a value that cast to int as 4. Sure I shouldn't make such presumptions, but if you wrote float floaty_var = 4.f; int inty_var = floaty_var; You would generally expect that inty_var would equal 4 and not 3. I have no idea if the IEEE standards mean that it will or it probably will or it very well might not. In my experience it always has, which is quite different from any certainty that 0.4 / 0.1 will cast to an int value of 4, but that's what happened when I tested with variables in a simple function, just not in the situation that led to my issue. Either way I'm well aware it was a PEBCAK, even if my semi-pun blog post title might have suggested otherwise ;)

CurtHagenlocher 14y ago
Computer math is not math. You can't generally assume that (a * b) / b will produce a. With floating-point, you have representational issues, and will all types you can get overflow.
- MikeDucker 14y ago
  I have certainly not had a bug that so plainly highlights this before. If it had been a bug about a more complex calculation than ( 4.0 * 0.1 ) / 0.1 I wouldn't have thought it worth mentioning. The fact that calc generally does result in a number that casts to 4 made it more interesting to me that in at least one case it didn't. I guess it was some state of the FPU (possibly) that gave a different result when there was sufficient time between the mult and the div. I will probably never know.
  - acqq 14y ago
    There's no "some state in the FPU" every partial result is repesented in 64 bits if you use doubles or in 32 bits if you use floats. Nothing is hidden "somewhere." It's especially nothing to "never know," every step can be followed exactly as long as you step through the assembly code or simply imagine that every partial result must also be represented as the FP number as specified not as you'd wish it to be. And don't think in decimal while you do the steps.