Hi Stephen, I tend to agree with Britton. I think a technically accurate but non-informative message should be suppressed at its source sooner rather than later. I would think exception handling in numpy should make this possible...for Dedalus, we use numpy to dump you into ipython if a certain kind of error occurs for deubgging purposes, so I imagine something simpler like quieting a particular message in a particular place should be possible...that having been said, I don't know how to do it. j On Mon, Aug 15, 2011 at 12:23 PM, Britton Smith wrote:

I think the issue is that these are messages coming straight out of numpy that are nearly impossible to supress.  My personal opinion is that they are annoying at best and can ruin screen output that the user might be looking for.  I feel that if we let these stick around, more of these will pop up. If at a later date someone wants to clean up the code so that the warnings go away, it will be much more difficult to locate them since the warning messages come completely without context.  I say try to get rid of it if possible.

Britton

On Mon, Aug 15, 2011 at 3:18 PM, Casey W. Stark wrote:

...

At the risk of introducing complexity, we could do debug levels. If somebody wants these messages, they can set something, but they are supressed by default.

On Monday, August 15, 2011, Stephen Skory wrote:

...

Hi all,

this may not be a big issue because most people won't be using Geoffrey's new ellipsoidal halo information. However, it may spark discussion about this topic overall and set a useful precedent.

I have just finished vectorizing some of Geoffrey's code that is attached to the halo finder code. In so doing, I am allowing NaNs to come into the calculation because it keeps thing simple. Happily, the NaNs only exist where I know the answers can't be, and numpy.nanargmin/max() happily ignores the NaNs. But when I make the NaNs through a divide by zero (and some other stuff) I get warning messages telling me I just did what I knew was going to happen.

My question is, do we think that I should try to suppress these warnings? They are accurate, but the math that makes them is done intentionally, so they're not informative.

Can I get a +1/0/-1? Thanks!

-- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Ok by me, though as you all probably know, I am (almost) always an advocate of turning down verbosity! On Mon, Aug 15, 2011 at 12:40 PM, Matthew Turk wrote:

Hi all,

Okay, how about we check the loglevel inside the yt/logger.py module. If it's set to less than debug, suppress them globally.  Would that work?

I have found these to be very unhelpful.  You can't actually *do* anything with them, in my experience, as instructing them to throw an exception or fail simply suppresses them on most operating systems. This would have the side effect of getting rid of the warnings when yt tries to detect the radius field.

-Matt

On Mon, Aug 15, 2011 at 3:34 PM, j s oishi wrote:

...

Hi Stephen,

I tend to agree with Britton. I think a technically accurate but non-informative message should be suppressed at its source sooner rather than later. I would think exception handling in numpy should make this possible...for Dedalus, we use numpy to dump you into ipython if a certain kind of error occurs for deubgging purposes, so I imagine something simpler like quieting a particular message in a particular place should be possible...that having been said, I don't know how to do it.

j

On Mon, Aug 15, 2011 at 12:23 PM, Britton Smith wrote:

...

I think the issue is that these are messages coming straight out of numpy that are nearly impossible to supress.  My personal opinion is that they are annoying at best and can ruin screen output that the user might be looking for.  I feel that if we let these stick around, more of these will pop up. If at a later date someone wants to clean up the code so that the warnings go away, it will be much more difficult to locate them since the warning messages come completely without context.  I say try to get rid of it if possible.

Britton

On Mon, Aug 15, 2011 at 3:18 PM, Casey W. Stark wrote:

...

At the risk of introducing complexity, we could do debug levels. If somebody wants these messages, they can set something, but they are supressed by default.

On Monday, August 15, 2011, Stephen Skory wrote:

...

Hi all,

this may not be a big issue because most people won't be using Geoffrey's new ellipsoidal halo information. However, it may spark discussion about this topic overall and set a useful precedent.

I have just finished vectorizing some of Geoffrey's code that is attached to the halo finder code. In so doing, I am allowing NaNs to come into the calculation because it keeps thing simple. Happily, the NaNs only exist where I know the answers can't be, and numpy.nanargmin/max() happily ignores the NaNs. But when I make the NaNs through a divide by zero (and some other stuff) I get warning messages telling me I just did what I knew was going to happen.

My question is, do we think that I should try to suppress these warnings? They are accurate, but the math that makes them is done intentionally, so they're not informative.

Can I get a +1/0/-1? Thanks!

-- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

I would propose that if you have code that you know is going to throw an error, you suppress it directly with something like with warnings.catch_warnings(): warnings.simplefilter("ignore") do_your_thing() That way unintentional errors, like trying to plot the log of a signed quantity, won't get killed. I make dumb errors like that all the time, so these errors can be useful even if having them actually raise an exception doesn't work. d. On Mon, Aug 15, 2011 at 2:01 PM, Stephen Skory wrote:

Matt,

...

...

Okay, how about we check the loglevel inside the yt/logger.py module. If it's set to less than debug, suppress them globally.  Would that work?

I think that's a good plan.

-- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- Sent from my computer.