6 kyu
Compare powers
123 of 2,286GiacomoSorbi
Loading description...
Algorithms
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.
My solution passed tests, but Execution Timed Out (12000 ms). I used BigInt in the loop for big calculations. What should i do?
If you have execution timeout, then the solution does not pass, despite of returning correct answers.
See if this paragraph helps.
In Java i find it imposible to do the large number part, because its bigger than the range of long
Not a kata issue, naive exponentiation will fail.
Consider a different approach to this problem.
I am curious if maybe something is incorrect with the python tests?
My solution passes all "larger numbers" and passes all "random tests". But in the "Smaller Tests" it fails only one test. I cannot see what is being tested though.
Your solution returns incorrect answer for input:
[1, 7]and[1, 8].Lua translation!
Go translation
D translation
Approved
Rust translation
23891895^ 91618561 shoudl be larger than 42369119^ 59683074 (should return -1 checked with wolframalpha) however it is saying return 1 is correct in random tests c++
I keep failing the random tests, but I think the test is wrong. It's passing 676^147 and 890^137. It's expecting a zero and I'm returning -1. I checked it in Wolfram Alpha and the first one IS greater.
Should be fixed, please verify.
This kata is a subject to deduplication process here: https://github.com/codewars/content-issues/issues/122.
Please join the discussion to help us identify duplicate kata and retire them.
This kata was decided to stay.
595^119 with 601^112 expects 0 in C# random tests.
I'm getting the same problem. I think the checker for the random values is wrong.
There was a bug in a reference solution. It should be fixed now. Can you check and verify?
My solution passed the random tests now.
Hi guys I can understand, my c# consider that "34 98" smallest than "51 67". But in this task Expected: -1 But was: 1 Where is mistake.
This comment has been hidden.
This comment has been hidden.
Please use a spoiler like you've been asked to. See there: https://docs.codewars.com/training/troubleshooting/#post-discourse
This comment has been hidden.
That was harder than I thought. Even though I solved it in the end, I think I just accidentally won by using the common sense instead of using the math knowledge, which I don't possess anyway... At least I've learnt something about numpy and its limits!
COBOL translation.
approved
Great kata, got stuck on this for a long time and skipped and suddenly got the eureka moment ^^
Some tests in Haskell are not enough informative :
Ruby 3.0 should be enabled.
Enabled in this fork
This Kata has a problem with ruby language. Bignum class numbers, when they are high the power, end up being considered Infinity So, the comparison ends up being impossible
That is not how you would solve this problem :)
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This one is pretty good
Thanks :)
C# Compare 334^127 to 646^138 - expected answer 0, answer received 1. - why the expected answer is 0?
Should be fixed, please verify.
Still experiencing [1,7] [1,8] expected to be equal 0 not 1 in JavaScript :(
Aren't they the same number?
your brain sometimes farts after few hours of coding ;) thanks for quick reply!
My pleasure :)
This comment has been hidden.
Done, thanks!
Thank you for this kata ☺
Thank you for your time :)
Doesn't have to be a high level mathematical solution. Try thinking around testing for out of range outputs then reducing the inputs until the outputs are within a range where they can be accurately calculated.
Issue with Javascript tests, when i run sample tests i get 5 / 5 correct in the smaller numbers. when i run solution against all, i get 49/50 correct, the incorrect one being the last one in the smaller numbers test.. confused..
Which case are you failing?
The last one of the smaller numbers basic tests: Expected: 0, instead got: 1
but when i run all the tests it passes.
edit: sorry i meant when i run just the 5 small tests, it passes
Then you have a problem with that test case: check your code.
But when i just run the 5 small tests the last one passes.. when i run all of them that same last one of the 5 small tests doesn't pass.
how can it pass and not pass?
Did you downvote my previous answer?
Most likely the tests are different, as easy as that: can't you just
console.log()the input?python: you should put some tests that can make my code fail
This kata is not compatible with Python 3; could use
rangein place ofxrangeto fix this (from the random cases).Done!
C and NASM translations. Please review and approve.
NASM description made the C version unapprovable: can you fork?
I created a new fork and resolved conflicts in the description.
Approved :+1:
This comment has been hidden.
I'm so tired of "gotcha" katas - katas with a simple enough description and simple enough initial tests and then you get wollopped on final test because it involves extremes not hinted at in the kata description or the initial tests.
The kata description should have mentioned that extremely large numbers (beyond JS's abilities) and should have hinted at the mathematical trick needed to solve it. This is supposed to be a test in coding, not obscure math theory (I studied engineering with more than two years of calculus and I had to stretch my memory to remember this chestnut.) The other problem is that in certain boundry conditions this would fail. This trick is not not lossless - if two of the compared numbersh happen to be close enough, they will read as false. You can't encode 100 bits of number into a 64 bit data type and not loose some precision. It only will work if the numbers are far enough apart to distinguish themselves over the loss of resolution.
It comes a bit late, but i second your opinion.
I come to this site in search for puzzles that help me improve my algorithmic and coding skills and too often stumble in problems that rely on deep knowledge of Math.
Well, brute-forcing even smaller number is VERY computationally intensive, so that is bad (and you should learn about avoiding those pitfalls); the "deep knowledge of Math" might by in some other katas, this one requires stuff I learnt in middle-grade...
With a very basic mathematical knowledge you can solve this kata, just think. Like GiacomoSorbi says, the point is trying to find a way to avoid useless big calculations when you can do the same with a small one, that's also coding skill.
This comment has been hidden.
Please, when posting code always use the spoiler tag and correctly format it (using a starting and ending triple backtick).
I tried to reproduce the case you linked, but the
Expectedvalue is correctly given (1): you can also see it by yourself, as12**836==144**209. Also, I think you missed the point that in this kata you have to return -1 if the first argument is bigger.Finally: very creative solution, but I doubt that is always going to work.
An interesting discussion concerning this kata difficulty and the general ranking system on CW: if you have anything to say, everyone's contributions are welcome :)
For anyone having trouble solving this kata when it comes to tests that result in Infinity - you need to find a way to calculate the number of digits that will be in the a^b result, rather than trying to calculate the actual result.
Mh, that's not the way I would recommend as it is rather open to edge/ambigous cases, but let me know if it works :)
This comment has been hidden.
This comment has been hidden.
Random tests needs to be fixed for JS they are sending in integers that are too large and being operated on as infinity
Same as below: you can't solve this kata if you calculate each single power.
Beautiful kata, thanks!
My pleasure :)
As someone fairly new, I'm not sure this is appropriate as a '7th kyu' kata. I managed the first step of writing code to pass the initial tests but couldn't figure out or even understand how to compare the massive exponents. Maybe this should be reclassified?
I myself gave it a higher rank, as it was not so trivial for me too (it is the largest part of a medium level problem on ProjectEuler, to give you an idea), but apparently other voters thought otherwise.
I can't reclassify it, but if you feel like proposing another rank, post it and I hope some admin will notice it :)
Well, proposal for a discussion about ranking in general submitted, if anyone feels like contributing :)
Jake listened to your prayers and the kata was thus upranked :)
The random tests for Javascript are so large that they return as Infinity so even if one number is larger than the other, Infinity compared to Infinity will always return as equal. Example: [ 3704, 8110 ], [ 8893, 5636 ]
The trick is solving it in another way, so that it won't either time out or come up to Infinity vs Infinity.
The test case for [1,7], [1,8] in the Javascript kata is wrong. It is expecting 1 when it should expect 0.
Fixed, thanks!
Same bug in Haskell.
Actually not: the Haskell code properly awaits for them to be equal: what error message did you get, specifically?
Guys, I think something went wrong with Python's test ( after you hit the Submit button ). It just breaks on the basic tests though all tests in kata were passed successfully. If neccessary I can show my solution.
See below. This has been reported twice already ^^".
Try now, it should be fixed :)
Hey, kinda new to this! I get this error, but i'm not sure how to fix it (ruby) Should i post my code?
Smaller numbers Test Passed: Value == 1 Test Passed: Value == 1 Test Passed: Value == 0 Test Passed: Value == -1 Expected: 1, instead got: 0
I only get the 1 error? Thanks!
I believe this is actually an issue with the test cases themselves, as some people have pointed out already. The test case in question uses the parameters [1, 7] and [1, 8], which should return 0 but the test case wrongly expects 1.
Ahh ok, I thought it might be, but I was unsure which numbers were being tested, I guess i'll come back to it, ta!
Fixed, thanks for your feed and see if anything else happens again :)
Why should
compare_powers([1,7],[1,8])return 1 as1 ^ nis always 1 it should return 0?Duplicate issue, see timp's issue below.
I'm afaid I can't as I have yet to complete this kata
However I will resolve this
Fixed, try now!
Haskell translation kumited. The example test cases contain the trivial solution, which works on the small numbers generated by QuickCheck, but fails on
Largenumbers, so it's not really a spoiler.I don't get it: what fails with large numbers? I assume the translation is ok, so what I need to know before approving it?
The trivial solution that's spoilered in the example tests will fail on the real tests:
You can approve the translation without any problems ^^".
Oh, I see. And I was not notified on this, sorry for the delay: gladly approved :)
No problem, I guess this is due to #141.
This comment has been hidden.
Yeah, the reference solution in Python also shortcuts if the first base is 1, which isn't really correct if the second one is also 1 or the exponent is zero.
There is the same problem with the javascript submit cases
All fixed, sorry for the inconvenience!
That's… Crazy. Crazy brilliant. I didn't think of that. It's great for katas where you compare floating point values. But for this kata it's probably too much, given that the user should return an integer (or boolean, if you changed that). :D
Oh, don't mock me: it was a rather trivial idea, with the added benefit that you can use it also in katas with 500+ successful submissions (apparently you can edit anything in those other than the full test cases tab, so putting it into the preloaded tabs is a blessing).
I'll make up my mind about the value to be returned and eventually fix this kata in the next 24Hrs or so.
And exactly that's the kind of information I would love to see in the conjured Codewars codex. It might seem trivial/easy/obvious (now that you've mentioned it), but something like this is worth spreading. :)
Oh, it also works in order not to have to update your sample test cases, which is now rather annoying (if not impossible); on a side note, I put the fuzzy tests here by mistake, as I had to add them to another kata, but, oh, well, I see they had some undirect purpose after all, so I think I'll keep them here as a memento.
Well, if you think of yourself as really patient and feel like guiding me into some contribution, we can give it a shot ;)
Btw, kata updated.
This comment has been hidden.
Your algorithm is too slow. The inputs can be very large, so you really don't want to calculate the values.
As Azuaron-senpai stated, with bigger numbers your algo is quite far from being optimal; I think 6000ms are not even enough to make a single test (out of 50) with the largest numbers.
It might be too late now, but you really should've conformed to the standard -1, 0, 1 for less than, equal to, greater than comparison that most languages use.
As it is, what happens if they're equal?
Only 29 solutions, so it's not really too late. Also, it would make a Haskell translation easier (one could use
data Ord = LT | EQ | GT).I thought about it, but I mutuated it from an algo I made to parse a large number of powers and find the greatest; so I needed a truthy value and implemented it as in the description:
0 if the first member is larger, 1 otherwise.If this is seriously considered a hindrance, I should have no serious trouble changing it the way you suggest.
Do you mean "greater or equal", or "greater but not equal" by larger? Either way, you should make this clear. At this point, a boolean would make more sense than
1or0, so you should probably consider usingtrue/falseor-1/0/1.I would definitely use whatever's most appropriate for the language implemented:
-1,0,1in Java and Python,<0,0,>0in JS and C#,data Ord = LT | EQ | GTin Haskell, and whatever else is most appropriate for other languages based on existing comparison functions.I thought about it for a while and I didn't find any strong point for keeping the old version.
Plus, who am I to say "no" to 2 senpai on such a matter?
Kata updated, now it performs with the -1/0/1 output, the only bother will be for coders who had opened it and still got the old testing samples.
Only positive integers are tested here. I think you should add that to description.
It would be fun, however, if we could test also negatives, zeroes (cases like
[81247, 0], [8, 1]can be fun), and probably even floats (especially powers in range 0...1). Is it worth a separate kata?That could be a nice addition to the base kata, but yeah, I would rather go for creating a new one; negative bases in particular could be rather tricky, mh...
What kind of tests where you considering in particular :)?
I don't know, I did not think much in that direction. Just thoght that there could be tricky cases if we allow more variety of arguments.
Stimulated by the feed of the senpai above, I changed this kata required output, thus I edited your code too with a temporary version.
I hope you won't find it disrespectful, but I preferred to act quickly, so to not let any user down if possible.
[I also discovered that dealing with CS was easier than I thought with backticks, mh... I might think about trying my hand a bit with it]
I've added my Coffeescript translation. Please note that I modified the description there, by adding CoffeeScript examples and also by modifying JS examples.
Approved :)
This comment has been hidden.
Fixed and added specific edge tests: nice catch :)
This comment has been hidden.
This comment has been hidden.