6 kyu
A Fun Way of Finding Pythagorean Triples
185 of 213brodiemark
Loading description...
Geometry
Mathematics
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.
is this broken?
what makes you think it's broken?
When doing a full attempt, it comes up saying i have extra triples, although these triples are valid, and Im pretty confident my iteration through range of a is working correctly. I saw that the task was somewhat old and that wisdou had issues with c# big numbers before, thought it possible that the testing algorithm had become outdated or something maybe. Can you perhaps look at my code and tell me whether I have just created a faulty program or if the issue is something deeper. Am new to both c# and codewars so could issue be a me issue.
I believe you are correct! The C# (and the Java and Swift translations) are overlooking solutions where the squares of one or more of a,b,c exceed the integer bound.
For example, for diff = 8696, low = 945745, high = 2531281, the Python solution finds (947864, 51654240, 51662936) as a valid triple. But the C# version does all the calculations in integers, and so overlooks this (and other triples). If the calculations are done using doubles (as your program wisely does), it finds them. Amazingly, all the people who solved the C# version previously overlooked this as well (so I don't feel so bad :-)).
I believe I have fixed the translations.
Congratulations on discovering this!
PickCormac, please try your solution again. It should be successful.
Yes, it has been accepted now, thanks
create_pythagorean_triples(564, 456, 1654) [(1128, 846, 1410)] should equal []
But 1128 ** 2 + 846 ** 2 == 1410 ** 2, 846 + 564 == 1410
Did i miss something?
a, the first element of the triple, has to be the smallest side. This is not true for 1128, 846, 1410.
If i return [] everytime first element is not smallest i get another error telling [] should be some not empty list.
Nvm, solved.
yes, you shouldnt make it so returning anything is dependent on if one triplet found is actually invalid. I believe your mistake is in making it return no valid triples based off the fact that one triple had a > b. I would reccomend making it so a!>b is a condition within the statement that checks if for a given value of a, if a is triplet so it doesnt add an invalid ( a>b triplet to the list in the first place). Unless i misunderstand your problem i think that is what needs a fix.
C# translation has issue with big numbers
Can you please provide an example? When I click on “View Solution I see Python code, so I can't tell a lot from that. The problem is only intended to deal with integers, so you don't have to return bigger numbers.
It does not consider triangles with the length of A bigger than one million in random tests
Thanks for noticing! I believe it is fixed (and in the Java version as well).
Hi,
Inputs are 3,9,9, so output: [(9, 12, 15)] should equal []=> why?Cheers
Why you removed your next comment? I also get the same answer
[(9, 12, 15)], so the ref sol is wrong, no?because I thought it was a ref solution, but it's an input generator, actually. I didn't investigate further (didn't want to). But it probably boils down to the very saame problem (an exclusive boudnary that should be inclusive). But again, I didn't check that is the actual problem.
This is the same issue that Just4Coders identified last night. When I 'fixed' it then, I forgot that there are two sets of random tests (small and large inputs), and I only fixed one. I have now fixed both (and I ran 5,000 random tests in my IDE to check.)
The fixed tests have the example (4, 100, 100) -> [(100,1248,1252)]), so they illustrate the correct behavior.
You should specify the input range of arguments.
Done.
Question: Is it ever acceptable for a kata to have different input ranges for different languages? Or when you specify the input ranges for the first language, should you think ahead whether all translations will be able to cope with the same ranges?
If you have performance criteria, the input range should be tweaked to fit those per language. In other cases, I would use the same range across languages.
This comment has been hidden.
Let's see how it goes when new translations get added. If each language gets its own range, perhaps it's better to specify the intended complexity (big O notation), rather than range of input.
This comment has been hidden.
Wow, amazing catch! I must've run those 50 random tests 10 times without seeing that even once.
I've removed the case num==0, since the only alternative I see is placing some duplicated code in the else near the end of generate_random_test. If anyone has a cleaner solution that keeps the case num==0 please let me know!
I added the imports.