Timeline for Random numbers with fixed sum
Current License: CC BY-SA 4.0
35 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Aug 28, 2019 at 5:48 | vote | accept | Angs | ||
Jul 16, 2019 at 20:53 | answer | added | Roman | timeline score: 1 | |
Jul 16, 2019 at 19:25 | answer | added | user87616 | timeline score: 3 | |
Jul 16, 2019 at 16:13 | answer | added | Robin Ryder | timeline score: 2 | |
Sep 8, 2018 at 7:20 | answer | added | Angs | timeline score: 1 | |
May 19, 2018 at 19:04 | answer | added | HatsuPointerKun | timeline score: 3 | |
May 19, 2018 at 7:23 | comment | added | Angs |
@LuisMendo the same applies to any number really, not just for 0. For instance, Java.Random has a 48-bit seed, so it can't produce all double-precision floating-point numbers ∈[0,1] since they have 52 bits of precision. Some common sense is required since it's hard to make a rule that would cover all cases. Maybe rounded to 10 digits after the comma, all cases should be equally common with an error margin of 1%.
|
|
May 19, 2018 at 7:10 | comment | added | Angs | @xnor none of the test cases may take longer than a second on your machine, so at least the most naive rejection sampling is out of the question. The implementation details don't matter if the output is correct. And like user202729 mentioned, 10 digits of precision is needed so multiples of 1e-10 or smaller work. | |
May 19, 2018 at 4:36 | history | tweeted | twitter.com/StackCodeGolf/status/997697572696453121 | ||
May 19, 2018 at 3:27 | comment | added | user202729 | @xnor Only if you have a supercomputer ("1 second"). | OP said 10 digits. | |
May 19, 2018 at 3:10 | answer | added | Οurous | timeline score: 2 | |
May 19, 2018 at 0:11 | comment | added | xnor |
Is it OK if our code uses rejection sampling, and so takes very long for test cases likes=2.99999999999, n=3 ? May we generate random reals in multiples of, say, 1e-9 ?
|
|
May 18, 2018 at 22:29 | comment | added | Luis Mendo | Requiring the interval to be closed or half-closed (as opposed to open) is a theoretically unobservable requirement. Many random number generators give the output in (0,1). How to test that the output interval is [ 0,1) and not (0,1)? The value 0 "never" occurs anyway | |
May 18, 2018 at 17:36 | answer | added | colossus16 | timeline score: 1 | |
May 18, 2018 at 17:10 | comment | added | l4m2 | @Angs or should same size area near zero have higher possibility as float precision is higher near zero? | |
May 18, 2018 at 16:54 | comment | added | Angs | @l4m2, no, equally likely == uniform distribution, of course with the understanding that there isn't a total uniformness with floating point errors and the like. | |
May 18, 2018 at 16:47 | comment | added | l4m2 | @Angs so any distribution is allowed as the possibility are all zero? | |
May 18, 2018 at 16:37 | comment | added | Angs |
@l4m2 when the parameters n and s are fixed, the valid outputs should be about equally likely. The order matters, so for instance (0.2, 0.3, 0.1) and (0.3, 0.2, 0.1) both should be as common as (0.6, 0.0, 0.0) for n=3, s=0.6
|
|
May 18, 2018 at 16:08 | comment | added | l4m2 |
All valid n-tuples have to be equally likely within the limitations of floating point numbers. do you mean same probably for same size? (usually such definition, but not always)
|
|
May 18, 2018 at 15:50 | answer | added | Neil | timeline score: 3 | |
May 18, 2018 at 15:09 | answer | added | Kevin Cruijssen | timeline score: 4 | |
May 18, 2018 at 14:49 | answer | added | l4m2 | timeline score: 8 | |
May 18, 2018 at 14:33 | history | edited | Angs | CC BY-SA 4.0 |
added 26 characters in body
|
May 18, 2018 at 14:15 | comment | added | user202729 | "Integer"? But the question ask for floating point output. | |
May 18, 2018 at 14:11 | history | edited | Angs | CC BY-SA 4.0 |
added 116 characters in body
|
May 18, 2018 at 14:07 | comment | added | Angs | One way to do this is to use this approach mirrored at the centre and then using rejection sampling | |
May 18, 2018 at 13:08 | comment | added | Angs | @JayCe that would be invalid, since all valid n-tuples have to be equally likely. | |
May 18, 2018 at 13:05 | comment | added | user202729 |
@KevinCruijssen No, that's only true for s==0 or s==3 . For all other values of s , the plane has nonzero area and you have to uniform-randomly choose a point on that plane.
|
|
May 18, 2018 at 12:56 | history | edited | Angs | CC BY-SA 4.0 |
added 28 characters in body
|
May 18, 2018 at 12:47 | comment | added | user202729 | Because not all languages have floating point support, (at least) how many digit of accuracy/precision must be supported? (the suggested test case above implies 13, but you may want a softer restriction) | |
May 18, 2018 at 12:43 | comment | added | JayCe |
When you say This is equal to uniformly sampling from the intersection - i can see a program choosing randomly from just the corners of that intersection. Would that be valid ?
|
|
May 18, 2018 at 12:24 | history | edited | Angs | CC BY-SA 4.0 |
Added Test case suggested by user202729
|
May 18, 2018 at 12:18 | answer | added | TFeld | timeline score: 6 | |
May 18, 2018 at 12:15 | comment | added | Martin Ender | Related. | |
May 18, 2018 at 12:11 | history | asked | Angs | CC BY-SA 4.0 |