I'm pretty sure you can have numbers with more than 6 decimal places, TheLogFather made a calculator for pi that could calculate to hundreds of thousands of digits, so there must be a way.

Sigton

Sigton wrote:

I'm pretty sure you can have numbers with more than 6 decimal places, TheLogFather made a calculator for pi that could calculate to hundreds of thousands of digits, so there must be a way.

Sigton

He may have logged each number place to make it; I've experienced the same, having numbers that round up.

Sigton wrote:

I'm pretty sure you can have numbers with more than 6 decimal places, TheLogFather made a calculator for pi that could calculate to hundreds of thousands of digits, so there must be a way.

Sigton

There are calculators which store numbers as strings, and operate on them digit-by-digit. They're complicated to make though, and I think it would be OK to add this suggestion (which just affects the display). It could be a right-click option on the variable watcher, with an option like “set number precision” or something like that.

However, there is an easy way to force the number to display as a string: join a space onto the end of it. It is better to use a separate variable for the display and update it when needed, that way you can keep the working variable as a number and you don't have to convert it all the time.

There is still a limit of ~14 decimal places on any number variable, but I don't think they could change that without changing every project, or by changing how variables are created to let you pick a type.

Sigton wrote:

I'm pretty sure you can have numbers with more than 6 decimal places, TheLogFather made a calculator for pi that could calculate to hundreds of thousands of digits, so there must be a way.

Sigton

I'm talking about variable display.
In https://scratch.mit.edu/projects/134874196/
This happened:
http://i.imgur.com/e59otd8.png
I clicked 1.4142135, and these buttons only use join function. The “number” treatment messed up this. The solution is as easy as simply joining them and showing them this way, and only treat them as “numbers” when needed. Therefore I type 0.100000000000000001 and it remains that way, then another number 0, and when I add them it's calculated using floating point, resulting in 0.1. But what it actually does is show me 0.1 when I type. I hate it.
Also it does weird things like 999999999999.0001 instead of 999999999999.

Another calculator has the exact same problem:
First version: https://scratch.mit.edu/projects/2249855/
Current version: https://scratch.mit.edu/projects/11655635/

So like some implementation of bigfloat calculations?

Sigton

Sigton wrote:

So like some implementation of bigfloat calculations?

Sigton

No, I'm talking about changing the view of variable.

set [ v] to [1.4142135]

This will display variable as 1.414214, even though the double float used in Scratch can store a lot more.

set [a v] to [1.4142135]
wait (1) secs
set [b v] to [10]
wait (1) secs
set [c v] to ((a) * (b))

This will display variable as 1.414214, then b as 10, then c is shown to user as 14.142135. It stores it in double float but user sees a mere 6 decimal places. Also in the first script it didn't say anywhere to treat it like “number” and limit it to 6 decimal places.

If I had to guess, I would say that this is likely something to do with Flash's implementation of converting floats to strings, but I could be wrong - I have seen the same behavior, for example, in displaying floating point numbers in C with printf without specifying precision to print with.

If that is the case, the only change that needs to be made is that the float-to-string display conversion needs to be done manually, or with a higher precision function, and those are both pretty simple to do, so support.

TheMonsterOfTheDeep wrote:

If I had to guess, I would say that this is likely something to do with Flash's implementation of converting floats to strings, but I could be wrong - I have seen the same behavior, for example, in displaying floating point numbers in C with printf without specifying precision to print with.

If that is the case, the only change that needs to be made is that the float-to-string display conversion needs to be done manually, or with a higher precision function, and those are both pretty simple to do, so support.

Look at this script:

set [a v] to [1.4142135]

Where did it say to treat it like “number” and convert it to 6 decimal places? There is no need to treat it like “number”. 1.4142135 is a pure string until used in operations like this:

((a) + (1))

But when I click on it, it says all decimal places that float can show. Only when I show variable it shows it limited to 6 decimal places. Say blocks limit it to 2 decimal places.

set [a v] to [1.0000000000000000001]

The block above… It will display 1. I didn't type 1 in, I didn't do any arithmetic, but it's stored as 1 due to float limitations, and it shows as 1.

set [a v] to ((1.4142135) + (0.00000000000000000001))

The block above gets stored as 1.4142135 (which is fine, due to float limitations, and doesn't need to be fixed) but variable display is bad, showing 1.414214.
When no arithmetic is done, it should just treat it as if it was a string and display what was written.

set [a v] to (join [1.414213] [5])

The above is not arithmetic operator, it's string operator so it should display 1.4142135.

So what I was suggesting is that it should keep it as string until arithmetic is done. Then report result of arithmetic blocks as a string.

Scratch variables can store up to 16 decimal places. Why it only shows 6 in variable watchers, I have no idea and I believe that should be changed.

3 minutes later

I did some testing. It's worse than that.

• The variable watcher will show 6 decimal places only if the whole number before the decimal is x where -2 < x < 2. Also x has to be a 1 digit number. “00” counts as a 2 digit number.
  
• If you try to put the number 1.2222222222222 in a variable watcher by adding each digit one by one like this:
  

  set [a v] to (join (a) [1]) 

  You'll get 6 decimal places. Try to add them in reverse order like this:
  

  set [a v] to (join [2] (a)) 

  You'll get 16 decimal places.
  

Well, welcome to Scratch.

Alberknyis wrote:

Scratch variables can store up to 16 decimal places. Why it only shows 6 in variable watchers, I have no idea and I believe that should be changed.

3 minutes later

I did some testing. It's worse than that.

• The variable watcher will show 6 decimal places only if the whole number before the decimal is x where -2 < x < 2. Also x has to be a 1 digit number. “00” counts as a 2 digit number.
  
• If you try to put the number 1.2222222222222 in a variable watcher by adding each digit one by one like this:
  

  set [a v] to (join (a) [1]) 

  You'll get 6 decimal places. Try to add them in reverse order like this:
  

  set [a v] to (join [2] (a)) 

  You'll get 16 decimal places.
  

Well, welcome to Scratch.

But I can't do them in reverse order since what I'm using join blocks for is a calculator with buttons that insert a character. 792, press 1 -> 7921

Workaround: always join a space at the start for any var that you're actually showing. Scratch will then treat them as a string when showing in the variable watcher.

They will still be treated as numerical in all mathematical expression, so you don't need to change any other script.

For example, if the var being shown is called ‘result’, and you have something which multiplies it by variable ‘a’:

set [result v] to ( (a) * (result) ) // 'result' will only be shown to six d.p.

Instead, you would just do:

set [result v] to (join [ ] ( (a) * (result) )) // that first gap contains a space character

TheLogFather wrote:

Workaround: always join a space at the start for any var that you're actually showing. Scratch will then treat them as a string when showing in the variable watcher.

They will still be treated as numerical in all mathematical expression, so you don't need to change any other script.

For example, if the var being shown is called ‘result’, and you have something which multiplies it by variable ‘a’:

set [result v] to ( (a) * (result) ) // 'result' will only be shown to six d.p.

Instead, you would just do:

set [result v] to (join [ ] ( (a) * (result) )) // that first gap contains a space character

This bug is still annoying. When I set variable to 1.4142135, it shows ugly 1.414214. It's more intuitive to have this fixed than to use workaround. It's not intuitive that

set [variable v] to [1.4142135]

would display 1.414214. This whole problem makes me hate the word “number”!

Please bump this topic!

I need this topic bumped

HI ChatUSer2.

I've avoided replying to this for a while, but you've continued to bump this, thinking that it may be possible to ‘fix’ what you see as a ‘bug’.

Unfortunately, I can't imagine that what you want will be useful to have, generally. Indeed, I can't even imagine how it could be done in a sensible and consistent way…


It's kinda complicated to explain, but the bottom line is that what you want will only serve *your* desires in *this particular* situation (and a number of other limited cases).

It may be worth you stopping for a while to consider in more detail how your proposal would behave more widely – i.e. what Scratch would show in general, for all other projects where there are mathematical operations giving numerical values in variables that have watchers showing.

I'd be interested to know your thoughts about that…

Scratch should have “accurate variable viewer” option.
It shows the string representation. If it doesn't exist, it converts floating point number to a string without rounding.

Hello,

I am creating a Pi calculator, and ran into this same problem. However, I just managed to fixed the problem, by setting a variable to a space joined with my equation, tricking Scratch into thinking that what I had set the variable to was a sting. Strings can not be rounded, so Scratch left it alone. The code is displayed below:

set [Variable v] to (join [ ] (Number))

Or, if you are looking to do an equation that gets inputted into a variable:

set [Variable v] to (join [ ] ((A) / (B)))

Just be sure to add a space to the first join input.

(join [(SPACE)] (Whatever You Want))

I will post a link of my finished project when it is done.

I hope this helps.

Hmmm…I've never experienced something like this before? Contact the Scratch Team if any more problems exist.

(Do not request this to be closed, there still might be a solution!)

I think the variables get rounded so that you won't have infinitely-repeating decimals, like 1/3.