Kata

Right, thanks: Python fixed :+1:

Deleted

No, try now.

Happy now. :-)

Cool, thanks for spotting it, Tachyon :)

I would rather put it in a comment of the template code, but as you see fit.

Comment added.

Ruby to my knowledge does not seem to have that method available

Maybe you should implement the comparison with margin yourself, then? And C++ does have EqualsWithDelta.

It would help if CodeWars made it available. Can we suggest that somewhere? I also have code for Haskell available ( stolen from someone else, but I don't remember who ).

Hi johan, toFixed is notoriously trash and is quite unriable. Take a look at the following :

console.log(35.855.toFixed(2)) // This gives "35.85" which is wrong, should be "35.86" and not .85

As you can see that is wrong, Another example :

console.log(1.275.toFixed(2)) // This gives "1.27" which is also wrong, should be 1.28 and not 1.27

Reason for the following :

1.275 when converted to binary has the following representation :

= 0b1.01000110011001100110011001100110011001100110011010......
         ^^^^

Since it has infinite digits, it cannot be represented exactly in a computer unless you use an arbitrary precision library. JavaScript numbers do not use such library for performance reasons.

Since the original value has already lost precision before it even reacheed JS, rounding it will not improve the persicion in anyway.

Hope that explains.

@__i so what? These 2 examples tested with Python's built-in round give me the same result - 35.855 --> 35.85 and 1.275 --> 1.27. Does this also mean that Python's round is a notoriously trash and unreliable function?

I figured something like that when I took a look at 2.55 * 100 ( it has the same problem. 2.55 is in the MDN article ).

But you can't blame toFixed for that; it's basic floating point representation inaccuracy. Everything that works with floating point values suffers from the same problem. Including, apparently, Python's round.

Anyway, thanks for your answer. ( The concise answer would be "it works with floating point values". )

Does this also mean that Python's round is a notoriously trash and unreliable function?

Well, yes. :]

Though it would be more correct to say floating point values are notoriously trash and unreliable. After all, they are.

Python is not unreliable: it behaves precisely the same in those 2 cases; JS's .toFixed() is unreliable for other reasons, see link below.

Though it would be more correct to say floating point values are notoriously trash and unreliable

This. People can go to any length to trash something, having no idea what the real root of the problem is. Though, I must admit that reading an explanation why rounding functions are bad because computers can't round numbers like people do is funny.

Also, turns out no one simply copy-pasted this explanation from stackoverflow. Way to show how knowledgeable he is XD

And guess what? I never heard about it.

Plus the kata is already pretty easy, at least let them round!

Problem is it's not numerically safe.

If my result is 1.4449999999, because I did things in a different order, and your result is 1.4450000001, I'll fail the test. And I shouldn't.

Flooring or ceilinging instead of rounding just shifts the universe by .5.

That means I now have to read your mind, in what order you want calculations done. Or look at Unnamed's solution.

Really, approximating is better. With IEEE.something(704?) double precision floating point values, there will always be the possibility of a representation error.

I'm surprised that after so many occurrences of faulty translations and issues, Giacomo is still not following best practice often enough.

You see, there are lots of issues in your translations for a reason ;-)

@JohanWiltink, this problem seems pretty straightforward to me and even the solution you mention apparently passes the tests without any issue. For the range considered, I would expect either no or extremely rare occurrences of rounding not working.

Is that method supported across all languages?

@Voile, I am surprised that given your skills you don't find any better use of them than to try to be randomly mean and obnoxious, probably for the sheer pleasure of feeling somebody under your thumb. Considering the amount of translation I did, I would say that the issues are around 1% or so, otherwise I would get flooded with that. There is definitely room for improvement, but I don't even think there is any need to point that out, is it?

If so, what was your contribution supposed to bring?

It seems that you're, again, assuming things about me more than the issue at hand. So let's be clear here:

1. Doing any floating point comparisons without threshold is straight out bad kata design. Bad kata design should never be tolerated, or it teaches people bad things. Frankly, if it was me I'd have raised this as an issue instead. Some people may dislike me raising issues all over the place, but that's just me growing a huge distaste on improperly designed kata: they've been proven to cause confusion and frustration to everyone in the future.
   (Of course, if rounding is required you'd need to make sure random tests don't generate cases that cause some values to be in the rounding boundary, but it's fragile.)
2. Floating point errors are not anything new at all, it happens in CW so often I specifically put it in a separate entry in the github wiki. I'd expect a veteran from CW to have understood a commonly occurring elementary concept (just like "don't make your random tests break if user mutates the input") and not do that in the first place.
3. ...So you're aruging 1% translation issue rate is not very high? There is, ideally speaking, only one acceptable value: 0%. There's no excuses to this. In fact I'd say even once per month is too high.
4. And in the end, what do you expect me to say then? If you've written katas/translations that has issue, of course I'm going to tell you to be careful next time. Happens multiple times and/or you're not getting the actual issue being raised, then I'd tell you to really get better, and perhaps takes some better practice, like copying a whole set of random tests from a known working language to a translation you're working on. In fact I'm not the only one who has pointed it out before.

Anyways, just remember this: when we're raising suggestions/issues, we know what we're doing and we really mean it, so arguing otherwise is often pointless unless you also absolutely know what you're doing. But it seems like you don't from time to time, so... just listen to us and make the changes. It'll be better for everyone, we promise.

Ok, now that's better:

1. I assume you being disliked or not depends more on the tone, oftentimes, than it does on the content itself. Again, this specific kata, had a clear range in mind and I see very unlikely that people will have issue with it - there are even solutions with the very unreliable .toFixed(). Knowing of the method Johan was suggesting just now, I might implement it later.
2. Glad that you took your time to update the github wiki, but despite being a veteran (or not), I do not live for CW and I completely missed such update: how was I supposed to know about it, specifically?
3. I am not arguing about being high, much less it is a point of being acceptable or not: writing bugged, imperfect code - particularly at the first run - is merely physiological. I am glad you are apparently immune from it and I long to read your manuals on the new "0% bugs software development" (after a lot of crappy fad which are often more common sense wrapped into marketing than anything remotely useful, that one should be a smash hit and for a good reason!), but until then, I see little grace from this original sin.
4. I think I clearly stated already what I was expecting: a more constructive feedback (particularly if addressed to newbies, but I know how you think about it already...). I am not sure why you did bother to make a search and grab a comment in which FArekkusu was actually wrong. Twice, as he pointed out a flaw in an old translation meant to support only P2 and it referred to another kata in which he did the mess. He was definitely right in another number of occasions, not this one. Also, how come that somebody gifted enough to write 100% correct code does need to resort to peer pressure to prove his point?

Similarly, spare me where you talk as "we", as your opinion might not match everybody else, even limiting it to powerusers/veterans/whatever you want to call them, as it happened multiple times before.

As mentioned, I will consider editing it later.

Thanks for the advice anyway :+1:

Thank you for fixing.

However, if you're using assertApproxEquals, there should be no rounding. Rounding to two decimals introduces an error of up to .005, which is more than the 1e-9 assertApproxEquals allows. Comparing approximately after rounding has the same problem as comparing exactly after rounding.

Addressing your earlier questions:

This method may not be supported across all languages. Unfortunately. But you can always write a simple wrapper yourself. The JS source is in here. ( For Haskell, I have something lying around; just ask. It's not really easy in Haskell, but lots of things in Haskell testing aren't. )

Unnamed's solution passes the tests, but it has an entirely different way of getting at the answer. So even guessing the order in which the reference solution does the computations does not help - you might get at an ever so slightly different answer, even if maths say they're the same ( because it's not a maths error, it's a representation error ).

If I may give an example: you'd expect Math.hypot(5,1) and Math.sqrt(26) to be the same. They aren't. And rounding has the possibility of introducing much greater errors even ( see original comment ). That is why you do not want to round and you do want to compare with a margin for error.

So, uhm, sorry, not fixed.

Mh, somebody really has fun downvoting today.

Got it for the use of it, I will fix it later; I still insist that given the range of the tests, an error in that regard is highly unlikely. Concerning .toFixed(), see here for example; it is known to be discouraged if you need high-precision computations.

downvoting

That wasn't me, and I didn't think you deserved it. So I actually upvoted you again.

toFixed is not more or less unreliable than everything else that touches IEEE754 ( I looked it up :) floating point values. If you need high-precision computations, don't touch floating point values with or without a 10' pole.

Thanks in advance for fixing it later.

Oh, sorry if I was ambiguous: the thought that you might have downvoted never even crossed my mind. I think I can make some educated guess about that.

About .toFixed(), you might see more of its inconsistency running something like this snippet:

for (let i = 10; i < 100; i++) console.log((+`0.${i}5`).toFixed(2) == +`0.${i}`)

A similar script with Math.round() gives much more reliable results.