empty and the number 0

[Cairoo]

Just some LC silliness to brighten your day:

By testing the following statements one-by-one in the message box, I can't help but conclude that empty is equal to 0:

Code: Select all

put (empty < 0)

Code: Select all

put (empty > 0)

Code: Select all

put (empty <= 0)

Code: Select all

put (empty >= 0)

And then to spite me, testing the following statement disproved my conclusion:

Code: Select all

put (empty = 0)

I knew it! My computer is deceiving me!

[richmond62]

What your scripts prove is that empty is NOT = 0.

After all: empty is BIGGER than 0
empty is SMALLER than 0
empty is BIGGER or EQUAL to 0
empty is SMALLER or EQUAL to 0

and I suspect that the word to meditate on is 'or'.

[dunbarx]

You are both silly.

Zero is a number, like 42. It is smaller than 42, but larger than -4, and one should not divide by it. In any case, it is NOT the poor cousin of any other number. In fact it is rather special; it is anything but nothing.

Empty is not anything at all. It is nothing but nothing. The two concepts do not mix well; don't try it.

@ Cairoo. What made you think that your string of trials would lead you to the conclusion that empty had anything to do with 0?

Craig

[Cairoo]

empty is BIGGER than 0

LC told me it's not

empty is SMALLER than 0

LC told me it's not

[richmond62]

Dear Captain Sensible,

( https://youtu.be/9Q6YJ-r5SQs )

You are both silly.

Never, ever claimed to be otherwise.

Yes, of course empty is empty as in vacuum, while 0 is not a vacumm.

BUT, the logic of LC is also silly returning the messages it does.

Zero is a number, like 42.

Well, it might be a number, but it is not like 42: it behaves quite differently.

[Cairoo]

What made you think that your string of trials would lead you to the conclusion that empty had anything to do with 0?

Just LC's logic. If LC says (empty < 0) is false, and (empty > 0) is false, but (empty <= 0) is true, and (empty >= 0) is true, then logically (empty = 0) must be true. I can also add 1 to empty and get 1.

[richmond62]

Aye, but you can also add empty to 0.

[dunbarx]

Cairoo.

AHA.

You did not say, along the first run of tests, that some returned "true". I skimmed them and thought they all should return "false".

So if "empty < 0" returns "false" AND "empty = 0" returns false BUT "empty <= 0" returns "true" then I think it is just a bug in LC, not an inconsistency in the universe. It is no reflection on zero.

Anyone have a better explanation?

Craig

[Cairoo]

I also think it's a LC bug, so I posted my proof just to tease you all.

I knew that LC treats empty like the number zero in arithmetic operations. I just did not expect that the <= operator would disagree wirh the < and = operators when comparing empty with the number 0.

[dunbarx]

I knew that LC treats empty like the number zero in arithmetic operations.

But that is just the way that LC works, likely for convenience sake, in that if you add 42 to empty, you do not get an error, but rather 42.

Nevertheless, empty is NOT a number; it is nothing.

So LC does allow you to add a number to, er, an emptiness, but that is not the same as adding to 0, even though in this case the result is the same.

I agree the "<=" thing is a bug.

Craig

[mwieder]

Nope

Code: Select all

put empty is nothing

[dunbarx]

Mark.

Sheesh. I was trying to make a point

Empty is indeed not nothing. Interestingly, "nothing" in not a native word that has its own entry in the dictionary. It is mainly associated with the "strictly" operators, and without much explanation. In fact, I interpreted the article there as if "nothing" was indeed empty.

Craig

[mwieder]

Actually nothing is defined in LC10. And has an entry in the dictionary.

put nothing is empty -- true
put nothing is 0 -- true

The nothing value behaves like empty when used in string context, and like
zero when used in number context.

[richmond62]

As usual nothing is simple.

[dunbarx]

Mark.

So they changed the nature of "nothing", because in LC9, both those statements return "false".

Is nothing a constant?

Anyway, as long as we know...

Craig