PoofToof wrote:

Agreed! Less work means better… right?

when green flag clicked
forever
switch costume to [smile v]
end

<(number1) > ((number2) - (1))> // more than or equal to
<(number1) < ((number2) + (1))> // less than or equal to

<<(foo) < [-1]> or <(foo) = [-1]>>
<<(foo) > [-1]> or <(foo) = [-1]>>

key [w v] pressed? or key [up arrow v] pressed? :: sensing boolean

jromagnoli wrote:

No support. Easy workaround:

<<(foo) < [-1]> or <(foo) = [-1]>>
<<(foo) > [-1]> or <(foo) = [-1]>>

The4thPixel wrote:

jromagnoli wrote:

No support. Easy workaround:

<<(foo) < [-1]> or <(foo) = [-1]>>
<<(foo) > [-1]> or <(foo) = [-1]>>

This is a slightly easier alternative for my workaround above.

<not <[] > []>>
<not <[] < []>>

stickfiregames wrote:

Your workaround above only works for whole numbers.

The shortest workaround is

<not <[] > []>>
<not <[] < []>>

stickfiregames wrote:

Your workaround above only works for whole numbers.

The shortest workaround is

<not <[] > []>>
<not <[] < []>>

jromagnoli wrote:

stickfiregames wrote:

Your workaround above only works for whole numbers.

The shortest workaround is

<not <[] > []>>
<not <[] < []>>

Who's? His? I have tested mine before.

(() - (number)) // empty is 0

((-1) * (number))

((number) / (-1))

MathlyCat wrote:

cheezboy18 wrote:

No support. Do you really want a

[]=>[]::boolean operators

when you can just take 2 Blocks and go

<not <[] < [ ]>>

?
Plus, it would be confusing to new scratchers.

Or anyone who hasn't done a high enough math level.
No support as per workarounds.

• The lack of these blocks is confusing. Do you want to know why this topic has been posted over and over again throughout the years? It's because many Scratchers do know about the composite -or-equal-to operators, and are confused by their absence. I would argue that adding these blocks would make booleans more accessible to New Scratchers, or at least no more confusing than our existing comparator blocks already are.
  
• Popular languages have these as a basic feature. Scratch is supposed to be a preparation for other programming languages. Why, then, does it not comply with the standard of including -or-equal-to inequalities as booleans? The argument could be made that leaving out these operators is actually setting programming novices up for failure. Every equality and inequality boolean is important, and ignoring two will lead to less efficient code. It still works, but it takes so much more effort when a single operator for the task already exists.
  
• The workaround is more confusing than the suggestion. I always see replies on these threads that are saying at least one of two things: that the suggestion is confusing, and that it should be no-supported because there's an easy workaround. The thing is, this workaround is obtuse and unintuitive. It requires a leap of lateral thinking not only to realize for oneself that inverting the output of the opposite existing operator reports the desired output (which most people won't, hence why they ask for the tools they're familiar with on these forums), but why this works at all. You first need to fully understand how booleans work, then mentally apply them as sort-of Euclidean vectors on a number line. At least with the blocks being suggested, the answer is in the name of the symbol! And therein lies the usefulness.
  But more to the point, this not-notation that's needed for the workaround just muddles the code, and can make complicated booleans just that much harder to figure out, even when you know what the workaround means and does. At first glance, there's always the chance that you'll only see the opposite of what you get. With the booleans being suggested, you'll learn what they mean once if you don't already know. But the workaround, with its doubly-backwards operators, requires you to stop and think through the intended result every time, even if for a fraction of a second; and then remember it as the result isn't clearly stated in the code.

Ninkancho wrote:

-snip-
The workaround is more confusing than the suggestion. I always see replies on these threads that are saying at least one of two things: that the suggestion is confusing, and that it should be no-supported because there's an easy workaround. The thing is, this workaround is obtuse and unintuitive. It requires a leap of lateral thinking not only to realize for oneself that inverting the output of the opposite existing operator reports the desired output (which most people won't, hence why they ask for the tools they're familiar with on these forums), but why this works at all. You first need to fully understand how booleans work, then mentally apply them as sort-of Euclidean vectors on a number line. At least with the blocks being suggested, the answer is in the name of the symbol! And therein lies the usefulness.
But more to the point, this not-notation that's needed for the workaround just muddles the code, and can make complicated booleans just that much harder to figure out, even when you know what the workaround means and does. At first glance, there's always the chance that you'll only see the opposite of what you get. With the booleans being suggested, you'll learn what they mean once if you don't already know. But the workaround, with its doubly-backwards operators, requires you to stop and think through the intended result every time, even if for a fraction of a second; and then remember it as the result isn't clearly stated in the code.