Weird Decimal Values

Game Development ChoiceScript Help
1

Um, can somebody explain this to me why this is happening?

I tested on CSIDE and Dashingdon.

*temp a 3
*temp mod 1.1
*set a (a * mod)

Which results in: 3.3000000000000003

Changing a’s value results in:

4 * 1.1 = 4.4
5 * 1.1 = 5.5
6 * 1.1 = 6.6000000000000005
7 * 1.1 = 7.700000000000001

Here's my actual code which has different results:

I’ll only include the relevant bits.

*create smart_mod 1.0

After picking some choices:

*set smart_mod 1.1

*gosub_scene code stat "smart" 3 "I've always liked numbers since I was a toddler." 2

Here’s the gosub:

*params var amount msg type
*temp num amount

*if {var&"_mod"} > 1
	*set num (amount * {var&"_mod"})  //(3 * 1.1)
*set {var} +num

Now the message part:

*temp numount (num-amount)
(+${amount} @{(amount != num) [+${numount}]|}

…which displays:

(+3 [+0.30000000000000027] Precocious) I've always liked numbers since I was a toddler.

I don’t know about this precocious toddler, but I’m pretty sure the result of (3.3 - 3) should just be 0.3.

It’s also weird since the above code said the result was 3.3000000000000003.

Changing the value of “amount”:
1 = 0.10000000000000009
2 = 0.20000000000000018
4 = 0.40000000000000036
5 = 0.5
6 = 0.6000000000000005
7 = 0.7000000000000011

There seems to be a pattern, but it doesn’t make sense.

I managed to solve it by adding:

*set numount -(numount modulo 0.001)

which makes it 0.3. But…

Where are those decimals coming from?

1 Like
2

Chirping in. @dfabulich

*temp x 3
*temp f 1.1
*set f * x

Results in: 3

*temp x 3
*temp f 1.1
*set x * f

Results in: 3.3000000000000003

2 Likes
3

Oh! I got a little bit excited thinking that switching the order gave the right result. :sweat_smile:

But that’s even more wrong!

Thanks for testing it too.

1 Like
4

Lel :stuck_out_tongue:
I always tried all possible things whenever I found peculiar thing like this.
In fact, the… fact that it has a different result by simply swapping the order is peculiar.

Makes me think, what about +/-//?

1 Like
5

Floats are weird.

Basically, computers can’t store decimals (or “floating point values”/“floats”) properly, and thus using decimal values will often result in “floating point errors” (i.e. what you’ve got). In proper programming languages there are ways around it, but in CS, I’m not really sure how you could fix it. :confused: Would it be possible to just have 11 instead of 1.1?

4 Likes
6

@Franzinyte
You may want to just move the decimal over like this:

*temp a 3
*temp mod 11

*set a (a * mod)
*set a (a / 10)

a = ${a}

Haven’t tried this under all circumstances, but I have hopes for this process.
Let me know if it works for you?

1 Like
7

Well, that works! I was thinking of multiplying and then dividing, but my brain is fried right now.

I don’t have time to test it on the subroutine, but I probably wouldn’t need it now actually, since I found the extra information just a clutter.

But I’ll keep it in mind. Thanks! :hugs:

Still, it’s a huge bug with decimals.

1 Like
8

I mean, I don’t know what you expect, there are literally whole websites dedicated to this problem: http://floating-point-gui.de/

1 Like
9

Welp, now I’m feeling like a jerk, summoning Dan for such an obvious thing.

Umm, the more you know, I guess? :grimacing:

1 Like
10

Well, I didn’t know. :neutral_face: If I was in another language I might’ve considered looking it up (I thought it might be CS specific), but hey, at least @Carlos.R gave me a solution.

@Szaal I’d say that multiplication order thing you found is still a bug though. I think. :stuck_out_tongue: