Re: built-in pow() vs. math.pow()

[2QdxY4RzWzUUiLuE]

On 2023-04-01 at 08:16:46 -0700,
Andreas Eisele  wrote:

> BTW, there is another difference: built-in pow() deals with complex
> arguments, while functions in math won't accept them at all.

See also .
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: built-in pow() vs. math.pow()

[Andreas Eisele]

Andreas Eisele schrieb am Donnerstag, 30. März 2023 um 11:16:02 UTC+2:
> I sometimes make use of the fact that the built-in pow() function has an 
> optional third argument for modulo calculation, which is handy when dealing 
> with tasks from number theory, very large numbers, problems from Project 
> Euler, etc. I was unpleasantly surprised that math.pow() does not have this 
> feature, hence "from math import *" overwrites the built-in pow() function 
> with a function that lacks functionality. I am wondering for the rationale of 
> this. Does math.pow() do anything that the built-in version can not do, and 
> if not, why is it even there? 
> Thanks in advance for any enlightening comment on this. 
> Best regards, Andreas

Thanks a lot to all of you for the insightful replies! 
I now understand why math.pow() behaves the way it does and whoever tells me I 
should have read the doc of the math module before using it is 100% on point. 
BTW, there is another difference: built-in pow() deals with complex arguments, 
while functions in math won't accept them at all.
I also agree with the warning that importing * from any module is generally a 
bad idea, and I normally would not do it.  But here I had written a little tool 
that evaluates an expression given on the command line, and in this case having 
math functions available without further ado is very convenient, so it seemed 
appropriate to make an exeption to this rule.
I ended up assigning the built-in pow function to a different name before 
importing the math module, which is a good way to keep both variants accessible.
Best regards, and thanks again, Andreas
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: built-in pow() vs. math.pow()

[Oscar Benjamin]

On Fri, 31 Mar 2023 at 20:24, Peter J. Holzer  wrote:
>
> On 2023-03-31 07:39:25 +0100, Barry wrote:
> > On 30 Mar 2023, at 22:30, Chris Angelico  wrote:
> > > It's called math.pow. That on its own should be a strong indication
> > > that it's designed to work with floats.
> >
> > So long as you know that the math module is provided to give access
> > the C math.h functions.
> >
>
> Well, that's the first line in the docs:
>
> | This module provides access to the mathematical functions defined by
> | the C standard.
>
> Of course a Python programmer may not necessarily know what mathematical
> functions the C standard defines or even what C is.

Or they might know that and might also realise that it is not really
an accurate description of Python's math module e.g. math.factorial,
math.gcd, math.isqrt which are all integer functions. How many of
these 60 names are defined by the C standard:

In [6]: dir(math)
Out[6]:
['__doc__',
 '__loader__',
 '__name__',
 '__package__',
 '__spec__',
 'acos',
 'acosh',
 'asin',
 'asinh',
 'atan',
 'atan2',
 'atanh',
 'ceil',
 'comb',
 'copysign',
 'cos',
 'cosh',
 'degrees',
 'dist',
 'e',
 'erf',
 'erfc',
 'exp',
 'expm1',
 'fabs',
 'factorial',
 'floor',
 'fmod',
 'frexp',
 'fsum',
 'gamma',
 'gcd',
 'hypot',
 'inf',
 'isclose',
 'isfinite',
 'isinf',
 'isnan',
 'isqrt',
 'ldexp',
 'lgamma',
 'log',
 'log10',
 'log1p',
 'log2',
 'modf',
 'nan',
 'perm',
 'pi',
 'pow',
 'prod',
 'radians',
 'remainder',
 'sin',
 'sinh',
 'sqrt',
 'tan',
 'tanh',
 'tau',
 'trunc']

--
Oscar
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: built-in pow() vs. math.pow()

[Peter J. Holzer]

On 2023-03-31 07:39:25 +0100, Barry wrote:
> On 30 Mar 2023, at 22:30, Chris Angelico  wrote:
> > It's called math.pow. That on its own should be a strong indication
> > that it's designed to work with floats.
> 
> So long as you know that the math module is provided to give access
> the C math.h functions.
> 

Well, that's the first line in the docs:

| This module provides access to the mathematical functions defined by
| the C standard.

Of course a Python programmer may not necessarily know what mathematical
functions the C standard defines or even what C is.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: built-in pow() vs. math.pow()

[Barry]

> On 30 Mar 2023, at 22:30, Chris Angelico  wrote:
> 
> On Fri, 31 Mar 2023 at 08:13, Oscar Benjamin  
> wrote:
>> 
>>> On Thu, 30 Mar 2023 at 17:31, Andreas Eisele  
>>> wrote:
>>> 
>>> I sometimes make use of the fact that the built-in pow() function has an 
>>> optional third argument for modulo calculation, which is handy when dealing 
>>> with tasks from number theory, very large numbers, problems from Project 
>>> Euler, etc. I was unpleasantly surprised that math.pow() does not have this 
>>> feature, hence "from math import *" overwrites the built-in pow() function 
>>> with a function that lacks functionality. I am wondering for the rationale 
>>> of this. Does math.pow() do anything that the built-in version can not do, 
>>> and if not, why is it even there?
>> 
>> It is useful for when you want the pure floating point power which has
>> an approximately fixed computational cost (unlike integer powers).
>> Perhaps it would have been better if it was named fpow similar to fsum
>> vs sum.
>> 
> 
> It's called math.pow. That on its own should be a strong indication
> that it's designed to work with floats.

So long as you know that the math module is provided to give access the C 
math.h functions.

Barry

> 
> ChrisA
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: built-in pow() vs. math.pow()

[Chris Angelico]

On Fri, 31 Mar 2023 at 08:13, Oscar Benjamin  wrote:
>
> On Thu, 30 Mar 2023 at 17:31, Andreas Eisele  wrote:
> >
> > I sometimes make use of the fact that the built-in pow() function has an 
> > optional third argument for modulo calculation, which is handy when dealing 
> > with tasks from number theory, very large numbers, problems from Project 
> > Euler, etc. I was unpleasantly surprised that math.pow() does not have this 
> > feature, hence "from math import *" overwrites the built-in pow() function 
> > with a function that lacks functionality. I am wondering for the rationale 
> > of this. Does math.pow() do anything that the built-in version can not do, 
> > and if not, why is it even there?
>
> It is useful for when you want the pure floating point power which has
> an approximately fixed computational cost (unlike integer powers).
> Perhaps it would have been better if it was named fpow similar to fsum
> vs sum.
>

It's called math.pow. That on its own should be a strong indication
that it's designed to work with floats.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: built-in pow() vs. math.pow()

[Oscar Benjamin]

On Thu, 30 Mar 2023 at 17:31, Andreas Eisele  wrote:
>
> I sometimes make use of the fact that the built-in pow() function has an 
> optional third argument for modulo calculation, which is handy when dealing 
> with tasks from number theory, very large numbers, problems from Project 
> Euler, etc. I was unpleasantly surprised that math.pow() does not have this 
> feature, hence "from math import *" overwrites the built-in pow() function 
> with a function that lacks functionality. I am wondering for the rationale of 
> this. Does math.pow() do anything that the built-in version can not do, and 
> if not, why is it even there?

It is useful for when you want the pure floating point power which has
an approximately fixed computational cost (unlike integer powers).
Perhaps it would have been better if it was named fpow similar to fsum
vs sum.

--
Oscar
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: built-in pow() vs. math.pow()

[avi.e.gross]

Some questions are more reasonable than others.

If the version of a function used in a package were IDENTICAL to the
built-in, then why have it?

There are many possible reasons a package may tune a function for their own
preferences or re-use a name that ends up blocking the view of another name.

The bottom line is if you do not want the other one, then don't ask for it
by not importing the entire module into your namespace or by explicitly
asking for the base function in the ways python provides.

Others have replied about differences in various implementations of pow()
and reiterated my point above that if you want a specific function instance,
it is your responsibility to make sure you get it.

One method I would mention that I have not seen is to copy pow() to your own
name before importing other things. Something like:

pow3 = pow
import ...

Then use the new name.

Or import all of math (despite advice not to) and then make pow3 a synonym
for the base version.

Most people most of the time will want a small and fast function that does
what they asked for and does not waste time looking for an optional third
argument and doing something additional. Would you be satisfied if
math::pow() simply checked for a third argument and turned around and called
base::pow() to handle it?

A deeper question I can appreciate is wondering if it is a bug or feature
that python (and many other languages) allow results where you can hide a
variable or function name. I call it a feature. As with all such variables,
scope rules and other such things apply and make the language powerful and
sometimes a tad dangerous.



-Original Message-
From: Python-list  On
Behalf Of Andreas Eisele
Sent: Thursday, March 30, 2023 5:16 AM
To: python-list@python.org
Subject: built-in pow() vs. math.pow()

I sometimes make use of the fact that the built-in pow() function has an
optional third argument for modulo calculation, which is handy when dealing
with tasks from number theory, very large numbers, problems from Project
Euler, etc. I was unpleasantly surprised that math.pow() does not have this
feature, hence "from math import *" overwrites the built-in pow() function
with a function that lacks functionality. I am wondering for the rationale
of this. Does math.pow() do anything that the built-in version can not do,
and if not, why is it even there?
Thanks in advance for any enlightening comment on this.
Best regards, Andreas
-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: built-in pow() vs. math.pow()

[Dennis Lee Bieber]

On Thu, 30 Mar 2023 19:22:53 +0200, Roel Schroeven 
declaimed the following:

>Either import the things you need explicitly: "from math import sin, 
>cos, exp" (for example).
>Or a plain import: "import math" combined with "math.sin", "math.cos".
>Or use an abbreviation: "import math as m" combined with "m.sin", "m.cos".

Or, for this particular example of not wanting math.pow...

>>> from math import *
>>> pow(3, 4)
81.0
>>> del pow
>>> pow(3, 4)
81
>>> 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: built-in pow() vs. math.pow()

[Grant Edwards]

On 2023-03-30, Thomas Passin  wrote:
> On 3/30/2023 5:15 AM, Andreas Eisele wrote:

>> [...] I was unpleasantly surprised that math.pow() does not have
>> this feature, hence "from math import *" overwrites the built-in
>> pow() function with a function that lacks functionality. [...]
>
> Not an answer to your question, but it's better not to use "import *".
> It's usually better to import just the names you actually need.

Or to imporot math and then use math.pow().

Unfortunately, the official Python documentation always seems to
assume you do "from  import *". I think that leads people to
believe it's a good practice when, in fact, it's a frequent source of
trouble as the OP found out.

-- 
Grant


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: built-in pow() vs. math.pow()

[Thomas Passin]

On 3/30/2023 5:15 AM, Andreas Eisele wrote:

I sometimes make use of the fact that the built-in pow() function has an optional third 
argument for modulo calculation, which is handy when dealing with tasks from number 
theory, very large numbers, problems from Project Euler, etc. I was unpleasantly 
surprised that math.pow() does not have this feature, hence "from math import 
*" overwrites the built-in pow() function with a function that lacks functionality. 
I am wondering for the rationale of this. Does math.pow() do anything that the built-in 
version can not do, and if not, why is it even there?


Not an answer to your question, but it's better not to use "import *". 
It's usually better to import just the names you actually need.


--
https://mail.python.org/mailman/listinfo/python-list

Re: built-in pow() vs. math.pow()

[Roel Schroeven]

Andreas Eisele schreef op 30/03/2023 om 11:15:

I sometimes make use of the fact that the built-in pow() function has an optional third 
argument for modulo calculation, which is handy when dealing with tasks from number 
theory, very large numbers, problems from Project Euler, etc. I was unpleasantly 
surprised that math.pow() does not have this feature, hence "from math import 
*" overwrites the built-in pow() function with a function that lacks functionality. 
I am wondering for the rationale of this. Does math.pow() do anything that the built-in 
version can not do, and if not, why is it even there?
According to the docs, "Unlike the built-in ** operator, math.pow() 
converts both its arguments to type float. Use ** or the built-in pow() 
function for computing exact integer powers." I think that means that 
math.pow() is more meant to work with floats, while the built-in is more 
meant for integers (even though the built-in works with floats just fine).


In any case, I would strongly advocate against "from math import *" (not 
just for math but for any module really). One of the reasons is the 
potential for name conflicts, which is exactly what you experience here.


Either import the things you need explicitly: "from math import sin, 
cos, exp" (for example).

Or a plain import: "import math" combined with "math.sin", "math.cos".
Or use an abbreviation: "import math as m" combined with "m.sin", "m.cos".

--
"There is no cause so noble that it will not attract fuggheads."
-- Larry Niven

--
https://mail.python.org/mailman/listinfo/python-list

Re: built-in pow() vs. math.pow()

[Barry Scott]

> On 30 Mar 2023, at 18:11, Barry Scott  wrote:
> 
> 
> 
>> On 30 Mar 2023, at 10:15, Andreas Eisele  wrote:
>> 
>> I sometimes make use of the fact that the built-in pow() function has an 
>> optional third argument for modulo calculation, which is handy when dealing 
>> with tasks from number theory, very large numbers, problems from Project 
>> Euler, etc. I was unpleasantly surprised that math.pow() does not have this 
>> feature, hence "from math import *" overwrites the built-in pow() function 
>> with a function that lacks functionality. I am wondering for the rationale 
>> of this. Does math.pow() do anything that the built-in version can not do, 
>> and if not, why is it even there?
> 
> Maybe math.pow() aways using IEEE 754(?) float point via the C runtime math 
> routines.
> pow() will give int answer if called with int args.

And the C version of pow only supports 2 arg call.

SYNOPSIS
 #include 

 double
 pow(double x, double y);

 long double
 powl(long double x, long double y);

 float
 powf(float x, float y);


> 
> Barry
> 
> 
>> Thanks in advance for any enlightening comment on this.
>> Best regards, Andreas
>> -- 
>> https://mail.python.org/mailman/listinfo/python-list
>> 
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: built-in pow() vs. math.pow()

[Barry Scott]

> On 30 Mar 2023, at 10:15, Andreas Eisele  wrote:
> 
> I sometimes make use of the fact that the built-in pow() function has an 
> optional third argument for modulo calculation, which is handy when dealing 
> with tasks from number theory, very large numbers, problems from Project 
> Euler, etc. I was unpleasantly surprised that math.pow() does not have this 
> feature, hence "from math import *" overwrites the built-in pow() function 
> with a function that lacks functionality. I am wondering for the rationale of 
> this. Does math.pow() do anything that the built-in version can not do, and 
> if not, why is it even there?

Maybe math.pow() aways using IEEE 754(?) float point via the C runtime math 
routines.
pow() will give int answer if called with int args.

Barry


> Thanks in advance for any enlightening comment on this.
> Best regards, Andreas
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

built-in pow() vs. math.pow()

[Andreas Eisele]

I sometimes make use of the fact that the built-in pow() function has an 
optional third argument for modulo calculation, which is handy when dealing 
with tasks from number theory, very large numbers, problems from Project Euler, 
etc. I was unpleasantly surprised that math.pow() does not have this feature, 
hence "from math import *" overwrites the built-in pow() function with a 
function that lacks functionality. I am wondering for the rationale of this. 
Does math.pow() do anything that the built-in version can not do, and if not, 
why is it even there?
Thanks in advance for any enlightening comment on this.
Best regards, Andreas
-- 
https://mail.python.org/mailman/listinfo/python-list