@Firefly2002: yes, indeed i did. However, after the new note, i simply removed my vote, as i feel i would not have done so, had the note already been in place. The voting is "How satisfied are you with this kata?", which is rather subjective. In this case, i spent more time reading about some library i am not interested in (for mentioned reasons), than actually solving the problem. It was also an unexpected issue, i thought the library would not cause problems for such straight-forward use. This caused me to be slightly unhappy about the kata, which, for a voting system like this, which is not fine-grained enough for a "slightly unhappy", results in the related vote.

@FArekkusu: Iirc the mentioned note was not there when i solved the kata. You coming here, just to write something like this, should tell anyone who was not involved a lot already. For anyone bored enough to wonder, here is the related debate he is referring to: https://www.codewars.com/kata/return-negative/discuss/javascript - it's the issue that was posted by me and has 17 replies. PS: this part of the answer got cut short, due to me following advice from people i asked about the situation, which was "don't waste your time with people like that".

Technically, numbers in JS are floats, but in reality they are integers

You took some of the good stuff today, didn't you?

@Deantwo what i originally complained about was only that a function which returns -0 for an input of 0 passes, even though the description sais that

makeNegative(0) //return 0
Zero (0) can't be negative, see examples above.

which imho clearly requires that a return of -0 is not allowed. That would invalidate a lot of solutions though, so perhaps slightly rewording the description may be preferrable.

PS: this discussion exists on the top voted javascript solution aswell.

Apart from you missing the .toString(2) on the other side: (X >>> 0).toString(2) === (0).toString(2), do you even realize for how many numbers that is true? Do you want to argue now that 0.5 is the same value as 0? Or 4294967296 is the same as 0? Even NaN would be the same as 0 by your logic. If you mean that Int32 does not have signed zero (note here that javascript >>> behaves as if on UInt32, which obviously doesn't have signed zero), yes, but i don't see how that relates to the topic at all.

The description explicitly says (i am now repeating quotes i already made in this same thread):

makeNegative(0) //return 0
Zero (0) can't be negative, see examples above.

If that is not explicitly saying that makeNegative(0) should not be -0, i don't know what would.

PS: the point is exactly that they are different in their binary representation, but i already noted that...

You know 0 and -0 are not the same number, so why are you then arguing as if they are?

When I get a function, that by spec explicitly should not return -0 for an input of 0, but returns -0, it's a mistake. Whether you like it or not. If it wasn't specified too strictly, one would have to research what it does for these cases - but given the details as-is, I don't understand how you can even try to debate it.

You seem to know Object.is. I expect you know 1 / -0 vs 1 / 0, or what they look like when writing to a typed array and reading the related bytes. They obviously make differences in code and are not some "magical being".

Edit:
Reading through the comments again, i don't actually know for sure whether you are aware. 0 and -0 have different binary representations in float, which also behave differently for some operations. 0 is 0000...0000₂ (64 digits), while -0 is 1000...0000₂ (64 digits) for javascript number, which as noted uses float64 IEEE754-2008. They are part of the denormals of IEEE754, but the specifics are a longer topic and don't belong here.

Javascript does not have integers (in the sense you are talking about) - 4.3.20 Number value - primitive value corresponding to a double-precision 64-bit binary format IEEE 754-2008 value, though you can sometimes emulate them (e.g. with bitwise operators or typed arrays).

I did what had to be done, so that people will see the issue. I don't intend to waste my time with this any more.

Making a "turn negative" kata and not adding a proper remark about -0 is asking for it.

This is programming and not math. IEEE754 has negative zero and is almost the absolute standard for float in all languages (including javascript's number). The description explicitly states

makeNegative(0) //return 0
Zero (0) can't be negative, see examples above.

Yet if i write a function returning -0 for said input, there is no problem.

Javascript (and potentially other languages): Faulty or missing test cases for potential -0, although the case is explicitly mentioned in the description (the kata is too old to change test cases, but afaik the description can still be modified).

This has been mentioned here before, but imho is simply a mistake and should be an issue, not some half hearted comment that can be ignored.

Javascript: Add a description note that e.g. (5, 10, 5) and (10, 5, 5) are not to be taken as different solutions. This is heavily implied by the examples but never mentioned explicitly. It was previously clear due to the "c<=a<=b" remark, which however doesn't make too much sense as was already noticed. From what i can see, "a <= b" is enough.

Don't have enough time right now but sounds fun and short - maybe i'll do it later.

However, just to confirm, the map is always rectangular without boundaries inside the rectangle, right? Because the map format allows for all sorts of fancy 2D map shapes.

+----+  +----+
|B...|  |B...|
+--+.|  +--+.|
|....|     |.|
+----+     +-+

Where the empty spaces on the latter would potentially be filled by either spaces (which wouldnt be in the list of recognized symbols) or just some border symbol.