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

lol

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

already handled here

done

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

Codewars works by receiving code as a piece of text from your web browser; saving it to a file ;executing it on their server with the appropriate compiler/interpreter; and returning the output to your browser. It follows that you can get information on the system that runs your code by calling the appropriate commands.

It's easy to establish that the server runs on Linux because of the low-level nature of C (for example the __linux__ macro is defined); web servers also typically run on Ubuntu, and the x86_64 architecture has become almost ubiquitous for desktop computers. But you can make sure of that by running something like this on Codewars (i wrote it in C because it is the only language you trained, but you could do the equivalent in almost all the other languages on Codewars):

void print_os (void)
{
#ifdef __linux__
    char buffer[256];
    FILE * fp = popen("lsb_release -c -d", "r"); // lsb_release prints the OS info
    while (fgets(buffer, sizeof buffer, fp) != NULL) 
        printf("%s", buffer);
    fclose(fp);
    fp = popen("lscpu", "r"); // lscpu prints the architecture info
    while (fgets(buffer, sizeof buffer, fp) != NULL) 
        printf("%s", buffer);
    fclose(fp);
#endif // you could add more test macros and code for Windows, etc.
}

Use this function on Codewars (just call it in the function you're supposed to write for the kata) and you will see:

Description:	Ubuntu 18.04.6 LTS
Codename:	bionic
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              4

So we know the endianness, OS, and architecture.

how are you associatting these termss with the code ?

C is a compiled language and C compilers generate lower-level assembly code for a specific architecture. We've established that Codewars runs on Linux x86_64, so we only need to search which calling convention is used: the System V ABI. A calling convention is a way to precisely describe how functions are to be called in assembly and how they return. It specifies which arguments are to be put in which registers by the caller, what the callee has to restore before returning control, etc. Without a calling convention, the different parts of a program could not talk to each other and it would be impossible to write reliable code.

is an IEEE754 double number

IEEE 754 is a techincal standard/specification for floating-point numbers. It's so widely adopted that it's become almost synonymous with them. Almost all programming languages use it for their float and/or double datatypes.

what made you think it was little endian was it the assembly code ?

we've established that Codewars runs on a Little-Endian machine, so the bytes that represent the float value are going to be hardcoded in little endian order in the executable files (on disk) as well, as they will be directly loaded into memory (RAM) in the same order.

linker cares about is that there is something called multiply associated with a callable piece of code

You should experiment with compiling and building C programs that are split between several files to get a better understanding of the process. The peculiarity of the Codewars setup is that it uses no header (.h) files, unlike most large C programs. The command basically goes like cc user_code.c tests.c. Due to the absence of header files there is no mechanism to ensure that types are compatible between the two files. All tests.c knows (from a declaration) is that there is a function int multiply(int, int) that it can call, but nothing prevents you from writing e.g. double multiply(int a, float b, short c) instead in user_code.c (which is the file that you edit when you train on a kata), and it will still compile and run (but will behave strangely); you can see it for yourself.

can you name the resource materials, concepts that I would need to learn in order to have knowledge like this.

I have known (not in great detail) about these things for some time now and it would be hard for me to give advice to a beginner on the best way to learn in 2025, especially within the current AI boom. Many Wikipedia articles give in depth descriptions of subjects such as calling conventions; cppreference.com is a good reference on C/C++ specifically, godbolt.org is good to see what your code compiles to in different languages/environments/compilers, I often use tsnippet.trust-in-soft.com to find bugs in my C programs. But none of these tools are aimed at beginners.

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 ?

. Returned object should be the new-style class, which has only to inherit the base methods of the class object.

this line in the description is irrelevant since Python3

approved

tests require proper @it() / @describe() blocks and explicit import of test and class_name_changer

approved by someone

in the initial code, class ReNameAbleClass(object): is legacy from Python2 and should be changed to the more modern class ReNameAbleClass: