New Block: () Is Even/Odd?

BB1000000000

The block would be a Boolean that reports if the specified number is even/odd. If so, it would return true, if not it would return false. Such a block could be placed in the Operators category. This is what the block might look like:

<(10) is [even v]? ::operators>

A workaround may be to use the

() mod ()

along with the

[] = []

.

Last edited by BB1000000000 (Dec. 26, 2019 18:48:36)

WindOctahedron

I don't think that it needs to be added, because the workaround is very easy to make:

<((n) mod (2)) = [0]> // outputs "true" if the number is even
<((n) mod (2)) = [1]> // outputs "true" if the number is odd

Last edited by WindOctahedron (Dec. 26, 2019 18:33:11)

BB1000000000

WindOctahedron wrote:
I don't think that it needs to be added, because the workaround is very easy to make:
<((n) mod (2)) = [0]> // outputs "true" if the number is even
<((n) mod (2)) = [1]> // outputs "true" if the number is odd

That's what I said at the end of the post: you can use the

() mod ()

and the

[] = []

blocks together to recreate the function of the supposed new block, but I think that the new block would be easier for New Scratchers to understand and comprehend, and to reduce the file size of more complex projects.

fdreerf

BB1000000000 wrote:
That's what I said at the end of the post: you can use the
() mod ()
and the
[] = []
blocks together to recreate the function of the supposed new block, but I think that the new block would be easier for New Scratchers to understand and comprehend, and to reduce the file size of more complex projects.

1.) When will an even/odd block be useful, let alone understood, by New Scratchers?
2.) How will one block reduce the file size of a project when it will most likely be used once or twice?

WindOctahedron

BB1000000000 wrote:
WindOctahedron wrote:
-snip-
That's what I said at the end of the post: you can use the
() mod ()
and the
[] = []
blocks together to recreate the function of the supposed new block.

I saw it, I just wanted to show you the full workaround.

but I think that the new block would be easier for New Scratchers to understand and comprehend, and to reduce the file size of more complex projects.

I agree that it would be easier to understand; I've seen some users who said “when I joined, the only block I didn't understand was the ”mod“ block”.
However, I disagree with the fact that it would take up less space. All blocks are groups of commands/calculations, and those commands/calculations are made of simpler commands/calculations, and so on. Some commands/calculations (and blocks) require more simpler commands/calculations to be executed, so they take up more space. Following this logic, “_ is even?” would take up as much space as the workaround I posted.

45afc4td

As mentioned, bitwise operations on a single bit like this are easily workaroundable.

So, you are suggesting this programming concept:

(x & 1) == 0

(x & 1) == 1

On an integer x, a bitwise & operation on a single bit, a power of two, is achieved like this:

((((int x)/(65536))mod(2))*(65536))

65536 is a power of 2. This is only for powers of 2; the code for arbitrary & operation on doubles is more complicated.

In turn, int(x) is workarounded as

((((([floor v]of(x))mod(4294967296))+(2147483648))mod(4294967296))-(2147483648))

However, the mathematical odd/even booleans are not dependent on signed 32-bit overflow, so it can be ignored. Because the power of 2 in the and is 1, the divisions and multiplications can be skipped. As a result, the programming concept converts to

<(([floor v]of(x))mod(2))=(0)>
<(([floor v]of(x))mod(2))=(1)>

However, it casts x to an integer. However, in mathematics when a number is not an integer, it is neither odd or even. So, an extra condition is required:

<<(([floor v]of(x))mod(2))=(0)>and<([floor v]of(x))=(x)>>
<<(([floor v]of(x))mod(2))=(1)>and<([floor v]of(x))=(x)>>

And this is the final workaround.

No, you cannot always use “the shorter code”:

<((-0.99999999999999985) mod (2)) = [1]>

It returns true. However, the double -0.99999999999999985 is not an odd number, as it's not an integer.

<<(([floor v]of(-0.99999999999999985))mod(2))=(1)>and<([floor v]of(-0.99999999999999985))=[-0.99999999999999985]>>

That properly returns false. -0.99999999999999985 is a distinct double from -1 and can be detected as not an integer.

I would have used -0.9999999999999999 for that example, but for some reason Scratch 2.0 interprets that as -1.

MrFluffyPenguins

fdreerf wrote:
BB1000000000 wrote:
That's what I said at the end of the post: you can use the
() mod ()
and the
[] = []
blocks together to recreate the function of the supposed new block, but I think that the new block would be easier for New Scratchers to understand and comprehend, and to reduce the file size of more complex projects.
1.) When will an even/odd block be useful, let alone understood, by New Scratchers?
2.) How will one block reduce the file size of a project when it will most likely be used once or twice?

When would

<((n) mod (2)) = [0]>

be understood by New Scratchers though?

Last edited by MrFluffyPenguins (Dec. 28, 2019 03:04:51)

fdreerf

Mr_PenguinAlex wrote:
When would
<((n) mod (2)) = [0]>
be understood by New Scratchers though?

That doesn't answer my question on when it'd be useful.

45afc4td

Mr_PenguinAlex wrote:
fdreerf wrote:
BB1000000000 wrote:
That's what I said at the end of the post: you can use the
() mod ()
and the
[] = []
blocks together to recreate the function of the supposed new block, but I think that the new block would be easier for New Scratchers to understand and comprehend, and to reduce the file size of more complex projects.
1.) When will an even/odd block be useful, let alone understood, by New Scratchers?
2.) How will one block reduce the file size of a project when it will most likely be used once or twice?
When would
<((n) mod (2)) = [0]>
be understood by New Scratchers though?

Is this better?

<<(([floor v]of(x))mod(2))=(0)>and<([floor v]of(x))=(x)>>
<<(([floor v]of(x))mod(2))=(1)>and<([floor v]of(x))=(x)>>

Nambaseking01

45afc4td wrote:

Is this better?

<<(([floor v]of(x))mod(2))=(0)>and<([floor v]of(x))=(x)>>
<<(([floor v]of(x))mod(2))=(1)>and<([floor v]of(x))=(x)>>

Is this supposed to be sarcasm? Because that workaround is more complex than the ones suggested,

—

Should I ask you why you want this block when the workaround is obvious? Fine, some blocks might actually be there even though the workaround is simple but this one is maths. We can't sit adding every single mathematical calculation into Operations just because there already exist a few.

I might as well add binary calculators, Pi radius counters, and so on… Don't you understand that maths is almost endless?

Sheep_maker

Some programming languages require the mod workaround for even vs odd, so forcing Scratchers to use this workaround would better prepare them for those languages (though in many of those languages you are able to define utility procedures to make your code easier to understand, so maybe Scratch should just add custom reporters)

const isEven = n => n % 2 === 0
 
console.log(isEven(10)) // true

However, languages like Racket have even and odd procedures

By the way, typically when dealing with even vs odd, it's implied that one is working with integers

BB1000000000

Nambaseking01 wrote:
45afc4td wrote:
Is this better?
<<(([floor v]of(x))mod(2))=(0)>and<([floor v]of(x))=(x)>>
<<(([floor v]of(x))mod(2))=(1)>and<([floor v]of(x))=(x)>>
Is this supposed to be sarcasm? Because that workaround is more complex than the ones suggested,

—

Should I ask you why you want this block when the workaround is obvious? Fine, some blocks might actually be there even though the workaround is simple but this one is maths. We can't sit adding every single mathematical calculation into Operations just because there already exist a few.

I might as well add binary calculators, Pi radius counters, and so on… Don't you understand that maths is almost endless?

I would absolutely agree that the more complex version is even harder to comprehend by New Scratchers, and unless the number can be a floating-point (contains a decimal point) negative number, that the simpler workaround should be used instead. (The one with the

(() mod ())

and the

 <[] = []>

blocks combined together).

fdreerf

Nambaseking01 wrote:
Is this supposed to be sarcasm? Because that workaround is more complex than the ones suggested,

You learn something new everyday.
Anyway, this topic should be closed by now, there's a simple workaround to block suggested.

Starstriker3000

fdreerf wrote:
Nambaseking01 wrote:
Is this supposed to be sarcasm? Because that workaround is more complex than the ones suggested,
You learn something new everyday.
Anyway, this topic should be closed by now, there's a simple workaround to block suggested.

Just because there's a workaround doesn't mean it should be closed just for that reason. In fact,

LastContinue wrote:
Literally everything is workaroundable, the ATs figured out the minimum amount of blocks needed to use Scratch at one point, all else is “workaroundable”.

BB1000000000

Starstriker3000 wrote:
fdreerf wrote:
Nambaseking01 wrote:
Is this supposed to be sarcasm? Because that workaround is more complex than the ones suggested,
You learn something new everyday.
Anyway, this topic should be closed by now, there's a simple workaround to block suggested.
Just because there's a workaround doesn't mean it should be closed just for that reason.

fdreerf wants the topic closed, while Starstriker3000 thinks the topic should stay open. I am going to leave the topic open, in case anyone else wants to add to the information in the forum topic/thread.

MrFluffyPenguins

Support, would be useful for cool games and s t u f f

mica43683

I don't think you'd need the dropdown. Just use

<() is even?::operators>

and

<not <() is even?::operators>>

Za-Chary

mica43683 wrote:
I don't think you'd need the dropdown. Just use
<() is even?::operators>
and
<not <() is even?::operators>>

But “not even” is not the same as “odd”. For example, 1.5 is neither even nor odd.

I suppose this could be fixed if the block returned something like NaN for non-integer values.

BB1000000000

Za-Chary wrote:
I suppose this could be fixed if the block returned something like NaN for non-integer values.

I don't think that it would be possible, because to my knowledge Boolean blocks only return true or false, not numbers or strings (text). If it was a reporter, it could return a string, number or other non-binary values.

Sheep_maker

It should just return false for non-integers

BB1000000000 wrote:
Za-Chary wrote:
I suppose this could be fixed if the block returned something like NaN for non-integer values.
I don't think that it would be possible, because to my knowledge Boolean blocks only return true or false, not numbers or strings (text). If it was a reporter, it could return a string, number or other non-binary values.

Boolean blocks are supposed to return true or false by design, but technically they can return anything. Apparently Scratch considers NaN as falsy:

<not <((0) / (0))::#8BC34A>> // true

< _ > block is from my extension

Za-Chary wrote:
mica43683 wrote:
I don't think you'd need the dropdown. Just use
<() is even?::operators>
and
<not <() is even?::operators>>
But “not even” is not the same as “odd”. For example, 1.5 is neither even nor odd.

I suppose this could be fixed if the block returned something like NaN for non-integer values.

If someone is dealing with even vs odd, they're probably already limiting their domain to integers

However I think also adding an odd? block would help with readability

Discuss Scratch