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

Change PRNGKey to key in jax-101 PRNG guide #19645

Closed
wants to merge 1 commit into from
Closed

Conversation

IvyZX
Copy link
Collaborator

@IvyZX IvyZX commented Feb 3, 2024

jax.random.PRNGKey use cases should be replaced by jax.random.key as planned by #17297.

@IvyZX IvyZX requested a review from jakevdp February 3, 2024 04:01
@jakevdp
Copy link
Collaborator

jakevdp commented Feb 5, 2024

Hi - I think @froystig has a branch that does this, but we've been waiting on fuller support for new-style keys in downstream libraries before swapping over the docs. @froystig, what's the status of that?

@jakevdp jakevdp requested a review from froystig February 5, 2024 17:30
@froystig
Copy link
Member

froystig commented Feb 5, 2024

I could rebase and update the docs branch, and then look for places to include a disclaimer like the one you added to the RNG tutorial here. Then we can aim to merge it prior to waiting for more downstream libraries. How about that?

@IvyZX
Copy link
Collaborator Author

IvyZX commented Feb 6, 2024

What kind of downstream libraries are we waiting for? I can definitely add a disclaimer there, but if the blocker is downstream should we explain that (like, this new API doesn't work for bla bla cases)?

@froystig
Copy link
Member

The challenge is that jax itself is backwards compatible by way of polymorphism: all jax.random functions accept both old- and new-style keys, and those that return keys (split and fold_in) do so based on what flavor of key they were given. Meanwhile, other libraries that deal with jax's keys might have not yet upgraded to new-style. If our docs encourage new-style keys to users, then those users might pass new-style keys to a library that doesn't understand the new style yet.

I don't think anything is blocking this really, and my guess is that we only need disclaimers in our own docs for now. Does that sound right to you?

@froystig
Copy link
Member

froystig commented Mar 9, 2024

#17741 (which Jake was referring to above) included similar changes to these files and has been merged.

@froystig froystig closed this Mar 9, 2024
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.

None yet

3 participants