Crazy arithmetic

v2: Troubleshooting
1

I try to compute something:
${22*10.8} in therory is 237.6
but SB returns
237.60000000000002
someone can explain me?

2

The intricacies of floating point arithmetics - the easiest way to handle this is to just use string.format("%.2f", value).

3

SB also considers the speed of light and time dilation caused by gravitational anomalies and passing gravitational waves. That extra 0.00000000000002 is just spacetime curvature. Or maybe SB is calculating in a 15-dimensional floating-point hyperspace.
You’re just seeing a projection artifact from a parallel universe. Totally normal.

JK

:smiley:

3 Likes
4

yes but the result is wrong string.format is a mask

5

The problem is fundamental, nothing to do with SB. It's the way computers work. See the article I linked to.

6

lua online editor => return the correct answer
Strange?

7

It probably does some masking. Try 22*10.8 == 237.6 in the online editor. I suspect it will say false.

8

SilverBullet's Lua implementation leans on JavaScript math, which is maybe different than Lua's "native" floating point math. @mjf did some work to align the two, but don't remember if he touched the floating point aspects there as well.

1 Like
9

Indeed javascript evaluates 22*10.8 to 237.60000000000002

1 Like
10

In the current Edge version, the calculation is correct.
${22*10.8} return 237.6

11

See UPDATE at the bottom, please.

@zef @malys This is intentional (at least for now). We do plain JS arithmetics for the most common arithmetical operations (but not for all). I agree it should be documented somewhere where we align with standard Lua and what is JS-native. Taking note to do so soon. :slight_smile:

The decision where to draw the exact line between hybrid compromised approach we have now and the full alignment was mostly about the performance. We require Space Lua be fast, as it's interpreted on miscellaneous devices.

With current engine all we can do is to sanitize certain code paths, otherwise the performance impact would be huge. If we managed to gain 100% Lua alignment, including arithmetic boundaries and simply everything, we must rewrite it from the scratch! Really, there is no other way. With current approach we achieved at least some sensible performance and alignment compromise and the most critical paths seems to be sanitized. So, what you reach is not a bug, it's feature (although not documented anywhere yet).

You can also check the client/space_lua/arithmetic_test.lua (I stress that it must pass both standard Lua 5.4 and Space Lua execution, and it does).

Summary of what was aligned/works/etc. is bellow. To note, we gained some nice performance improvements, then we lost them and gain them again. So not much fun! The result is that, except some minor table operation performance regressions, Space Lua is even little faster now and more aligned with standard Lua than it used to be.

Add numeric result normalization for arithmetic operations:

  • Integer operations preserve int type, collapse -0 to +0
  • Float operations preserve float type, maintain -0.0
  • Division always produces float results

Fix for-loop variable type tracking:

  • Loop variable type determined by start/step parameters
  • Integer loops produce integer variables
  • Float/mixed loops produce float-tagged variables

Implement table key normalization:

  • Integer-valued floats (1.0, 2.0) normalize to integer keys
  • All zero variants (0, 0.0, -0.0) map to same key
  • Non-integer floats (1.5) remain distinct keys

Also:

Rework numeric semantics to preserve Lua integer vs float behavior:

  • 0 vs 0.0 and − 0.0 ,
  • explicit zero kind representation, and
  • updates arithmetic/bitwise coercions accordingly.

Improve parser correctness by rejecting unary plus with aligned Lua errors and better parsing errors reporting.

  • tonumber updated to Luae conversion using luaToNumberDetailed,
  • math.modf return corrected,
  • math.type accuracy improvements for float/integer and − 0.0 ,
  • math.pi added.

UPDATE

To be honest, I got myself confused with this too. In standard Lua 5.4:

> 10.8*22
237.6
> 10.8*22 == 237.6
false
> 10.8*22 == 237.60000000000002
true

@zef @malys So the behaviour is not a bug at all! It's perfectly aligned with Lua and no fix is needed. :smiley:

Lua 5.4 also returns false for 10.8 * 22 == 237.6 - for the exact same IEEE-754 reason. Both 10.8 and 237.6 are not exactly representable in binary double precision, and the multiplication result does not produce the same bit pattern as the literal 237.6. Therefor Space Lua's behaviour is correct and aligned with Lua 5.4. The display showing 237.6 via luaToString is also correct (Lua's print formats via %.14g which rounds for display; also see recent patches on edge).

1 Like