Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shipping Culture Is Hurting Us

bitbashing.io

Post reply on HN
Print view View original

151–160 of 169 posts

Re: Shipping Culture Is Hurting Us

#151

Post by kazinator »

aidenn0 wrote: post #62
kazinator wrote: post #21

Earlier quoted context omitted.

The stupid thing about IEEE NaN is that it's not equal to itself! If variable x holds a NaN, then (x == x) is false. This violates: http://en.wikipedia.org/wiki/Law_of_identity If (x == x) tests false, then it asserts that x is not itself, which is logically preposterous. ANSI Common Lisp has a bit of this problem in it too, but it's not required ; it is there for some weird historic implementations. That is to say,…

You are missing a lot of nuance here. First of all it is debatable over whether or not the spec allows (eq x x) to be false. eq is required to return true if the arguments are the same identical object. It would be a twisted interpretation of that to allow (eq x x) to ever return false. Now (eq 1 1) is specifically not required to return true, as, for example an implementation that boxes all numbers could create two…

Direct quote from Common Lisp HyperSpec, under Function EQ:

"An implementation is permitted to make ``copies'' of characters and numbers at any time. The effect is that Common Lisp makes no guarantee that eq is true even when both its arguments are ``the same thing'' if that thing is a character or number. "

Re: Shipping Culture Is Hurting Us

#152

Post by kazinator »

hueving wrote: post #52
kazinator wrote: post #47

Earlier quoted context omitted.

I don't understand your point. This is not a number: char *p = "abc"; Yet, this yields true: p == p The square root of -1 is easily representable in floating math. You just need two floats to make a complex.

The point is that you can have very different things that are not a number. It's not safe to say that multiple things that are not a number are equal.

The values of two expressions that evaluate the same variable are not "multiple things".

Re: Shipping Culture Is Hurting Us

#153

Post by kazinator »

cwyers wrote: post #120
kazinator wrote: post #47

Earlier quoted context omitted.

I don't understand your point. This is not a number: char *p = "abc"; Yet, this yields true: p == p The square root of -1 is easily representable in floating math. You just need two floats to make a complex.

Okay, but while "abc" is not a number, it is also the string "abc". NaN is special in that all it tells you is that the value is not a number -- it doesn't tell you what it is . In order to return a true value from an equality test, it isn't enough to know that both values are not a number, you have to know what they actually are.

If it is not known what is in the p variable, then the variable is indeterminate; it has exactly the same status as a variable that has not been initialized. In this case, the behavior upon accessing the variable should be undefined.

I agree with making accesses of NaN-valued variables undefined behavior, so that not comparing equal is then a possible consequence of undefined behavior.

I don't agree with defining the unequal comparison as the required behavior. To define the behavior is tantamount to the recognition that a NaN is something: an object. A variable can have a defined value which is that something, and that value must obey the Law of Identity.

Re: Shipping Culture Is Hurting Us

#154

Post by kazinator »

Hasu wrote: post #150
hesselink wrote: post #122

Earlier quoted context omitted.

While your overall point is correct, your example is wrong: 17/0 == Infinity, and 0^0 == 1. Neither is NaN :)

Infinity is Not a Number, so 17/0 is NaN.

IEEE floating point distinguishes infinities and NaNs.

Re: Shipping Culture Is Hurting Us

#155

Post by kazinator »

nemothekid wrote: post #68
kazinator wrote: post #21

Earlier quoted context omitted.

The stupid thing about IEEE NaN is that it's not equal to itself! If variable x holds a NaN, then (x == x) is false. This violates: http://en.wikipedia.org/wiki/Law_of_identity If (x == x) tests false, then it asserts that x is not itself, which is logically preposterous. ANSI Common Lisp has a bit of this problem in it too, but it's not required ; it is there for some weird historic implementations. That is to say,…

The stupid thing about IEEE NaN is that it's not equal to itself! Why would it be? The rationale makes perfect sense. It would be unexpected to believe that 17/0 == 0^0. Both are NaN, and equally nonsense, but 2 very different statements. Secondly, IIRC, NaN is supposed to break assert(x==x), because if you use NaN in your program, then your program is undefined.

Your == expression has distinct operands which are the results of different evaluations.

The problem is that a NaN is not equal to itself:

    double nan = /* NaN-producing expression */

    if (nan == nan) {
      /* dead code */
    }

Re: Shipping Culture Is Hurting Us

#156

Post by kazinator »

chrisdevereux wrote: post #147
jks wrote: post #70

Earlier quoted context omitted.

According to http://stackoverflow.com/a/1573715 the IEEE-754 committee decided to make NaN != NaN in order for programmers to have a simple way of detecting NaN before there was a standardized isnan function or macro.

I'm lacking sleep a bit here, but wouldn't NaN == NaN do the same trick?

Yes, if you take the false result to be the indication that you have a NaN. Either polarity comparison will work, if you correctly interpret its result.

Re: Shipping Culture Is Hurting Us

#158

Post by aidenn0 »

kazinator wrote: post #151
aidenn0 wrote: post #62

Earlier quoted context omitted.

You are missing a lot of nuance here. First of all it is debatable over whether or not the spec allows (eq x x) to be false. eq is required to return true if the arguments are the same identical object. It would be a twisted interpretation of that to allow (eq x x) to ever return false. Now (eq 1 1) is specifically not required to return true, as, for example an implementation that boxes all numbers could create two…

Direct quote from Common Lisp HyperSpec, under Function EQ: "An implementation is permitted to make ``copies'' of characters and numbers at any time. The effect is that Common Lisp makes no guarantee that eq is true even when both its arguments are ``the same thing'' if that thing is a character or number. "

Ah, you're correct, a copy can be made at the call to eq.

I stand by the rest of what I said. It's no more strange for (eq 1 1) to be false than (eql '(1) '(1))

Re: Shipping Culture Is Hurting Us

#159

Post by username223 »

angersock wrote: post #58
username223 wrote: post #57

Earlier quoted context omitted.

Yeah, the title and the article have very little to do with each other. Complaining about NaN semantics is especially irrelevant. OTOH, it's funny you bring up Netscape. Yes, they shipped. Back in the Netscape 3-4 days of the Browser Wars, every new version was a crap shoot. It might un-break some page you wanted to use, but it might also be drastically slower, crash a page that you needed, lose your preferences, or…

So, on the one hand, I agree very much that having the options available was pretty cool. On the other hand, having seen this repeated time and time again in the enterprise world, I don't think users should be given the option of not updating, especially for services that they aren't hosting themselves. All they end up doing is creating a support burden and being dissatisfied. Our users are increasingly ignorant abou…

Since I don't support anything "enterprise," I'm probably a bit biased. Still, "creating a support burden" basically means "making more work for the developer," while "updating" almost always means "making more work for the user." I happen to use Emacs, and even though it's very slow-moving and careful about backward compatibility, I always put aside some free time for major updates, because they always break my setup somehow. And I'm lucky compared to the average software user: I'm a coder, so I can usually work around the breakage without too much trouble. Regularly making work for people without this option is inhumane.

Regarding ignorance, you know far more about how the systems work, but they probably know far more about how they use them.

I still think the auto-update treadmill is a symptom of developer arrogance, laziness, and callousness, but maybe I'm just old before my time.

Re: Shipping Culture Is Hurting Us

#160

Post by mattlutze »

chii wrote: post #97
mattlutze wrote: post #81

Earlier quoted context omitted.

I wonder if ship-it-now isn't more a reflection of the times, rather than the right answer. "Pick off the low-hanging fruit" works for a shop looking to turn some mad profit without having to do a lot of deep thinking. And that's certainly fine. But if that's the culture of the industry, we'd be sacrificing progress and innovation for a quick and ephemeral dollar. There's a quiet theme that runs through the community…

> we'd be sacrificing progress and innovation for a quick and ephemeral dollar. until the low hanging fruit all got picked.

On this tree called "life", new low-hanging fruit grows every day. It's a reason we see such churn in the sorts of tech that keeps solving the same easy problems in different ways.
Post reply on HN