Menu

#7 More verbose output for "nodes inconsistence" errors

Unstable_(example)
open
nobody
None
1
2014-02-21
2014-02-21
Anonymous
No

JAGS is very curt when it comes to reporting "node inconsistence errors" during a model initialization. User is only provided with a name of the node when an error occurs. To get rid off such errors user has to reconstruct the chain of parent nodes values and find out in which place something goes wrong. Some may do it using paper and pencil, some may recompile JAGS with debbuging symbols and run it under debugger, but when it comes to complicated models with many parent nodes (and many levels of parent nodes) both methods are very inconvinient.

I have just faced such a problem. While I was unable to deal with it using paper and pencil and the parents tree of my "inconsistent node" involved dozens of nodes (so printing them all under a debugger will take a long time), I simply did some adjustments to the JAGS source code:
- I have added a "printParentsTree(std::ostream out, string prefix, SymTab& symtab, int depth)" function to the "Node" class. This function simply prints the node name and value and then calls itself on all parent nodes with depth reduced by 1 (and prefix extended by " "; prefix is used to provide indentation off the output). When "depth" reaches 0 recursion ends.
- I have changed the error catching macro in the "Console" class, so it calls "printParentsTree()" method on the node reported in an object of a "NodeError" class.
This simple changes finally allowed me to find out, what caused my problem.

Maybe merging this changes into the JAGS will be beneficial also for other users.

Best regards,
Mateusz Żółtak (zozlak@zozlak.org)

ps 1 For my own purpose I have hardcoded parents tree dump depth to 5 levels but in production environment it would be nice to be able to adjust that with a JAGS command (such a "DEBUG LEVEL n" or something like that). I can write such a patch.

ps 2 It turned out that the problem with my model was, that it used logits of quite a big numbers (e.g. 50-60 :) ) and probabilities for such a big logits are numerically equal to each other (and all equal 1) because off a double data type precision.

1 Attachments

Discussion

Anonymous
Anonymous

Add attachments
Cancel