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

First PN.RND after P.SEED isn't random #337

Open
mikeyford opened this issue Nov 18, 2024 · 2 comments
Open

First PN.RND after P.SEED isn't random #337

mikeyford opened this issue Nov 18, 2024 · 2 comments

Comments

@mikeyford
Copy link

mikeyford commented Nov 18, 2024

Please describe the bug.

The first call to PN.RND always returns the same value, after seeding the randomization via P.SEED with any seed. Subsequent calls of PN.RND are random.

I'm happy to look into this, but please let me if you have any pointers or I'm misunderstanding the feature.

Please include the hash displayed at startup and the release of the software (e.g. "Teletype v2.0.1 5f838c9")

Teletype v5.0.0 00FDFD2

What steps are required to reproduce the bug?

fill pattern 0 with values
P.SEED x
PN.RND 0
will always return the same value, regardless of x

Alternatively, filling 0 with values, and pattern 1 with seeds, then create a script like:

P.SEED PN.NEXT1
PN.NEXT 2 PN.RND 0

then trigger the script repeatedly to fill pattern 2 with the same value

@Dewb
Copy link
Contributor

Dewb commented Nov 18, 2024

I can reproduce this. The behavior is consistent with a call to random_next() with an uninitialized random state (r and z both 0), but from a quick skim of the code it looks like the pattern random state should be initialized alongside all the other random data in the scene state, none of which exhibit this issue. Could be possible that something is accidentally stomping on just the pattern random state after initialization.

@mikeyford
Copy link
Author

mikeyford commented Nov 19, 2024

I think because we're using a constant to initialize z here we're not fully randomly seeding.

I don't have a C toolchain here at work, but I was able to reproduce with the algorithm in Python. The numbers produced are different, but are similar, especially at the end. After a few iterations it shakes out. We're taking the mod of the random value to choose from the pattern, which I guess is why it hasn't been so obvious in other contexts? (Although I've noticed the initial value from ops like RAND 10000 with different seeds tend to be clustered.)

Switching to r->z = ~seed seems to resolve it.

Will test properly with Teletype when I'm home and throw up a PR in the next day or two.

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

No branches or pull requests

2 participants