[Math] Help in debugging process

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[Math] Help in debugging process

Gilles Sadowski
Hi.

What do you think of introducing logging statements in CM?
[If it was already discussed, does someone have a pointer?]

Best,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Help in debugging process

Ted Dunning
I would think that this would only be of use in very long running iterative
algorithms and of only very minimal interest to the user.

On Fri, Jun 11, 2010 at 6:21 AM, Gilles Sadowski <
[hidden email]> wrote:

> What do you think of introducing logging statements in CM?
> [If it was already discussed, does someone have a pointer?]
>
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Help in debugging process

Roman Werpachowski
In reply to this post by Gilles Sadowski
Depends on the performance impact. I certainly wouldn't want to
discover that upgrading CM to new version made my code 20% slower
because the optimizer now logs stuff I'm not interested in.

Regards,
Roman Werpachowski

On Fri, Jun 11, 2010 at 2:21 PM, Gilles Sadowski
<[hidden email]> wrote:

> Hi.
>
> What do you think of introducing logging statements in CM?
> [If it was already discussed, does someone have a pointer?]
>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Help in debugging process

Ted Dunning
From a user's point of view logging is a waste of time if it doesn't tell
them something that they need/can take action on.  Thus, I could see that a
solve might log some hints about what to do when it detects a badly
ill-conditioned input, but I would be really not happy if it logs every
pivot value that it chooses.  In general, things that work like java.math
should not log, especially if they throw exceptions anyway.  Larger scale
systems could plausibly log, but I would be very dubious.

On Fri, Jun 11, 2010 at 12:21 PM, Roman Werpachowski <
[hidden email]> wrote:

> Depends on the performance impact. I certainly wouldn't want to
> discover that upgrading CM to new version made my code 20% slower
> because the optimizer now logs stuff I'm not interested in.
>
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Help in debugging process

Bill Barker


--------------------------------------------------
From: "Ted Dunning" <[hidden email]>
Sent: Friday, June 11, 2010 1:11 PM
To: "Commons Developers List" <[hidden email]>
Subject: Re: [Math] Help in debugging process

> From a user's point of view logging is a waste of time if it doesn't tell
> them something that they need/can take action on.  Thus, I could see that
> a
> solve might log some hints about what to do when it detects a badly
> ill-conditioned input, but I would be really not happy if it logs every
> pivot value that it chooses.  In general, things that work like java.math
> should not log, especially if they throw exceptions anyway.  Larger scale
> systems could plausibly log, but I would be very dubious.
>
+1

Including logging in [math] has been discussed before  (I don't have a
pointer, but searching the archives for this list should turn it up).  Ted's
comment pretty much sums up the consensus.  Of course, there is also the
very strong feeling that [math] should not have any required external
dependencies.

> On Fri, Jun 11, 2010 at 12:21 PM, Roman Werpachowski <
> [hidden email]> wrote:
>
>> Depends on the performance impact. I certainly wouldn't want to
>> discover that upgrading CM to new version made my code 20% slower
>> because the optimizer now logs stuff I'm not interested in.
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Help in debugging process

Ted Dunning
For what its worth (with warning about different strokes for different
folks), we just removed all logging from the math portions of Mahout and
were glad of it.

The only exception was the massive map-reduce SVD solver that can run for
hours or days.  Getting log message out of that is actually nice for piece
of mind.

On Fri, Jun 11, 2010 at 5:26 PM, Bill Barker <[hidden email]>wrote:

> Including logging in [math] has been discussed before  (I don't have a
> pointer, but searching the archives for this list should turn it up).  Ted's
> comment pretty much sums up the consensus.  Of course, there is also the
> very strong feeling that [math] should not have any required external
> dependencies.
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Help in debugging process

Phil Steitz
In reply to this post by Gilles Sadowski
Gilles Sadowski wrote:
> Hi.
>
> What do you think of introducing logging statements in CM?
> [If it was already discussed, does someone have a pointer?]

We have not discussed this topic much since the beginning of [math],
when we made the decision to try to avoid any external dependencies
and the dependency that we had in the early pre-1.0 release code on
commons-logging was removed [1].  We have talked about logging in
commons components a few times over the years [2][3] and as Craig
pointed out in [2] the discussion always splits into two parts - the
first part is do you need logging at all in the component and the
second is if you do, what is the right framework to use doing it.
[math] has gotten *much more complex* than it was when we concluded
that we could communicate all we needed to clients via exceptions,
so I think the topic it is worth revisiting now.

Thinking about my personal experience both debugging and using the
library, I see four basic use cases for logging in [math]
0) exception logging
1) progress indication
2) alternative to exceptions for communicating warnings or other
information to the client
3) intermediate results / algorithm traces
I don't see a compelling need for 0)-2) and 2) is in general a bad
idea (even worse than relying on exception messages).  I have
inserted and removed logging for 3) *many* times though and have
even thought about adding "instrumented" versions of some methods to
keep track of and make available to clients intermediate values /
objects.  So I think at least that use case is worth talking about.
 I am sure there are others as well.

Lets decide the first question first - do we *need* logging - before
we attack the second one (how to do it).  Thanks to great work by
Ralph, Simon, Dennis et al over the last couple of years,
introducing logging into commons components is not as scary as it
used to be, so we should not preempt the discussion of whether or
not we should do it with concerns about implementation.

Phil

[1] http://markmail.org/message/xlrtk2kw35qlyy65
[2] http://markmail.org/message/c2rcbcwg24ly43h2
[3] http://markmail.org/message/4oziorlrr2fbkr5s


>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]