"space >= zero" is true:
Willkommen im Forum!
(That's all the German I know -- I mean, all Google told me. :~) )
Yeah, I think there's something weird about words containing only spaces. The spaces don't print as brown \cdot{s} and they behave weirdly in comparisons and in LETTER 1 OF.
We'll look into it someday.
Literally "Welcome in the forum", which sounds about right.
I know some German, but not much. I know from Snap! that "true" and "false" are "wahr" and "falsch", and I know a few conjunctions ("und" for "and", "oder" for "or"), nouns (one that stands out is "Brot" for "bread"), etc.
?
Again, ?
Duh, I was clearly asleep when I said that -- they shouldn't print as brown \cdot{s} in speech balloons!
Duh, I was clearly asleep when I said that -- they shouldn't print as brown \cdot{s} in speech balloons!
Ah.
That little bit of LaTeX looks like this: $$\cdot{s}$$
How do I make colored text here?
Wasser, brot, milch, du, bist, nein, ja, eine, ein, und, etc.
Wasser, brot, milch, du, bist, nein, ja, eine, ein, und, etc.
nacht, ich, bien, vier
I forgot ich and ist!
Of the ones you gave, the only one I don't know is "milch". I also know all German numbers, as can be seen by my number name project.
Milch is milk.
I realized that last night, while thinking about if I had milk.
Nacho is night.
EDIT: I mean nacho.
EDIT 2: Nacht is night.
Umm. Maybe we should stop hijacking this topic?
Maybe space
is defined as nothing (object without value) so this show true because nothing=0 . This same situation exists when you put any other letter to this block:
Space is not the same as nothing:
But it's true that a string of digits with leading and/or trailing spaces is still considered a number:
But that's not true for embedded spaces:
How about a string of only spaces?
It's a string, not a number. So I would expect comparisons to use Unicode order:
Space should come before zero. So the behavior shown by the OP is inconsistent with other Snap! behaviors. I speculate that the rule for eligibility to participate in numeric comparisons is looser than the rule for being declared a number. I'm sure we inherited this behavior from Scratch. I'm guessing Jens will say this is how it should be, in which case it's a misfeature rather than a bug. :~)
This is only a problem with ≤ and ≥. All the scratch operators <, =, and > return false in this situation. It happens because ≤ is implemented as (a, b) => !this.reportBasicGreaterThan(a, b)
, rather than from less than and equality.
All the scratch operators <, =, and > return false in this situation.
Well that's wrong too! One of them has to be true, unless they all error.
I can think of two useful ways it could go:
- They all error. Reason:
- You can't order different types. (Number being one type)
- Space is less than 0. Reason:
- If you take the Unicode values, Space (32) is less than 0 (48)
You can't order different types. (Number being one type)
I think that ship has sailed. Once it's settled that we convert automatically between numbers and strings of (base 10) digits, which was a correct decision in Scratch because human beings shouldn't have to worry about hardware data types, then it'd be inconsistent not to allow Unicode ordering of strings one of which happens to be all digits.
I think that ship has sailed.
That's the first time I've heard that saying. (But I do get what it means.)
Once it's settled that we convert automatically between numbers and strings of (base 10) digits, which was a correct decision in Scratch because human beings shouldn't have to worry about hardware data types, then it'd be inconsistent not to allow Unicode ordering of strings one of which happens to be all digits.
Indeed it would be. And I guess it is, in Snap! at least.