OK

the what

8to16 wrote:

Only read like 2 paragraphs into the wikipedia page you linked and it's pretty obvious this doesn't fit with the Scratch Design Goals. It should be easy to climb in and get started with Scratch - even for Scratchers who have no experience programming. I guess this is rejected.

How? If you re-read it, this is simply just a way to minimize floating point errors, such as 0.1 + 0.2 = 0.300…004. This would instead minimize confusion and prevent some rounding errors making scratch easier to get into, rather than harder.

GamesReinvented wrote:

8to16 wrote:

Only read like 2 paragraphs into the wikipedia page you linked and it's pretty obvious this doesn't fit with the Scratch Design Goals. It should be easy to climb in and get started with Scratch - even for Scratchers who have no experience programming. I guess this is rejected.

How? If you re-read it, this is simply just a way to minimize floating point errors, such as 0.1 + 0.2 = 0.300…004. This would instead minimize confusion and prevent some rounding errors making scratch easier to get into, rather than harder.

It still wouldn't eliminate them. The only way to truly eliminate them would be to introduce an integer data type (and possibly a fraction data type and maybe decimal data type?), but that's a very different suggestion.

IT WELL MAKE NUMBER LIMIT BIGER

GamesReinvented wrote:

(#7)
How? If you re-read it, this is simply just a way to minimize floating point errors, such as 0.1 + 0.2 = 0.300…004. This would instead minimize confusion and prevent some rounding errors making scratch easier to get into, rather than harder.

oh i misread

but that will be kinda slow right? also what if somebody intentionally uses floating point rounding errors to make a project, if the error is different that will break projects

IT NOT slow

jvvg wrote:

It still wouldn't eliminate them. The only way to truly eliminate them would be to introduce an integer data type (and possibly a fraction data type and maybe decimal data type?), but that's a very different suggestion.

As I said, minimize.

8to16 wrote:

Dingineer549 wrote:

(#4)
https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format

Only read like 2 paragraphs into the wikipedia page you linked and it's pretty obvious this doesn't fit with the Scratch Design Goals. It should be easy to climb in and get started with Scratch - even for Scratchers who have no experience programming. I guess this is rejected.

Just because the ceiling is higher doesn't make the floor harder to get on. I don't understand octuple-precision floating points yet but I still want them, seems like they could help me code better, and also help me with more advanced programming languages.

also, the wikipedia link is the wrong one. The one were looking four is Octuple, not quadruple. quadruple doesn't work for planck units where extreme precision is required. https://en.wikipedia.org/wiki/Octuple-precision_floating-point_format

we should also add sexdecuple (the tuple for 16) floating points /j

I mean like five people would probably use it ever, but sure. Why not.

bjagain wrote:

I mean like five people would probably use it ever, but sure. Why not.

let's be honest, a griffpatch tutorial would form and it would become (semi) common knowledge

bump

bump

I will point out that the way Scratch currently stores floating-point numbers is the way JavaScript, the language Scratch 3.0 (and most of the interactive stuff on the web) is programmed in.

To change that, and still have the Online Editor exist, they would have to implement some sort of system that would probably wind up being somewhat laggy and slow, and likely wouldn't be perfect anyways.

BigNate469 wrote:

I will point out that the way Scratch currently stores floating-point numbers is the way JavaScript, the language Scratch 3.0 (and most of the interactive stuff on the web) is programmed in.

To change that, and still have the Online Editor exist, they would have to implement some sort of system that would probably wind up being somewhat laggy and slow, and likely wouldn't be perfect anyways.

That's what I was thinking. Scratch would need to implement their own custom system to eliminate floating point errors, since it's just using javascript for the math.

However, floating point errors don't show up on the variable watchers. So it really isn't a noticeable issue, but this means that Scratch does already have some sort of system to fix floating point errors.

And even though the issue isn't noticeable, I can still certainly see it causing confusion. For example, a floating point error would say that a variable is not equal to 0.3, even though the variable watcher says it is 0.3. And the length would show 19 instead of 3, and joining it would also join the floating point error.