MétaCan
Menu
Retour à la cohorte
Enregistrement W6931093132 · doi:10.5281/zenodo.16813645

TuringLang/Turing.jl: v0.40.0

2025· other· en· W6931093132 sur OpenAlex

Pourquoi ce travail est dans la base

Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.

affAu moins un auteur déclare une institution canadienne dans l'instantané OpenAlex épinglé.

Notice bibliographique

RevueZenodo (CERN European Organization for Nuclear Research) · 2025
Typeother
Langueen
DomaineComputer Science
ThématiqueComputability, Logic, AI Algorithms
Établissements canadiensFowler Kennedy Sport Medicine ClinicTellabs (Canada)University of British Columbia
Organismes subventionnairesnon disponible
Mots-clésTuringValue (mathematics)Variable (mathematics)Relation (database)Field (mathematics)Object (grammar)

Résumé

récupéré en direct d'OpenAlex

Turing v0.40.0 Breaking changes DynamicPPL 0.37 Turing.jl v0.40 updates DynamicPPL compatibility to 0.37. The summary of the changes provided here is intended for end-users of Turing. If you are a package developer, or would otherwise like to understand these changes in-depth, please see the DynamicPPL changelog. @submodel is now completely removed; please use to_submodel. Prior and likelihood calculations are now completely separated in Turing. Previously, the log-density used to be accumulated in a single field and thus there was no clear way to separate prior and likelihood components. @addlogprob! f, where f is a float, now adds to the likelihood by default. You can instead use @addlogprob! (; logprior=x, loglikelihood=y) to control which log-density component to add to. This means that usage of PriorContext and LikelihoodContext is no longer needed, and these have now been removed. The special __context__ variable has been removed. If you still need to access the evaluation context, it is now available as __model__.context. Log-density in chains When sampling from a Turing model, the resulting MCMCChains.Chains object now contains not only the log-joint (accessible via chain[:lp]) but also the log-prior and log-likelihood (chain[:logprior] and chain[:loglikelihood] respectively). These values now correspond to the log density of the sampled variables exactly as per the model definition / user parameterisation and thus will ignore any linking (transformation to unconstrained space). For example, if the model is @model f() = x ~ LogNormal(), chain[:lp] would always contain the value of logpdf(LogNormal(), x) for each sampled value of x. Previously these values could be incorrect if linking had occurred: some samplers would return logpdf(Normal(), log(x)) i.e. the log-density with respect to the transformed distribution. Gibbs sampler When using Turing's Gibbs sampler, e.g. Gibbs(:x => MH(), :y => HMC(0.1, 20)), the conditioned variables (for example y during the MH step, or x during the HMC step) are treated as true observations. Thus the log-density associated with them is added to the likelihood. Previously these would effectively be added to the prior (in the sense that if LikelihoodContext was used they would be ignored). This is unlikely to affect users but we mention it here to be explicit. This change only affects the log probabilities as the Gibbs component samplers see them; the resulting chain will include the usual log prior, likelihood, and joint, as described above. Particle Gibbs Previously, only 'true' observations (i.e., x ~ dist where x is a model argument or conditioned upon) would trigger resampling of particles. Specifically, there were two cases where resampling would not be triggered: Calls to @addlogprob! Gibbs-conditioned variables: e.g. y in Gibbs(:x => PG(20), :y => MH()) Turing 0.40 changes this such that both of the above cause resampling. (The second case follows from the changes to the Gibbs sampler, see above.) This release also fixes a bug where, if the model ended with one of these statements, their contribution to the particle weight would be ignored, leading to incorrect results. The changes above also mean that certain models that previously worked with PG-within-Gibbs may now error. Specifically this is likely to happen when the dimension of the model is variable. For example: @model function f() x ~ Bernoulli() if x y1 ~ Normal() else y1 ~ Normal() y2 ~ Normal() end # (some likelihood term...) end sample(f(), Gibbs(:x => PG(20), (:y1, :y2) => MH()), 100) This sampler now cannot be used for this model because depending on which branch is taken, the number of observations will be different. To use PG-within-Gibbs, the number of observations that the PG component sampler sees must be constant. Thus, for example, this will still work if x, y1, and y2 are grouped together under the PG component sampler. If you absolutely require the old behaviour, we recommend using Turing.jl v0.39, but also thinking very carefully about what the expected behaviour of the model is, and checking that Turing is sampling from it correctly (note that the behaviour on v0.39 may in general be incorrect because of the fact that Gibbs-conditioned variables did not trigger resampling). We would also welcome any GitHub issues highlighting such problems. Our support for dynamic models is incomplete and is liable to undergo further changes. Other changes Sampling using Prior() should now be about twice as fast because we now avoid evaluating the model twice on every iteration. Turing.Inference.Transition now has different fields. If t isa Turing.Inference.Transition, t.stat is always a NamedTuple, not nothing (if it genuinely has no information then it's an empty NamedTuple). Furthermore, t.lp has now been split up into t.logprior and t.loglikelihood (see also 'Log-density in chains' section above).

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.

Prédiction distillée sur la base complète

Imitation des enseignants

Ni prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.

score de la tête « metaresearch » (Codex)0,001
score de la tête « metaresearch » (Gemma)0,001
Version: codex-gemma-dda1882f352aStatut de validation: machine_predicted_unvalidated
Catégories candidatesMéta-épidémiologie (sens strict), Communication savante, Charge utile insuffisante (le modèle a refusé de juger)
Catégories consensuellesCharge utile insuffisante (le modèle a refusé de juger)
DomaineSignal candidat: aucune · Signal consensuel: aucune
Devis d'étudeSignal candidat: Sans objet · Signal consensuel: Sans objet
GenreSignal candidat: Autre · Signal consensuel: Autre
Score de désaccord entre enseignants0,185
Score d'incertitude au seuil1,000

Scores Codex et Gemma par catégorie

CatégorieCodexGemma
Métarecherche0,0010,001
Méta-épidémiologie (sens strict)0,0000,000
Méta-épidémiologie (sens large)0,0000,000
Bibliométrie0,0010,001
Études des sciences et des technologies0,0010,000
Communication savante0,0020,000
Science ouverte0,0050,006
Intégrité de la recherche0,0000,001
Charge utile insuffisante (le modèle a refusé de juger)0,0160,013

Scores machine (provisoires)

Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.

Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.

Tête enseignante Opus0,025
Tête enseignante GPT0,238
Écart entre enseignants0,213 · la distance entre les deux têtes enseignantes sur ce seul travail
Statut de validationscore_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle