PkmnQ wrote:

6d66yh wrote:

PkmnQ wrote:

Scratch is not meant for C coders. Scratch is meant for those who want to learn to code. If you want Scratch to be more like C, go to Snap.

Snap is not more like C, as it lacks integer arithmetic, therefore it is off-topic to this suggestion.

Then code it yourself. Advanced stuff like this should be programmed in. Plus, Snap may be easier to implement this in. But they probably will not be natively implemented. Scratch runs on JS, not C. And I think JS doesn't have 64 bit integers.

That goes against the entire point. The point is that the integers are native, and I use them to build more complex abstractions. Not the other way around as that would significantly slow down the program rather than speed it up.

6d66yh wrote:

PkmnQ wrote:

6d66yh wrote:

PkmnQ wrote:

Scratch is not meant for C coders. Scratch is meant for those who want to learn to code. If you want Scratch to be more like C, go to Snap.

Snap is not more like C, as it lacks integer arithmetic, therefore it is off-topic to this suggestion.

Then code it yourself. Advanced stuff like this should be programmed in. Plus, Snap may be easier to implement this in. But they probably will not be natively implemented. Scratch runs on JS, not C. And I think JS doesn't have 64 bit integers.

That goes against the entire point. The point is that the integers are native, and I use them to build more complex abstractions. Not the other way around as that would significantly slow down the program rather than speed it up.

It'll run slow anyway. This is Scratch. And as I said, JS doesn't have 64 bit integers natively.

PkmnQ wrote:

6d66yh wrote:

PkmnQ wrote:

6d66yh wrote:

PkmnQ wrote:

Scratch is not meant for C coders. Scratch is meant for those who want to learn to code. If you want Scratch to be more like C, go to Snap.

Snap is not more like C, as it lacks integer arithmetic, therefore it is off-topic to this suggestion.

Then code it yourself. Advanced stuff like this should be programmed in. Plus, Snap may be easier to implement this in. But they probably will not be natively implemented. Scratch runs on JS, not C. And I think JS doesn't have 64 bit integers.

That goes against the entire point. The point is that the integers are native, and I use them to build more complex abstractions. Not the other way around as that would significantly slow down the program rather than speed it up.

It'll run slow anyway. This is Scratch. And as I said, JS doesn't have 64 bit integers natively.

But the developers could use an asm keyword to use native instructions. And check out the definitive list in my signature, it is not just 64-bit integers.

but maibe someone is using a 32 bit os to access scratch (raspberry pi OS 32 bit) not to mention that people could use a 16 bit os if they had enough technical knowledge they could maibe add the blocks in a extension named advanced math with more advanced mathematics blocks in it to solve the proplem with the dubble floats i recommend you to just use more than one per integer like maibe 2 dubble floats per 1 64 bit variable i do not know so much about binnary things so plz correct me if i am wrong

6d66yh wrote:

But the developers could use an asm keyword to use native instructions. And check out the definitive list in my signature, it is not just 64-bit integers.

Ok, fine, you have a lot of reasons to implement it, but all of them combined are outweighed by one reason not to implement it:
Scratch is meant as a beginner programming language.

6d66yh wrote:

PkmnQ wrote:

6d66yh wrote:

PkmnQ wrote:

Scratch is not meant for C coders. Scratch is meant for those who want to learn to code. If you want Scratch to be more like C, go to Snap.

Snap is not more like C, as it lacks integer arithmetic, therefore it is off-topic to this suggestion.

Then code it yourself. Advanced stuff like this should be programmed in. Plus, Snap may be easier to implement this in. But they probably will not be natively implemented. Scratch runs on JS, not C. And I think JS doesn't have 64 bit integers.

That goes against the entire point. The point is that the integers are native, and I use them to build more complex abstractions. Not the other way around as that would significantly slow down the program rather than speed it up.

Even if Scratch somehow supported these “native integers”, there would be very little performance improvement. Scratch is slow because it's an interpreted programming language, not because it uses floats instead of integers, and this suggestion does nothing in the way of solving that.

This suggestion is completely infeasible, would have negligible benefits, and would serve primarily to confuse new Scratchers about different types of numbers. Scratch is not meant to be a C, it is meant to be an introductory programming language, and these “64-bit integers” are completely unnecessary.

i am very confused…

WHAT??

PkmnQ wrote:

(#85)

6d66yh wrote:

But the developers could use an asm keyword to use native instructions. And check out the definitive list in my signature, it is not just 64-bit integers.

Ok, fine, you have a lot of reasons to implement it, but all of them combined are outweighed by one reason not to implement it:
Scratch is meant as a beginner programming language.

I think keeping it for advanced scratchers is ok.

if [advanced v] scratcher detected :: #009999 hat
add [Harder v] coding languages :: #009999 cap

AFNNetworkK12 wrote:

No support. Scratch is supposed to be simple, that would be confusing to younger people.

Then remove the trig from the scratch editor to.

Oh look, a necropost!

JavaScript doesn't have a distinct integer class of numbers. Pretty much every number in Scratch is a float. But the nature of these numbers, any number less than 2^53 - 1 has perfect to the ones place accuracy.

It's not 64 bit, but it's practically 53.

I do think it would be nice to have more precision. Custom number systems in Scratch are painfully slow.

IndexErrorException wrote:

(#92)
JavaScript doesn't have a distinct integer class of numbers. Pretty much every number in Scratch is a float. But the nature of these numbers, any number less than 2^53 - 1 has perfect to the ones place accuracy.

It's not 64 bit, but it's practically 53.

I do think it would be nice to have more precision. Custom number systems in Scratch are painfully slow.

Indeed.