Y a-t-il un bug d'ajustement non linéaire dans jmp 16.0 ?J'ai un script (merci peng_liu) qui place les estimations de paramètres Max et k de l'ajustement non linéaire dans des variables de table portant les mêmes noms, que j'avais prévu d'utiliser dans un calcul ultérieur.Il semble que la création des variables de la table bloque le tracé d'ajustement non linéaire.
- lors de la première exécution du script, les variables de table Max et k sont créées à partir des paramètres Max et k à partir d'un fit non linéaire. S'ils existent déjà, ils sont simplement définis sur de nouvelles valeurs.
- le tracé d'ajustement non linéaire fonctionne jusqu'à présent comme excepté, avec la ligne d'ajustement se déplaçant lorsque j'ajuste manuellement les paramètres Max ou k dans la fenêtre non linéaire
- quand le script est exécuté après les variables du tableau ont été créées, le tracé d'ajustement non linéaire reste bloqué/statique et il n'y a aucune réaction lors de l'ajustement manuel des paramètres Max ou k
- lorsque je supprime les variables de table Max et k, une nouvelle exécution du script crée à nouveau un ajustement non linéaire fonctionnel.
Que faire?
Tableau de donnéesScriptles fenêtresRe : Y a-t-il un bug d'ajustement non linéaire dans jmp 16.0 ?Mise à jour/résolu ? : il semble que si je renomme les variables de table Max et k par exemple Max2 et k2 après ils ont été créés par le script, l'ajustement non linéaire fonctionne comme prévu/ne se bloque pas, et sont toujours définis sur des valeurs de paramètres estimées par le script. Je ne sais pas pourquoi.
Re : Y a-t-il un bug d'ajustement non linéaire dans jmp 16.0 ?Update2 : lorsque j'enregistre, ferme et ouvre à nouveau la table de données, le script crée à nouveau Max et k (sans tenir compte des renommés Max2 et k2), et le problème avec l'ajustement non linéaire verrouillé est de retour.
Re : Y a-t-il un bug d'ajustement non linéaire dans jmp 16.0 ?Je crois que la cause est due au "scoping", un jargon de programmation. Donc, dans ce cas, je ne pense pas que ce soit une solution pour vous en sauvegardant les estimations de paramètres en tant que variables de table en utilisant le exactement la même noms.
En termes de portée, le tracé dynamique auquel vous faites référence a un "environnement d'évaluation", qui a deux variables avec le même nom "Max" et "k". Pour le voir, faites un clic droit sur le tracé, sélectionnez "Personnaliser", puis sélectionnez "Ajuster le modèle actuel". Vous verrez une formule qui utilise "Max" et "k". Chaque fois que vous cliquez sur les curseurs pour modifier les valeurs de "Max" et "k", le programme met à jour ces valeurs et réévalue la fonction. Cependant, il existe un autre ensemble de "Max" et "k", qui se trouve dans "l'environnement d'évaluation" de la table de données, qui ne sont pas mis à jour. Malheureusement, en raison de la priorité d'évaluation, la formule les voit en premier et les utilise, même l'ensemble mis à jour se trouve quelque part à proximité. Cela explique pourquoi l'intrigue ne change pas.
La seule chose à laquelle je pense est d'utiliser un préfixe ou un suffixe pour les noms de variables de table, ou quelque chose qui est facile à reconnaître pour vous, et les noms de variables n'entreront pas en collision.
