Gotcha, I changed it to assert.closeTo with a delta of 0.01 (1 percentage point), I would think that would be large enough to capture other correct calculation orders.
Now the issue is that people that do calculations in a different order than the reference solution may fail tests when they shouldn't ( even fixed tests might be affected ). Testing should be done with assert.approximately instead of assert.equal ( or, in both cases, an equivalent ).
This is documented, but the whole subject is a wasps' nest.
I knew calculations with floating point numbers aren't always precise so I figured rounding and converting to a string may avoid that. Another thought I had would be to have the input expect 0-100 as a "percentage" and output a float from 0-100. Do you think that would help?
I see no specification of order of operations, so the kata is dealing with inexact values regardless. It's also theoretically possible to extract the floating point values from the output string and compare these with the required margin for error to the expected value.
Author should have just picked a task limited to integers for his first kata. This is going to be a nightmare any which way. It should probably be fixed by an experienced author.
Note that percentages encoded as strings would be ok(ish), if calculations would be kept in a precise domain. If inputs were precise decimal values (potentially encoded as strings), or precise fractions, or anything like this, then string encoded decimals could be acceptable in some languages. But in this kata, inputs are (despite of what the description claims) not decimal values, but they are binary floating point values, what can cause problems if the final result is expected to be precise.
Added, thanks!
Maybe add more tags like statistics and probability
Yep, that should work. :]
Gotcha, I changed it to assert.closeTo with a delta of 0.01 (1 percentage point), I would think that would be large enough to capture other correct calculation orders.
Now the issue is that people that do calculations in a different order than the reference solution may fail tests when they shouldn't ( even fixed tests might be affected ). Testing should be done with
assert.approximatelyinstead ofassert.equal( or, in both cases, an equivalent ).This is documented, but the whole subject is a wasps' nest.
Changed from strings to floating point.
Fixed, thank you for catching that!
This comment is hidden because it contains spoiler information about the solution
Thanks for the tip! I added a loop for random tests.
I knew calculations with floating point numbers aren't always precise so I figured rounding and converting to a string may avoid that. Another thought I had would be to have the input expect 0-100 as a "percentage" and output a float from 0-100. Do you think that would help?
I see no specification of order of operations, so the kata is dealing with inexact values regardless. It's also theoretically possible to extract the floating point values from the output string and compare these with the required margin for error to the expected value.
Author should have just picked a task limited to integers for his first kata. This is going to be a nightmare any which way. It should probably be fixed by an experienced author.
Note that percentages encoded as strings would be ok(ish), if calculations would be kept in a precise domain. If inputs were precise decimal values (potentially encoded as strings), or precise fractions, or anything like this, then string encoded decimals could be acceptable in some languages. But in this kata, inputs are (despite of what the description claims) not decimal values, but they are binary floating point values, what can cause problems if the final result is expected to be precise.
Do not encode percentages as strings. Encode them as floating point values, with all difficulty that entails.
Ideally you should have around 100-200 random tests. You can create a loop to generate and run the tests. See this guide for more information: https://docs.codewars.com/languages/javascript/authoring/
Ok I updated it, let me know if that works.
Loading more items...