IMHO , for the parameteers instead of 'new_stock' , the term 'delivery' or 'new_delivery' seems more appropriate to the objet of the calculations

Just checked. There are two "if"s and two "me"s

I'll remove the duplicates when I have a moment

Thanks

Hi

I have filtered the words beginning with 'if' from dictionnary. result : ['if', 'if']

Is it normal to find duplicates in the dictionary ?

Has anyone seen the picture announced in the description ?

You've renamed the function. The way the tests work is that they call your function with the function argument. If you rename the function, the tests try to call a function that doesn't exist which will cause an error. Also, the function input is a string, so your function wouldn't work correctly even if it had the correct name.

I agree , yesterday I wrote a post with the same source above. I am a newbye in round function :)

Nevertheless, to avoid issues with the different modes of calculations, dont you think that an unique rounding is more appropriate.

the result depends on the parity of the last unit before the dot .

Is this really strange? This is what the "half to even" rounding mode is, a.k.a. "banker's rounding". It is also documented.

sorry to have launched such an animated discussion :) , but I discovered the strange behaviour of round with that kata :

370+370 * 0.15 = 425.5 and round(370+370 * 0.15) = 426

270+270 * 0.15 = 310.5 and round(270+270 * 0.15) = 310

the result depends on the parity of the last unit before the dot .

In that kata , IMHO , the issue is that we understand we must made a first rounding to get an integer and after a second rounding to round to 5 if the unit of the first rounding is between 1 and 4. ( the same with values between 6 and 9 to round to the next tenth)

With an unique rounding (the second one) , no issue : if the result is >x0.0 , you round the price with x5. with a result >x5.0 you round the price to (x+1)0

It's..not my own criteria? They're completely valid test cases that are avoided because people write code that produces incorrect results.

Are you really arguing that their math is right and if only float was an exact data type it would produce correct answer and therefore their code that produces wrong answer should be considered correct? -- What if they used a freaking exact data type like they meant to then? Incorrect code should fail.

I understand the argument of reducing repeated discourse posts but I don't agree with that either. At what point do we start accepting incorrect solutions in other kata as well? Well done you passed 95 out of 100 tests, A+

If your argument is that the kata rank and author intention is to use float, then the kata is inherently incorrect and shouldn't be allowed to exist due to reinforcing misuse of float. That stuff needs to be nipped in the bud. Idk what your argument is because you don't say, instead you only say that I don't understand or something to that effect. Well, how could I?

BTW the rounding step makes no sense to begin with, it leads to cases that are LESS than a 15% increase (contradicting the description) and there already is a rounding strategy to int in rounding up to a multiple of 5. Rounding twice seems ill advised and I question what the kata author's motivation is for including that, maybe that is again something to do with float. It is very suspiciously worded: "An additional requirement:" kinda like "note" where an author simply adds something on afterwards to fix something, instead of adjusting the description.

Guys, you're working in revese, here. As long as the ref solution itself is wrong according to your own criteria, there is actually no reason to discard any of those approaches.

Now if you update the ref, you can try to enforce that, but I have strong doubts about what will happen with other users.

there is not reason to discard any of round(x+x*0.15), round(x*1.15) or x+round(x*0.15)

I mean, I do not really agree with this. The reason to discard some of these and accept the others is that some of them can produce correct answers in the given range of inputs, and some might not. The ones which do, can be accepted (if any). The ones which don't - should not. And the baseline of "correct" could be established by implementing the solution with pen and paper first, and then translating it to code using the same internal representations. I am pretty sure you would not use floats on paper. My point is that introducing inaccuracies in a solution is a user error. We already have similar situation with, for example, the Tortoise Racing kata.

(don't forget to mention this is also because the ref solution is also using floats, and that there is not reason to discard any of round(x+x*0.15), round(x*1.15) or x+round(x*0.15))

@hobovsky

I think I still do not understand the problem :(

if you mean what me and B4B disagree on, what I don't like is that the tests skip over the cases where float may cause incorrect results, here:

    def rndprice(fn):
        while True:
            n = fn()
            if abs(n*1.15%5 - 0.5) > 1e-9:
                return n

the kata doesn't say to use floats, so it is a solver's choice to write it with floats and potentially do so incorrectly (arguably incorrectly even if correct results but that's not a fight I'll pick, if it passses it passes)

because they are always present, nowadays. No random tests is an issue.