# Incosistant number formatting in web player vs simulator

TLDR: when i divide by a fraction, the number is displayed with the decimal point in the simulator but not in Pulp's web player

Details:
I noticed that the score when played in the web player is an integer (as I'd expect)

However, when i export the same game to pdx and play it in the simulator:

The score is always a whole number,but I am dividing it by a number (which has a value of 0.5, 1 or 2 ) to scale the score, but the resulting number is always a whole number. Interestingly in this case I'm just dividing by 1, but I'm guessing once I divide by a number it changes from an integer to a float.

For reference, here is how the score is calculated:

``````		turn_score = 0
_i = 0
virus_score = 1
while _i < virus_counter do
virus_score *= 2 // each virus cleared in one turn awards an increasingly large score
turn_score += virus_score
_i++
end

// divide by "drop_rate_scaler" to award more points when on higher difficulty
turn_score /= drop_rate_scaler

// add this turn's score to total score
score += turn_score
``````

if i `floor` the number along the way, it shows up without a decimal point in the simulator as well:

``````		// divide by "drop_rate_scaler" to award more points when on higher difficulty
turn_score /= drop_rate_scaler
turn_score_int = floor turn_score

// add this turn's score to total score
score += turn_score_int
``````

1 Like

Whoa, this ended up being a really meaty issue (that revealed an even meatier issue). I have a solution. But it comes at a performance cost on actual hardware.

Basically to mimic the Lua’s number formatting, I have to track the lifetime of any number that is divided or added to, subtracted from, or multiplied by a float. This requires wrapping each arithmetic operator in another function so the JavaScript bridge has a way to maintain that history.

But this would affect the speed of every arithmetic operation regardless of whether the numbers flowing through them were destined to be displayed or not. I’m not comfortable with that trade-off.

I think the solution here is just to note in the docs where the web player and Lua runtime differ. In this case, integers are integers until divided or otherwise mathed with another number that is or has been a floating point number. If an integer is desired then you must `floor` the number before display.

Oh, and the meatier issue is that the Lua runtime uses a single-precision floating point format while JavaScript uses double-precision. Which probably won’t be an issue for the math Pulp games will demand. I have updated the JavaScript runtime to match the Lua formatting for floats (eg. instead of `3.142857142857143` the web player will now match the Lua truncated length of `3.142857`).

Oh wow! Having to `floor` a number to make it look nice in a display is definitely a small price to pay for avoiding a performance hit on every arithmetic operation!

Thanks for looking into it!

1 Like