• This will have a merge conflict since the description update to fix the pictures. You may want to fork it.

  • Add ascii value of memory cell to the output tape.

    Although the random tests are extremely unlikely to generate cases with non-ASCII characters, it would be better if it's checked after generation, at least for self-documenting purposes.

  • Approved. I hope it's good, as I don't know Java...

    • Hi.
    • Thanks a lot for the translation
    • I have checked the translation and might have noticed some mistakes, but not sure if those are actually mistakes, since I'm not a professional in Java))
    • Hence -> please post the translation link in the comments section with a following comment like Java translation - please see and approve, so that another powerfull user who knows Java will be able to check it.
    • For now the only thing I would ask you to do is add the following block of text into the description of the kata, where it says 'Write a function':
     ```                <- looks like this

    This is supposed to be done in order to provide the proper function name for all the Java users, solving this kata. See the link for more info: https://github.com/codewars/codewars.com/wiki/Markdown-Formatting#sequenced-code-blocks

    • cheers
  • Hey, thanks for the translation !

    • could you rename the method doubleToIEEE_754 ? the num was for JavaScript's data type Number
    • since Java has both floats and doubles , could you also implement a floatToIEEE_754 method, like I did in the C version ?

    cheers :)

  • Seems to be solid now, approved :)

  • Changed getRandomDouble() to generate less NORMALIZED and more other types.

  • We're getting closer to approval :)

    I checked out your getRandomDouble and there is a problem. Since you're just making a double out of random bytes, numbers that come out will almost always be NORMALIZED numbers, because the probability to randomly generate 11 times the same bit in a row for the exponent is extremely low ;-).
    And thus, the tests are not torough enough because someone could just check the sign and return POSITIVE_NORMALIZED or NEGATIVE_NORMALIZED and still manage to pass.

    What you could do to make it more comprehensive is to generate a random number to decide if the exponent will either be :

    • only 0s , for DENORMALIZED numbers and ZEROES ;
    • only 1, for NANs and INIFNITYs
    • random, which will almost always be NORMALIZED for the reason stated above

    you can do something similar for the mantissa, except that you dont need the case where it's entirely composed of 1s


  • I did use enum at first but it kept failing to detect class name so I used class instead.
    While keep trying to use enum in Preloaded, I noticed that the file name of Preloaded is determined by class keyword so I found a workaround by putting class FloatTypeEnum in a comment and declaring FloatTypeEnum as enum.

  • I'm glad you figured it out :)

    Another point is that you could use a real enum to represent the float types.
    enums are used in the C and Python versions of the kata and it's the most natural data type to make tags.

    The reason I didnt use an enum in Javascript is that Javascript ... does not have enums ;-).

    You could write something like so :

    enum FloatType {
    public class Solution {
        public static FloatType getNumberType(double d) {

    which feels a lot more natural and readable ;-)

  • It is my bad. When I tried -Double.NaN like JavaScript, the sign remained unchanged so I thought it was unobtainable and provided an extra method to produce it. I assumed the same for POSITIVE_SIGNALING_NAN and NEGATIVE_SIGNALING_NAN as I could not find those in JavaScript and I did not know how to obtain them instead of converting from binary string.
    I found that Double.longBitsToDouble(long) can be used to produce those values so I removed the said method.

  • Hi, thanks for the translation :)