debugging -- behaviour to be explained.

[pauldepstein]

I am debugging a program to price options which involves a recursive
function:

double node::get_equity(Parameter * const params_ptr, int x, int y,
const int rights)

This recursive function is behaving oddly. I made it print statements
into a debug file to try and capture the anomalous behaviour, and I did
capture something that to me (as a newbie) is very puzzling.
The function includes this block of code:

debug << endl << "This puzzles me!!";
debug << endl << "rights" << rights;
debug << endl << "That's the puzzle";

That block of 3 lines occurs consecutively. It is a brief excerpt,
yes, but nothing is left out of the middle.

The first two lines give me exactly the output I expected.

However, the third line gives me nothing. In other words, "That's the
puzzle" appears nowhere.

How can this be?

I am a beginner so don't be afraid to make suggestions that would mean
I did something stupid.

However, I was obviously printing to the debug stream successfully
because I was successful in getting the first line "This puzzles..." to
print as expected. (The 2nd line printed fine, too.)

What seems to be happening is that some of my code is simply being
ignored and I don't know why.

That block of 3 lines is part of a loop which is executed several
times. Each time, the 3rd line "That's the puzzle" is mysteriously
missing.

(I am having great trouble using the dev c++ debugger so I'm making do
without it. And yes, I did use the dev c++ help manual for the
debugger.)

Thank you for your help.

Paul Epstein

[Mike Wahler]

<pa**********@att.net> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

I am debugging a program to price options which involves a recursive
function:

double node::get_equity(Parameter * const params_ptr, int x, int y,
const int rights)

This recursive function is behaving oddly. I made it print statements
into a debug file to try and capture the anomalous behaviour, and I did
capture something that to me (as a newbie) is very puzzling.
The function includes this block of code:

debug << endl << "This puzzles me!!";
debug << endl << "rights" << rights;
What does the identifier 'rights' denote?
debug << endl << "That's the puzzle";

That block of 3 lines occurs consecutively. It is a brief excerpt,
yes, but nothing is left out of the middle.
But you did leave out important parts. Put together
a small, *compilable* example that produces the problem
behavior and post it here.

The first two lines give me exactly the output I expected.

However, the third line gives me nothing. In other words, "That's the
puzzle" appears nowhere.

How can this be?

With the very limited information you give, I can only hazard
a guess that something about whatever the name 'rights' represents
is doing something unexpected to your stream.

-Mike

[Stephan Brönnimann]

[e-mail] schrieb:

I am debugging a program to price options which involves a recursive
function:

double node::get_equity(Parameter * const params_ptr, int x, int y,
const int rights)

This recursive function is behaving oddly. I made it print statements
into a debug file to try and capture the anomalous behaviour, and I did
capture something that to me (as a newbie) is very puzzling.
The function includes this block of code:

debug << endl << "This puzzles me!!";
debug << endl << "rights" << rights;
debug << endl << "That's the puzzle";

That block of 3 lines occurs consecutively. It is a brief excerpt,
yes, but nothing is left out of the middle.

The first two lines give me exactly the output I expected.

However, the third line gives me nothing. In other words, "That's the
puzzle" appears nowhere.

How can this be?

I am a beginner so don't be afraid to make suggestions that would mean
I did something stupid.

However, I was obviously printing to the debug stream successfully
because I was successful in getting the first line "This puzzles..." to
print as expected. (The 2nd line printed fine, too.)

What seems to be happening is that some of my code is simply being
ignored and I don't know why.

That block of 3 lines is part of a loop which is executed several
times. Each time, the 3rd line "That's the puzzle" is mysteriously
missing.

(I am having great trouble using the dev c++ debugger so I'm making do
without it. And yes, I did use the dev c++ help manual for the
debugger.)

Thank you for your help.

Paul Epstein

Write to std::cerr instead to debug because it this stream is
never buffered.
Also I don't understand why you first write std::endl and then
the content, but that's a matter of style.

Regards, Stephan
br****@osb-systems.com
Open source rating and billing engine for communication networks.

[pauldepstein]

Thanks, Mike.

rights is an integer variable.

My intent is to create a recursive function where rights is a
parameter, and where the definition is recursive in terms of rights-1
etc.

One step is to ask it what value it thinks the parameter takes -- it
answered how I thought -- 2.

I will try and make a compilable example out of this. But it's tricky
to disentangle it that way -- I know that probably means I have bad
coding style.

I don't see how rights would do anything to the stream.

Conceptually what I'm trying to do is define f(rights) by saying if
(rights==0) return ...;

if (rights > 0) return f(rights - 1,...);

I will think about how I can disentangle the bits and pieces to provide
a complete example.

Paul Epstein

[pauldepstein]

Thanks.

I'm not familiar with cerr but I'm happy to google it. Is the command
just cerr<< .. (combined with using namespace std;) ?

I use std::endl to print on a new line. Are you advocating \n instead?

Paul Epstein

[TB]

pa**********@att.net sade:

I am debugging a program to price options which involves a recursive
function:

double node::get_equity(Parameter * const params_ptr, int x, int y,
const int rights)

This recursive function is behaving oddly. I made it print statements
into a debug file to try and capture the anomalous behaviour, and I did
capture something that to me (as a newbie) is very puzzling.
The function includes this block of code:

debug << endl << "This puzzles me!!";
debug << endl << "rights" << rights;
debug << endl << "That's the puzzle";

<snip>

And 'debug' is what? In what context is it used?

TB

[pauldepstein]

TB wrote:

pa**********@att.net sade:

I am debugging a program to price options which involves a recursive
function:

double node::get_equity(Parameter * const params_ptr, int x, int y,
const int rights)

This recursive function is behaving oddly. I made it print statements
into a debug file to try and capture the anomalous behaviour, and I did
capture something that to me (as a newbie) is very puzzling.
The function includes this block of code:

debug << endl << "This puzzles me!!";
debug << endl << "rights" << rights;
debug << endl << "That's the puzzle";
<snip>

And 'debug' is what? In what context is it used?

TB

debug is a stream for a text file. I use it to print variables for
debugging.

I followed Stephen's advice just now using cerr, and there were no
anomalies.

Perhaps the fact that debug << endl << "That's the puzzle" failed could
be used to find a significant problem with the recursion.

I am still very puzzled by that. I can think of no earthly reason why
I wouldn't get "That's the puzzle" printed in the line after the word
"rights" occurs. This happens when I use the cerr stream but not when
I use debug.

Maybe, if I understood this, I would see the whole problem and resolve
it quickly.

Paul Epstein.

[Stephan Brönnimann]

pa**********@att.net schrieb:

I'm not familiar with cerr but I'm happy to google it. Is the command
just cerr<< .. (combined with using namespace std;) ? std::cerr is the (unbuffered) standard error output while
std::cout is the (buffered) standard output.
I've suggested to use std::cerr because I don't know the behavior of
debug:-?

Also, if you debug make sure the output is flushed,
either with std::endl or std::flush as last argument.

I use std::endl to print on a new line. Are you advocating \n instead?

Yes, except for the <b>terminating</b> newline:
std::cout << "Hello " << name << ",\n"
<< "welcome back" << std::endl;

Regards, Stephan
br****@osb-systems.com
Open source rating and billing engine for communication networks.

[Stephan Brönnimann]

pa**********@att.net schrieb:

I followed Stephen's advice just now using cerr, and there were no
anomalies.

Perhaps the fact that debug << endl << "That's the puzzle" failed could
be used to find a significant problem with the recursion.

Just come to my mind: and if you use std::cout instead of debug?

Stephan

[Dave Townsend]

<pa**********@att.net> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

TB wrote:

pa**********@att.net sade:

I am debugging a program to price options which involves a recursive
function:

double node::get_equity(Parameter * const params_ptr, int x, int y,
const int rights)

This recursive function is behaving oddly. I made it print statements
into a debug file to try and capture the anomalous behaviour, and I did capture something that to me (as a newbie) is very puzzling.
The function includes this block of code:

debug << endl << "This puzzles me!!";
debug << endl << "rights" << rights;
debug << endl << "That's the puzzle";

<snip>

And 'debug' is what? In what context is it used?

TB

debug is a stream for a text file. I use it to print variables for
debugging.

I followed Stephen's advice just now using cerr, and there were no
anomalies.

Perhaps the fact that debug << endl << "That's the puzzle" failed could
be used to find a significant problem with the recursion.

I am still very puzzled by that. I can think of no earthly reason why
I wouldn't get "That's the puzzle" printed in the line after the word
"rights" occurs. This happens when I use the cerr stream but not when
I use debug.

Maybe, if I understood this, I would see the whole problem and resolve
it quickly.

Paul Epstein.

The reason you are missing the third line is that you have not added an endl
after
it, the data may not be necessarily flushed without the endl. I'd suggest
bracketing
the text you want to output with endl's or adding a flush after each output
to ensure
the text is captured in your debug output. Try that and see if your output
makes more
sense.

debug << endl << "This puzzles me!!";
debug << endl << "rights" << rights;
debug << endl << "That's the puzzle";

[pauldepstein]

With cout, it works as expected.

Which is a pity. I want it to fail so that I can pinpoint the strange
behaviour.

Yes, it seemed to be about not flushing the buffer.

It works with debug << endl <<.... << endl;

A pity because I was hoping the problem would lead to an understanding
of why the algorithm was failing.

Thanks, anyway.

Incremental progress but still progress.

Paul Epstein

[TB]

pa**********@att.net sade:

TB wrote:

pa**********@att.net sade:

I am debugging a program to price options which involves a recursive
function:

double node::get_equity(Parameter * const params_ptr, int x, int y,
const int rights)

This recursive function is behaving oddly. I made it print statements
into a debug file to try and capture the anomalous behaviour, and I did
capture something that to me (as a newbie) is very puzzling.
The function includes this block of code:

debug << endl << "This puzzles me!!";
debug << endl << "rights" << rights;
debug << endl << "That's the puzzle";

<snip>

And 'debug' is what? In what context is it used?

TB

debug is a stream for a text file. I use it to print variables for
debugging.

I followed Stephen's advice just now using cerr, and there were no
anomalies.

Perhaps the fact that debug << endl << "That's the puzzle" failed could
be used to find a significant problem with the recursion.

I am still very puzzled by that. I can think of no earthly reason why
I wouldn't get "That's the puzzle" printed in the line after the word
"rights" occurs. This happens when I use the cerr stream but not when
I use debug.

Since I lack any sort of context, all I can say is that most streams
are buffered by default. That means that unless you std::flush them or
send a std::endl (not the same as a single '\n' [std::ends]) the
characters in the buffer won't be written to the connected device or io
channel. That means that your last print statement is delayed until it's
flushed or 'debug' is destroyed. That's why Stephan suggests using
std::endl at the end of a print statement.

There is also a std::clog.

TB

[pauldepstein]

TB wrote:

pa**********@att.net sade:

TB wrote:

pa**********@att.net sade:
I am debugging a program to price options which involves a recursive
function:

double node::get_equity(Parameter * const params_ptr, int x, int y,
const int rights)

This recursive function is behaving oddly. I made it print statements
into a debug file to try and capture the anomalous behaviour, and I did
capture something that to me (as a newbie) is very puzzling.
The function includes this block of code:

debug << endl << "This puzzles me!!";
debug << endl << "rights" << rights;
debug << endl << "That's the puzzle";

<snip>

And 'debug' is what? In what context is it used?

TB

debug is a stream for a text file. I use it to print variables for
debugging.

I followed Stephen's advice just now using cerr, and there were no
anomalies.

Perhaps the fact that debug << endl << "That's the puzzle" failed could
be used to find a significant problem with the recursion.

I am still very puzzled by that. I can think of no earthly reason why
I wouldn't get "That's the puzzle" printed in the line after the word
"rights" occurs. This happens when I use the cerr stream but not when
I use debug.

Since I lack any sort of context, all I can say is that most streams
are buffered by default. That means that unless you std::flush them or
send a std::endl (not the same as a single '\n' [std::ends]) the
characters in the buffer won't be written to the connected device or io
channel. That means that your last print statement is delayed until it's
flushed or 'debug' is destroyed. That's why Stephan suggests using
std::endl at the end of a print statement.

There is also a std::clog.

TB

Yes, this was exactly the problem. Thanks. I didn't know the details
of these commands before. All I knew was that endl begins output on a
new line.

Paul Epstein