data entry fields and decimals

Hi there, Vic!

It looks like you have 9 total characters with a decimal point (so a decimal and 8 digits). The acceptable answer field should allow for 14 digits, so technically the number 922185.33 shouldn't cause any issues.  I'm going to clarify with my team about that discrepancy.  

I'll keep you posted on what I find out! Sorry about the trouble. 

great thank you! 

Another related and similar problem... 

I have set it up so that you can reveal the correct answer - e.g

When you preview and click it seems to populate the variable as 922185.3 not 922185.33 like it should.

Thanks!

Vic

Ok - this is getting really weird... I tried with the next data set and same thing - the bigger numbers didn't register as correct (shown by green rectangle around answer).

So I did the reveal answer thing as above to see what happens - and these are the numbers it threw out (triggers for reference)

If I start the preview from scratch and enter the weird numbers that it populated the variables with, it recognizes them as correct.

The variables aren't used elsewhere

Any ideas? I just updated Storyline just in case that was the problem but it wasn't.

Thanks

Vic

Hey Vic,

Thanks for reaching out and sharing some additional details. 

Alyssa has filed this as a potential bug for our team to take a closer look at. I do not have an update to provide at this time.

This conversation is attached so that we can pop in and update you here when we have additional information to share.

@Vic - thanks for starting this thread!

@ Leslie & Alyssa - thanks for making sure we're not lost!

We are running into similar problems with the number of digits. If there are more than 7 digits, the calculation starts rounding, even without decimals. For example, input 12345678 into box 1, with a trigger to add the contents of box 1 to a total, and have a text box display the total. The total display  shows 12345680.  Input 12345674 the total displays 12345670. If decimals are involved, eventually you see the 2nd place fall off as mentioned in Vic's comments.

I'm in state government, working with accountants and auditors, so seeing numbers that large really isn't something unexpected. All the examples we see on Heros using calculations and numeric input are using smaller numbers (i.e. car payments, weekly groceries, etc.)

I've attached a quick example file with notes.

We're starting to suspect it's the numeric variables being based on scientific notation, even if it's not converting to the same format for extremely long numbers.

@Trey - All of Storylines inbuilt operations (addition, multiplication, subtraction, division) will change the result to a precision of 7 significant digits (except for integer multiplication).

Not entirely sure why (haven't looked into it).

But yes, that means that any integer or floating point number with more than 7 digits (that aren't 0's added at the end) will lose precision when using "Storyline arithmetic". I.e. 12345678 (becomes 12345680) or 123.45678 (becomes 123.4568)

The only workaround I can think of, without starting to "fix" Storyline's player code yourself, is to do any calculations needing more in Javascript triggers. The variables can hold more precision - the same as Javascript normally can, meaning the largest "guaranteed precise" integer is 9007199254740991. It's the operations that do the rounding.

There are, however, some unrelated bugs in how Storyline stores numeric variables for resuming a course later. It won't store decimal digits at all, and integers beyond 4294967295 (32-bit) - possibly even half that number (i.e. signed 32-bit) - will be stored very randomly.

Hey Jimmi, thanks for popping in. I dropped this in just to have an additional example. We haven't encountered the random storage issue, but then we're not using it much except for one course we're creating. I'm working with my other developer to create the java to handle this. The storage by itself for calling the variable doesn't seem to be an issue for us. I'll use Java to do the math then return the response as a text variable for later use.

I think the part that's frustrating for most users who finally encounter it is we're all spoiled by how well math works in PP. lol

I've also just realized this is a change in behavior from SL 2 to SL 3. I found an old calculator from Preston Ruddell created in SL 2 for ELC #162 ( https://community.articulate.com/discussions/articulate-storyline/freebie-automatic-calculation ) [*Note I had it in a download folder labeled REALLY COOL IDEAS] that does the calculations with a different numbers, but shows the actual answer. I tested it with 9 digits, and get the response I would expect.

Hi Everyone,

I am happy to share that we just released the newest version of Storyline 360 (Build 3.36.21213.0) this morning! With this release, we fixed the numeric-entry questions that are evaluated incorrectly, even when learners entered the right answer.

The next step is to update Storyline 360 by heading to your Articulate 360 desktop app and clicking "Update" next to Storyline 360.

As always, we are happy to answer any questions you have by posting in this discussion, or you can contact our Support Engineers directly here.

Vincent - Sorry to report I updated my SL360 and tried the example I included in this thread, and still get the same results. If I enter a value of 12345678 and have it add to a total, the reported total is 12345680. If I add 123456.88, the reported value is 123456.9. I also just discovered the total changes if I put the values in the example in the opposite box.  For example, If I put 12345678 in box 1, then 123456.88 in box 2, I get 12469140 in the total. If I reverse these, I get 12469130 in the total.

Verified build 3.36.21213.0 in about.

I've added it to here Review360 if anybody wants to just see it without downloading.

Thanks, Trey.

I've opened a support case on your behalf with the original file that you shared so that our team can take a closer look and work with you 1:1 on this.

You should be hearing from someone soon.

Yeah, looking through the player code in update 36, nothing has changed in terms of calculations on variables. It still seems like someone added toPrecision without knowing exactly what it does (described in my previous post). There's no actual reason to use toPrecision that I can see. There might be a semi-valid reason (floating point wackiness - e.g. 0.1 + 0.2 = 0.30000000000000004) for rounding to e.g. 7 decimals, but that's not what toPrecision(7) does.

Hi, 

Is this possible to add 4 number after decimal? I am trying to do this but it round off the numbers by default and show incorrect feedback while enter complete value. Please provide solution,  Thanks

Hi Monika,

It's possible to add 4 numbers after the decimal when using a numeric entry field as well as a variable. The number variable will be looking for a whole number, but the text variable can handle the thousandths place.

I've attached a quick sample file and here's a quick demo:

Do you know what version of Storyline you're using?

You can check by going to:
Help > About Articulate Storyline

We are currently on Build 3.40.22208.0 of Storyline 360. You can read all of the details here.

Is there any movement on this issue please?

I'm using Storyline 360 V3.48.24159.0 and still experiencing something similar - I've to validate against a number to 6 decimal places. To do this previously (for 4 decimal places) I've multiplied the input by 10000 then testing against a whole number, e.g. enter 59.3333 - scale up and check against 593333 - all works fine.

I've now got an example where the correct answer is 14.180024 - using the same logic as above by multiplying by 1000000 - when displaying the variable gives 14180020 rounding down the last digit. I've even tried using the same multiplier and testing against a decimal e.g. 141800.24 this gives 141800.2 dropping the last digit completely.

Hi Paul,

Thanks for reaching out! It would help to take a look at your file for further testing on this and confirm the issue. Can you share it privately with our support engineers so they can take a closer look?