This is in reference to the bug report about CmdStan doing the max. treedepth diagnosis incorrectly.
Currently, CmdStan hardcodes the maximum tree depth rather than reading it from the CSV file, which is not a big surprise, since the stan::io::stan_csv_reader class doesn’t read in that bit of information from the CSV file. What I’m thinking of doing is the following:
-
Modifying the
stan::io::stan_csv_metadatastruct to have an integer membermax_depthfor the maximum treedepth (and having the struct’s constructor initialize it to 10). -
Modifying
stan::io::stan_csv_reader::read_metadatato read in the max. tree depth. As far as I can tell, this should be as simple as addingelse if (name.compare("max_depth") == 0) {metadata.max_depth = boost::lexical_cast<int>(value);}to the function.
Once that’s done, modifying CmdStan’s diagnose utility should be as straightforward as changing int max_limit = 10; to int max_limit = stan_csv.metadata.max_depth and fixing the instances where the variable max was used where max_limit should have been used.
I do have a couple questions, though.
First, is there any objection to my approach to modifying stan_csv_reader? Would it mess up any overarching design scheme for Stan readers or introduce any other problems?
Second, if my approach to fixing this CmdStan problem is reasonable, would I need to do two pull requests, one for the CSV reader (which as far as I can tell is part of the common Stan code rather than CmdStan itself) and one for CmdStan’s diagnose utility?