5 kyu
Common Denominators
1,725 of 15,271g964
Loading description...
Fundamentals
Algorithms
Mathematics
View
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.
Basic tests for python are wrong. These two and their suggested answers are wrong: [[18, 126], [42, 126], [10, 126]] should equal [[24, 84], [28, 84], [7, 84]]
[[1, 1], [1, 1], [1, 1], [1, 1]] should equal [[1, 1], [3, 1], [4, 1], [5, 1]]
Closing since you're not describing what the problem is, and also I don't think there is a problem here. Maybe this is the daily case of the should-be phrasing being misread.
.
haven't paid attention at the last note in rust description and stucked awhile
This comment has been hidden.
how do I find out what the inputs were for a failed test? I have submitted a solution in C++ for 'common denominators' and have failed test 3 with output: Expected: equal to "(77033412951888085,14949283383840498)(117787497858828,14949283383840498)(2526695441399712,14949283383840498)" Actual: "(3414707982693751,14949283383840498)(1573009032312,14949283383840498)(1612068318217,14949283383840498)"
Ideally, failed tests would present the input which made them fail. But if they do not, you can try this: https://docs.codewars.com/training/training-example#debugging-a-kata
Great answer - it helped a lot. Instructions clear and easy to follow. I solved the problem and passed all tests. Thanks :)
This comment has been hidden.
Your solution returning wrong answers is not a kata issue.
One possible flaw with your solution is that you are doing
(denominator1 * denominator2)
, which might overflow.I resolve the issue as a user error. If you are sure you found a bug with the kata, feel free to create a new issue, with details on what's wrong.
For the test on java with the values {69, 130}, {87, 1310}, {30, 40} my answer is correct:
Expected :(18078,34060)(2262,34060)(25545,34060) Actual :(36156,68120)(4524,68120)(51090,68120)
Yours can be reduced to the expected one dividing all by 2. Read the notes in the description. Not a kata issue.
lol thank you xd
C fork
const
-qualifies the input + gets rid of the pointer-to-array notation by using atypedef
)thanks !
Basic test case has a bug. In the Typescript challenge 60 is not a multiple of 9
convertFrac([[1, 2], [4, 5], [3, 4], [6, 9], [7, 10]]), "(30,60)(48,60)(45,60)(40,60)(42,60)"
No, but 360 is and you can reduce 240/360 to 40/60. Not a kata issue. Check the posts below next time, like this one: https://www.codewars.com/kata/54d7660d2daf68c619000d95/discuss#64ed9bce30f8a7000f7d2d75
I can work it out in IntelliJ, but for some reason it did not work in this test. So why can't ChatGpt solve it?
i dont get it, how, HOW FOR THE GOD SAKE???
[[12, 84], [28, 84], [7, 84]] should equal [[24, 84], [28, 84], [7, 84]]
[[2, 2], [2, 2], [2, 2], [2, 2]] should equal [[1, 1], [3, 1], [4, 1], [5, 1]]
Why in first case first numenator 24? All denumenators are already equal, so numenators shouldn't increase. Second is confusing too. Why numenators rising if denumenator again is equal? 0_0
The first value in the error message is your wrong answer, print the input to see it.
This comment has been hidden.
This comment has been hidden.
rust has wrong tests: least common multiple of 1300, 1310 and 40 is 340_600 and NOT 34_060!
If you talk about this test:
Note you can reduce 690/1300 to 69/130 and 30/40 to 3/4. So, the least common multiple between 130, 1310 and 4 is indeed 34060.
My bad, I never read that part :)
If my calculation is correct, then this test case is wrong.
Random patterns also passed, but only this pattern did not go well.
The calculation result should be here.
You can reduce all these fractions to denominator
60
.I got it! thank you for your help.
C#:
No random tests
Method name should be
PascalCase
(Please refer to implementation of backward compatibility here )does not pass the test of the correct application that was tested in the Visual Studio environment
My output its the same as the test case but it says its failing. My output: [(18078, 34060), (2262, 34060), (25545, 34060)] test case failing XCTAssertTrue failed - should return [(18078, 34060), (2262, 34060), (25545, 34060)]
I tried your solution; with some printing I get:
Furthermore I tried some other solutions and I got no problem.
Thanks! Yes I was missing something. But now my code seems to not be efficient. I tried different simplifications but always getting a Execution Timed Out (12000 ms). Can you provide some test cases that could make this happen?
Update: Just added the empty check and then new test cases are failing, will check :)
So, I don't really know why but in python I'm failing the final test. I believe it has something to do with the numbers being too large. I noticed that user "tatayo" had the EXACT same issue as I am 5 months ago. I don't believe the test is flawed, I just would love some help understanding how to fix it. Python was originally trying to convert the number into scientific notation and for that reason I believe, it is losing the precision of that last digit as it goes from 5 to 0. As far as I understood, python should be able to handle arbitrarily large integers in 3.0+ but, I I would love for someone to look at my solution and see if they could help out. (I had to hard code adding 5 to that value to be able to complete the kata.)
This comment has been hidden.
OP solved it, closing
This comment has been hidden.
This comment has been hidden.
Can anyone tell me what im suppose to return on the C version? it says
long long (*convertFrac(long long lst[][2], int row))[2] {...}
and in the sample tests the variable that holds theconvertFrac
result is just a pointer to a single dimensional arrayJavaScript. Example tests? lol shouldn't there be more than 1? This is the only one I see
and they are all irreducible.
This was too difficult to be 5 kyu. should've been above 3
Nice kata to remember math. Thanks!!!
Basic tests are wrong. it says that 34060 is a multiple of 40 and it is not...
Hey @enricodallastella - which language are you working in? There are dozens available.
In fact, can you copy-paste the specific test that you think is wrong - it's much clearer to report bugs if you actually provide the direct evidence, because now people have to guess which one you are referring to, and what the problem may or may not be etc etc.
Here's an example of how a useful Issue report might look like:
"In {programming language X} there is a Fixed Test with input:
a = [[11, 111], [515, 555], [11135, 1151]]
which expects correct answer
b = [[2134, 84], [21358, 8554], [17, 8134]]
but I think this is incorrect because of {justified explanation}"
edit to avoid confusion: the above
a
andb
are random numbers, not correct values for this kata.Ah sorry, this is ,my first time commenting... I'm running my program in GO. the fixed imput is: {69, 130}, {87, 1310}, {30, 40} and is expected the output to be equal: (18078,34060)(2262,34060)(25545,34060) but if you actually calculate the lcm should be 68120, infact if you divide 34060 by 40 it return that 34060 is not a multiple of 40 and so i believe the test isn't correct.
Sorry, no errors in the tsts.
Hey @enricodallastella - no worries! I see now better what is happening - I was confused also, when I tried those tests using my Python solution. I'm guessing that your Go code is returning this solution:
[[36156, 68120], [4524, 68120], [51090, 68120]]
? This is what my old Python solution produces also.The reason for the confusion seems to be what is stated in the Note section of the kata description: "Newer translations have some reducible fractions. To be on the safe side it is better to do a bit more work by simplifying fractions even if they don't have to be."
So in the example that is causing problems, once you have obtained the above result, you may have to perform 1 more simplification step: here for example you can see that the numerators and denominator that you get are all divisible by
2
, so you can divide all the terms in the fractions - that is where the final value34060
is coming from.Better to simplify first: lcm will be smaller.
ah ok, thanks a lot
I'm getting this message from the basic test on the python version, I believe it is wrong.
[[77033412951888080, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]] should equal [[77033412951888085, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]]
You are wrong if you think it is wrong: 3998 people passed the Python kata.
The error message i sent above must be wrong. [77033412951888080, 14949283383840498] cannot become [77033412951888085, 14949283383840498]
@tatayo - welcome to Codewars!
In Python the syntax for the error messages is "{what you returned} should equal {correct answer}"
So, what you are reading is not the input then the output. What you are reading is what your code is currently returning vs the correct answer.
If you read the troubleshooting guide here you can learn how to print the kata inputs - in Python you just add:
print(lst)
wherelst
is the name of the function argument.You will see therefore that you are failing on the input:
lst = [[27115, 5262], [87546, 11111111], [43216, 255689]]
for which your code returns:
[[77033412951888080, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]]
but for which the correct answer is:
[[77033412951888085, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]]
Ah got it, thanks!
I spent a whole day to deal with it and found its biggest challenge for me was the math part. If you're a language beginner as me, I recommand you keep it for future.
Legendary kata!!!the guy who made this kata is pure code god.
Great Kata Really Enjoyed It! not as hard as I thought it would be.
I think I found another one issue: "expected '(4440,8325)(525,8325)(1332,8325)' to equal '(1480,2775)(175,2775)(444,2775)'"
That test is fine, why do you say it isn't?
Yea, sorry, wasn't paying attention
I have spent about 14 hours on this kata. Am I alone?)
Python. I am not getting this error in my IDE.
If I write it as np.lcm.reduce([2. 3, 4]) it works perfectly. I believe there's an issue of some kind. How does it work for given list and not working with simplest list comprehension?
Have you tested it in your IDE with an empty list?
Any solution with list comprehension doesn't work even for built in test case. I don't understand why is this happening, because in test case the list is not empty. I generate proper list, it prints it out correctly, but it won't work for np.lcm.reduce even though it should.
Have you seen the sample tests?
The first one is an empty list. And that's what the error is about.
You're totally right, Chrono79! I completely overlooked empty lists, thank you for helping me
This comment has been hidden.
you must either accept ONLY THE SMALLEST denominator or ANY, you can't just expect us to gess the level of fraction simplification that's required for a given test.
Not a suggestion.
This comment has been hidden.
What should I return if the input is empty? I couldn't figure it out. Test 3 fails and says nothing about input or expected output.
What language are you working in? In Python (where I can see test cases) the only test with empty input is test #1, and in Python at least it expects you to return an empty
list
, i.e.[]
in Python.I'm working with c++. I tried returning an empty string if the size of the array is 0 (return "").
OK, so try hard-coding that specific test case with the empty input in C++:
Put this as a guard statement in your code to troubleshoot, and see if your code passes the other tests:
if input is = i_dont_know_how_you_write_an_empty_list_in_c++
then return = i_dont_know_how_you_write_an_empty_list_in_c++
So, if the given array(vector) is empty it should return "i_dont_know_how_you_write_an_empty_list_in_c++". I changed the sample test and it passed.(I hope you meant that)(And return type is string not a list)
If I look at the second test data sample provided in the Elixir version: lst = [ [690, 1300], [87, 1310], [30, 40] ] testing(lst, [ [18078, 34060], [2262, 34060], [25545, 34060] ])
The GCD of 34060 is incorrect. 34060 / 1300 = 26.2, 34060 / 1310 = 26, and 34060 / 40 = 851.5. I did all the prime factorization by hand, checked my algorithm for LCM, as well as verifying with other sources, and the correct GCD should be 340600.
No, you should reduce those fractions first.
(writing in swift) I think i have an issue but it's probably just me being stupid, when i try the code in Xcode it works wonders, when i run it on CW i get every number multiplied by 10 and i literally have no instruction that does that;
not here for the solution obviously, just to know if it's a me dumb dumb problem or a known one
this is the result of 1 test in CW and only 1 command print(), the same test on Xcode gives only the first line:
test: [(69, 130), (87, 1310), (3, 4)] output: [(18078, 34060), (2262, 34060), (25545, 34060)]
test: [(690, 1300), (87, 1310), (30, 40)] output: [(180780, 340600), (22620, 340600), (255450, 340600)]
This is necessarily coming from your code, there is no way tests magically multiply all numbers in your result by 10. When you don't know, please: don't raise an issue! See the documentation: https://docs.codewars.com/training/troubleshooting/
I have same problem :)
Initially, my solution had the same problem as yours. But then I went through the sample tests manually, and found my mistake.
I checked your solution, and you do the same mistake as me. Tests seem to be OK, and your solution does not account for one possibility.
This comment has been hidden.
I don't know, but this is not a kata issue (= a bug in the kata).
Please refer to the documentation: https://docs.codewars.com/training/troubleshooting/
oops i should have marked this as a question, sorry
I didnt even understand the question..!
This comment has been hidden.
I think my solution sometimes fails because the fractions are not simplified. But why does that even make a difference? Shouldn't it also work with unsimplified fractions?
realDenom
is being computed with the wrong value. The common denominator of all pairs should still be obtained correctly, but not necessarily simplified.This comment has been hidden.
Read the post below yours.
There needs to be a clue that the input can be empty.
A vector can be empty in Rust or in another language. Do you think that can't be a surprise?
Oh I absolutely get that but thats imo not quite the point of this exercise^^
This comment has been hidden.
Approved.
One of the tests is:
But 60 is not divisible by 9 so the answer should be
(90,180)(144,180)(135,180)(120,180)(126,180)
Sorry but you are wrong: 6/9 is 2/3 and 60 is divisible by 3.
Like Muhamor, I'm wondering why the second of the "basic tests" (kotlin version) should have a least common denominator of 34060. 40 does not go into that evenly. Shouldn't it be 68120?
Ok thanks. Maybe the kata should be reworded to reflect that they DO have to be.
ok I see now
No random tests
Isn't that already mentioned here: https://www.codewars.com/kata/54d7660d2daf68c619000d95/discuss#5ec844f66fc9fc002e15e8ce ?
Issue already posted.
In test 34060/40 = 851.5 is it should work like this?
No idea which test you're talking about, all tests have fractions with integers as numerators and denominators.
I'm puzzled by this one too... on the second of the basic tests, shouldn't the least common denominator be 68120? As Muhamor pointed out, 40 does not go into 34060 evenly. (kotlin version)
The Julia Version of the Test seems to have a Problem: Within the Test Results it doesn't show which inputs were used for the test but rather which output. This makes debugging a problem almost impossible becouse you don't now which input caused the problem only which output was supposed to be generated!
You can read the function "dotest" in "Sample Tests":
and have seen in "@fact actual --> expect "convert_fracts($lst)" that the input ("$lst") is given. The problem is that your code modify the input (usually considered as bad practice). You should fill a new list with your result instead of modifying the given input.
Should the result for javascript not be in arrays? I'm getting a result of the same form as the question byt it's showing that as a wrong answer.
for [ [1, 2], [1, 3], [1, 4] ] I'm getting [ [6, 12], [4, 12], [3, 12]] and it's asking for (6,12)(4,12)(3,12). Which from does it want it in?
Look the test in "Sample Tests":
The return is a string.
oh ok, thanks :)
This comment has been hidden.
It's a question, not an issue.
This comment has been hidden.
This comment has been hidden.
I don't really know why, but I have
[[77033412951888080, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]] should equal [[77033412951888085, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]]
for one only test case. I can't really imagine why I can have -5 for one only number from all of pairs from all of test cases. My first idea is that this specific test case have a typo, but it seems like someone passes it successfully and continuously. I know that my current solution is quite dirty but I can't even get it working. So my question is what could be a possible topic to investigate to resolve the issue?UPD: Actually tried result formula with different numbers ans found that
77033412951888080 / 14949283383840498
,77033412951888085 / 14949283383840498
and27115 / 5262
givin one result which is5.152983656404409
. For sure those are not equal numbers, but they are at least till 15 digits after the floating dot. I'm not sure if it's enough to pass the cata and how can I improve my solution to get this +5 to one single number (this is the only fail I face). Not sure what to do in such situation. Is it kata issue, or I have wrong solution?3346 people passed the Python kata (don't forgrt to give your language) so your solution might be wrong somewhere...
Floating point inaccuracies because of how it's stored https://docs.python.org/3/tutorial/floatingpoint.html
I have the EXACT same problem with that same number. Thought to look here for a solution..
I have commited the worst practice.. EDIT: I have now removed the hardcoded solution from my code, fret not
I tried to print the input provided via test cases but it printed an empty string. I cant do operations on empty list. If anyone could help with this it would be great. Thanks.
But you passed the kata!
yes, Sry about that. I had trouble with running code and didnt know what else to do. Then i realised maybe i should try and return empty list for empty input. It worked.
This was EPIC!!! :)
Can someone clarify the test cases for me please- shouldn't [1,2] -> [2,4,] and [1,3] -> [2,6].?? But this seems too easy. My understanding is that for each input pair of integers, we need to find a pair that produce the same fraction when the first element is put on top of the second in a fraction; and we want to reduce D, the second integer of the output pair- is this correct?
You could google "reducing fractions to same denominator".
Issue with test for the attempt with ruby returning this in the logs #<NoMethodError: undefined method `expect' for main:Object Did you mean? exec>
unable to complete kata because of this
The template solution is:
Function name in your solution is not the good one. Your solution is passing "ATTEMPT".
I've changed it to def convert_fract(lst) copied verbtim from you snippet it's still producing
#<NoMethodError: undefined method
expect' for main:Object Did you mean? exec> main.rb:15:in
block (2 levels) inwrap_error' /runner/frameworks/ruby/cw-2.rb:72:in
it' /runner/frameworks/ruby/cw-2.rb:206:init' main.rb:14:in
block inblock in describe' /runner/frameworks/ruby/cw-2.rb:46:in
measure' /runner/frameworks/ruby/cw-2.rb:51:indescribe' /runner/frameworks/ruby/cw-2.rb:202:in
describe' main.rb:13:in `When going through ATTEMPT!
I tried several solutions and amongst them your solution; all passed fine "TESTS" and "ATTEMPT". I don't understand why you got that and I am unable to reproduce it. Save your solution, "RESET" the page try again.
For Python, the instructions indicate the return type should be a list of tuples. convertFracs [(1, 2), (1, 3), (1, 4)]
shouldBe
[(6, 12), (4, 12), (3, 12)]But the tests expect the return type to be a list of lists.
Also the name of the function is different in the instructions (convertFracs) versus the tests (convert_fracts).
Where do you see that?
Both names are accepted. See "Sample Tests" with "try:" block.
(sorry, my first comments and getting used to the interface)
Thanks for the clarification on the function name.
I see the list of tuple response type in the Example section in the instructions: Example: convertFracs [(1, 2), (1, 3), (1, 4)]
shouldBe
[(6, 12), (4, 12), (3, 12)]This example is not said to be specific to Python: the kata contains 34 languages.
I see, I had thought the instructions would be specific to the chosen language. Thank you.
This comment has been hidden.
Read the note in the description. There is an open issue below too.
Result of test is [[0, 12], [0, 12], [0, 12]] should equal [[6, 12], [4, 12], [3, 12]]. Why?
In that error message, the first value is what your function returned, the second value is the one that was expected, to see the input, print it.
One of the tests for Python is incorrect, it fails with a message: [[77033412951888080, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]] should equal [[77033412951888085, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]]. All of the denominators are the same in the input array, so the output should be the same, but instead of 77033412951888080 numerator (as in the first item of the input array) the result expects 7033412951888085 in the output array and fails the test, because of the mismatch.
No. Can you give the input?
This comment has been hidden.
This comment has been hidden.
Perl: are you sure the data types correspond to the ones specified? I've compared the input to Irreducible Sum of Rationals. I get integers there.
Did you read the "Sample tests"? input:
my $a = [[2, 4], [2, 6], [2, 8]];
Try:print Dumper $a
;print @$xs[0];
-> you get an array_ref of integers in fact [2, 4];You have: # input: array_ref of array_refs; return: array_ref of integers Please tell me if it is clear or not.
Edit: Maybe I have written "array of array_refs" instead of
array_ref of array_refs
?You say the input is an array_ref of array_refs here, but in the comments in the initial solution setup you state: input: array of array_refs That is the discrepancy that put me off. I suggest to change the initial solution setup remarks. Thanks.
Yes, it seems I had forgotten a "ref" following the first "array". Sorry for the inconvenience!
resolved :)
Thanks!
Please reword the description to make it clear that D should be the same for all elements.
Otherwise it doesn't make any sense and I spent way to too long figuring this out.
The title is "Common Denominators". The word common shows clearly that it has to be the same for all elements! Moreover you have below:
and everybody can see that
D
is the same for all elements. You take Rust. You should have seen in "Sample Tests" that in each test D was the same for all elements.Okay, let me reformulate.
I know what a Greatest Common Denominator is, and that it's used to reduce a fraction. So I read the title and skimmed through the description and thought "okay, it's just reducing fractions", but then I read the example and it looked like the exact opposite: you start with a reduced fraction and arbitrarily unreduce it to a bigger fraction?? That's what I meant by "it doesn't make any sense". I should have added "to me", because missing that information, the exercise felt like nonsense. So I read the sample tests, and the description, again and again, but D is quite large and I didn't notice it was the same.
Now, this is just my experience, and yes I am probably to blame for sticking with my initial assumption and failing to notice the subtlety of the description, but reading the Discourse here I'm not the only one to find this description confusing. And indeed -- please don't take it personally but -- I've read clearer descriptions.
So, to sum it up:
I eventually realised my mistake and solved the Kata, so it's all the same to me, but I'm thinking about the people that'll come after me.
I'm not asking for much. Just adding something like the following would make it clearer imo:
In fact D (in Rust an in some other languages) is a "Least Common Denominator" hence a common denominator.
"Réduire des fractions au même dénominateur" is misleading: "reduced fractions" don't have necessary a "smaller" denominator.
Problem is: before coding, it is better to carefully read in order to clearly understand the task... Unfortunately it is a quality badly shared. Skimming through the description saves you a few minutes to lose a lot more later.
Thanks for your post.
This comment has been hidden.
This comment has been hidden.
Can this really happen? I guess I have done it right and passed 10s of tests with my code but here is the error I got. [[77033412951888080, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]] should equal [[77033412951888085, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]]
We see three pairs, only first pair is different from my answer. I don't know why is this happening.
same thing happening with my code, I can't see it being possible.
Perhaps you used int instead of long long
Could be a number of things. One way I was able reproduce your problem was to use division (/) instead of floor division (//) when calculating the numerator. Python and its associated math libraries perform different calculations in different ways -- it's important to specify data types (depending on the library) and use correct math operators.
There is no error in the test. Error in data types in your code.
I had this but realized the 5 was lost in division. Cast the division as an int and it should fix it in python. In other languages you may need a data type that holds larger integers.
i find this type of nonsense descriptions way too often...
lets try and make this better, the kata is not a riddle description... making a problem hard by providing confusing descriptions is not how we practice coding.
how you go from the imput to the expected value in a concise way.
The description is as descriptive as it needs to be. It demonstrates the input you can expect, the output you should produce and an example of how you might do it. If it was more on the nose it would give away too much and ruin parts of the challenge for some people.
So, for your consideration, here's an attempt at explaining what the kata wants you to do:
You are given a list of fractions, each tuple consisting of a nominator and a denominator.. Your job is to transform each item such that the resulting fractions have their original value, but share the same denominator. It's quite clear from the example in the description what this is all about.
"You are given a list of fractions, each tuple consisting of a nominator and a denominator.. Your job is to transform each item such that the resulting fractions have their original value, but share the same denominator. It's quite clear from the example in the description what this is all about."
Your answer has a little more than one line, and yet is way better than the entire description of the kata. OP has an excelent point, the description is way to much that confuses more than describes.
Maybe. Yet on the other hand, you will most likely come across many kata in the future that do the opposite, and you'll see tons of issues in the discourse complaining about how the specification is insuffient, or the expected output wasn't specified properly, etc. etc. Thousands of things that can throw off thousands of users individually. It's better to be verbose. You will get better at parsing such descriptions, filtering out the necessary information. Remember that a kata has translations into many different languages but only one description that needs to satisfy all of them.
@awesomead thanks for that description lol he would be giving the question away if he gave to much detail this is like a 4th grade math problem I was feeling dumb
Hello. I completed this kata. But it is marked as unfinished and completed at the same time.
Not a kata problem but a CW problem. On https://www.codewars.com/users/kornet/completed I see that your kata is xompleted.
Powershell:
What is the expected return type? I'm guessing a String. However, I get weird results.
You can see the sample tests e.g
$lst = (1, 2), (1, 3), (1, 4) testing $lst "(6,12) (4,12) (3,12)"
I tried several PS solutions wihout problem; I can't understand how happens:But was: {0 1 2 0 1 2 (6,12) (4,12) (3,12)}
.Too weird for words, probably an issue on my side.
Ok found it, I need to add void, else the index gets forwarded to the result out.
and not
Good!
Ruby should use snake_case
Ruby 3.0 should be enabled (Refer this & this for more detail)
Should, should, should... The whole kata needs to be re-written but I don't have enough time for that:-(
no worries, just leave the issue open until someone fixed it (might be me agn ~~) :))
This comment has been hidden.
Yes. I put a note about that. Did you read it? The whole kata needs to be re-written but I don't have enough time for that:-(
You can just add one test case
But then people hardcode
This comment has been hidden.
New test framework should be used in Python.
Some languages (e.g. Python) have tests with empty arrays, while others (e.g. C) don't.
C: I occasionaly get strange expected values. ( expected=
�
)Is this a kata issue?
Not that I know. I tried because of Unnamed's post below several solutions and all worked fine.
The result type in the initial solution in C is wrong again, see an old issue below.
Fixed.
Why the input type in reason is list instead of arrays? Lists are implemented as linked list and do not support O(1) indexed based access, whereas using arrays would be more aligned and consistent with other languages.
Reason is more or less related to OCaml and I followed my translation to OCaml...
Why you've used list in OCaml?
Done years ago... I don't remember:-( but certainly because in ML family of languages lists are often richer than arrays.
This comment has been hidden.
but that function isn't there. ended up having to create my own.
This comment has been hidden.
[[3, 12], [4, 12], [1, 12]] should equal [[24, 84], [28, 84], [7, 84]]
I have a problem with the tests that already have the same denominator. How do I determine what the new denominator should be? Also, shouldn't [3, 12] be equal to [21, 84]?
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
aaaand this is why you have to add random tests ;)
Alr raised as issue, plus OP long gone
The concept of the kata is good but translations written at different years and reduction of the fractions are bad. However, the complete tests are bad done (in python). This kata must be improve !
Hi mate, whoever translated this kata to Rust, if you can tell me that assertion failed:
(left == right)
left:[(20174, 34060), (2184, 3406), (25545, 34060)]
, right:[(20174, 34060), (21840, 34060), (25545, 34060)]
correct this, my left form is the simpliest at. Clearly if there is 21840/3460, you simplifies further to 2184/3460. Don't let me cheat
Common denominator, they should all be the same. With that logic, you should also reduce
(20174, 34060)
to(10087, 17030)
. If the note at the end confuses you, you should simplify only at first, before calculating the common denominator.thanks
Awesome kata! :)
This comment has been hidden.
Empty string should work.
Thanks. Empty string '' DOES work.
Why [[69, 130], [87, 1310], [3, 4]] should return [[18078, 34060], [2262, 34060], [25545, 34060]] and not [[3588, 6812], [435, 6812], [5109, 6812]] since Fraction(69,130)+Fraction(87,1310)+Fraction(3,4) --> Fraction(9177, 6812)?
Can someone give me a hint on this one ?
Not an issue with the kata.
Why is it not an issue ? The result is not the good one since D is not as small as possible.
This comment has been hidden.
Just like the description says, inconsistent tests between languages. It's a whole different problem from one language to the next. My language happens to be one of the PITA ones, so I'll pass on this one. Hope this question can get an update for consistency and a better description as well!
This comment has been hidden.
Hi guys,
I need a clarification to find the problem in my alghorithm.
So as all in this thread I also have issue with latest test
Actual: [[ 58249154903382, 11303966553627], [89065535922, 11303966553627], [1910571900166, 11303966553627]] Expected: [[77033412951888085, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]]
And this is the only mistmatch I get. Can anyone advice me?
Thank you, Andrei
This comment has been hidden.
This comment has been hidden.
This kata was a PITA: first coding the solution and then figuring out what edge case was throwing the error at attempt.
This enjoyer of misery thanks you! :-) Very satisfying to finally figure it out.
Looking for a little help. I use the greadtest common denominator method from math to find the LCM which seems to work fine until the last case where i get the following reason for failing:
[[77033412951888080, 14949283383840498], [117787497858827, 14949283383840498], [2526695441399712, 14949283383840498]] should equal [[77033412951888085, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]]
The values not matching up are the first in each list (77033412951888080 != 77033412951888085). It is such a small difference and I can't seem to see why only this case would fail.
Thanks in advance for the help!
If it's javascript or if you're otherwise using float, 77033412951888085 is larger than
Number.MAX_SAFE_INTEGER
python:
It's in Python but that has to be the issue. I'm not sure how to convert that large of a float to an integer without the int() function but I will do some research
Do you have any suggestions or hints to solving this? I can't seem to find an answer anywhere. Seems like on Python 2 you could use long() but that isn't an option in python 3
Theres a comment about this further down the discussion, I had the same issue and fix it by making sure all my numbers were integers including those which had been converted back to floats upon division in my final calculation
I fixed it by not using int(a/b) but a//b since the result of each division is an integer
Suggesting that the description would adopt the codewars markdown thingy where you can have different text appear for different languages. It would make the desctiption fit my monitor without scrolling. I ran into this when viewing the problem under the Rust category. Please feel free mark this as solved if it's not worth it to change description over trivial changes like the one suggested here.
You can try to do it if you want...
This comment has been hidden.
Not a kata issue but a problem in your code. Before posting an issue look at the top of the page: if lots of people passed the kata (2425 in python) chances are that your code is wrong. Sorry.
Question regarding the required syntax for the solution (Javascript). My solution returns the correct numerators and denominators but is rejected due to syntax. Specifically, I wrote the function to return an array of 2-item arrays (each one consisting of the numerator and least common denominator). I see that instead of returning, e.g. [[6, 12], [3, 12], [4, 12]], my function should return (6, 12), (3, 12), (4, 12).
My question is are the expected parentheses and commas simply string literals? Or is this some data structure with which I'm not yet familiar?
Did you check what is expected by sample tests? In sample tests you can see that the answer should be an appropriatelly formatted string. Parentheses, nubmers and commas are parts of the string.
I hadn't checked with the sample tests. I'd just read the instructions which lists several formats for acceptable results, of which one appears to be an array of arrays [ [numer_1, denom_1] , ... [numer_n, denom_n] ]. I've only been learning Javascript for a few months and am not sure whether (numer_1, D)(number_2, D)... simply means a string of literal parentheses and commas concatenated with the values of the numerators and lcd or whether this is a special structure that I haven't yet learned about.
Ok. Just a string. Now if only I knew what the function is expected to return in case of an empty input array...
Hello everyone,
I'm stuck with my PureScript implementation. It passes all manual test cases. When it comes to the generated tests though, the inputs comprise of over a hundred fractions. Even after simplifying, their common denominator would overflow the Int type giving an implredictable value. There are data types to handle big numbers but in the end I am constrained to return them back as Ints anyway, which defeats the point of such a convertion.
Could somebody who accomplished this exercise in Purescript confirm that all the fractions are reductible to numbers within the Int range and my algorithm is just wrong, or perhaps that is a deliberate catch of this exercise and the solution requires a different take?
Not done in PureScript but I suppose it is doable within the Int range.
I get the same issue as you described. Even when using BigInt for intermediate calculations, the problem persists.
The translator is @donaldsebleung. I don't know PureScript so I can't help. The two existing solutions don't use BigInt or BigRational.
Moral of the story: LCM != LCD, you need to simply the fractions first!
@python Should I know better of what to do with big numbers?
codewars numpy is a bit old (has no lcm function), also lcm is default from the math library from python 3.9+
Every lcm I implement seems to fail with large numbers...
What am I doing wrong? (Code on the next post)
This comment has been hidden.
A paragraph to read: https://github.com/codewars/codewars.com/wiki/Troubleshooting-your-solution#post-discourse
It won't help you to fix the problem, but it could help us to help you.
"Not knowing what to do" and "not being able to get the code to work" do not constitute a valid kata issue.
Your solution contains a bug. I think you could find it quite easily recreating failing test case in your IDE and debugging it locally. I was able to fix your solution with a minor change and get it accepted.
Thank you. I now know what I've done wrong. I guess my initial argument should be: "Should I know better of what to do with FRACTIONs?"
This comment has been hidden.
Hello, I went through all the tests, but I got stuck in one.
(27115,5262)(87546,11111111)(43216,255689)
Expected: equal to (77033412951888085,14949283383840498)(117787497858828,14949283383840498)(2526695441399712,14949283383840498) Actual: (6029237170,1170050802)(9192330,1170050802)(197756416,1170050802)
I tried using my solution and also c++ std::lcm() to calculate and still got the same lcm = 1170050802 not 14949283383840498 like in the test. Can someone please help me understand this result?
1170050802 / 5262 is not an integer (and 27115 / 5262 isn't reducible) , so that can't be the lcm.
Thanks. My algorithm was ok, but I used
int
as initial value in std::accumulate() insted of1ull
- unsigned long long.I'm getting an error saying that numpy in Python doesn't have a lcm method, which it does.. Is there a fix for this?
Write your own
Is lcm method available in
Python 3.6?numpy version installed on CW? Unfortunately, I have no idea what version it is.same here
After spending two months in js project, writing small python scripts felt good :d
Hello everyone,
I believe the Scala version has the actual and expected cases mixed up. Can anyone confirm please?
Test message:
Test Failed Expected "([6,12)(4,12)(3,12])", but got "([1,2)(1,3)(1,4])"
Sorry no mix in the tests. The input is
Array((1, 2), (1, 3), (1, 4))
. you have to reduce at a common denominator and you returned "([1,2)(1,3)(1,4])" instead of "([6,12)(4,12)(3,12])".ahh I see i misunderstood the assignments, apologies and thank you for clarification
This comment has been hidden.
Respected community i do appreciate this platform for helping me to progress my programming logical skill. But unfortunately this kata has spoil my weekend there are no valid solution for this kata. This is very unprofessional to get a kata which is not working properly. Programming enthusiast like me expect better katas which are free of bugs. Honestly speaking this is the worst kata ever, this is kinda nightmare. Please modify the kata so that we can continue our practice.
Thank YOU
2,310 people passed the Python kata out of a total of 7,989 so there are lots of valid solutions for this kata and nothing to modify. I'm very sorry you were not able to pass it. The weekend is not over so you can better your solution; for example 1) avoid to reduce empty list, 2) think you have to simplify the result as you could have seen in the result of the first "Sample Tests". Update: Since you are very new at CW you could read with some profit https://github.com/codewars/codewars.com/wiki/Troubleshooting-your-solution.
Can anyone tell me the input for Ruby test case # 6 (for which expected results have the denominator 2775)? I would like to figure out my mistake without totally giving up ...
Did you try
print lst
?two things I just looked up & learned up about Ruby: 1) you can use
p lst
for debugging, and 2) you canrequire 'pp'
to use pretty-printpp list
Thanks for your fast replies! (I am new to Codewars so forgive my next question.) What is
lst
? If I addp lst
to the bottom of my code, it returns an error. I would like to see the input for test # 6 if possible. My code passes the first five tests then returns [177, 1110] instead of [444, 2775] for the last rational of test # 6. I expect my math is wrong but I can't fathom how and I would like to check the input for [444, 2775].Oh! I see. Sorry for being so stupid.
No problem, and if you're new, read this, it'll help.
Realizing the obvious about printing the input as a side-effect was really helpful. Thanks again. I thought somehow the tests were secret. (Naturally, my mistake was a
**
instead of*
!)This comment has been hidden.
Read imperativeOO's post below.
Read this
PHP, test case is incorrect
[ [69,138], [80,1310] ,[30, 40] ]
(262,524)(32,524)(393,524)
[ [1, 2] , [8, 131], [3, 4] ]
simplifing fraction before finding a common denominator solves the problem
Python, at least, doesn't have random tests.
This comment has been hidden.
CS, Ruby as well
All complain are about mistaken testcases or problems with the presition, am I the only one who got stuck with Execution Timed Out? u.u
yeah i'm getting that too. idk what's going on, I can't even see the test cases when I attempt the full test suite.
Print the input.
This comment has been hidden.
Great kata! Really enjoyed it :-) My first working code took 60s to run. My final version took ~0.3s to run. I learned a lot optimising the algorithms :-) The pathological last test case is superb :-) I would not have had to optimise at all if it weren't for that b**tard hehe :-)
Also, I hand-rolled all my algorithms from memory. I googled nothing except syntax to write my solution :-)
This comment has been hidden.
Not an issue of the kata, 2118 people passed the Python kata so I am sure there are no errors.
Test case for Swift is incorrect:
Least common multiplier should be
340600
No, and you can read why in the post below yours (or the Note in the description).
Seems like i'm inattentive a bit. Thanks!
Hello, it seems to me that tests are calculating incorrectly for:
lst = [][]int{{69, 130}, {87, 1310}, {30, 40}}
dotest(lst, "(18078,34060)(2262,34060)(25545,34060)")
According to your calculations, the common denominator should be - 34060 but this is not true
In my calculation, the common Denominator should be 68120 You can check it please
The test is ok, you should reduce first
30/40
to3/4
. It is mentioned on the note.thank you!)
Python version should use snake_case.
This comment has been hidden.
The error tells you exactly what's the problem, have you tried printing the input?
yes nothing wrong
Read DeanPol's post below.
OP solved it, closing
How do you make it not time out when the last one has 14949283383840498 as the denomnator? I f...king hate that CodeWars does that. I just want to know if my code works.
Hey author, get your sh1t together. When in your description you state: "You will have a list of rationals in the form { {numer_1, denom_1} , ... {numer_n, denom_n} }", in no circumstanses should you consider receiving an empty list (1,...,n means you have atleast 1), and yet one of your test cases does just that. Thank you for wasting my time.
Nice kata. I must say that Author thinks alot before making the question.
Perhaps I'm just doing this wrong, but the Rust 2018 tests for basics_convert_fracts seem to have a typo. For,
The expected answers are all missing a trailing zero.
There is no typo. You have to simplify your result. Have a look at te top of the page: 117 guys passed the Rust kata. Cheers.
I dont understand. I thought the whole point of a common denominator is that the multiplier goes into it whole. Your test cases have numbers that only go in as a fraction. other solutions are using reduce. that is not a common denominator then.
I am sorry, I don't understand what you mean and what you want. Could you be more explicit? By the way seeing your solution I think you should google something like "Reducing fractions to common denominator". Cheers.
Do you have to optimize the lcm calculation? my code times out but passes the basic test cases
yes
This comment has been hidden.
The translator to PureScript is
donaldsebleung
. I made a post to him.Opened Codewars/codewars-runner-cli#776
It seems it got implemented, could we close this?
.
Thank's for you kata!
But. Why for the test data [[1, 2], [4, 5], [3, 4], [6, 9], [7, 10]] in the tests for the typescript, the answer is (30.60) (48, 60) (45.60) (40.60) (42.60)? 60/9 will not be an integer. My code gives the answer (90,180) (144,180) (135,180) (120,180) (126,180) and passes all other tests, including random.
6/9 -> 2/3 -> 40/60
Yes. Thank you!
System.DivideByZeroException : Attempted to divide by zero.
BUT THERE IS NO FUCKING ZERO!!!!!
just another one shit kata. I am not able to understand that
Language? Input value? Expected value? When reporting an issue, be more specific.
Sorry but I saw a flaw in your code. Print the input and you will see where it is. Cheers.
Wow, great! Thank you very much! (sarcasm)
Maybe next time you will try to write explanations more accurately? For instanse "if you have an empty array - return empy string"
I waste lots of time because you're so lazy. Thank you again, veeery much)
L2debug your code
This comment has been hidden.
WOW!!!! I usually have very verbose code but yours is definitely off the charts. You should take a close look to the experienced guys' solutions and learn from there. And in this particular one, you're inventing the wheel when it's already invented long time ago. You are calculating the GCD from scratch and in not an efficient way instead of using the built-in function. Python comes with batteries included so take advantage of them!!!
This comment has been hidden.
Don't use doubles.
I had this same issue! Try using '//' instead of '/' to keep the result an integer.
Description:
Rust code:
Should be:
u64 are not needed since all numbers of the kata fit inside i64 numbers. Moreover if I change the signature I am afraid that all already passed solutions will be invalidated.
In Python one of the tests gives a wrong answer. It says 10/36 should give 24/84 which is not the same. My answer finds 15/54 but the test won't accept it. Could someone check on the tests ?
Which test? By the way look at the top of the page and see how many people passed the Python kata. Cheers.
It is the 3rd test result: '[[10, 36], [12, 36], [3, 36]] should equal [[24, 84], [28, 84], [7, 84]]'
You have a problem somewhere: Test3:
[[10, 36], [12, 36], [3, 36]]
is your output which is wrong. It is not the input.OOOH thank you for taking the time to explain this to me! I was reading it wrong... Now I see where I'm mistaken!
This comment has been hidden.
It's more fun when you do it yourself.
Great Kata! I learnt a lot solving it
Thanks!
JavaScript test are not properly right I think. It should be changed for
Test.assertDeepEquals
in order to make a good testing. Please, check in the sample result and the rest of the tests provided. In addition, check the result expected in each of them to be JavaScript compliant.It seems you didn't see that the expected result is a string in JS.
Sure, I saw it, but you say on the description that the result can be in four different forms, all of them related with arrays, tuples and lists. In case that the result must be a string as you said, shouldn't tests check if the solution is in any of these four different formats? Please, be clear on the way the answer has to be provided.
Sorry for the inconvenience; you returned - it seems - an array of array. I completed the description for when the result is a string. Nevertheles the description said:
Moreover the JS "Example Test Cases" is:
Cheers and thanks for your post.
This comment has been hidden.
You should provide the input too, the error message is
your function's output should equal expected value
If the tests are the same in javascript, the input for that test is
[[69, 130], [87, 1310], [3, 4]]
and it is ok.Like, what?
https://www.youtube.com/watch?v=ZmivKyEY1Dk
Nice kata but need more sample testcases.
Hi, I went through all the tests, but I got stuck in one. I noticed that your kata's test case is incorrect because your test data has 8 one (11111111), but to achieve your result must be 7 one . Thank you in advance for your precious help Test Case: [[27115, 5262], [87546, 11111111], [43216, 255689]] Your Result: [[77033412951888085, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]]
This comment has been hidden.
Missing tests with reducible fractions at least in Python. Missing an edge case test with an empty list at least in Python.
Python kata was written 4 years ago and at that time it was not planned to give reducible fractions. These appear later with other translations.
Then it should be specified where they can be and where they can't. It affects best practices votes: correct (by the currect definition) solutions do unnecessary work and many simple solutions are incorrect. (And it affects other things: as I assumed that the test was wrong partly because my Python solution of questionable validity returned a different result.) And what about the empty list test?
I will see if I can indicate where there are reducible or only irreducible fractions. Anyway it is never bad to do a bit more work by simplifying fractions even if they don't have to be. I could add an empty list but I don't see any interest to that since there is nothing to do in that case.
This comment has been hidden.
I added a note about reducible and irreducible fractions; added empty list.
That's better, although I don't really like this situation anyway.
I'm surprised how 40 people actually managed to complete it in C. C fixed (!) test:
But
80/1310 != 32/524
.You have to reduce first 80/1310 to 8/131 and multiply both numerator and denominator by 4, that's 32/524 isn't it?
I've posted about that in Typescript some time ago:
and here the answer I got:
My bad,
80/1310 == 32/524
. But I checked it with my Python solution, so I guess there's an issue with the lack of tests there.No problem, and if you want, you can add javascript to the above issue.
Incorrect type in the initial solution in C. It looks like the expected type is
long long (*convertFrac(long long[][2], int))[2]
. (And corresponding types in the tests.)Can you be more explicit? I don't see what you mean.
convertFrac
is used as if it werelong long (*convertFrac(long long lst[][2], int row))[2]
, but it's defined aslong long** ...
in the initial solution, so everyone (including myself and like 10 people in the comments for the last 2 years) codes a solution returninglong**
and gets crashes and random values.I can be wrong but almost all solutions (including mine) use
long long** convertFrac(long long lst[][2], int row)
without crashing or getting random values, some others use a pointer to a structure and don't crash either. If I replace the signature of my solution bylong long* convertFrac(long long lst[][2], int row)
and return along long*
it passes too. I don't have your knowledge but I don't see a problem there.It's C, so you can even use
long long convertFrac(long long lst[][2], int row)
and it will pass (in practice; not guaranteed by the standard). But if the return type waslong long
, how would you guess that the result should be a pointer to an array of pairs?long long**
is a pointer to a pointer and it'sfree
d in the tests. So I expect amalloc
ed array of pointers to memory allocated in some way. So it's either anothermalloc
for a big block (but how would the testsfree
it then?) or onemalloc
per pair (but I don't seefree
in a loop in the tests anyway). So Imalloc
each pair, return the result and get an error message that "actual" with random values different from what was returned should equal "expected" that equals to what the solution tried to return. From your solution:If the return type is
long long**
, why isn'tresult
long long**
too? Becauselong long (*)[2]
is the correct return type. Then why the type cast? It just hides a valid warning. Without the cast it still works, but it sayswarning: incompatible pointer types returning 'long long (*)[2]' from a function with result type 'long long **' [-Wincompatible-pointer-types]
.OK, I see your point. What advice do you give me now? Only change the initial signature? Unfortunately whatever the solution there is no warning from CW.
Change the function signature and the corresponding type in the sample tests:
Done.
I see changes in the tests, but the signature in the initial solution remains the same.
Initial solution was changed to:
That's better, but why not
long long (*convertFrac(long long lst[][2], int row))[2]
?Clearer now?
Yes, looks good.
C++ version: Using a
std::vector<int>
to represent the rational numbers is awkward and brittle; in theory, I'd have to test whether or not I actually have exactly two numbers in thatvector
, not 1 or 3 (Monty Python holy grenade problem ;-) ).Suggestion: Use
std::pair<int, int>
as type for the rationals.All the tests pass, but the exit code is 139. What can be the reason? I use c++.
Not an issue. That's segfault.
One of the java tests is wrong.
expected:<([18078,34060)(2262,34060)(25545,34060])> but was:<([6026,11353)(754,11353)(8515,11353])>
All of the first set, above are divisible by 3.
34060 is not.
You're....right. So why is my code thinking it is when it understands smaller numbers??.....weird. It shouldn't be hitting long overflow.....
In the description it says "where all numbers are positive ints." for the input, then one of the test cases has "[[3.4285714285714284, 12.0], [4.0, 12.0], [1.0, 12.0]] should equal [[24, 84], [28, 84], [7, 84]]". Hmmm... those are not positive ints. Also, the denominators are all the same, so one would assume that "in which D is as small as possible" would be 12, not the 84 that is required if you want the rationals to have ints on the top and bottom. I guess what you meant was that the result must all be positive integers and d is as small as possible, which is an entirely different problem. Can you either be more clear with instructions, perhaps making them accurate, or at least give enough examples that what you meant can be inferred even if your description is inaccurate or unclear?
Which language? As far as I know all numbers are integers. Did you mutate the input?
I apologize, this is for python, I did not mutate the input, those lists were pulled from the failed test cases.
You do know that in Python tests,
X should equal Y
X
is the value your function returns andY
is the expected value right? The non integer value was produced by your code, that's not the input value.again g964 and again bad kata explanation. really, enough!
PureScript Translation Kumited - please accept :D
in which D is as small as possible and
N_1/D == numer_1/denom_1
My code generate (3,6) for pare (1,2) and here D is the smallest, but test code generate (6,12). And such situation in each test. One more example. Expected: '(18078,34060)(2262,34060)(25545,34060)', instead got: '(207,390)(261,3930)(9,12)' But my D is smaller than test D and my answer still correct because 18078/34060 = 207/390 2262/34060 = 261/3930 25545/34060 = 9/12
The output fractions should have the same denominator, as seen in the instructions.
So you want to say that
2
is same denominator as12
? Seriously?I didn't say that, read the instructions (until you get them) and the sample tests. Do you know what common denominator is?
You don't need to reduce the fractions after you got the common denominator, the denominator as I already said before, has to be the same for all fractions.
None of the solutions pass all tests for Python 3 due to how number precision changed: https://docs.python.org/3/tutorial/floatingpoint.html
You have to use Python 2.7 to pass this.
Python 3.4.3 and 3.6 work very well for that kata. Moreover you don't need float numbers.
[[77033412951888080, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]] should equal [[77033412951888085, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]] I tried this problem in Python. but i got this message. It said me that '77033412951888080' should be '77033412951888085'. However, because this number is extremly large number and it required to use multiplication, gap '5' between my answer and problem's answer is nonsense. please check this issue quickly.
make every output an int - LCM is an int, LCM/numerator is an int. Don't let floats creep into your results ANYWHERE. That worked for me.
For Python 3.6 the test case with (77033412951888085, 14949283383840498), (117787497858828, 14949283383840498), (2526695441399712, 14949283383840498]) is wrong. The first nominator has to be 77033412951888080 (or there are precision issues with large numbers, but I doubt that).
The tests look correct. 77033412951888085 can't become 77033412951888080, whatever D would be.
This comment has been hidden.
This number is bigger than the maximum precisely representable float, so floats can't be used here. I still don't understand what you think is wrong.
As I said, there is an issue with precision - that's exactly what is wrong. One could argue if you should provide for this case (by choosing smaller numbers) - this is not something you should be required to know only to solve this problem.
Try to use the integer division which uses the operator "//" instead of the usual "/" i think that you have a precision issue
make every output an int - LCM is an int, LCM/numerator is an int. Don't let floats creep into your results ANYWHERE. That worked for me.
I had the same percision issue. You have to use // instead of /. @Morcu - Thank you for the tip!
There is a an error in the GO test cases, the solution to {{69, 130}, {87, 1310}, {30, 40}} should be (36156,68120)(4524,68120)(51090,68120) and not (18078,34060)(2262,34060)(25545,34060). 34060%40 is not Zero.
issue confirmed: the expected ouput is effectively
[[36156, 68120], [4524, 68120], [51090, 68120]]
(tested with python top solution)=> either there is a bug in the go version or actual and expected are swapped in the assertions.
Issue not confirmed:-) You forgot to simplify the resulting fractions...
36156/68120 == 18078 / 34060
and same for others... Numerators and denominators must be as small as possible.Hey! 36156 / 68120 == 18078 / 34060 == 695 / 1310 and same for others... And what to do?
There is an error in the PHP test cases, the solution to (69,131)(80,1310)(30,40) is (180780,361560)(22080,361560)(271170,361560) not (262,524)(32,524)(393,524).
The same for (6,9)(5,8)(7,8)(2,3)(5,6) is (48,72)(45,72)(63,72)(48,72)(60,72) not (16,24)(15,24)(21,24)(16,24)(20,24).
Not a kata issue, you have to reduce the fractions first and then find the common denominator.
@Chrono79, you are right, thx!
There is an error in the F# test cases, the solution to (690, 1300); (87, 1310); (30, 40) is (180780, 340600); (22620, 340600); (255450, 340600) not (18078, 34060); (2262, 34060); (25545, 34060) as stated in the tests.
im returning a string (6,12),(4,12),(3,12) instead of (6,12)(4,12)(3,12) how can i remove the "," ? it must works on all sizes (nnnnnn,ddddd)(nnnnnn,ddddd)(nnnnnn,ddddd)
Format the strings correctly, and you'll get the correct output.
i am trying to do with python, numpy.lcm is not working..
the same. numpy module is absent or too old. Thus try to code your own lcm by hands)))
Currently numpy module version is 1.14, so no lcm.
This comment has been hidden.
Denominators should be as small as possible.
Ah... I see what you're saying!
I'm trying to do this kata in F#. My code passes the sample tests and all the random tests but it gives the following cryptic error message when doing the first part of the automated tests:
I can't tell from this if there is a problem with my code (an edge case I've not considered) or if there's a problem with the tests themselves. Can someone please clarify this?
First: when you are not sure if the problem comes from your code or from the kata, please post a question not an issue:-) Second: nobody else than I passed the F# translation. All I can say is that I pass the tests... Morever I use nowhere "reduce". So it could be your code when you use "reduce" in your function "convertFracts". Cheers.
I thought it would count as an issue as it was giving an error message rather than simply telling me that the code failed a test. I don't get this error message in the REPL on my own machine so it seems to be particular to the site. But I take your point!
I doubt that the reduce function is the issue, given that it passes all the random tests, but I'll try and alternative solution so see if that works better. Out of interest, how many tests are there under the
should work for some examples
section? I see four passing tests, then an error message, then all the random tests passing. Is it failing on the fifth test maybe?OK, got it. I was running into an unexpected "feature" of reduce that I was unaware of.
Inelegantly solved. Thanks for your help.
This comment has been hidden.
This comment has been hidden.
Yes it's ok, TS became long after JS translation and I don't think it is a problem. Little by little I will try to modify all languages in this way.
Already raised as an issue
This comment has been hidden.
Alr raised as issue
expected:<([200,20000)(60,20000)(8,20000)(1,2]0000)> but was:<([100,10000)(30,10000)(4,10000)(0,1]0000)> sorry, the 0,1]0000 , I can't understand!!!
What's between square brackets, is different between actual and expected.
Ok,thanks, I will solution this one finally.!
I'm having problems with one particular test case... I am getting the following error when lst = [ [1, 2], [4, 5], [3, 4], [6, 9], [7, 10] ]; expected '(90,180)(144,180)(135,180)(120,180)(126,180)' to equal '(30,60)(48,60)(45,60)(40,60)(42,60)' Is LCM(2, 5, 4, 9, 10) really 60? My code passes all other tests but this one, it passes even the random tests... I'm not sure if I'm doing something wrong or if there is an issue with the test cases... Also, not sure if it matters or not, but I'm trying to code it in TypeScript.
EDIT: I found the error, and now I feel dumb for not realizing it sooner...
This comment has been hidden.
This comment has been hidden.
At least one where you have to reduce the given fractions first. :)
Hi, I am using Python(3.4). All other tests pass. May I know why this is happening for the last one? Thanks! [[77033412951888080, 14949283383840498], [117787497858827, 14949283383840498], [2526695441399712, 14949283383840498]] should equal [[77033412951888085, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]]
This comment has been hidden.
Is a precission issue try to use the try to use the integer division which uses the operator "//" instead of the usual "/"
make every output an int - LCM is an int, LCM/numerator is an int. Don't let floats creep into your results ANYWHERE. That worked for me.
Thanks for that @Woody Woodburn I would have never guessed what was the issue.
The random tests appear to be wrong for typescript as the LCD is not always selected:
ex.:
expected '(30,60)(48,60)(45,60)(40,60)(42,60)' to equal '(90,180)(144,180)(135,180)(120,180)(126,180)'
for TEST: 1,2,4,5,3,4,6,9,7,10, RES: 30,60,48,60,45,60,40,60,42,60
After running several of the solutions to this kata (in Python) I can only assume that the tests have changed since the inception. None of the solutions I tried would clear all of the current tests; some test fails because the true lcm would not have been found, and two tests fails because the assertions of the tests are obviously wrong ([[1480, 2775], [174, 2775], [444, 2775]] should NOT equal [[1480, 2775], [175, 2775], [444, 2775]] for example).
Fraction 175/2775 = Fraction 7/111
(7/111 is the second given fraction; you can verify that:111*175=7*2775=19425
) but your answerFraction 174/2775
is NOT equal toFraction 7/111
(111*174=19314
). Google "Equality of two fractions".I see that I totally misunderstood the output of the tests. Sorry for wasting your time.
I'm failing the tests: [[1480, 2775], [174, 2775], [444, 2775]] should equal [[1480, 2775], [175, 2775], [444, 2775]] and [[77033412951888080, 14949283383840498], [117787497858827, 14949283383840498], [2526695441399712, 14949283383840498]] should equal [[77033412951888085, 14949283383840498], [117787497858828, 14949283383840498], [2526695441399712, 14949283383840498]]
It seems to me that the input should be equal to the output in both of these cases and that the test is wrong. Am I missing something? I'm doing the kata in Python 3.4.
Please look at the top of the page to see how many guys passed the Python kata. When you ask for help, post a question not an issue.
Ok, sorry for posting it as an issue. I'll rephrase myself: How can those tests be correct when 174/2775 != 175/2775 for example?
make every output an int - LCM is an int, LCM/numerator is an int. Don't let floats creep into your results ANYWHERE. That worked for me.
I have passed the test cases when I attempt the problem in c++ but it does not display the Sumbit solution button...
I wrote a solution in python3 that works in my IDE for any test case I can think of and the web-tester says it passes, but the final upload says it fails and gives me a screwy error message:
[[1, 1], [3, 1], [4, 1]] should equal [[1, 1], [3, 1], [4, 1], [5, 1]]
How the hell is the solution supposed to have an extra pair of num/denom not even in the input?
Input is [[1, 1], [3, 1], [4, 1], [5, 1]]
I just ran the test again with the same code and the input [[1, 1], [3, 1], [4, 1]], which in my IDE gets me the expected output ([[1, 1], [3, 1], [4, 1]]) but the grader does not get the same result. The other test cases also work fine in my IDE and the web-tester, but this particular input makes it brainfart. I think there might be a little gremlin inside this program messing with the outputs
I don't know about your code but here's some tips for Python or any other languages: 1.) look up LCM and GCD (math terms) 2.) in Python, be sure to use integer division when warranted, as opposed to float, I had some problems in python with that ... 3.)as a sidenote, there are some efficient algorithms apparently that compute GCD with heavy usage of bitwise operations, but traditinoal recursive GCD such as found in "Introduction to Algorithms" Cormen,Leiserson, Rivest seemed to work for me.
This comment has been hidden.
OP solved it, closing
I was doing this in python and apparently I have the wrong parameter type or wrong return type...? I was doing this in PyCharm and I have parameter lst is a list of tuples.
Based on your description i think i faced the same problem. In Python3 / (truediv()) returns float. Use // for integer division (floordiv()). You can also change the interpreter version above the editor area.
Question not specified.
This comment has been hidden.
You could print the input.
Welp, I guess I lost sight of the wood for the trees there :'D thanks
Tests are wrong!!
With my code, the result of one test is:
[[7860, 17030], [2431, 17030], [12876, 17030]] should equal [[322260, 698230], [99671, 698230], [527930, 698230]]
This is not correct. The gcd is not 698230!! Is 17030, 41 times lower than 698230. So, to be honnest, I would pass the kata if test would be correct.
...Do you expect people to know what you're talking about when you don't provide the input for this test?
For the record, the input is
[[6, 13], [187, 1310], [31, 41]]
. You can calculate by hand that the lcm is 698230.Please reflect on yourself before saying the test is wrong, and if you want to say the tests are wrong you need to give enough info to let others know (and follow up) what you're talking about. It's the no.1 mistake newbies make on this site ;-)
12876 / 17030 != 31 / 41
Hi, my solution in Swift produces
Process exited prematurely with a SIGILL signal.
Is there something bad in my solution or another errors occurs?
It is a question, not an issue. Your code is too slow or has error(s). 14 guys passed the Swift translation.
I used the older version of python (2.7) to pass the test. Its failing in the new version as long is not supported
the same happened to me, but it didn't work to use 2.7 I used decimal.Decimal before multiplying
After completed this Kata, I've looked upon the previous solutions and hell... The test cases are not adequate! Almost everybody is using recurse and totally forgets about big numbers!
Using recursive algorithm with big numbers may be a suicide way (as may kill your stack). A recurse modulo-GCD can go into a 127-deep recurse-chain. (which can cost 24000 CPU-tick vs. iterative version's 490 tick worst case) I highly discourage using that, in particular if there are more ways to avoid the recurse!
Also if you can't be sure that numbers will always be small enough, then you really should: first divide then multiply! (a * b / gcd() can overflow eg. a = 2^64-2, b > 1)
Note for strings: repeately building the exact same string from a non-changing "constant" (least common multiplier) in every step in the result-building loop... well you should avoid that too. (always pre-occupy memory (reserve) if you can estimate the usage)
This comment has been hidden.
Getting timeout error each time i run.
For the time being CW times out with every kata I tried...
In C, the casting the long long ** act into a (long long (*)[2] ) is changing the values and I have no idea why.
Learned a lot about finding the gcd. Very challenging and pedagogical.
rust test cases seem to be wrong
the lcm of 1300,1310,40 is 340600 this is different than the test case 34060
see: https://www.wolframalpha.com/input/?i=lcm(1300,1310,40)
Yes but the lcm of 130,131,4 is 34060...
Is this issue had been fixed?
There is no issue.
Try again? ;-)
Thanks. Got it. I make a mistake.
empty array.... what a boring case!
I'm working on C# language the test give me this error: "System.ArgumentOutOfRangeException : Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index"
I copy and paste the expected output in the return sentence => "(6,12)(4,12)(3,12)" and it gave me the same error. When I put a shorter or larger string it say me that the outputs doesn't match. But when I put the exact characters it give me the out of range error. What am I doing wrong?
I think the description should specify what to do in case of dealing with an empty array.
This comment has been hidden.
[[1, 2], [0, 2], [0, 2]]
is what your solution returned. If you want to see the input, you can print it.OK thanks I did not realise that. Not sure how I can print the input. I have not seen how to do this. In the meantime I have been logged out so it seems I have lost the chance to complete the kata.
In the language of 'С' is not working. Sample test is not working and my code is also not working. Some problem with memory. =/
There are no errors in the tests. You could have given what the kata is returning.
The final test times out. and I have no clue to why. the initial test is all fine.
Could you please post the test case input arrays? The "expected output" does not seem to follow the instructions for all solutions as the second value in the pair cannot always be divided evenly by the first value in the pair. Thanks.
You could have seen that 433 guys passed the JS kata (out of a total of 2502). The fixed test cases are the same in all languages. Print the input to see it. PS: it's not an issue since it is not a problem of the kata.
This comment has been hidden.
This comment has been hidden.
I guess the problem may come this line :
long long** result = (long long**)calloc(row, sizeof(long long));
try to declare result as :
long long (*result)[2] = calloc(row, sizeof(lst[0]));
I believe there should be some fallacies in test cases since the description require a minimum D. Other than the case raised by tchar. Also there can be test case like: [[2/4]] which should generate this output: [[1/2]]
Maybe the author could modify the problem description so that solvers are required to put the l.c.m. as the denominator.
I'm trying to complete this problem using c++ but am getting a SIGSEGV error during attempts. Does anyone have any suggestions for how to resolve this? My guess is that the issue stems from multiplying two large integers when calculating the least common multiple.
Passed all tests, but can't finish kata. What's problem? I've written code on Java.
Currently Codewars platform has lots of issues. It's not a problem of this kata. See:
https://github.com/Codewars/codewars.com/issues/893
Thx for information.
My solution has a problem about round() when the input number is very large.
Hey. I have trouble allocating memory for result in C language. Error. Expected {{6, 12},{4, 12},{3, 12}} but got {{6, 12},{0, 33},{4, 12}} I have also verified whether by returning shifted array I could reproduce the bug. I did. So at my platform my array is continuos {6,12},{4,12},{3,12}. However, at return, it is read as {6,12},{0,33},{4,12},{0,33},{3,12}. I have verified (to no avail) whether sizeof(long long) is equal on both ends - it is indeed. I am stuck here, and my kata is basically solved (algorithm-wise). Here is how I've allocated said array: http://pastebin.com/yXzTDvGG
I have the same problem. Don't know hot to submit...
This comment has been hidden.
This comment has been hidden.
Did you see at the top of the page how many guys passed the Python kata?
I did see how many people passed it but not sure what you mean by that. My question was in regards to the simplification of the fraction(numerator & denominator) prior to finding common denominators since the code I posted above does that. I thought I understood from some of the other discussions below that you had updated the kata to include simplified fractions but I guess not.
Not trying to be a pain in the ****, I did learn a lot while troubleshooting this one so thanks for posting!
This comment has been hidden.
Thanks!
This comment has been hidden.
Something is not right when testing my solution. It fails for me on one of the test cases, but when I print my solution, it's the same as expected one:
XCTAssertTrue failed - should return [(6, 12), (4, 12), (3, 12)] convertFracts 1 : XCTAssertTrue failed - should return [(6, 12), (4, 12), (3, 12)] Log Result: [(6, 12), (4, 12), (3, 12)]
It it possible == operator fails which makes me fail the test? If I'm not seeing things, my solution is the same as expected one.
I just tried and saw no problem but as you are the first who tries to pass with Swift could you post your code (mark it as spoiler) and I will give it a try? The
==
operator has been extended to take into account the nature ofreturn
and ofexpected
.This comment has been hidden.
This comment has been hidden.
Good!
This comment has been hidden.
Description says:
Do you think your denominateur
361560
is as small as possible?Take a look at this, please.
But what's more important, is that
524
number isn't denominator for138
.My PHP Solution is giving me an error as well and it seems to be the same as Sardis93's.
My attempt echo's each test run's input:
everything works as expected until that last test case it errors, giving me:
This is certainly a bug in the Kata I would think. That last test just doesn't check out.
Please take a look @g964
There is no error in the tests. Your result has not the as small as possible numerators and denominators.
Can you explain to me how that is?
Show me the math on that test string to get a smallest common denominator of
524
please.Here is a wolfram link showing the Least Common Multiple for
138
,1310
, and40
(the denominators from the test case): https://www.wolframalpha.com/input/?i=least+common+denominator&rawformassumption=%7B%22F%22,+%22LCM%22,+%22commonnumbers%22%7D+-%3E%22(138,1310,40)%22&rawformassumption=%7B%22C%22,+%22least+common+denominator%22%7D+-%3E+%7B%22Calculator%22%7DRunning into the same issue, I've love to see the math to get to 524 like jmherbst said.
This comment has been hidden.
The Python (?) tests was planned to use only irreducible fractions in first array. I was not able to modify that since more than 500 guys passed the Python kata: the tests are no more editable after the 500+ rule.
This comment has been hidden.
Hi. Why i have this error? language-Python 3.4.3
[[12, 84], [28, 84], [7, 84]] should equal [[24, 84], [28, 84], [7, 84]]
Your result is wrong. Print the input and you should see that.