"power of" method ??

[Aaron Gallimore]

Hi,

Pretty simple one I think...Is there a "power of" or squared function in
C++. This is what i'm trying to achieve.

(array[1][0]-array[0][0])*2

this doesnt work with minus numbers so i need a square or power function.

also.. Is there a "sum of" function. Ultimately i'm trying to do a euclidean
distance equation and need to find the "sum of" some numbers.

Thanks
Aaron

[Karl Heinz Buchegger]

Aaron Gallimore wrote:

Hi,

Pretty simple one I think...Is there a "power of" or squared function in
C++. This is what i'm trying to achieve.

(array[1][0]-array[0][0])*2

this doesnt work with minus numbers so i need a square or power function.

power of: pow()

but if all you want is a square, I would write one myself, since
pow is a littel bit of overkill for this specific task:

double square( double x )
{
return x * x;
}
also.. Is there a "sum of" function.
No. But it's easy to write one, once you know how you represent
the set of numbers you want to sum over.

BTW: What text books are you using?
Ultimately i'm trying to do a euclidean
distance equation and need to find the "sum of" some numbers.

???
What for? To calculate the distance between 2 points (x1,y1) and
(x2, y2), all you need to do is (using the square function from above):

double Dist = sqrt( square( x1 - x2 ) + square( y1 - y2 ) );

Don't tell me you want to replace the simple addition with a function
call :-)

But ok, here you go:

double sum( double Arg1, double Arg2 )
{
return Arg1 + Arg2;
}

double Dist = sqrt( sum( square( x1 - x2 ), square( y1 - y2 ) ) )

But then why not replace the subtraction with a function call of it's own :-)

double dif( double Arg1, double Arg2 )
{
return Arg1 - Arg2;
}

double Dist = sqrt( sum( square( dif( x1, x2 ) ), square( dif( y1, y2 ) ) ) );

Hmm. Remindes me somehow to pure Lisp :-)

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

[Pierre Maurette]

"Karl Heinz Buchegger" <kb******@gasca d.at> a écrit ...
[...]

double square( double x )
{
return x * x;
}

inline double square( double x )
{
return x * x;
}

And so on. No?

Pierre

[Buster]

"Pierre Maurette" <mmaauurreetttt ttee.ppiieerrrr ee@@ffrreeee.ff rr>
wrote

"Karl Heinz Buchegger" <kb******@gasca d.at> a écrit ...
[...]

double square( double x )
{
return x * x;
}

inline double square( double x )
{
return x * x;
}

And so on. No?

It's probably easier to compile with optimizations. A good compiler
will inline this function without being told to. Generally "inline"
is only essential as a means of allowing a function definition to
occur more than once in a program, for example, when a function is
defined at namespace scope in a header.

Regards,
Buster.

[Rolf Magnus]

Pierre Maurette wrote:

"Karl Heinz Buchegger" <kb******@gasca d.at> a écrit ...
[...]

double square( double x )
{
return x * x;
}

inline double square( double x )
{
return x * x;
}

And so on. No?

Why would we want to convert integers or floats into doubles and later
back?

template<typena me T>
inline T square(T x)
{
return x * x;
}

[Rolf Magnus]

Buster wrote:

"Pierre Maurette" <mmaauurreetttt ttee.ppiieerrrr ee@@ffrreeee.ff rr>
wrote

"Karl Heinz Buchegger" <kb******@gasca d.at> a écrit ...
[...]

> double square( double x )
> {
> return x * x;
> }
inline double square( double x )
{
return x * x;
}

And so on. No?

It's probably easier to compile with optimizations. A good compiler
will inline this function without being told to.

It will, but only if the function is defined in the same translation
unit as it is used. If not, the compiler simply has no chance to inline
it at all. If you make the funciton static and define it in the header,
you can actually go without inline.
Generally "inline" is only essential as a means of allowing a function
definition to occur more than once in a program, for example, when a
function is defined at namespace scope in a header.

Right, and that's exactly what you need to do if you want your function
to be inlined in every translation unit where it's called.

[Buster]

"Rolf Magnus" <ra******@t-online.de> wrote in message
news:c1******** *****@news.t-online.com...

Buster wrote:

"Pierre Maurette" <mmaauurreetttt ttee.ppiieerrrr ee@@ffrreeee.ff rr> wrote

"Karl Heinz Buchegger" <kb******@gasca d.at> a écrit ...
[...]
> double square( double x )
> {
> return x * x;
> }

inline double square( double x )
{
return x * x;
}

And so on. No?
It's probably easier to compile with optimizations. A good compiler will inline this function without being told to.

It will, but only if the function is defined in the same

translation unit as it is used.
Yes. It is.
If not, the compiler simply has no chance to inline
it at all. If you make the funciton static and define it in the header, you can actually go without inline.
True enough. I assume by "make the function static", you mean
putting it in an anonymous namespace. I knew this but I hadn't made
the connection with avoiding inline. So, can we conclude (on the
assumption that our compiler is 'good') that inline is never
essential?

Generally "inline" is only essential as a means of allowing a function definition to occur more than once in a program, for example, when a function is defined at namespace scope in a header.

Right, and that's exactly what you need to do if you want your

function to be inlined in every translation unit where it's called.

Cheers,
Buster.

[Rolf Magnus]

Buster wrote:

If not, the compiler simply has no chance to inline
it at all. If you make the funciton static and define it in the
header, you can actually go without inline.
True enough. I assume by "make the function static", you mean
putting it in an anonymous namespace.

I actually meant declaring it as 'static', but an anonymous namespace
will be ok, too. The point is that you need to make sure the linker
won't get into trouble if the function is defined multiple times.
I knew this but I hadn't made the connection with avoiding inline. So,
can we conclude (on the assumption that our compiler is 'good') that
inline is never essential?

Inline is only a hint anyway. The compiler is free to not inline
functions that are declared 'inline' or to inline functions you didn't
delcare so. But on some compilers the potential for the function to be
inlined is higher if you declare them as 'inline'. So if you want them
inlined, you should still say so.
Also, inline will make sure that multiple definitions of the function
don't make trouble. You can also do that with static or an anonymous
namespace, but it is still a different. In places where your function
is not inlineed, a non-inline version of that function is needed. When
declared 'inline', only one non-inline version exists for the whole
program (dunno if the standard says that, but on typical
implementations , it's the case), while static or anonymous namespace
will be decided on a per translation unit basis, and so the program
might contain the non-inline version several times.

[Karl Heinz Buchegger]

Rolf Magnus wrote:

Pierre Maurette wrote:

"Karl Heinz Buchegger" <kb******@gasca d.at> a écrit ...
[...]

double square( double x )
{
return x * x;
}

inline double square( double x )
{
return x * x;
}

And so on. No?

Why would we want to convert integers or floats into doubles and later
back?

template<typena me T>
inline T square(T x)
{
return x * x;
}

Because if the OP asks a question like this you can bet your
ass that he has not heared of templates up to now. Why confuse
him with concepts that are way beyond his head? Let him manage
functions first and until he gets more fluent in C++ introduce him
to templates.

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

[Karl Heinz Buchegger]

Pierre Maurette wrote:

"Karl Heinz Buchegger" <kb******@gasca d.at> a écrit ...
[...]

double square( double x )
{
return x * x;
}

inline double square( double x )
{
return x * x;
}

And so on. No?

Yes, sure.
But given the OP's current level of knowledge I didn't want
to introduce things that could confuse him :-)

Let him learn how to write functions, let him write some
programs wich use functions and then show him how he could
squeeze out a few nano seconds of his code.

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