unprectable behaviour

[hurry]

Hi,

In my piece of code I see some unprectable behaviour for simple
functions like for example pow() function in math.h returns, -1#IND0
for simple arguments like POW( (double) 1, (double) 2 ) and
arbitrarily even some simple multiplication seem to return the same,
-1#IND0 ( in debugging mode, individual variables have correct values
but final product is undefined).

I was trying to solve this and in the process, found a wierd soltn, on
just repeating the same line again gives the correct result.



TIA

bye,
hurry.

 

[Richard Bos]

In my piece of code I see some unprectable behaviour for simple
functions like for example pow() function in math.h returns, -1#IND0
for simple arguments like POW( (double) 1, (double) 2 ) and
arbitrarily even some simple multiplication seem to return the same,
-1#IND0 ( in debugging mode, individual variables have correct values
but final product is undefined).

Wild guess... did you remember to #include <math.h>?

Richard

 

[hurry]

yup I did

 

[Jaspreet]

Hi,

In my piece of code I see some unprectable behaviour for simple
functions like for example pow() function in math.h returns, -1#IND0
for simple arguments like POW( (double) 1, (double) 2 ) and
arbitrarily even some simple multiplication seem to return the same,
-1#IND0 ( in debugging mode, individual variables have correct values
but final product is undefined).

I was trying to solve this and in the process, found a wierd soltn, on
just repeating the same line again gives the correct result.



TIA

bye,
hurry.

Could you please post your code ?

 

[hurry]

Sorry Its a pretty huge workspace.

Is there any chance of memory related issues which could cause this ...

 

[Jaspreet]

Sorry Its a pretty huge workspace.

Is there any chance of memory related issues which could cause this ...

Please do not use the broken Reply link present at the end of the
message. Instead goto top of the message you are replying to and click
on options to get a Reply link. Use that to post your reply so that we
can see the previous context you are replying to.

Which compiler ? Which platform ? Is "-1#IND0" the errror code / return
??

 

[hurry]

Please do not use the broken Reply link present at the end of the
message. Instead goto top of the message you are replying to and click
on options to get a Reply link. Use that to post your reply so that we
can see the previous context you are replying to.

Which compiler ? Which platform ? Is "-1#IND0" the errror code / return
??

I am working in VC++ 6.0. "-1#IND0" is the value returned from pow()
function and in the other was the result of a simple multiplication.
The code keeps running but the value becomes "-1#IND0" .

reading one of the archives of usenet I see the following comment for
"-1#IND0" ,

 

[hurry]

Please do not use the broken Reply link present at the end of the
message. Instead goto top of the message you are replying to and click
on options to get a Reply link. Use that to post your reply so that we
can see the previous context you are replying to.

Which compiler ? Which platform ? Is "-1#IND0" the errror code / return
??

I am working in VC++ 6.0. "-1#IND0" is the value returned from pow()
function and in the other was the result of a simple multiplication.
The code keeps running but the value becomes "-1#IND0" .

reading one of the archives of usenet I see the following comment for
"-1#IND0" ,
"It is the VC++ way of outputting 'quiet Nan' or 'Indefinite' "

 

[Jaspreet]

I am working in VC++ 6.0. "-1#IND0" is the value returned from pow()
function and in the other was the result of a simple multiplication.
The code keeps running but the value becomes "-1#IND0" .

reading one of the archives of usenet I see the following comment for
"-1#IND0" ,

Oh.. Could you atleast post the snippet which on execution generates a
NaN ? VC 6.0 is not regarded highly by most here and to be honest is a
broken compiler. You would be better off posting your query to a
microsoft specific newsgroup.

 

[Vladimir Oka]

I am working in VC++ 6.0. "-1#IND0" is the value returned from pow()
function and in the other was the result of a simple multiplication.
The code keeps running but the value becomes "-1#IND0" .

reading one of the archives of usenet I see the following comment for
"-1#IND0" ,
"It is the VC++ way of outputting 'quiet Nan' or 'Indefinite' "

Can you try paring down your code to a small (compilable, standard)
example that still exhibits the problem? Posting that here may enable
someone to give you a better idea, and in the process you may figure
out what's wrong anyway.

 

[Martin Ambuhl]

Hi,

In my piece of code I see some unprectable behaviour for simple
functions like for example pow() function in math.h returns, -1#IND0
for simple arguments like POW( (double) 1, (double) 2 ) and

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Capitalizing 'pow' is a severe error. Don't do it even for purposes of
explication. And the casts are completely unnecessary, serving only to
jar the reader of your code into thoughts that the writer of it doesn't
understand the language.

arbitrarily even some simple multiplication seem to return the same,
-1#IND0 ( in debugging mode, individual variables have correct values
but final product is undefined).

If you won't show the code that (mis)behaves in this way, there is not a
chance that anyone can see what's happening. Play nice. (Are you sure
you #included <math.h>?).

 

[hurry]

I am working in VC++ 6.0. "-1#IND0" is the value returned from pow()
function and in the other was the result of a simple multiplication.
The code keeps running but the value becomes "-1#IND0" .

reading one of the archives of usenet I see the following comment for
"-1#IND0" ,

 

[jacob navia]

Jaspreet a écrit :

Oh.. Could you atleast post the snippet which on execution generates a
NaN ? VC 6.0 is not regarded highly by most here and to be honest is a
broken compiler. You would be better off posting your query to a
microsoft specific newsgroup.

I disagree. Visual C++ has been one of the best compilers around for x86
systems, both in quality of the generated code and in the overall easy
of use. Yes, it is not perfect, but it is a good compiler.

 

[Flash Gordon]

Oh.. Could you atleast post the snippet which on execution generates a
NaN ? VC 6.0 is not regarded highly by most here and to be honest is a
broken compiler. You would be better off posting your query to a
microsoft specific newsgroup.

The problem here is almost certainly a C problem rather than a VC
problem (unless the code is actually C++) , so this group is a
reasonable place to post.

To the OP, you are probably overflowing, dividing by 0 or something
similar. Either that or corrupting memory. Try extracting the problem
code (or a subset of it) in to a small compilable test program. You
coud, for example, use the debugger to see what values variables have
just before things go wrong then write a program of the form:

#include <math.h>
#include <stdlib.h>

int main(void)
{
/* declare variables and initialise them to values the debugger gave
you */

/* maths code that shows up the problem */

/* print out the results */

return 0;
}

If this works then you know the problem is earlier, if not you have a
small complete compilable program you can post here for help.

 

[Richard Heathfield]

Jaspreet said:

VC 6.0 is not regarded highly by most here and to be honest is a
broken compiler.

I regard it very highly indeed, once you get the Service Pack that fixes
that stupid stdio glitch. Apart from that minor problem, what is it about
VC 6.0 that you think is broken, and why do you think it is not regarded
highly by most here?

You would be better off posting your query to a
microsoft specific newsgroup.

Why?

 

[pete]

Hi,

In my piece of code I see some unprectable behaviour for simple
functions like for example pow() function in math.h returns, -1#IND0
for simple arguments like POW( (double) 1, (double) 2 ) and
arbitrarily even some simple multiplication seem to return the same,
-1#IND0 ( in debugging mode, individual variables have correct values
but final product is undefined).

I was trying to solve this and in the process,
found a wierd soltn, on
just repeating the same line again gives the correct result.

Try to come up with a small code example
that exhibits the same problem.

 

[Roberto Waltman]

Jaspreet a écrit :

I disagree. Visual C++ has been one of the best compilers around for x86
systems, both in quality of the generated code and in the overall easy
of use. Yes, it is not perfect, but it is a good compiler.

<off-topic>
VC 6.0 has been heavily criticized in C++ circles for lack of
conformance to the language standard. I do not know if this is also
applicable to C.
</off-topic>

 

[jacob navia]

Roberto Waltman a écrit :

<off-topic>
VC 6.0 has been heavily criticized in C++ circles for lack of
conformance to the language standard. I do not know if this is also
applicable to C.
</off-topic>

Well, of course it doesn't support the C99 C standard. Microsoft has
declared that standard not applicable ...