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

Return True to Win

alf.nu

Post reply on HN
Print view View original

101–110 of 123 posts

Re: Return True to Win

#101

Post by jomamaxx »

nv-vn wrote: post #94
jomamaxx wrote: post #84

Earlier quoted context omitted.

I wish an empty string was not false. In 'object' terms, an empty string is still a string! It's something. I guess if you think about it from a memory perspective, it's 'nothing'. But since JS is not actually like C, I really wish "" were true.

"" is actually true in C, but that's also because it represents something in memory. Consider how C encodes strings: an empty string is a _pointer_ to a 0 (or a '\0', if you want to think of it as a char). However, the pointer (being an address) is non-zero (since the address 0 is NULL).

touché

Re: Return True to Win

#102

Post by lake99 »

posterboy wrote: post #87
teraflop wrote: post #74

Earlier quoted context omitted.

That one isn't specific to Javascript, though. If you can find a mainstream language that doesn't have any values that aren't equal to themselves, I'll give you a cookie. (Going from memory of the last time I tried this challenge, since I can't get it to load at the moment.)

The important property of evaluation is determinism defined by the equality of the output. Classically, id(x) != id(x) is logically inconsistent. Boolean Logic and natural languages are pretty mainstream in my opinion. Do you mean programming languages? If IEEE whatsthenumber is implemented in the FPUs to provide fcmp (Floating-point Compare Instruction), the languages don't have much of a choice. When there are diff…

> Classically, id(x) != id(x) is logically inconsistent.

Equality is domain dependent. For example ∞!=∞ could be justified, as can (0/0)!=(0/0). In the domain of real numbers, equality can be an undecideable problem[1]. I guess the designers of these languages had to choose between tolerable defaults or throwing exceptions. I'm happy with JS doing this:

    % node
    > 1.0/-0
    -Infinity
    > 1.0/0
    Infinity
    > 0/0
    NaN
    > 0/NaN
    NaN
    > 1+NaN
    NaN
[1] https://math.stackexchange.com/questions/143727/determining-...

Re: Return True to Win

#103

Post by Zarel »

astrobe_ wrote: post #93
XaspR8d wrote: post #80

Earlier quoted context omitted.

So you disagree with the IEEE floating point specification, then? Javascript is directly following spec there.

Does that spec forces you to implement equality test between floating point numbers?

...yes? I'm not sure exactly what you're asking here, though.

Re: Return True to Win

#105

Post by imtringued »

liquidise wrote: post #54
fauria wrote: post #21

This table is quite useful to solve some problems: https://dorey.github.io/JavaScript-Equality-Table/

> Moral of the story: Always use 3 equals unless you have a good reason to use 2. NaN === Nan // => false [] === [] // => false {} === {} // => false [1] === [1] // => false [0] === [0] // => false I guess i never see the gains in the triple vs double equal sign wars.

You're comparing two expressions of the same type so it doesn't matter whether you use == or ===, but == can return true even if the expressions are of different types.

Re: Return True to Win

#106

Post by AgentME »

Kapow wrote: post #82
fauria wrote: post #21

This table is quite useful to solve some problems: https://dorey.github.io/JavaScript-Equality-Table/

JS gets even weirder when you include all the comparison operators. https://jsfiddle.net/5Yzs6/17/ Did you know undefined is equal to undefined, but not = undefined? Or that two instances of the same object/array are not equal (e.g. [-1] != [-1]), but are both = each other? Or that /.*/ is non-comparable (only != is true) to all numbers, but greater than [-0.5] and "-0.5", and less than [0] and "0"?

Most of the examples you point out make sense if you know that using greater than or less than casts the value to a number. >= and <= always cast their parameters to numbers while == only does if either side is already a number.

Re: Return True to Win

#107

Post by AgentME »

liquidise wrote: post #54
fauria wrote: post #21

This table is quite useful to solve some problems: https://dorey.github.io/JavaScript-Equality-Table/

> Moral of the story: Always use 3 equals unless you have a good reason to use 2. NaN === Nan // => false [] === [] // => false {} === {} // => false [1] === [1] // => false [0] === [0] // => false I guess i never see the gains in the triple vs double equal sign wars.

[] and {} create new objects. === always compares by identity, which isn't a unique feature. It's equivalent to Java's ==, and two different objects aren't ever equal to each other. === is equivalent to Python's `is`, and you'll get false from `[] is []` in Python for example.

Re: Return True to Win

#109

Post by __jal »

AgentME wrote: post #106
Kapow wrote: post #82

Earlier quoted context omitted.

JS gets even weirder when you include all the comparison operators. https://jsfiddle.net/5Yzs6/17/ Did you know undefined is equal to undefined, but not = undefined? Or that two instances of the same object/array are not equal (e.g. [-1] != [-1]), but are both = each other? Or that /.*/ is non-comparable (only != is true) to all numbers, but greater than [-0.5] and "-0.5", and less than [0] and "0"?

Most of the examples you point out make sense if you know that using greater than or less than casts the value to a number. >= and <= always cast their parameters to numbers while == only does if either side is already a number.

If you define "make sense" as "having an explanation not rooted in the supernatural", then yes.

By that definition, Brainf*ck[1] also makes sense.

[1]https://en.wikipedia.org/wiki/Brainfuck

Re: Return True to Win

#110

Post by effie »

XaspR8d wrote: post #80
posterboy wrote: post #58

Earlier quoted context omitted.

Indeed, I refuse to believe there should be a solution to the 'reflexive' task.

So you disagree with the IEEE floating point specification, then? Javascript is directly following spec there.

Do you think that such rule for NaN state is useful?
Post reply on HN