Posted by
Luigi Ballabio on
URL: http://quantlib.414.s1.nabble.com/FdAmericanOption-problem-and-Tracing-tp3483p3490.html
On 01/06/05 06:31:46, Joseph Wang wrote:
> Also there has been some discussion on adding a trace statement.
>
> once we have agreed to a format for putting in trace statements, there is
> a lot of work to do adding trace statements to the code. My own
> experience has been that it is practically impossible to debug highly
> numerical code without some tracing mechanism. Also, my experience has
> also been that keeping trace code in the production code is usually a
> good thing. (i.e. if you have to add some print debug statements to
> track down a problem, it is really nice to have a mechanism to keep those
> debug statements in the production code).
I agree that trace code should stay in. But surely you're not suggesting
that adding such code should be done all at once? People might simply add
it when they need it and leave it there afterwards.
As to the format:
> something that I've seen that I think is interesting syntax is
>
> #define TRACE(x) if (turn_on_trace(x)) trace_ostream
>
> This lets you write things like
>
> TRACE(2) << "Trace statement";
Nice, but fragile: for instance,
if (condition)
TRACE(2) << "statement";
else
do_something();
might not do what one expects when tracing is on...
I'd go for something like
TRACE(tag, statement);
which does not suffer from such problems and can be #defined away by speed
frea---I mean, performance-concerned users :) Moreover, the macro could be
written so that it allows
TRACE(tag, "statement1" << variable << "statement2" ...);
which is almost as nice as TRACE(tag) << whatever.
Finally, I intentionally wrote a generic "tag" variable, as I'm not sure
whether a number or a string should be used. Thoughts?
Later,
Luigi