Hi, when we perform tobit command with --guiet flag we sometimes get the following message: "Warning: couldn't improve criterion (gradient = 6.04477e-06)", which /per se/ makes estimation not so quiet. So, the question is: shall we leave current behavior or make 'tobit --quiet' really quiet? If the later, I wrote a simple patch which suppress any messages (attached). Another possibility would be adding '--silent' flag, which I could do either?

Since the message in fact comes from 'gretl_bfgs.c', there could be a set option for optimizers for suppressing any warnings/messages.

On Thu, 19 Jan 2023, Marcin Błażejowski wrote: > Since the message in fact comes from 'gretl_bfgs.c', there could be a > set option for optimizers for suppressing any warnings/messages. Does the "set warnings" command help?

Am 19.01.2023 um 09:22 schrieb Marcin Błażejowski: Hi, when we perform tobit command with --guiet flag we sometimes get the following message: "Warning: couldn't improve criterion (gradient = 6.04477e-06)", which per se makes estimation not so quiet. So, the question is: shall we leave current behavior or make 'tobit --quiet' really quiet? If the later, I wrote a simple patch which suppress any messages (attached). Another possibility would be adding '--silent' flag, which I could do either? Personally I think that choosing "quiet" doesn't mean that I don't want to see warning messages, so the current behavior is OK. "silent" could be a possibility, but then I think we would have to do it for all estimators, not just for tobit out of coincidence. Right now I think the guideline is more or less that "silent" exists for tests and for system estimation (where even quiet prints a little bit of regular output). I believe there's a workaround to really suppress all output: Wrap it in an "outfile" block: string temp outfile --buffer=temp tobit ... outfile end And simply discard the string. Admittedly not very elegant...

On 19.01.2023 14:47, Cottrell, Allin wrote: > Or more efficiently: > > outfile null > # do stuff silently > end outfile Well, it works of course but for me it is a trick rather than a true solution. It is because the message does not come from triggered command but from underlying apparatus. So from my point of view suppressing any messages from optimizers by 'set' command to silent/quiet/whatever would be better.

On 19.01.2023 16:48, Cottrell, Allin wrote: > My feeling is that neither --quiet nor even --silent as applied to > individual commands should suppress warnings; they're about reducing > or eliminating regular output. Ok. But printing warnings in numerical methods (like optimizers) might be seen as some kind of debugging. If so, suppressing any messages could be an option.

Am 19.01.2023 um 14:47 schrieb Cottrell, Allin: Or more efficiently: outfile null # do stuff silently end outfile Ah, thanks, Allin, I was looking only for double-dash options in the doc and so I overlooked this one. Actually, for Marcin's case something like "outfile stderr" might also be interesting.

Hi, the solution was simpler that I thought: the problem was that print_NR_status() did verify 'set messages on/off' , but did not checked for 'set warnings on/off'. The patch in attachment.

On 26.01.2023 08:51, Sven Schreiber wrote: > Am 26.01.2023 um 08:45 schrieb Marcin Błażejowski: >> >> Hi, >> >> the solution was simpler that I thought: the problem was that >> print_NR_status() did verify 'set messages on/off' , but did not >> checked for 'set warnings on/off'. The patch in attachment. > > Marcin, I don't think this is the complete solution. It wasn't a bug > that 'set warnings' did not apply there, it was part of the spec. > This is quite orthodox (or literal) understanding of it's definition: "Suppress or resume the printing of warning messages issued when arithmetical operations produce non-finite values." Because what we have here (from the above-mentioned definition) is: 1. "warning message", and 2. "issued when arithmetical operations produce", and 3. "values". The only difference is that produced value is not infinite, but it some sense not so good (or not optimal if you want). > So now we want to treat 'warnings' differently, OK, but that would > mean to change it in other places as well, I believe. I don't know > exactly where or in how many places, but most likely not just in a > single one. > Certainly. But the behavior we have now I would call "extremely user non-friendly".

On Thu, 26 Jan 2023, Marcin Błażejowski wrote: > Hi, > > the solution was simpler that I thought: the problem was that > print_NR_status() did verify 'set messages on/off' , but did not > checked for 'set warnings on/off'. The patch in attachment. Marcin, of course in this case this is not a problem, because the patch is quite small and one can easily see what's going on, but generally speaking you may want to add the -w flag to "diff" (or "git diff") to suppress lines where changes only involve whitespace.