7 kyu
Distance from the average
2,673 of 4,303GiacomoSorbi
Loading description...
Arrays
Lists
Statistics
Fundamentals
Data Science
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
JS here. Why would the only test that's failing be the one with a super long array as param?
I didn't understand why I should calculate the mean - the value. For me it would make more sense to calculate the value - mean, because if the value is 12 and the mean is 10 I would get 2 more. The way it's asked for here gives -2, when in fact, I collected 2 contacts more. What didn't I understand correctly? There is no way everyone did this wrong, without questioning.
push in attempt with cpp. the test doesn't work.
Should be fixed, to some extent.
doesnt this also resolve this and this ?
Oh it solves one, but the other is still there and needs a stringizer for doubles. I did not add it, but yes, it would be needed to make presentation of errors better.
Not sure why, but attempt keeps timing out. Using Python. Not calling any special libraries. Help?
Let's say the list has 1 million elements, You're adding them 1 million times, that's slow. Think if you need to do that.
why in nparray I have a right answer, but when I want to use data.tolist() i get it: 4.200000000000003, -35.8, -2.799999999999997, 23.200000000000003, 11.200000000000003 i tried to round by np.round and round every nunmber in list, but it,s unsuccessfull It's awful kata, if you worry about your nervs
there kind of is an issue here even if you're not stating what it is, but in any case it's a duplicate issue. your code is also not rounding as requested, you're not getting this behaviour as a result of using numpy, but as a result of not doing the requested actions.
the actual issue here being that 4.2 isn't representable by float and yet it compares by == instead of approx equals. as mentioned, an open issue exists for that.
I need help with roundind. [4.2, -35.8, -2.8, 23.2, 11.2] All tests are passed but "Execution Timed Out (12000 ms)".
How can i use """With Clojure to round use: (defn roundTo2 [n] (/ (Math/round (* n 100.0)) 100.0))""" in python???
This comment has been hidden.
I didnt like this Kata. Bascially my code is sound and works. PAssed most of the test, but then throws errors with the long array. I think the test is broken. Because all I did was keep hitting 'attempt', without actually checning my code and it worked. I like the Kata from a stats point of view, but think the tests need looking at.
I have done the same :D
The funniest thing is that my solution has the same problem and it is the same as the best practice 😁
python new test framework is required. updated in this fork
Approved
C++ tests are broken. For example, the sample tests will fail when running just the initial tests, but the same sample tests will pass when running all the tests.
I dunno, I just opened it and solved it without issues (both sample and attempt tests). It's true that the feedback is terrible (you're seeing identical outputs, but it doesn't account for accuracy issues).
Having a quick peek at your solution, consider using
doublewhere appropriate :PDoh! Can't believe I was the that dumb intermixing float and double :(. Thanks for the help!
This comment has been hidden.
This comment has been hidden.
in JS my code perfectly work on jsFiddle but here throing errors.
I've finally read that I had to round results, but test cases for C++ showing me:
How did you solve problem?
This comment has been hidden.
Hi GiacomoSorbi and anyone else,
Would it help to specify that the average ie mean of the values should to 2 decimal places and that differences from average should be to 2 decimal places in return array?
AND / OR
Does Blind4Basics have a point where he says => JS: there are rounding troubles in the tests => the assertions should be done with a margin, not with assertSimilar
I think samtsan is also hinting at the same thing in comments below...
I noticed even 'top' solution had same problems my solution had in JS in that it worked most times but glitched here and there...
Just a thought.
Otherwise excellent kata:)
A tolerance is needed on the comparison. The out can depend on things like if you sum in an int or double, if you round the mean, and probably many other subtle things.
Added.
Hi,
i'm trying to solve your kata in Haskell and I'm interested in your
Codewars.Kata.Test.DSLmodule. Could you show it to me? I need it to run your test in my local environment.Thank you :)
I think you have more chance to get an answer on CodeWar's Discord server (there's an Haskell channel).
Missing
within_delta()with precision in sample tests of C++Added.
ExampleTests Expected: [ 4.2, -35.8, -2.8, 23.2, 11.2 ] Actual: [ 4.2, -35.8, -2.8, 23.2, 11.2 ]
and its not working? can anyone help me? thanks
i done it, problem was in rounding with 2dcs. If u have same problem, just use round math formula from the description it will work, nice kata :)
Ruby 3.0 should be enabled.
Enabled in this fork
JS: there are rounding troubles in the tests => the assertions should be done with a margin, not with
assertSimilarjs fork
I doubt the other languages accept different rounding strategies so that is still an issue for other languages
Python 3.6 is not available. Select it as the default version and VERIFY that it's working.
3.6 passes all the tests, but when I try to publish it, it gives me
Default Version is not a supported version; ideas?https://github.com/Codewars/codewars.com/issues/761
Try changing something in the tests/solution, and republish it using Python 3.6 as the default version.
Ok, works adding a random space in the code.
Python 3 should be enabled.
That to me would look more like a suggestion than an issue, but, whatever: fixed.
Python 3.6 is still not available.
C++ tests are just flat out broken, I copy and pasted the "working" code from the solutions and they all failed.
Your code isn't rounding to the nearest hundredths, per kata description. The test suite is rounding the results for display, but the underlying values are not rounded.
This comment has been hidden.
JS?
Nah C++
Can't help you then: try to post under the translator (Dentzil)'s comment.
This may be the same rounding issue that michael_gibbons was having above.
This comment has been hidden.
Can you comment under the c++ translator post?
Yeah sure i can.
Is this a post for this kata? If so where abouts is it?
Thanks.
Ah i found the thread! This issue has been reposted there!
Any hint how to round it properly in JS, mr Giacomo?
2 decimal places
Works, thanks.
Seems like this kata does not properly compare double values... rounding issues here.
A bit more info for this feed, like language and some example of bad behaviour?
I assume we can close the issue, if there are not any news...
Same issue here, C++ version.
Post under the C++ translator comment, then, so that he can be notified. Thanks :)
Fixed.
The notification doesn't work properly.
Despite setting up my rounding parts properly I'm getting some weird outputs on the first test: Expecting [4.2, -35.8, -2.8, 23.2, 11.2], instead got: [4.200000000000003, -35.8, -2.799999999999997, 23.200000000000003, 11.200000000000003]
Anyone know what's up with that? Every other test passes fine.
It does not look much like "properly" rounding, actually...
I'm in Ruby and I'm using #round(2), which should cap it off at 2 decimal places, no?
You are not using it right, then, as you probably use it on some intermediate result, so you get the rounding problem when summing it to other stuff.
random tests appear to ask for 2 decimal places.
here is the output:
Testing for 67,41,22,-29,-27,-41,49,-32,-65,42,59,89,-99,-61,-56,65,-46,10,2,-15,6,64,-77,-22,88,-7,0,-87,-27,-64,4,-18,7,-5,76,-49,-88,-61,6,64,32,55,-29,78,-24,-78,-26,27,-34,-88,12,9,-39,-80,-87,-36,-2,-81,47,56,0,-85,37,-88,-31,-79,-32,-80,-48,44,45,11,60,-39,2,76,-62,10,57,18,100,-78,9,-65,-45,68,6,70,56,78,-45,-72,4,13,-12,-16,-43,28,72,35
✘ It should work for random inputs too - Expected: [-72.24,-46.24,-27.24,23.76,21.76,35.76,-54.24,26.76,59.76,-47.24,-64.24,-94.24,93.76,55.76,50.76,-70.24,40.76,-15.24,-7.24,9.76,-11.24,-69.24,71.76,16.76,-93.24,1.76,-5.24,81.76,21.76,58.76,-9.24,12.76,-12.24,-0.24,-81.24,43.76,82.76,55.76,-11.24,-69.24,-37.24,-60.24,23.76,-83.24,18.76,72.76,20.76,-32.24,28.76,82.76,-17.24,-14.24,33.76,74.76,81.76,30.76,-3.24,75.76,-52.24,-61.24,-5.24,79.76,-42.24,82.76,25.76,73.76,26.76,74.76,42.76,-49.24,-50.24,-16.24,-65.24,33.76,-7.24,-81.24,56.76,-15.24,-62.24,-23.24,-105.24,72.76,-14.24,59.76,39.76,-73.24,-11.24,-75.24,-61.24,-83.24,39.76,66.76,-9.24,-18.24,6.76,10.76,37.76,-33.24,-77.24,-40.24], instead got: [-72.2,-46.2,-27.2,23.8,21.8,35.8,-54.2,26.8,59.8,-47.2,-64.2,-94.2,93.8,55.8,50.8,-70.2,40.8,-15.2,-7.2,9.8,-11.2,-69.2,71.8,16.8,-93.2,1.8,-5.2,81.8,21.8,58.8,-9.2,12.8,-12.2,-0.2,-81.2,43.8,82.8,55.8,-11.2,-69.2,-37.2,-60.2,23.8,-83.2,18.8,72.8,20.8,-32.2,28.8,82.8,-17.2,-14.2,33.8,74.8,81.8,30.8,-3.2,75.8,-52.2,-61.2,-5.2,79.8,-42.2,82.8,25.8,73.8,26.8,74.8,42.8,-49.2,-50.2,-16.2,-65.2,33.8,-7.2,-81.2,56.8,-15.2,-62.2,-23.2,-105.2,72.8,-14.2,59.8,39.8,-73.2,-11.2,-75.2,-61.2,-83.2,39.8,66.8,-9.2,-18.2,6.8,10.8,37.8,-33.2,-77.2,-40.2]
They do, AFAIK.
My code gives exactly the same output as expected but still it fails. ✘ Expected: [ 4.2, -35.8, -2.8, 23.2, 11.2 ] Actual: [ 4.2, -35.8, -2.8, 23.2, 11.2 ]
Language?
c++
Then post under the c++ translator post down below, so that he can get notified :)
@GiacomoSorbii adjusted a little the translation, but couldn't it re-publish because of "failed tests" (wich tests are failed i don't know). Therefore i made new fork. Can you please approve it? Thanks. :)
@sharifahmadas soon as the new fork is approved, you can try again to sumbit your solution. I hope, it'll be work fine. ;)
ok thanks
Be sure to update also the example test cases, then try to save it more than once (once in a while you get that message just because the server is not replying).
Hi GiacomoSorbi,
after i tried to save more than once (actually more than 10 times), i'm still getting the error
Kumite was published with failed tests!.Try to find them, then: example test cases? Some random one?
I seem to have this same issue (C++ as well):
✘ Expected: [ 4.2, -35.8, -2.8, 23.2, 11.2 ] Actual: [ 4.2, -35.8, -2.8, 23.2, 11.2 ]
Exactly same issue with me. :-(
Post down below, under the c++ translator post :)
Same issue with c++ Expected: [ -7.33, 48.67, -41.33 ] Actual: [ -7.33, 48.67, -41.33 ]
Hi
NickolasII,i have fixed the tests. Can you try to submit your solution once again? Thanks!
This comment has been hidden.
C#-Translation kumited.
C++-Translation kumited.
What's up with these translations?
@GiacomoSorbi,
can you please check and approve my translations? Thnaks! :)
Oh, I was notified that I got translations (no hint about which kata), just to click on a link leading to nothing; now I know which kata they were about.
Erledigt, danke!
Great! Thanx! :)
My code gives exactly the same output as expected but still it fails. ✘ Expected: [ 4.2, -35.8, -2.8, 23.2, 11.2 ] Actual: [ 4.2, -35.8, -2.8, 23.2, 11.2 ]
Hi,
can you please share your solution here and don't forget to mark it as spoiler. Thanks!)
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
Hi
StokesM,fixed. Try to submit your solution once again.
Hi Dentzil.
Thanks, its fixed, i can now submit. Just turns out at some point i have misunderstood the rounding requirements as on the submission tests i appear to be exactly 0.01 out on every answer! Haha. But then it rounds fine for the pre submission tests! Weird. Thanks for fixing that though!
This comment has been hidden.
I can't get something. On haskell I got a test break like this:
Why expected numbers are not rounded up?
I think bkaes' senpai mentioned it already, but it is about rounding errors; feel free to post under his comments down below for a certainly more educate and comprehensive answer, provided he is available :)
Oh, I'm sorry, I didn't read all the comments. But I still think, that kata looks uncertain: task description says you shouldn't round the distance value in Haskell, but test cases looks like
given [55, 95, 62, 36, 48] itReturns [4.2, -35.8, -2.8, 23.2, 11.2]. And from the first glance I can't understand why tests pass on unrounded values. But I'm a novice in haskell, so maybe I don't understand or know something. Thanks for kata anyway =)I might be wrong, as both me and bkaes-senpai are not native speakers, but the description seems to me to clearly tell no need to round your results on Haskell.
Me neither a native speaker, so I may express my thoughts pretty vague =) You are absolutely right, that the description is robust and correct. I meant, that the description tells not to round the results, but in the testcases the results are rounded. So this is a bit confusing for me. Also, the 8 test cases pass on both rounded and not rounded results, and random tests pass only on not rounded results.
I think that might be the case as the base test happen to be relatively simple, roundable numbers.
With randomness, things might get complicated; btw, always thanks for your feed :)
my code works right at my comp. but when it goes throught random tests,they fail, BUT the right solution is the same as the solution of this test at my comp. What's wrong???
Difficult to just guess it from here: care to post your formatted code with spoiler tags under here?
This comment has been hidden.
CoffeeScript translation kumited.
I was not notified about this, sorry; now approved :)
This comment has been hidden.
Don't worry, it's preloaded for you: nothing to do.
I'd like to run it locally.
I work on my solutions in an external editor so I'd like to run the code locally, including the the tests offered.
I don't think it is possible. You don't have access to the preloaded section and I'm not the Haskell translator.
Best shot at it: post under bkaes' comment and he might be notified about that.
However, you can shorten it to
That == doesn't look transitive. Don't you think it's a bad practice?
In general, yes. However, using equality tests on
Doubleis usually bad, given that(+) :: Double -> Double -> Doubleisn't associative. For example, the following loop might not halt (depends on the used floating point type, equality test, and interpretation of literals):At least
(==) :: FuzzyDouble -> FuzzyDouble -> Boolis still symmetric and reflexive. Also, none of the types are exported.Yeah, it's definitely the right way to compare doubles and the second piece of code looks good, but why call that function "=="?
Because
shouldBeFuzzyusesshouldBe, which uses(==) :: Eq a => a -> a -> Bool. That's actually the reason I useFuzzyDouble, so that I can "override" the behaviour ofshouldBeforDouble. That way, I didn't had to write the following code:Which, to be honest, seems actually smaller. Meh.
Clojure translation kumited. If you prefer I can suppress the printing of the given arrays and of the results in the random tests. I gave the rounding method to avoid discussions... I can suppress it too... all as you want:-)
I am ok with whatever you choose: you are the author of the clojure part after all :)
Thanks for you approval; I let it how it was.
I don't see your modifications in the description for Haskell about the "no-need" to round...
Mh, how strange; well, maybe it was because I had some connection trouble.
Saved again the edit and checked, now it should be fine!
Yes, fine!
@bkaes : It seems that you are not rounding to 2 decimal places or am I wrong somewhere? When I round to 2 decimals I can't pass the random tests but if I don't round at all I can pass.
Senpai is not rounding indeed: look at the preloaded code and you will see how he dealt with it.
I can't access the preloaded code... It's impossible to edit your kata (Something went wrong (500) ...). Nevertheless maybe he must edit the description because if you round (as I made in a first attempt since you ask for it in the description) you can't pass (at least I was unable to pass:-)
I am editing a Clojure version of your kata.
Oh, right: the kata is now approved, so unless you are a translator/contributor, you can't access it, I fear.
Description fixed, thanks for the warning :)
Nobody can't even be a contributor if they can't edit it.
You could have become a contributor when the kata was in beta.
Haskell translation with a completely arbitrary hspec eDSL kumited :D.
Thanks and gladly approved: I just hope that one day I will be able to write somethin in Haskell as the sweet code you put in the preloaded part.
:(. But I guess you've expected this comment.
Do you think I should change the testing code? Because right now it shouldn't be a concern, given the rounding requisite. But if I miss something, feel free to tell me.
This comment has been hidden.
This comment has been hidden.
int(...)takes an integral number, not a floating point one. Usefloat(...)instead.If I can expand senpai's answer,
intcan accept either a float value like 4.2 or a integer string like "4", but not a "floaty" string as "4.2".Then you could also spare the pain of using deviation as an index, going directly with something like
for deviation in test_listto loop through the list.You could also save a meaningless variable to optimize, changing your penultimate line with
result = [int(x) for x in result]; you certainly have to change the last, as you need toreturn, notprintthe result.Finally, I hope it is clear that you need to round values to the second decimal digit, which you are not currently doing.
Hope this helps :)
This comment has been hidden.
Yep, you are right; didn't know about .toFixed just truncating, so I edited the solution to now properly round; sorry for the about 10 good solutions that went invalid in the process, but this seemed a bit serious, so I preferred to fix it ASAP.
I agree and had many worries with the use of toFixed versus Math.round(x * 100) / 100 or Math.floor(x * 100) / 100 since in a previous version of the description Giacomo asked to round down ie to truncate:-) In fact toFixed does not round or truncate, it is simply imprevisible! Sometimes it rounds up, sometimes it truncates... About toFixed, google it and read the litterature. As bkaes said some time ago it is always better to give the rounding or truncating method in the description or to use a "fuzzy" assert_equal...
For clarification, toFixed() doesn't just truncate. That would be easier for people to understand at first glace than the real problem. Instead, it likes to trick you into thinking it works fine. 1.556 will properly round to 1.56 and 1.5551 will also properly round to 1.56 even though 1.555 will not. Even funkier is that toFixed(2) will turn 1.525 into 1.52 but 5.525 into 5.23. It is floating point stuff and it makes rounding a bit inconsistent and unreliable. In multiplying by 100, or however many 0s you need to get out of decimals, you move away from those floating point innaccuracies. So except in weird big number situations it is a good way to get a more accurate rounding result. Technically you could do (1.555 * 100).toFixed(0)/100 instead of Math.round(1.555 * 100)/100 to get the same workaround but Math.round is more self explanatory for integers than .toFixed(0) so it tends to be the better choice. There is also toPrecision() but I don't think it avoids this issue either. Here is some related content: http://stackoverflow.com/questions/588004/is-floating-point-math-broken/588014#588014 If you have never dealt with floating point weirdness and want to blow your own mind, try this: Console.log(.1 * .2);
Excellent and very informative contribution: you certainly gave my kata a new value, thanks a lot :)
[I have dealt many times with the poor precision of JS, yeah...]
Happy to help. Thanks for taking the time to make it and quickly adjusting it as well. ;)
Good one Giacomo :) Upvoted!
Thanks, man :)
In the description you write:
I don't exactly agree: your solution doesn't round ** down ** to 2 decimal places, it simply round to 2 decimal places; sometimes the rounding is up, sometimes down.
You are absolutely right: I meant rounding down to the second decimal digit, then I changed the text and forgot to remove "down"; fixed, thanks :)
I fighted rather long before finding the flaw... Have a good evening!
Ops, sorry and I wonder how the others did before^^'.
Thanks again and bonsoir to you!
They only saw down and not round:-)
I think more the opposite (the only say "round"), but ok :D
difference is defined in unintuitive way. it should be i-average instead of average-i
I would not call it an issue and I think the description clearly states why the input is wanted that way, with examples and discussion about it.
Any tip to improve the description?
I agree that from reading the description it's clear what's expected. However, one usually defines distance from average as x-average, i.e. if x>average the difference is positive. I would flip it around (-/+ -> +/-) and then everything shoul be cristal clear.
Well, I wanted to keep it extra-simple (and beginner-friendly, most of all), so while I myself considered that POV when I wrote it, I put myself also in the shoes of someone with zero previous statitics experience, tried to write a user story and create a kata accordingly.
Yet I see your point and if many other people will report the same, I will change stuff. Right now, I would prefer to avoid it, as it would be made on a subjective POV and it would invalidate all the previous good solutions.
When you began writing the description to the problem you actually seemed to agree with jmossel as you wrote
"(55, meaning -4.2 compared to the average) ... (95, 35.8 more than the average and so on)"
where the signs of the differences are as expected. You then later contradict yourself by writing
"The resulting list/array of differences starting from [55, 95, 62, 36, 48] is thus [4.2, -35.8, -2.8, 23.2, 11.2]."
A tip to improve the description would be to change the first quoted sentence to make it consistent with the second (I would say change the second to be consistent with the first, but that would make all existing solutions to the problem incorrect).
I also don't see how simplicity, beginner-friendliness or empathy with the beginner caused you to make this choice of sign (and to be inconsistent about it in the description).
Be my guest literally suggesting a rewording, then :)
Good one! For me It's ready to go!
Ah, always too kind: it is a simple kata, it is certainly far from the sophisticacy of your work, but as I was prompted to write something rather easy, I took the chance to implement a fast one here :)
You have many challenging katas that I haven't solved yet. Your difficult katas are better than mines. Yours are complex. Mines are complicated. :)
Nice use of adjectives, but semantics apart, I beg to differ and I will keep looking forward to reaching your level ;)
Even though I don't agree, I try to look beyond and your words are inspiring. Your healthy point of view to look others more excellent than yourself gives something that the most elegant codes and sophisticated algorithms can't bring by themselves only: the spirit of collaboration and deep respect to all the Codewarriors that stregthen this community to work as a great Team. From my point of view , your good influence for all the CW members spread worlwide is very important here. You deserve this recognition.
I won't object anymore on our respective skill level, I think we can agree to disagree (as the phlegmatic people in my new land like to say) and I will treasure your thoughts to keep and possibly renew my efforts in learning how to code.
Particularly considering my possible widespread influence, I will try my best to be more informative and, hopefully, not to mess up things when I translate or author a kata or give a reply ^^'.
Anyway, thanks for everything Raul and all other codewarriors :)