7 kyu
Large Matrix Expected Value
121 of 128daspreuße
Loading description...
Statistics
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.
Rust translation has an incorrect reference solution. For example, if r = 6 and c = 11 then the correct expected value rounded down is -3. But Rust expects -2.
Also, Sample Tests do not compile.
This comment has been hidden.
Fixed
Rust translation
The author of this kata states "There are no complicated formula that propagate many errors". I solved the kata with a rather complicated formula and it did propagate many errors, till I figure out when and where to do the notorious rounding.
@daspreuße, man... Your katas are so badly broken. You are messy while writing instructions, your testing fails all over and specs for intended types are unclear, too. This particular kata expects us to hardcode wrong practices. I see no point doing these.
So many times I found you just copy things all over without any review or thorough revision what did you actually wrote.
From this very moment on I avoid your katas for good. It's not worth the time.
Could you elaborate on the "expects us to hardcode wrong practices" part?
vaaaaaaaax! Don't I recognize you, whatt47? It seems like you leave a stream of havoc wherever you go.
I didn't read the entire thread below ( and, not having solved, I can't even see everything ). However:
Please do not use rounding. Expect an exact answer, or test with a ( relative ) error margin.
Please do not close this issue unless and until it has actually been addressed.
with 10^18, IEEE double precision floats will be precise to maybe the thousands place in decimal system.
We have 2^58 < 10^18
Imagine you have 2^58+64+1. Double precision will turn it into 2^58.
I chose 64 because I'm pretty sure it is not precise up to 64 when it is 2^58.
However python integer 2^58+64+1 remains 2^58+64+1.
This comment has been hidden.
Fractions or big floats might be better in Python, but with a possibility of translating to other languages rounded exact answers look good to me. (Well, another option is to reduce the range.)
This comment has been hidden.
This comment has been hidden.
Why rounded exact answers, and not exact answers, with a possible representation error, tested with an error margin? Is there something that makes this kata special? ( I haven't solved; not discounting the possibility. )
Returned in which type? With the current range 64 bits are enough for the result, 53 bits are not. With an
introunded down the difference from the exact answer is less than 1, with afloatit's all the missing bits. Isn't integer just a fixed point number with 0 digits after the point? It's an exact answer with a representation error too. Maybe it's not the closest integer if it's rounded down, but rounding down is less confusing because there's no ambiguity with .5s.Rounding down is just as bad as rounding halves up, just displaced by
0.5.0.9999999999rounded down is0.Type: yes, this is Python isn't it? I'm mostly used to JS, which only has
Number, ie. float64. I don't know; what type does the kata expect? Maybe it is unrealistic to expect the final answer to be the same type as intermediate values - but most kata do that. Maybe this kata is special in that respect.This kata is not special in that respect, Johan. Fraction is the only type that doesn't create additioal problems. This kata is about rational numbers, it should be a no-brainer to stick to Fraction as return type.
Rounding down works well for this kata: all input values are integers and all computations can be done with integer arithmetic. So there are no rounding issues. Returing Fraction could be problematic for languages without native rationals (e.g., JS).
All computations can be done with integer arithmetic, but solver does have to take care to only do divisions at the very end, and round after that?
In which case: Author, do you want endless issues because careless solvers use intermediate floats, no matter how carefuly you write the specs? It's yielding to careless solvers, granted, but IMO it beats the alternatives. Test with a relative error margin, and save yourself a lot of trouble ( and quite possibly downvotes ). Or use fractions, and a hypothetical JS translation may have to ask for a tuple of bigints.
I'm surprised we all of a sudden are OK with rounding results. As Johan said, we don't know which intermediate steps users take in their solution. Why can't we just expect precise results, since we are dealing with just basic integer arithmetic?
I am still not OK with rounding results. There are better possibilities.
Ultimately, it's author's choice, though I feel going against established best practices: might impact eventual approval; might lead to a lower quality kata, that might have unnecessarily low satisfaction; and would thus impact CW quality as a whole.
But the only thing we can do if an author insists on having rounding is raise issues ( which should be done once or maybe twice, but not endlessly ), and ultimately withhold approval ( at which point someone else might approve despite the lower than possible quality ).
Other opinions are obviously available: I value monadius' opinion quite highly, though I think he's a bit optimistic that solvers will be careful to maintain precision as long as possible. Also note that the Beta, with rounding, has lots of upvotes already ( though I don't know who these people are ).
I'm willing to let it go; I've had my say. I still would not understand why testing with an error margin wouldn't be a better solution, and why one wouldn't want a better soution, though.
This kata expects a precise well-defined mathematical result. So I don't understand why rounding down is a problem. Rounding != floating-point. I think it is an important lesson to learn (especially for beginners). Returning imprecise floating-point results is a not a good idea for this kata since precise options are available (rounded down integers are mathematically precise). There are many kata which require integer rounding and nobody complains.
I leave the final decision to the kata author. @daspreuße, either change the return type to
Fraction(and make it harder to translate this kata to languages which do not have rational numbers) or do not change anything and close this issue (and get potential downvotes and issues from those who solve this kata with floating-point arithmetic).That means it's not harder for languages which do not have rational numbers, as in those languages the user could just do integer arithmetic and return a
Tuple(int, int).Either way, like Johan, I don't want this hill to be my last stronghold before I die. Votes are good, kata is ready to be published.
I will leave it as is and close this issue now.
⌊(an integer)(sum of integers)⌋ is the quotient of an integer division, no floats, no rounding problems.
There is no reason not to expect a Fraction for this problem. Use Fraction instead of float as return type. If you do keep float, make sure even more accurate solutions using Fraction would also pass this kata.
This comment has been hidden.
This comment has been hidden.
(dummy comment to flush dashboard cache)
how would I go about solving this?
Either expect Fraction as an answer, or verify user solutions using approximate equility. The docs describe how to implement this.
This comment has been hidden.
Either change result type to a precise one (fraction or decimal), or if you want to keep float, reduce inputs to the point that expected answers are below MAX_SAFE_INTEGER or whatever it is what would prevent from losing precision.
This comment has been hidden.
You're not handling the root cause :/
Only if you ask users to return their solution as an integer with a doubled value. Multiplication in tests won;t help, it has to be returned from solution in a precise way. Which will be awkward to ask, unless you hav a good idea how to describe such requirement.
This would be tricky. Absolute tolerance would not work, because magnitudes wildly differ thorough the range of 1..10^18, and it would be difficult to find good absolute margin. Relative tolerance could help, but again, I think it would not be the way to go. Turning this problem into a precise one is very easy, either by changing return type or by reducing range of inputs to fit into float.
This comment has been hidden.
No, not really. It fails because if
ris big, thenr/2is also big, big neough to not fit into a float, and gets truncated. As a result,r/2is not equal to a half of the originalr, but is less than a half ofr.Should I just ask to return the closest integer solution rounded down? a simple bitshift will round down both positive and negative.
I think that I've already said a couple of times what would be IMO the best solution? Either reduce input range to 10^15, or use a precise data type like
fractionordecimal.We can wait for others to see what they would advise.
I have done that. I feel bad for erasing everyone's original solutions. I don't know how resubmitting works. I haven't used codewars much, but at least this is fixed for all future solutions.
I just realized how small 2^64 is and I know some other bits are set to mantissa or whatever so it is even smaller. I was naive to search up biggest float without realizing facts that the previous float before that one would be 2^971 less.
Again, not handling the root cause. This kata is a perfect candidate for expecting a rational number, aka Fraction in Python. I'm done here. Good luck with your kata.
I am sorry that you are bummed out. I feel the same. I turned it into a fraction solution, but somehow that work did not save and that bummed me out even more, so I don't want to redo that. I'll be more proactive.
Well, this kata has big potential, I like everything about it, except they way you handled the last remaining issue concerning the return type. The kata still manages to get high upvotes, so others are not as much (or not at all) bothered with the changes you made. I will drop the case and support this kata.
The "formatted" implies that the return value shouldbe a string. Why string, and not a precise fraction?
I removed that block of text. It is unnecessary.