yeah sorry about that, you reminded me about this kata and I started revamping a lot of awkward stuff I wrote years ago, and I tried to unify the description instead of relying on per-language blocks. you will have to fork the current translation, it is the only way to resolve a merge conflict; thanks for choosing the enum too

It won't be too unidiomatic, I think, as many projects also use table-emulated enums in Lua.

Also, since the original description has changed, I copied the new description and made a change to it. But the diff of the descriptions are a mess now, and I don't know how to resolve it.

approved

the other languages use an enum (except JavaScript where I tried to emulate one with an unmodifiable object whose keys are equal to their values). I tried to cobble together something equivalent for Lua, which does not have native enumerated types:

Preloaded:

local float_types = {
    "POSITIVE_DENORMALIZED", "NEGATIVE_DENORMALIZED", "POSITIVE_NORMALIZED",
    "NEGATIVE_NORMALIZED", "POSITIVE_INFINITY", "NEGATIVE_INFINITY",
    "POSITIVE_ZERO", "NEGATIVE_ZERO", "POSITIVE_QUIET_NAN",
    "NEGATIVE_QUIET_NAN", "POSITIVE_SIGNALING_NAN", "NEGATIVE_SIGNALING_NAN"
}

local FloatTypeBase = {}
for _, value in ipairs(float_types) do
    FloatTypeBase[value] = value
end

-- see https://www.lua.org/pil/13.4.5.html : Read-Only Tables
-- we use a proxy table for __index and override __newindex to prevent modifying the "enum"
local metatable = {
    __index = FloatTypeBase,
    __newindex = function(_, key, value)
          error("Cannot modify the enum")
    end
}
FloatType = setmetatable({}, metatable)
return FloatType

user solution:

local FloatType = require 'setup'

local function get_number_type(x)
-- return a member of the FloatType table, which emulates an enum:
    return FloatType.POSITIVE_DENORMALIZED
end

return get_number_type

tests:

local get_number_type = require 'solution'
local FloatType = require 'setup'

describe("solution", function()
    it("test for something", function()
        assert.are.same(FloatType.POSITIVE_NORMALIZED, get_number_type(0.5))
    end)
end)

What do you think ? is it too awkward / unidiomatic ?

i thought that scientific notation is easier to understand and more informative for beginners (for example it gives a better idea of how small subnormal numbers are), and I for one cannot easily read the hexadecimal notation. but if you think it's better it's not that big of a deal

I just think it's better to use hexadecimal notation here. Do you want me to switch to decimal scientific notation?

thanks for making the changes, is there a particular reason why you use the hexadecimal notation for the floating point literals ?

Lua translation!

Lua translation

I love how lua is like "oh you can't do that" and then has a random ass function that does it instead of making you manually convert stuff

Hello, I've updated the translation. Please review.

Hello, thanks for the translation. I am not experienced in Lua and have a few remarks:

• i think readability and maintainability would improve by wrapping the assertions in a function, e.g. (modify as you see fit):

local function do_test(expected, input)
    actual = number_to_ieee_754(input)
    message = string.format("for input %.17g\n", input)
    assert.are.same(expected, actual, message)
end

• why do you need to compute nan in preloaded ? can't you do have it in the tests, like

  local nan = -(0.0 / 0.0)
  

  ?

• In standard Lua, the type number can represent IEEE 754 DP values.

  I feel like the wording is ambiguous and can mislead beginners. How about something like "until Lua 5.3, all numbers were IEEE 754 DP. Since 5.3, numbers variables can also hold 2s complement integers". What do you think ?

Lua translation

Lua translation!

Good!