Confusing compile error

[Pmb]

I'm confused as to what the compiler error message I'm getting is refering
to. Can someone take a gander and let me know what I did wrong? The program
is below. When I compile it I get the following error

______________________________
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
d:\temp\complex\temp.cpp:
Error E2333 d:\temp\complex\temp.cpp 73: Class member
'Complex::conjugate(Complex)' declared outside its class
Error E2040 d:\temp\complex\temp.cpp 74: Declaration terminated incorrectly
*** 2 errors in Compile ***

Tool completed with exit code 1
______________________________

Did I screw up with the function which determines the

___________________________________
#include <iostream.h>
#include <math.h>

class Complex {
friend ostream &operator<<( ostream &, Complex & );
public:
Complex( float = 0.0, float = 0.0 );
Complex operator+( Complex & );
Complex operator-( Complex & );
Complex &operator=( Complex & );
bool operator==( Complex & );
private:
Complex conjugate( Complex );
float magnitude( Complex );
float re;
float im;
};

ostream &operator<<( ostream &output, Complex &z )
{
float x = z.re, y = z.im;

if ( y == 0 ) // z = a
output << x;
else if ( x == 0 && y > 0 ) // z = i b
output << "i " << y;
else if ( x == 0 && y < 0 ) // z = - i b
output << "- i " << -y;
else if ( x > 0 && y > 0 ) // z = a + i b
output << x << " + i " << z.im;
else if ( x > 0 && y < 0 ) // z = a - i b
output << x << " - i " << -y;

return output;
}

Complex::Complex( float a, float b )
: re( a ), im( b) { }

Complex Complex::operator+( Complex &z )
{
Complex sum;

sum.re = re + z.re;
sum.im = im + z.im;

return Complex( sum.re, sum.im );
}

Complex Complex::operator-( Complex &z )
{
Complex diff;

diff.re = re - z.re;
diff.im = im - z.im;

return Complex( diff.re, diff.im );
}

Complex& Complex::operator=( Complex &z )
{
re = z.re;
im = z.im;

return *this;
}

bool Complex::operator==( Complex &z )
{
return ( re == z.re && im == z.im );
}

Complex Complex::conjugate( Complex z );
{
return Complex( z.re, -z.im);
}

float Complex::magnitude( Complex z )
{
float x = z.re, y.im;

return sqrt( x*x + y*y );
}

int main()
{
Complex z( 3, 4 );

cout << "z = " << z << endl;
cout << "z* = " << conjugate( z ) << endl:

return 0;
}

___________________________________

[Victor Bazarov]

"Pmb" <so*****@somewhere.com> wrote...

I'm confused as to what the compiler error message I'm getting is refering
to. Can someone take a gander and let me know what I did wrong? The program is below. When I compile it I get the following error

______________________________
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
d:\temp\complex\temp.cpp:
Error E2333 d:\temp\complex\temp.cpp 73: Class member
'Complex::conjugate(Complex)' declared outside its class
Error E2040 d:\temp\complex\temp.cpp 74: Declaration terminated incorrectly *** 2 errors in Compile ***

Tool completed with exit code 1
______________________________

Did I screw up with the function which determines the
[...]
Complex Complex::conjugate( Complex z ); ^^^^
What's that there, at the end of the line?
{
return Complex( z.re, -z.im);
}

Victor

[Victor Bazarov]

"Pmb" <so*****@somewhere.com> wrote...

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:xAQtc.3032$3x.2476@attbi_s54...

"Pmb" <so*****@somewhere.com> wrote...

I'm confused as to what the compiler error message I'm getting is refering to. Can someone take a gander and let me know what I did wrong? The

program

is below. When I compile it I get the following error

______________________________
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
d:\temp\complex\temp.cpp:
Error E2333 d:\temp\complex\temp.cpp 73: Class member
'Complex::conjugate(Complex)' declared outside its class
Error E2040 d:\temp\complex\temp.cpp 74: Declaration terminated

incorrectly

*** 2 errors in Compile ***

Tool completed with exit code 1
______________________________

Did I screw up with the function which determines the

[...]

Complex Complex::conjugate( Complex z );

^^^^
What's that there, at the end of the line?

{
return Complex( z.re, -z.im);
}

Sorry but I have no idea what you're point is. Please be more precise.

Remove the semicolon.

[Pmb]

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:xAQtc.3032$3x.2476@attbi_s54...

"Pmb" <so*****@somewhere.com> wrote...

I'm confused as to what the compiler error message I'm getting is refering to. Can someone take a gander and let me know what I did wrong? The

program

is below. When I compile it I get the following error

______________________________
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
d:\temp\complex\temp.cpp:
Error E2333 d:\temp\complex\temp.cpp 73: Class member
'Complex::conjugate(Complex)' declared outside its class
Error E2040 d:\temp\complex\temp.cpp 74: Declaration terminated

incorrectly

*** 2 errors in Compile ***

Tool completed with exit code 1
______________________________

Did I screw up with the function which determines the

[...]

Complex Complex::conjugate( Complex z );

^^^^
What's that there, at the end of the line?

{
return Complex( z.re, -z.im);
}

Sorry but I have no idea what you're point is. Please be more precise.

Pmb

[Dave Townsend]

PMB,

these functions don't seem to be correctly
designed, the conjugate and magnitude should
be using the object, not another "z" value.

ie,
Complex Complex::conjugate( );
{
return Complex( re, - im);
}

float Complex::magnitude( )
{
float x = re;
float y = im;

return sqrt( x*x + y*y );
}

"Pmb" <so*****@somewhere.com> wrote in message
news:gP********************@comcast.com...

I'm confused as to what the compiler error message I'm getting is refering
to. Can someone take a gander and let me know what I did wrong? The program is below. When I compile it I get the following error

______________________________
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
d:\temp\complex\temp.cpp:
Error E2333 d:\temp\complex\temp.cpp 73: Class member
'Complex::conjugate(Complex)' declared outside its class
Error E2040 d:\temp\complex\temp.cpp 74: Declaration terminated incorrectly *** 2 errors in Compile ***

Tool completed with exit code 1
______________________________

Did I screw up with the function which determines the

___________________________________
#include <iostream.h>
#include <math.h>

class Complex {
friend ostream &operator<<( ostream &, Complex & );
public:
Complex( float = 0.0, float = 0.0 );
Complex operator+( Complex & );
Complex operator-( Complex & );
Complex &operator=( Complex & );
bool operator==( Complex & );
private:
Complex conjugate( Complex );
float magnitude( Complex );
float re;
float im;
};

ostream &operator<<( ostream &output, Complex &z )
{
float x = z.re, y = z.im;

if ( y == 0 ) // z = a
output << x;
else if ( x == 0 && y > 0 ) // z = i b
output << "i " << y;
else if ( x == 0 && y < 0 ) // z = - i b
output << "- i " << -y;
else if ( x > 0 && y > 0 ) // z = a + i b
output << x << " + i " << z.im;
else if ( x > 0 && y < 0 ) // z = a - i b
output << x << " - i " << -y;

return output;
}

Complex::Complex( float a, float b )
: re( a ), im( b) { }

Complex Complex::operator+( Complex &z )
{
Complex sum;

sum.re = re + z.re;
sum.im = im + z.im;

return Complex( sum.re, sum.im );
}

Complex Complex::operator-( Complex &z )
{
Complex diff;

diff.re = re - z.re;
diff.im = im - z.im;

return Complex( diff.re, diff.im );
}

Complex& Complex::operator=( Complex &z )
{
re = z.re;
im = z.im;

return *this;
}

bool Complex::operator==( Complex &z )
{
return ( re == z.re && im == z.im );
}

Complex Complex::conjugate( Complex z );
{
return Complex( z.re, -z.im);
}

float Complex::magnitude( Complex z )
{
float x = z.re, y.im;

return sqrt( x*x + y*y );
}

int main()
{
Complex z( 3, 4 );

cout << "z = " << z << endl;
cout << "z* = " << conjugate( z ) << endl:

return 0;
}

___________________________________

[Klaus Eichner]

"Pmb" <so*****@somewhere.com> wrote in message
news:gP********************@comcast.com...

I'm confused as to what the compiler error message I'm getting is refering
to.
[snip]
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
d:\temp\complex\temp.cpp:
Error E2333 d:\temp\complex\temp.cpp 73: Class member
'Complex::conjugate(Complex)' declared outside its class
Error E2040 d:\temp\complex\temp.cpp 74: Declaration terminated incorrectly *** 2 errors in Compile ***

Tool completed with exit code 1
[snip]
Complex Complex::conjugate( Complex z ); see post by Victor Bazarov to fix the error on the above line
{
return Complex( z.re, -z.im);
}
[snip]
int main()
{
Complex z( 3, 4 );

cout << "z = " << z << endl;
cout << "z* = " << conjugate( z ) << endl: the colon (":") at the end of the above line must be replaced by a
semi-colon (";")
return 0;
}

[Pmb]

"Dave Townsend" <da********@comcast.net> wrote in message
news:2Y********************@comcast.com...

PMB,

these functions don't seem to be correctly
designed, the conjugate and magnitude should
be using the object, not another "z" value.

ie,
Complex Complex::conjugate( );
{
return Complex( re, - im);
}

float Complex::magnitude( )
{
float x = re;
float y = im;

return sqrt( x*x + y*y );
}

They work fine. They do use the object. The class is defined as

class Complex {
friend ostream &operator<<( ostream &, Complex & );
public:
Complex( float = 0.0, float = 0.0 );
Complex operator+( Complex & );
Complex operator-( Complex & );
Complex operator*( Complex & );
Complex operator/( Complex & );
Complex operator=( Complex & );

float getRe() { return re; };
float getIm() { return im; };
Complex conjugate();
float magnitude();
private:
float re;
float im;
};
Thanks

Pmb

[Victor Bazarov]

"Dave Townsend" <da********@comcast.net> wrote...

PMB,

these functions don't seem to be correctly
designed, the conjugate and magnitude should
be using the object, not another "z" value.

ie,
Complex Complex::conjugate( );
You might consider watching your semicolons too.
{
return Complex( re, - im);
}
[...]

[Richard Herring]

In message <Ub********************@comcast.com>, Pmb
<so*****@somewhere.com> writes

"Dave Townsend" <da********@comcast.net> wrote in message
news:2Y********************@comcast.com...

PMB,

these functions don't seem to be correctly
designed, the conjugate and magnitude should
be using the object, not another "z" value.

ie,
Complex Complex::conjugate( );
{
return Complex( re, - im);
}

float Complex::magnitude( )
{
float x = re;
float y = im;

return sqrt( x*x + y*y );
}

Note that for serious numerical code, this is _not_ the way to code
complex::abs(). Your operator/ has a similar problem.

(Yes, I know this is only a pedagogical toy. All the same, it's not a
good idea to propagate bad practice.)

They work fine.
Now.
They do use the object.
But they didn't in your earlier posting.
The class is defined
- now -
as

class Complex {
friend ostream &operator<<( ostream &, Complex & );
public:
Complex( float = 0.0, float = 0.0 );
Complex operator+( Complex & );
Complex operator-( Complex & );
Complex operator*( Complex & );
Complex operator/( Complex & );
Complex operator=( Complex & );

float getRe() { return re; };
float getIm() { return im; };
Complex conjugate();
float magnitude();
private:
float re;
float im;
};
but originally you had
class Complex {
friend ostream &operator<<( ostream &, Complex & );
public:
Complex( float = 0.0, float = 0.0 );
Complex operator+( Complex & );
Complex operator-( Complex & );
Complex &operator=( Complex & );
bool operator==( Complex & );
private:
Complex conjugate( Complex );
float magnitude( Complex );
float re;
float im;
};

--
Richard Herring

[Pmb]

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:OA**************@baesystems.com...

In message <Ub********************@comcast.com>, Pmb
<so*****@somewhere.com> writes

"Dave Townsend" <da********@comcast.net> wrote in message
news:2Y********************@comcast.com...

PMB,

these functions don't seem to be correctly
designed, the conjugate and magnitude should
be using the object, not another "z" value.

ie,
Complex Complex::conjugate( );
{
return Complex( re, - im);
}

float Complex::magnitude( )
{
float x = re;
float y = im;

return sqrt( x*x + y*y );
}

Note that for serious numerical code, this is _not_ the way to code
complex::abs(). Your operator/ has a similar problem.

I can't help but wonder why you think that this comment of yours is useful.
It is about as useful as "No sa!"

A little advice - If you want to be helpful then back up a claim that
something is not right and then give what you hold to be correct. What I
gave is not incorrect. It works just fine. If you meant that it is
inefficient, i.e. not as computationally speedy as something else you have
in mind, then that comes into the relm of being a tradeoff between
efficiency and readability/maintainability. I may not be interested in an
efficient program. I may only be interested in an easy to write program.
Next time please clarify and justify your remarks.
(Yes, I know this is only a pedagogical toy. All the same, it's not a
good idea to propagate bad practice.)

Prove that this is a bad practice.

<snipped unhelpful comments>

Pmb

[Richard Herring]

In message <GP********************@comcast.com>, Pmb
<so*****@somewhere.com> writes

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:OA**************@baesystems.com...

In message <Ub********************@comcast.com>, Pmb
<so*****@somewhere.com> writes

>
>"Dave Townsend" <da********@comcast.net> wrote in message
>news:2Y********************@comcast.com...
>> PMB,
>>
>> these functions don't seem to be correctly
>> designed, the conjugate and magnitude should
>> be using the object, not another "z" value.
>>
>> ie,
>> Complex Complex::conjugate( );
>> {
>> return Complex( re, - im);
>> }
>>
>> float Complex::magnitude( )
>> {
>> float x = re;
>> float y = im;
>>
>> return sqrt( x*x + y*y );
>> }
Note that for serious numerical code, this is _not_ the way to code
complex::abs(). Your operator/ has a similar problem.

I can't help but wonder why you think that this comment of yours is useful.
It is about as useful as "No sa!"

It's intended to make you think.
A little advice - If you want to be helpful then back up a claim that
something is not right and then give what you hold to be correct. What I
gave is not incorrect. It works just fine.
Sure about that?

#include <ostream>
#include <iostream>
#include "your-complex-class.h"

int main()
{
complex x(0.0, 1e35);
float a = x.magnitude();
std::cout << x << ' ' << a << ' \n';
}
If you meant that it is
inefficient, i.e. not as computationally speedy as something else you have
in mind, then that comes into the relm of being a tradeoff between
efficiency and readability/maintainability. I may not be interested in an
efficient program. I may only be interested in an easy to write program.
Next time please clarify and justify your remarks.
This is Usenet. My remarks are worth every penny you paid for them.

(Yes, I know this is only a pedagogical toy. All the same, it's not a
good idea to propagate bad practice.)
Prove that this is a bad practice.

See example.
<snipped unhelpful comments>

--
Richard Herring

[Pmb]

"Pmb" <so*****@somewhere.com> wrote in message
news:GP********************@comcast.com...

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:OA**************@baesystems.com...

In message <Ub********************@comcast.com>, Pmb
<so*****@somewhere.com> writes

"Dave Townsend" <da********@comcast.net> wrote in message
news:2Y********************@comcast.com...
> PMB,
>
> these functions don't seem to be correctly
> designed, the conjugate and magnitude should
> be using the object, not another "z" value.
>
> ie,
> Complex Complex::conjugate( );
> {
> return Complex( re, - im);
> }
>
> float Complex::magnitude( )
> {
> float x = re;
> float y = im;
>
> return sqrt( x*x + y*y );
> }

This particular class and member function was never intended to be anything
other than something for me to use to learn about classes and C++ etc. Upon
inspection I don't recall why I didn't write the member function as

float Complex::magnitude( )
{
return sqrt( re*re + im*im );
}

But I suspect it has to do with me dabbling with how to implement member
functions and I simply used Complex numbers and magnitude as an obvious
example. However I, personally, would never label such a function "abs()"
since sqrt( re*re + im*im );is called the "modulus" in math circles.

Pmb

[Pmb]

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:Lr**************@baesystems.com...

In message <GP********************@comcast.com>, Pmb
<so*****@somewhere.com> writes

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:OA**************@baesystems.com...

In message <Ub********************@comcast.com>, Pmb
<so*****@somewhere.com> writes
>
>"Dave Townsend" <da********@comcast.net> wrote in message
>news:2Y********************@comcast.com...
>> PMB,
>>
>> these functions don't seem to be correctly
>> designed, the conjugate and magnitude should
>> be using the object, not another "z" value.
>>
>> ie,
>> Complex Complex::conjugate( );
>> {
>> return Complex( re, - im);
>> }
>>
>> float Complex::magnitude( )
>> {
>> float x = re;
>> float y = im;
>>
>> return sqrt( x*x + y*y );
>> }

Note that for serious numerical code, this is _not_ the way to code
complex::abs(). Your operator/ has a similar problem.
I can't help but wonder why you think that this comment of yours is useful.It is about as useful as "No sa!"

It's intended to make you think.

Comments such as yours are always unhelpful nd your response to constructive
criticism is even more unhelpful

A little advice - If you want to be helpful then back up a claim that
something is not right and then give what you hold to be correct. What I
gave is not incorrect. It works just fine.

Sure about that?

#include <ostream>
#include <iostream>
#include "your-complex-class.h"

int main()
{
complex x(0.0, 1e35);
float a = x.magnitude();
std::cout << x << ' ' << a << ' \n';
}

Another useless comment. Seems that you want to hint, rather than state,
what you mean. Seems that you now are trying to hint that one should take
the time to do a test to see if a number is real before taking the modulus.
Hardlly worth the effort, especially since you've yet to justify the
effort.

If you meant that it is
inefficient, i.e. not as computationally speedy as something else you havein mind, then that comes into the relm of being a tradeoff between
efficiency and readability/maintainability. I may not be interested in an
efficient program. I may only be interested in an easy to write program.
Next time please clarify and justify your remarks.

This is Usenet. My remarks are worth every penny you paid for them.

Yes, You're correct. They are worth nothing. I will assum that is par for
the course for you from now on
Plonk!

Pmb

[Jeff Relf]

[ Posted & e-mailed to Pete ( PMB ) ]

Hi Richard Herring, ( and Pete )

Re: Your complex x ( 0.0, 1e35 );

Are you hinting that one should use double variables ?

Or are you saying that you should check for overflows ?

Either way,
I don't think that was Pete's main concern at this point.

As you yourself said, your remarks are,
" worth every penny [ Pete ] paid for them. "

[Pmb]

"Jeff Relf" <[e-mail]> wrote in message
news:27***************@x.Jeff.Relf...

[ Posted & e-mailed to Pete ( PMB ) ]

Hi Richard Herring, ( and Pete )

Re: Your complex x ( 0.0, 1e35 );

Are you hinting that one should use double variables ?

Or are you saying that you should check for overflows ?

Either way,
I don't think that was Pete's main concern at this point.

As you yourself said, your remarks are,
" worth every penny [ Pete ] paid for them. "

He seems to think that, given the complex number z = x + i y, that its worth
testing as to whether x = 0 or y = 0 since then the modulus is either the
magnitude of x ( i y = 0) or the magnitude of y (if x = 0). However that
requires testing whether a floating point number is zero. In all numerical
applications that I can think of which use complex numbers such a test is a
waste of time. One should never test to see if a floating point number is
zero.It is quite unlikely that a complex number is either purely real of
purely imaginary. At least in all applications that come to mind. It simply
isn't worth the test since the occasion will never come up when determining
the modulus of z.

Pmb

[Jeff Relf]

Hi Pete ( Pmb ), [ Posted & e-mailed ]

I was looking in <math.h> when I was this:

// Definition of a _complex struct
// to be used by those who use cabs ( );
// and want type checking on their argument

// real and imaginary parts
struct _complex { double x, y ; } ;

_CRTIMP double __cdecl _cabs ( struct _complex );

And in the help, I found this:

float, 4 bytes, no other name, 3.4E +/- 38 ( 7 digits )
double, 8 bytes, no other name, 1.7E +/- 308 ( 15 digits )

[Dave Moore]

"Pmb" <so*****@somewhere.com> wrote in message news:<5I********************@comcast.com>...

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:Lr**************@baesystems.com...

In message <GP********************@comcast.com>, Pmb
<so*****@somewhere.com> writes

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:OA**************@baesystems.com...
> In message <Ub********************@comcast.com>, Pmb
> <so*****@somewhere.com> writes
> >
> >"Dave Townsend" <da********@comcast.net> wrote in message
> >news:2Y********************@comcast.com...
> >> PMB,
> >>
> >> these functions don't seem to be correctly
> >> designed, the conjugate and magnitude should
> >> be using the object, not another "z" value.
> >>
> >> ie,
> >> Complex Complex::conjugate( );
> >> {
> >> return Complex( re, - im);
> >> }
> >>
> >> float Complex::magnitude( )
> >> {
> >> float x = re;
> >> float y = im;
> >>
> >> return sqrt( x*x + y*y );
> >> }
>
> Note that for serious numerical code, this is _not_ the way to code
> complex::abs(). Your operator/ has a similar problem.

I can't help but wonder why you think that this comment of yours is useful.It is about as useful as "No sa!"

It's intended to make you think.

Comments such as yours are always unhelpful nd your response to constructive
criticism is even more unhelpful

Actually, his comments were quite helpful if you take the time to
understand them ... Your "criticism" was not constructive, it was more
like "petulant and whining" if you ask me ... in any case, you are
entitled to your opinion, but don't scold someone who is trying to
help you.

A little advice - If you want to be helpful then back up a claim that
something is not right and then give what you hold to be correct. What I
gave is not incorrect. It works just fine.

Sure about that?

#include <ostream>
#include <iostream>
#include "your-complex-class.h"

int main()
{
complex x(0.0, 1e35);
float a = x.magnitude();
std::cout << x << ' ' << a << ' \n';
}

Another useless comment. Seems that you want to hint, rather than state,
what you mean. Seems that you now are trying to hint that one should take
the time to do a test to see if a number is real before taking the modulus.
Hardlly worth the effort, especially since you've yet to justify the
effort.

Dude .. you need to back off .. Richard has done nothing but give you
good advice thus far .. don't chastise him because he didn't take the
time to spell it out for you. Even after you scolded him the first
time he still tried to help you understand why the code you posted is
flawed (and boy is it), he still posted again to help you see the
problem. If we (the usenet community) are going to take the time to
try to help you, you should commit a bit of time and thought to
understanding those comments. You purport to be some kind of "math
guy", but there is a lot more to writing good code than just knowing
the underlying math. His comments were well-meaning and justified ...
look in "Numerical Recipes" or another good reference on techniques
for numerical computations to help understand why. You might want to
google "const correctness" or just take a look at the C++ FAQ while
you're at it .. it might help you to improve your code and understand
other people's helpful comments.

Anyway, it takes time to type these posts, and we are only trying to
help you .. respect that and take some time trying to understand them.

Dave Moore

[Richard Herring]

In message <uI********************@comcast.com>, Pmb
<so*****@somewhere.com> writes

"Jeff Relf" <[e-mail]> wrote in message
news:27***************@x.Jeff.Relf...

[ Posted & e-mailed to Pete ( PMB ) ]

Hi Richard Herring, ( and Pete )

Re: Your complex x ( 0.0, 1e35 );

Are you hinting that one should use double variables ?

Or are you saying that you should check for overflows ?

Either way,
I don't think that was Pete's main concern at this point.

As you yourself said, your remarks are,
" worth every penny [ Pete ] paid for them. "
He seems to think that, given the complex number z = x + i y, that its worth
testing as to whether x = 0 or y = 0 since then the modulus is either the
magnitude of x ( i y = 0) or the magnitude of y (if x = 0).

No he doesn't. My objection has nothing to do with whether it's pure
real or pure imaginary. Did you try running my example?
However that
requires testing whether a floating point number is zero. In all numerical
applications that I can think of which use complex numbers such a test is a
waste of time. One should never test to see if a floating point number is
zero.
Not true. There are many occasions on which it would be better to test
if it's smaller than some epsilon; there are others on which a
comparison with zero is quite legitimate.
It is quite unlikely that a complex number is either purely real of
purely imaginary. At least in all applications that come to mind. It simply
isn't worth the test since the occasion will never come up when determining
the modulus of z.

--
Richard Herring

[Richard Herring]

In message <27***************@x.Jeff.Relf>, Jeff Relf <[e-mail]>
writes

[ Posted & e-mailed to Pete ( PMB ) ]

Hi Richard Herring, ( and Pete )

Re: Your complex x ( 0.0, 1e35 );

Are you hinting that one should use double variables ?
No (though that would be a good idea in any case.)
Or are you saying that you should check for overflows ?
No. I'm saying that you should code so as not to produce unnecessary
overflows.
Either way,
I don't think that was Pete's main concern at this point.
As I acknowledged in my original post.
As you yourself said, your remarks are,
" worth every penny [ Pete ] paid for them. "

--
Richard Herring

[Richard Herring]

In message <5I********************@comcast.com>, Pmb
<so*****@somewhere.com> writes

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:Lr**************@baesystems.com...

In message <GP********************@comcast.com>, Pmb
<so*****@somewhere.com> writes

>
>"Richard Herring" <ju**@[127.0.0.1]> wrote in message
>news:OA**************@baesystems.com...
>> In message <Ub********************@comcast.com>, Pmb
>> <so*****@somewhere.com> writes
>> >
>> >"Dave Townsend" <da********@comcast.net> wrote in message
>> >news:2Y********************@comcast.com...
>> >> PMB,
>> >>
>> >> these functions don't seem to be correctly
>> >> designed, the conjugate and magnitude should
>> >> be using the object, not another "z" value.
>> >>
>> >> ie,
>> >> Complex Complex::conjugate( );
>> >> {
>> >> return Complex( re, - im);
>> >> }
>> >>
>> >> float Complex::magnitude( )
>> >> {
>> >> float x = re;
>> >> float y = im;
>> >>
>> >> return sqrt( x*x + y*y );
>> >> }
>>
>> Note that for serious numerical code, this is _not_ the way to code
>> complex::abs(). Your operator/ has a similar problem.
>
>I can't help but wonder why you think that this comment of yours isuseful. >It is about as useful as "No sa!"
It's intended to make you think.

Comments such as yours are always unhelpful nd your response to constructive
criticism is even more unhelpful

You're the one asking for advice here, sunshine.

>
>A little advice - If you want to be helpful then back up a claim that
>something is not right and then give what you hold to be correct. What I
>gave is not incorrect. It works just fine.

Sure about that?

#include <ostream>
#include <iostream>
#include "your-complex-class.h"

int main()
{
complex x(0.0, 1e35);
float a = x.magnitude();
std::cout << x << ' ' << a << ' \n';
}

Another useless comment. Seems that you want to hint, rather than state,
what you mean. Seems that you now are trying to hint that one should take
the time to do a test to see if a number is real before taking the modulus.

Wrong again. Seems that you are trying to guess what I mean, with no
success.

Have you tried running my example?
Hardlly worth the effort, especially since you've yet to justify the
effort.
Have you tried running it?

> If you meant that it is
>inefficient, i.e. not as computationally speedy as something else youhave >in mind, then that comes into the relm of being a tradeoff between
>efficiency and readability/maintainability. I may not be interested in an
>efficient program. I may only be interested in an easy to write program.
>Next time please clarify and justify your remarks.

This is Usenet. My remarks are worth every penny you paid for them.

Yes, You're correct. They are worth nothing. I will assum that is par for
the course for you from now on
Plonk!

I doubt it. The pmb "killfile" is a source of much amusement in some
other groups.

--
Richard Herring

[Richard Herring]

In message <TY********************@comcast.com>, Pmb
<so*****@somewhere.com> writes

But I suspect it has to do with me dabbling with how to implement member
functions and I simply used Complex numbers and magnitude as an obvious
example. However I, personally, would never label such a function "abs()"
since sqrt( re*re + im*im );is called the "modulus" in math circles.

When it isn't called the "absolute value", of course. "Modulus" has
other meanings too.

http://mathworld.wolfram.com/AbsoluteValue.html
http://mathworld.wolfram.com/Modulus.html

The authors of the Holy C++ Standard chose to call their family of
functions abs(). If you don't like it, take it up with them.
--
Richard Herring

[Pmb]

"Pmb" <so*****@somewhere.com> wrote in message
news:uI********************@comcast.com...

"Jeff Relf" <[e-mail]> wrote in message
news:27***************@x.Jeff.Relf...

[ Posted & e-mailed to Pete ( PMB ) ]

Hi Richard Herring, ( and Pete )

Re: Your complex x ( 0.0, 1e35 );

Are you hinting that one should use double variables ?

Or are you saying that you should check for overflows ?

Either way,
I don't think that was Pete's main concern at this point.

As you yourself said, your remarks are,
" worth every penny [ Pete ] paid for them. "
He seems to think that, given the complex number z = x + i y, that its

worth testing as to whether x = 0 or y = 0 since then the modulus is either the
magnitude of x ( i y = 0) or the magnitude of y (if x = 0). However that
requires testing whether a floating point number is zero. In all numerical
applications that I can think of which use complex numbers such a test is a waste of time. One should never test to see if a floating point number is
zero.It is quite unlikely that a complex number is either purely real of
purely imaginary. At least in all applications that come to mind. It simply isn't worth the test since the occasion will never come up when determining the modulus of z.

This, of course, does not mean that one shouldn't test for division by zero.
That is something different from performance. That is a test to avoid a
runtime error.

Pmb

[Richard Herring]

In message <0a********************@comcast.com>, Pmb
<so*****@somewhere.com> writes

"Pmb" <so*****@somewhere.com> wrote in message
news:uI********************@comcast.com...
[...]

One should never test to see if a floating point number is
zero.

[...]
This, of course, does not mean that one shouldn't test for division by zero.

!
--
Richard Herring

[Richard Herring]

In message <1v***************@x.Jeff.Relf>, Jeff Relf <[e-mail]>
writes

Hi Pete ( Pmb ), [ Posted & e-mailed ]

I was looking in <math.h> when I was this:

// Definition of a _complex struct
// to be used by those who use cabs ( );
That's provided for compatibility with C. C++ has better ways of
handling complex numbers.
// and want type checking on their argument

// real and imaginary parts
struct _complex { double x, y ; } ;

_CRTIMP double __cdecl _cabs ( struct _complex );
And your point was?

You won't find any of that specified in the C++ Standard.
You're not supposed to look inside standard header files ;-)
And in the help, I found this:

float, 4 bytes, no other name, 3.4E +/- 38 ( 7 digits )
double, 8 bytes, no other name, 1.7E +/- 308 ( 15 digits )

That's implementation-dependent, but not atypical.

--
Richard Herring

[Jeff Relf]

Hi Pmb ( Pete ),

Re: Dividing by zero.

There are basically two ways to compile code:
1. For release, 2. For Debugging.

Dividing by zero with release-complied code
will trigger no error, and no exceptions,
provided that you are not in the debugger.

So a Div_By_Zero never leaves the end-user high and dry.

[Pmb]

"Jeff Relf" <[e-mail]> wrote in message
news:b1**************@x.Jeff.Relf...

Hi Pmb ( Pete ),

Re: Dividing by zero.

There are basically two ways to compile code:
1. For release, 2. For Debugging.

Dividing by zero with release-complied code
will trigger no error, and no exceptions,
provided that you are not in the debugger.

So a Div_By_Zero never leaves the end-user high and dry.

Compile and run the following
______________________________
#include <iostream.h>

int main()
{
int x, y, z;

x = 1;
y = -1;
z = 1/(x+y);

cout << "z = " << z << endl;

return 0;
}
______________________________

What do you get?

Pmb

[Richard Herring]

In message <b1**************@x.Jeff.Relf>, Jeff Relf <[e-mail]>
writes

Hi Pmb ( Pete ),

Re: Dividing by zero.

There are basically two ways to compile code:
1. For release, 2. For Debugging.

Dividing by zero with release-complied code
will trigger no error, and no exceptions,
provided that you are not in the debugger.
Where in the standard do you find that?
So a Div_By_Zero never leaves the end-user high and dry.

This is comp.lang.c++, where the topic is standard C++.

According to the standard, division by zero is undefined behaviour, up
to and including nasal demons.

--
Richard Herring

[Jeff Relf]

Hi Richard Herring,

I mentioned,
" Dividing by zero with release-complied code
will trigger no error, and no exceptions,
provided that you are not in the debugger. "

And you asked me,
" Where in the standard do you find that ? "

My clients are using my code, not your standards.

[Karl Heinz Buchegger]

Jeff Relf wrote:

Hi Richard Herring,

I mentioned,
" Dividing by zero with release-complied code
will trigger no error, and no exceptions,
provided that you are not in the debugger. "

And you asked me,
" Where in the standard do you find that ? "

My clients are using my code, not your standards.

Your clients are unimportant for this group.

The question remains:
Where in the C++ standard is it mentioned that
dividing by 0 does not trigger an exception with
release compiled code.

Just because *your* compiler produces code that behaves
that way doesn't mean that this is so on all compilers.

--
Karl Heinz Buchegger
kb******@gascad.at

[Phlip]

Jeff Relf wrote:

Hi Richard Herring,

I mentioned,
" Dividing by zero with release-complied code
will trigger no error, and no exceptions,
provided that you are not in the debugger. "

And you asked me,
" Where in the standard do you find that ? "

My clients are using my code, not your standards.

Wise programmers plan, just a little, for the future. The less
standard-compliant your code, the more likely it will break when you change
compiler vendors, or compiler versions, or even the compilation options.
This ensure clients may come back for more.

The C languages are "portable assembler". They provide a wide range of ways
to create "undefined behavior", meaning the compiler vendor is not required
to guarantee any particular result if a programmer crosses a very obvious
line. Things like double-deleting allocated memory, writing off the end of
an array, etc. Part of becoming proficient, and less than dangerous, in the
C languages is learning the complete list of undefined behaviors, and the
best practices that avoid them. That's what this newsgroup means each time
it slings out the loaded word "standard".

The fastest way to become non-proficient is to rely on "but my compiler
liked it". That attitude causes a skyrocketing rate of bugs, all
extraordinarily hard to detect and debug. Programmers who learn and follow a
sane subset don't get that problem.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Jeff Relf]

Hi Pmb ( Pete ),

Re: Dividing by zero.

I was only referring to floating point math, not integers.

Try this ( Compile for release, not debug ):

float N = 1, D = 1, DD = -1 ; N /= ( D + DD );
char Output [ 88 ];
sprintf ( Output, "%3.3f", N );

In VC 6, Output becomes: 1.#IO,
it runs with no complaints, even in the debugger.
[ Note, _isnan( N ) will let you catch that overflow ]

When I change everything to integers:
In the debugger it throws an exception, outside it hangs.

But I also tried to compile this:

int i ; i /= 0 ;

Which caused this funny result:

C:\AA.CPP(253) : fatal error C1001: INTERNAL COMPILER ERROR
( compiler file 'E:\8168\vc98\p2\src\P2\main.c', line 506 )
Please choose the Technical Support
command on the Visual C++ Help menu,
or open the Technical Support help file
for more information

E:\8168\vc98\p2\src\P2\main.c ?

I don't have anything that looks like that.

[Richard Herring]

In message <15**************@x.Jeff.Relf>, Jeff Relf <[e-mail]>
writes

Hi Richard Herring,

I mentioned,
" Dividing by zero with release-complied code
will trigger no error, and no exceptions,
provided that you are not in the debugger. "

And you asked me,
" Where in the standard do you find that ? "

My clients are using my code, not your standards.

Then you're off-topic for this newsgroup.

--
Richard Herring

[Jeff Relf]

Hi Karl Heinz Buchegger,

You asked,
" Where in the C++ standard is it mentioned that
dividing by 0 does not trigger an exception with
release compiled code. "

For VC 6 release-complied code,
a floating point divide-by-zero simply returns an overflow.
Which can then simply be checked using _isnan( float ).

I just checked integers ... They will hang your code ...
forcing you to kill it.

Now, ignoring standards for just one moment,
which response do you think was better behaved ?
A. The one that had to be killed by hand.
B. The one that simply returned an overflow,
and which could then be checked using _isnan( float ).

Take your time answering this question,
I know how hard it is for you.

After you answered that question,
I might answer your question
about IEEE floating point standards.

[Jeff Relf]

Hi Phlip,

Nothing is more undefined and nebulous
than a so-called standard.

Learn that buddy.

Coding is about testing, proving and then retesting.

... Standards ? Stop making me laugh.

[tom_usenet]

On Thu, 3 Jun 2004 08:54:15 -0700, Jeff Relf <[e-mail]> wrote:

Hi Pmb ( Pete ),

Re: Dividing by zero.

I was only referring to floating point math, not integers.

Try this ( Compile for release, not debug ):

float N = 1, D = 1, DD = -1 ; N /= ( D + DD );
char Output [ 88 ];
sprintf ( Output, "%3.3f", N );

In VC 6, Output becomes: 1.#IO,
it runs with no complaints, even in the debugger.
[ Note, _isnan( N ) will let you catch that overflow ]

When I change everything to integers:
In the debugger it throws an exception, outside it hangs.

But I also tried to compile this:

int i ; i /= 0 ;
i is uninitialized, which means you shouldn't do anything to it except
assign it a value. Divide by 0 is always a bug, so don't do it.
Which caused this funny result:

C:\AA.CPP(253) : fatal error C1001: INTERNAL COMPILER ERROR
( compiler file 'E:\8168\vc98\p2\src\P2\main.c', line 506 )
Please choose the Technical Support
command on the Visual C++ Help menu,
or open the Technical Support help file
for more information

E:\8168\vc98\p2\src\P2\main.c ?

I don't have anything that looks like that.

I don't see a question in there. What's your question?

If you divide by 0, you get undefined behaviour. Exactly what happens
varies from compiler to compiler, platform to platform, and can depend
on compiler options. So best not to do it! Check denominators before
dividing...

You might want to ask over in microsoft.public.vc.language for VC
specific issues, such as ICEs.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[tom_usenet]

On Thu, 3 Jun 2004 09:14:37 -0700, Jeff Relf <[e-mail]> wrote:

Hi Phlip,

Nothing is more undefined and nebulous
than a so-called standard.

Learn that buddy.

Coding is about testing, proving and then retesting.

... Standards ? Stop making me laugh.

Try upgrading to VC7.1 and you'll probably stop laughing when your
"tested" hacks stop working (since they relied on particular behaviour
of your current compiler) and have to be re-written. And so the cycle
continues when you upgrade to the next version...

If you write to standards, you'll find that testing goes a lot more
smoothly, and your code will work when compiled with a variety of
different compilers and versions.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[Phlip]

Jeff Relf wrote:

Hi Phlip,

Nothing is more undefined and nebulous
than a so-called standard.

Learn that buddy.

Coding is about testing, proving and then retesting.

... Standards ? Stop making me laugh.

Please please tell me you'l never program anything that flies over me.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[red floyd]

Jeff Relf wrote:

Try this ( Compile for release, not debug ):

My compiler has no "compile for release" option.

[Phlip]

red floyd wrote:

Try this ( Compile for release, not debug ):

My compiler has no "compile for release" option.

Then you won't get a VC++ "INTERNAL COMPILER ERROR".

;-)

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Jeff Relf]

Hi red floyd,

You said that your compiler,
' has no " compile for release " option. '

Why ? Is it the student version ?

Only the Pro version of VC 6 has the optimizer.

[Prateek R Karandikar]

Jeff Relf <[e-mail]> wrote

Hi Karl Heinz Buchegger,

You asked,
" Where in the C++ standard is it mentioned that
dividing by 0 does not trigger an exception with
release compiled code. "

For VC 6 release-complied code,
a floating point divide-by-zero simply returns an overflow.
Which can then simply be checked using _isnan( float ).

I just checked integers ... They will hang your code ...
forcing you to kill it.

Now, ignoring standards for just one moment,
which response do you think was better behaved ?
ignoring standards? the Standard is the very document that defines the
language, and Standard C++ is the topic of this group. If you choose
to ignore the Standard, then it becomes off-topic for this group.
A. The one that had to be killed by hand.
B. The one that simply returned an overflow,
and which could then be checked using _isnan( float ).

Take your time answering this question,
I know how hard it is for you.
Division by zero invokes undefined behaviour, so any behaviour is ok.
Efficiency is very important for C++. Option A would probably be more
efficient. Option B tests the second operand of operator/ (for the
inbuilt usages) for equality to zero, each time you divide. So it is
inefficient. If you are willing to check for overflow after the
division, why not simply check *before* the division whether the
second operand is zero or not? BTW, your scheme involves 2 checks: the
system checks once when you divide, and returns overflow on zero, and
then you check later for overflow. Instead, why not check just once
before the division?
After you answered that question,
I might answer your question
about IEEE floating point standards.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
To iterate is human, to recurse divine.
-L. Peter Deutsch
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[Karl Heinz Buchegger]

Jeff Relf wrote:

Hi red floyd,

You said that your compiler,
' has no " compile for release " option. '

Why ? Is it the student version ?

Only the Pro version of VC 6 has the optimizer.

Did it ever come to your mind that there are more C++
compilers around then VC++ ?

--
Karl Heinz Buchegger
kb******@gascad.at

[Karl Heinz Buchegger]

Jeff Relf wrote:

Hi Karl Heinz Buchegger,

You asked,
" Where in the C++ standard is it mentioned that
dividing by 0 does not trigger an exception with
release compiled code. "

For VC 6 release-complied code,
a floating point divide-by-zero simply returns an overflow.
Which can then simply be checked using _isnan( float ).

I just checked integers ... They will hang your code ...
forcing you to kill it.

Now, ignoring standards for just one moment,
which response do you think was better behaved ?
A. The one that had to be killed by hand.
B. The one that simply returned an overflow,
and which could then be checked using _isnan( float ).

Take your time answering this question,
I know how hard it is for you.
Man. You are one of the worst cases of 'All the world is a VAX'
that happend to come to this group in the last time.

Read it character by character:

T h i s g r o u p d o e s * N O T * d e a l
w i t h a n y s p e c i f i c i m p l e m e n t a t i o n.

F o r t h i s g r o u p , t h e r e i s o n l y t h e
S t a n d a r d s d o c u m e n t r e l e v a n t .
W h a t y o u r s p e c i f i c i m p l e m e n t a t i o n
d o e s o r n o t d o e s , i s i r r e l e v a n t a s
l o n g a s t h e S t a n d a r d s d o c u m e n t d o e s n ' t
s a y i t h a s t o d o i t.
Got it now: No platform specifics in this group!

After you answered that question,
I might answer your question
about IEEE floating point standards.

Q: Where in the standard is it mentioned that IEEE has to be used
in C++ ?
A: Nowhere. So IEEE is irrelevant to this group.

--
Karl Heinz Buchegger
kb******@gascad.at

[Alf P. Steinbach]

* Jeff Relf:

Hi Karl Heinz Buchegger,

You asked,
" Where in the C++ standard is it mentioned that
dividing by 0 does not trigger an exception with
release compiled code. "

For VC 6 release-complied code,
a floating point divide-by-zero simply returns an overflow.
Which can then simply be checked using _isnan( float ).
Try to use standard-conforming code to check for NaN. One simple way
is based on the fact that only NaN compares as unequal to itself.

I just checked integers ... They will hang your code ...
forcing you to kill it.
That is not mandated by the standard. What you have with integers is
undefined behavior. Anything could happen, depending on the phase of
the moon.

I might answer your question
about IEEE floating point standards.

You might find it educational to check out the standard's support for
IEEE floating point in std::numeric_limits.

If you static assert that floating point is IEEE (called "iec" in the
standard) and that floating point operations result in NaN's rather
than exceptions, and use standard-conforming code for checking for
NaN's, then your code can be standard-compliant; e.g., will also work
with other compilers that are standard-conforming in this respect, and
can be discussed in this group.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Richard Herring]

In message <7e**************@x.Jeff.Relf>, Jeff Relf <[e-mail]>
writes

[Do stop changing the subject, there's a good chap]

Hi red floyd,

You said that your compiler,
' has no " compile for release " option. '

Why ? Is it the student version ?

Only the Pro version of VC 6 has the optimizer.

"Compiler" is not synonymous with "VC6".

--
Richard Herring

[Jeff Relf]

Hi Alf P. Steinbach,

Re: Your irritation over my
real world account of a floating point division by zero.

Earth to Steinbach. Earth to Steinbach.
Come in Steinbach. Are you there Steinbach ?

You Only care about standards ?
Generating NaN's instead of locking up
is probably the default behavior according to the standard.

If you think I'm wrong about that ...
and if it's getting under your skin,
Why don't you just prove me wrong ?

As for me, I don't care either way.

[Steven T. Hatton]

Jeff Relf wrote:

Hi Alf P. Steinbach,

....
This is a person attack, and is thus inappropriate for this news group. If
you feel you must carry on this level of discourse, please take it to a
private channel.

--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Richard Herring]

In message <_J*************************@NCPlus.NET>, Jeff Relf
<[e-mail]> writes

[Will you kindly stop changing the subject? If you're responding to an
earlier posting, keep it in the same thread. That means not changing
the subject line and using standard References: headers.
Otherwise users of non-threading newsreaders won't be able to make any
sense of your postings.]

Hi Alf P. Steinbach,
You pressed the wrong button. This is comp.lang.c++, not a private
mailbox.
Re: Your irritation over my
real world account of a floating point division by zero.

Earth to Steinbach. Earth to Steinbach.
Come in Steinbach. Are you there Steinbach ?

You Only care about standards ?
Generating NaN's instead of locking up
is probably the default behavior according to the standard.
According to the standard it's undefined behaviour. End. Of. Story.
If you think I'm wrong about that ...
and if it's getting under your skin,
Why don't you just prove me wrong ?
ISO/IEC Standard 14882, section 5.5:

"If during the evaluation of an expression, the result is not
mathematically defined or not in the range of representable values for
its type, the behavior is undefined..."

There is no requirement for NaNs to even exist.
As for me, I don't care either way.

So why do you keep posting, troll?

--
Richard Herring

[Phlip]

Karl Heinz Buchegger wrote:

Jeff Relf wrote:

Now, ignoring standards for just one moment,

F o r t h i s g r o u p , t h e r e i s o n l y t h e
S t a n d a r d s d o c u m e n t r e l e v a n t .

http://www.politicsforum.org/images/...s/flame_67.php

--
Phlip

[Jeff Relf]

You wrote,
' ISO/IEC Standard 14882, section 5.5:
" If during the evaluation of an expression,
the result is not mathematically defined
or not in the range of representable values
for its type, the behavior is undefined..."
There is no requirement for NaNs to even exist. '

Riiiiiiiiight,
as if such a standard would not exist anywhere on the net,
so you can't provide a link. Suuuuure. Whatever you say.

As for the Subject: line in my headers,
People who aren't threading using the References: line
are lost causes anyways,
I'm not too worried about them.
( Yes, Google's threading is loony, I say )

What about my Reference:'s line ?
What's nonstandard about it ?

As for addressing the individual that I am replying to,
that adds a lot of clarity, I say.
Sure, it's an open letter, but so what ?