Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make random consistent: never output the top of the bound #37

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

idbrii
Copy link

@idbrii idbrii commented Aug 23, 2021

lume.random(1) can sometimes return 1, but lume.random() and lume.random(0,1) will never return 1. (And the converse for zero: they should all be able to produce 0.) Change the single argument version to conform to the same range regardless of inputs. Update the documentation to make the output range explicit using language similar to math.random.

Add a test that had two failures on the old code for the single argument
version:

FAIL test.lua:110: testeq(postcond.expected.count > 0, true)
Expected "true" got "false"
FAIL test.lua:111: testeq(postcond.unexpected.count, 0)
Expected 0.00 got 3.00

All tests pass.

@idbrii idbrii changed the title Make random never output the top of the bound Make random consistent: never output the top of the bound Sep 8, 2021
Fix lume.trace test fails on windows because "c:/blah.lua:34 boop"
matches `c` as the file and `/blah.lua` as the line. I can't see how
line numbers might not be digits (floating point or hex line numbers?).
Conform to the same range regardless of inputs. Changes the single
argument version of random to use the same bounds as the other two.

lume.random(), lume.random(1), lume.random(0,1) should all mean the same
thing: output a number in [0,1). They didn't all produce the same
results. The middle option would produce results in (0,1].

Add a test to try some iterations to test failures. An older version of
this test caught errors for the single argument version, but with lua54
I no longer see those failures (the sequence of numbers of the same seed
differs) so I've reworked the test.

Don't use testeq for each iteration like this:
    testeq(0 <= a, true)
    testeq(a < 1, true)
Because all that printing is very slow.

All tests pass.
@idbrii
Copy link
Author

idbrii commented Nov 20, 2023

Updated to change my test because it was failing on lua5.4. Now I'm no longer expecting any specific values from random since the rng doesn't produce the same sequence it did back on lua 5.1 (or whatever I was using).

Also added a commit to fix lume.trace test on Windows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants