"Double" problem

[Dragonoftheworld]

So I have double-type attribute as the player status attribute, but when it changes, there will be too many decimal numbers for some reason.
Setup:

hazard.hpdeduct = 0.18

player.changedhealth:

if (player.health >= 200){
// game mechanic trigger
}

Timer (1 second):

player.health = player.health - hazard.hpdeduct

The result:
100
99.82
99.64
99.46000000000002
99.28000000000002
or
99.289999999999999
99.109999999999998
98.929999999999997
or
99.28000000000001
and so on

I've tried to do add this after deduction:

player.health= player.health* 100
player.health= Round(player.health)
player.health= player.health/100.0

but it would trigger the game mechanic (if player.health >= 200) since 99 * 100 is 9900 which is undesirable.
I could add a bool player.triggerallowed to it:

if (player.triggerallowed){
if (player.health >= 200){
// game mechanic trigger
}
}

player.triggerallowed = false
player.health= player.health* 100
player.health= Round(player.health)
player.health= player.health/100.0
player.triggerallowed = true

but what if the player is in a hazardous area and at the same time tries to get to >200 health while player.triggerallowed = false?

Is there any other solution beside mine that could work?

[Pertex]

Perhaps this helps :https://docs.textadventures.co.uk/quest/using_doubles.html

[Dragonoftheworld]

Yeah I figured it would lead to this. I'll only use doubles for displaying purposes. Thanks for the help 👍

[angelwedge]

I have wondered if it might make sense for the Quest scripting language to have some bignum decimal type; to make it easier for beginners without programming experience (who seem to be the target audience). I know that in Perl, if I want to play around with arbitrary decimals and not worry about rounding errors, I can just put use BigDecimal; at the top of the script, and it loads a library which causes it to store decimals internally as strings, and overrides all the arithmetic operators to work with that. I suspect C# has a library which could be wrapped up in a Quest data type to provide similar functionality, making these situations a lot more intuitive for non-programmers.