`JointDistribution`s yield different PRNG behaviour on GPU and CPU
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 25/100
- Tipo di issue
- Bug
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- tensorflow
- Ambito
- machine-learning
Direzione di ricerca
Inizia con il Colab collegato e riproduci i risultati di JointDistribution stateless PRNG su CPU e GPU nelle modalità Eager, Graph e XLA. Poi traccia l’esecuzione di JointDistribution* e la documentazione di stateless PRNG per determinare se il riordinamento delle operazioni causa la differenza. Il lavoro è completo quando è stato stabilito se il comportamento è un bug o richiede documentazione, con un test riproducibile o un’aspettativa chiaramente documentata.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Hi All,
I noticed recently that stateless PRNG behaviour for JointDistribution* objects appear to do different things depending on whether random numbers are generated on GPU or CPU. This is demonstrated this Colab.
This appears to go against the assertions in the tf.random.stateless_* documentation that suggests that PRNG behaviour should be consistent across CPU and GPU devices. I guess that there may be reordering of operations within the JointDistribution* logic, but perhaps this should be documented?
Regards,
Chris
[edit] interestingly, this seems relevant only to Eager and Graph mode. XLA mode appears consistent.
- Lingua principale
- Jupyter Notebook
- Stelle
- 4.4k
- Fork
- 1.1k
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di tensorflow/probability
-
KL divergence between two `TransformedDistribution`s with a shared non-injective bijector (`AbsoluteValue`) returns the base KLForse già presa @Andreas-Hum l’ha presa 8 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
tensorflow/probability#2036 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
tensorflow/probability#2034 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
tensorflow/probability#2021 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
tensorflow/probability#2015 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 48/100
tensorflow/probability#2013 ·
Tutte le issue di tensorflow/probability
Issue simili
-
[Bug]: DoubleMLRDDData accepts a score_col that is no data column (as in its docstring example); the running variable then becomes a covariate and RDFlex failsForse già presa @vrjdev l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
DoubleML/doubleml-for-py#455 ·
I maintainer di solito rispondono entro 1 giorno
-
Install page: spectarf's CUDA engine fails with PyTorch for CUDA 13.0 (nvvmError: ERROR_INVALID_IR)Forse già presa @lukepolson l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 79/100
PyTomography/PyTomography#435 ·
I maintainer di solito rispondono entro 1 giorno
-
beginner friendly
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
aws-samples/sample-per-model-bedrock#821 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
instadeepai/InstaNovo-FM#50 ·