Exchange 2013

Ben L.

@Ben L. said:
Ask yourself: Is NaN a finite number?
NaN is Not A Number, but it is a Number primitive, but it's not a finite number. And if that wasn't confusing enough, just ask yourself, "Is 'Not A Number' a number, and if it was a number, would it be a finite number?"
Personally, I think it'd be a purple number.

A NaN is a IEEE 754 floating point value that is not equal to itself. All other IEEE 754 floating point values are equal to themselves. Numbers equal themselves. Therefore, NaN is not a number.

All finite numbers are numbers. NaN is not a number. Therefore, NaN is not a finite number.

anotherusername is a person. People are not numbers. Therefore, anotherusername is not a finite number.

HardwareGeek

@Ben L. said:

anotherusername is a person.

Presumably. As opposed to Ben L., whom we know is a Markov generator.@Ben L. said:

People are not numbers.

Tell that to the IRS.@Ben L. said:

Therefore, anotherusername is not a finite number.

isNaN(anotherusername) == true

anotherusername != anotherusername

Ben L.

@HardwareGeek said:

@Ben L. said:
Therefore, anotherusername is not a finite number.
isNaN(anotherusername) == true
anotherusername != anotherusername

It all checks out!

dkf

@anotherusername said:

@lushr said:
What are these, then?
Something completely different:
The aleph numbers differ from the infinity (∞) commonly found in algebra and calculus. Alephs measure the sizes of sets; infinity, on the other hand, is commonly defined as an extreme limit of the real number line (applied to a function or sequence that "diverges to infinity" or "increases without bound"), or an extreme point of the extended real number line.
The infinity used in algebra and calculus is not a number. It is a limit.

That all depends on which set of axioms you are accepting. The cool thing is that you can always pick a different set of axioms and win a definitional argument, though you have to be prepared to deal with the logical consequences of that. (What's even better is that there's no finite set of potentially-axiomatic statements to pick between; there's at least a countably-infinite number of possible axioms and hence of mathematical systems to study. Well, assuming you accept basic logic and basic arithmetic.)

anotherusername

@Ben L. said:

A NaN is a IEEE 754 floating point value that is not equal to itself.

Your logic is circular. You've defined a "value" that violates a property of numbers, and used that property to prove that it isn't a number.

boomzilla

@anotherusername said:

@Ben L. said:
A NaN is a IEEE 754 floating point value that is not equal to itself.
Your logic is circular. You've defined a "value" that violates a property of numbers, and used that property to prove that it isn't a number.

What's circular about the logic? We had an assumption about numbers (they equal themselves) and some assumptions about IEEE 754 values. One value isn't compatible with the assumption about numbers. That value isn't a number. QED. And no circles were harmed. Of course, we could have taken a shortcut and just expanded the abbreviation.

PJH

@anotherusername said:

@Ben L. said:
A NaN is a IEEE 754 floating point value that is not equal to itself.
Your logic is circular. You've defined a "value" that violates a property of numbers, and used that property to prove that it isn't a number.

Next, on tonight's schedule, a post from anotherusername astounded that the following program doesn't print '1':

[root@pjh tmp]# cat float.c
#include <stdio.h>
int main(void){
        float a = 1./3;
        printf("%d\n", a == 1./3);
}
[root@pjh tmp]# make float
cc     float.c   -o float
[root@pjh tmp]# ./float
0
[root@pjh tmp]#

You really haven't been doing this programming lark for very long have you? Either that or you're trolling us. Not that the two need be mutually exclusive of course...

anotherusername

@boomzilla said:

What's circular about the logic? We had an assumption about numbers (they equal themselves) and some assumptions about IEEE 754 values. One value isn't compatible with the assumption about numbers.

Because the people who drafted the IEEE 754 decided that it's defined as such, because it's not a number: It's a "value" which is defined to be not a number, so they decided that the reflexive property wouldn't hold, which can be used to prove that it isn't a number.

@PJH said:

You really haven't been doing this programming lark for very long have you? Either that or you're trolling us. Not that the two need be mutually exclusive of course...

When I started programming, if you divided by zero, you didn't get Infinity, you got Division By Zero. I preferred it that way. None of this fancy-schmancy NaN and Infinity business...

Arnavion

@PJH said:

Next, on tonight's schedule, a post from anotherusername astounded that the following program doesn't print '1':
[root@pjh tmp]# cat float.c
#include <stdio.h>
int main(void){
        float a = 1./3;
        printf("%d\n", a == 1./3);
}
[root@pjh tmp]# make float
cc     float.c   -o float
[root@pjh tmp]# ./float
0
[root@pjh tmp]# 

Off-topic (or maybe not), does the C/C++ standard guarantee that the expression 1./3 == 1./3 will always evaluate to true? How about if one or both of them is in a float variable?

anotherusername

@Arnavion said:

@PJH said:
Next, on tonight's schedule, a post from anotherusername astounded that the following program doesn't print '1':
[root@pjh tmp]# cat float.c
#include <stdio.h>
int main(void){
        float a = 1./3;
        printf("%d\n", a == 1./3);
}
[root@pjh tmp]# make float
cc     float.c   -o float
[root@pjh tmp]# ./float
0
[root@pjh tmp]# 
Off-topic (or maybe not), does the C/C++ standard guarantee that the expression 1./3 == 1./3 will always evaluate to true? How about if one or both of them is in a float variable?

I'd assume the compiler would calculate the result instead of having the code calculate it at runtime.

Arnavion

@anotherusername said:

I'd assume the compiler would calculate the result instead of having the code calculate it at runtime.

And I would assume the compiler would not do this if the standard didn't mandate it, hence leading back to my question.

The compiler could also do it if the standard said it was undefined, since "true" is one valid value for undefined (and likely what the programmer wanted, if the compiler is feeling in a good mood that day).

anotherusername

@Arnavion said:

And I would assume the compiler would not do this if the standard didn't mandate it, hence leading back to my question.

I actually just meant evaluating 1./3 at compile time, not the equality. Although it might do that, too, if both sides were constants.

Ben L.

@anotherusername said:

@Arnavion said:
And I would assume the compiler would not do this if the standard didn't mandate it, hence leading back to my question.
I actually just meant evaluating 1./3 at compile time, not the equality. Although it might do that, too, if both sides were constants.

The variable is 3fd5555560000000

The expression is 3fd5555555555555

Yeah, fuck implicit conversion.

anotherusername

@Ben L. said:

The variable is 3fd5555560000000

The expression is 3fd5555555555555

Yeah, fuck implicit conversion.

That was my suspicion... the literal was double-precision and the float variable was single-precision. But in general, comparing floats with == is always iffy and I wasn't sure if that was supposed to have had anything to do with it. It's generally better to use a window to test for near equality instead of exact equality... i.e. |x-y| < some small value.

Arnavion

@anotherusername said:

But in general, comparing floats with == is always iffy and I wasn't sure if that was supposed to have had anything to do with it.

Yeah, that's why I wanted to know if the standard had anything to say about it, one way or the other.

PJH

@Arnavion said:

Off-topic (or maybe not), does the C/C++ standard guarantee that the expression 1./3 == 1./3 will always evaluate to true?

Not that I recall. @Arnavion said:

How about if one or both of them is in a float variable?

Nope. And certainly not if they're of different types (e.g. literal and float as in my code example.)

Arnavion

@PJH said:

@Arnavion said:
Off-topic (or maybe not), does the C/C++ standard guarantee that the expression 1./3 == 1./3 will always evaluate to true?
Not that I recall. @Arnavion said:
How about if one or both of them is in a float variable?
Nope. And certainly not if they're of different types (e.g. literal and float as in my code example.)

Thanks.