Retired
Saint Petersburg Paradox Model (retired)
17 of 63GiacomoSorbi
Loading description...
Probability
Data Science
Statistics
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.
This comment has been hidden.
The Description proposes really interesting problem.
Infinite increase of reward with infinite decrease of reward probability added up to be an infinitely big number.
I would say it is not contradiction between rationality and math, but deficiency of math model in comparison to reality.
If we simplify our task we can say -- how much can we bet for a chance to get 1 Million as reward for say 10 tosses of a coin in a row.
If reward would be increased to infinity, than equivalen would also be infinity.
But on the fifth row of description author making assumption that in reality the value of this potential remuneration having range of values between
units. The rationale behind this assumption is completely not clear.For example in the vending machines kids are usually paying 2 units for the chance to win a prize worth 0.5 units. I.e. people could not be expected to behaive rationaly.
Next line Author suggest the reason of poor "rationality" and stating that people devaluate probability the further they get.
I.e. there is mathematical probability and there is human perception of it. Both are declining each step, but the later one declining more and the difference raise. (It looks like it is not relevant for the problem as problem considers fixed probability.)
And in next paragraph the explanation becomes completely hard to get.
Full toss has a value of 1. I.e. Sum of all consequitive tosses from the SPB paradox added all together gives 1.
And player devalue them.
No, seems the problem is -- lets have 1 unit as reward and p probability of each step. Than total expected reward for S steps would be: 1+ 1p + 1p^2 + ... 1*p^S
And our codewarriors are suggested to calculate it.
But i do not understand how this calculation is connected with SPB paradox ?
c++ code template contains the following:
At the same time test cases are:
I suggest to remove rounding requirement from the user code template. or Increase delta to be 0.01 in al ltest cases.
Can you explain please, what the perceived value is? I do not understand this from the description.
Ruby 3.0 should be enabled.
Kata retired.
The description is too long. It has to be shortened somehow.
you're kidding...? that's a description that could be considered too long x) (but it's not).
=> not an issue in any way, closing.
Using
assert_equals
in Python's random tests.Right, thanks: Python fixed :+1:
In Python, do you really want this much precision?
Deleted
No, try now.
Happy now. :-)
Cool, thanks for spotting it, Tachyon :)
Haskell : https://www.codewars.com/kumite/5bbbaffaf6e30da9ed00020e?sel=5bbbaffaf6e30da9ed00020e
(doesn't round, just checks that it is ~0.01)
If you are ok with that I can update the description.
I would rather put it in a comment of the template code, but as you see fit.
Comment added.
Python, Ruby, JS and (I'm 100% sure) Crystal still require rounding to work.
Languages changed; Ruby to my knowledge does not seem to have that method available. Feel free to suggest for either it or c++.
Maybe you should implement the comparison with margin yourself, then? And C++ does have
EqualsWithDelta
.It would help if CodeWars made it available. Can we suggest that somewhere? I also have code for Haskell available ( stolen from someone else, but I don't remember who ).
How is
toFixed
unreliable?( Yes, honest question. I'd like to know. )
Hi johan, toFixed is notoriously trash and is quite unriable. Take a look at the following :
As you can see that is wrong, Another example :
Reason for the following :
1.275 when converted to binary has the following representation :
Since it has infinite digits, it cannot be represented exactly in a computer unless you use an arbitrary precision library. JavaScript numbers do not use such library for performance reasons.
Since the original value has already lost precision before it even reacheed JS, rounding it will not improve the persicion in anyway.
Hope that explains.
@__i so what? These 2 examples tested with Python's built-in
round
give me the same result -35.855 --> 35.85
and1.275 --> 1.27
. Does this also mean that Python'sround
is a notoriously trash and unreliable function?I figured something like that when I took a look at
2.55 * 100
( it has the same problem.2.55
is in the MDN article ).But you can't blame
toFixed
for that; it's basic floating point representation inaccuracy. Everything that works with floating point values suffers from the same problem. Including, apparently, Python'sround
.Anyway, thanks for your answer. ( The concise answer would be "it works with floating point values". )
.
Well, yes. :]
Though it would be more correct to say floating point values are notoriously trash and unreliable. After all, they are.
Python is not unreliable: it behaves precisely the same in those 2 cases; JS's
.toFixed()
is unreliable for other reasons, see link below.This. People can go to any length to trash something, having no idea what the real root of the problem is. Though, I must admit that reading an explanation why rounding functions are bad because computers can't round numbers like people do is funny.
Also, turns out
no one
simply copy-pasted this explanation from stackoverflow. Way to show how knowledgeable he is XDShould really use
assertApproxEquals
instead of rounding.We burn newcomers at the stake for it.
And guess what? I never heard about it.
Plus the kata is already pretty easy, at least let them round!
Problem is it's not numerically safe.
If my result is
1.4449999999
, because I did things in a different order, and your result is1.4450000001
, I'll fail the test. And I shouldn't.Flooring or ceilinging instead of rounding just shifts the universe by
.5
.That means I now have to read your mind, in what order you want calculations done. Or look at Unnamed's solution.
Really, approximating is better. With IEEE.something(704?) double precision floating point values, there will always be the possibility of a representation error.
I'm surprised that after so many occurrences of faulty translations and issues, Giacomo is still not following best practice often enough.
You see, there are lots of issues in your translations for a reason ;-)
@JohanWiltink, this problem seems pretty straightforward to me and even the solution you mention apparently passes the tests without any issue. For the range considered, I would expect either no or extremely rare occurrences of rounding not working.
Is that method supported across all languages?
@Voile, I am surprised that given your skills you don't find any better use of them than to try to be randomly mean and obnoxious, probably for the sheer pleasure of feeling somebody under your thumb. Considering the amount of translation I did, I would say that the issues are around 1% or so, otherwise I would get flooded with that. There is definitely room for improvement, but I don't even think there is any need to point that out, is it?
If so, what was your contribution supposed to bring?
It seems that you're, again, assuming things about me more than the issue at hand. So let's be clear here:
(Of course, if rounding is required you'd need to make sure random tests don't generate cases that cause some values to be in the rounding boundary, but it's fragile.)
Anyways, just remember this: when we're raising suggestions/issues, we know what we're doing and we really mean it, so arguing otherwise is often pointless unless you also absolutely know what you're doing. But it seems like you don't from time to time, so... just listen to us and make the changes. It'll be better for everyone, we promise.
Ok, now that's better:
.toFixed()
. Knowing of the method Johan was suggesting just now, I might implement it later.Similarly, spare me where you talk as "we", as your opinion might not match everybody else, even limiting it to powerusers/veterans/whatever you want to call them, as it happened multiple times before.
As mentioned, I will consider editing it later.
Thanks for the advice anyway :+1:
Fixed.
Thank you for fixing.
However, if you're using
assertApproxEquals
, there should be no rounding. Rounding to two decimals introduces an error of up to.005
, which is more than the1e-9
assertApproxEquals
allows. Comparing approximately after rounding has the same problem as comparing exactly after rounding.Addressing your earlier questions:
This method may not be supported across all languages. Unfortunately. But you can always write a simple wrapper yourself. The JS source is in here. ( For Haskell, I have something lying around; just ask. It's not really easy in Haskell, but lots of things in Haskell testing aren't. )
Unnamed's solution passes the tests, but it has an entirely different way of getting at the answer. So even guessing the order in which the reference solution does the computations does not help - you might get at an ever so slightly different answer, even if maths say they're the same ( because it's not a maths error, it's a representation error ).
If I may give an example: you'd expect
Math.hypot(5,1)
andMath.sqrt(26)
to be the same. They aren't. And rounding has the possibility of introducing much greater errors even ( see original comment ). That is why you do not want to round and you do want to compare with a margin for error.So, uhm, sorry, not fixed.
Mh, somebody really has fun downvoting today.
Got it for the use of it, I will fix it later; I still insist that given the range of the tests, an error in that regard is highly unlikely. Concerning
.toFixed()
, see here for example; it is known to be discouraged if you need high-precision computations.That wasn't me, and I didn't think you deserved it. So I actually upvoted you again.
toFixed
is not more or less unreliable than everything else that touches IEEE754 ( I looked it up :) floating point values. If you need high-precision computations, don't touch floating point values with or without a 10' pole.Thanks in advance for fixing it later.
Oh, sorry if I was ambiguous: the thought that you might have downvoted never even crossed my mind. I think I can make some educated guess about that.
About
.toFixed()
, you might see more of its inconsistency running something like this snippet:A similar script with
Math.round()
gives much more reliable results.