On Fri, 09 Jan 2015 19:57:20 -0800, Devin Jeanpierre wrote:
> On Fri, Jan 9, 2015 at 7:05 PM, Gregory Ewing
> wrote:
>> It's far from clear what *anything* multiplied by itself zero times
>> should be.
>>
>> A better way of thinking about what x**n for integer n means is this:
>> Start with 1, an
On Fri, Jan 9, 2015 at 7:05 PM, Gregory Ewing
wrote:
> It's far from clear what *anything* multiplied by
> itself zero times should be.
>
> A better way of thinking about what x**n for integer
> n means is this: Start with 1, and multiply it by
> x n times. The result of this is clearly 1 when n
>
Steven D'Aprano wrote:
I'm just sketching an informal proof. If you want to make it vigorous
I think the usual term is "rigorous", unless the mathematician
is taking some kind of stimulant... :-)
--
Greg
--
https://mail.py
Steven D'Aprano wrote:
Arguably, *integer* 0**0 could be zero, on the basis that you can't take
limits of integer-valued quantities, and zero times itself zero times
surely has to be zero.
It's far from clear what *anything* multiplied by
itself zero times should be.
A better way of thinking a
On Fri, Jan 9, 2015 at 2:20 AM, Steven D'Aprano
wrote:
-snip-
> I don't understand what you're trying to say here. You can't just
> arbitrarily declare that 0**1 equals something other than 0 (or for that
> matter, doesn't equal anything at all).
You can, actually. It's just silly. (Similarly, yo
On Fri, Jan 9, 2015 at 11:24 PM, Steven D'Aprano
wrote:
>> 5 * 0 * 0 * 0 * 0 = 0
>
> Where did the 5 come from?
>
> You're effectively saying that 0**0 becomes 5*0**0, then cancelling the 0**0
> because they're all zeroes and so don't matter, leaving 5. And that simply
> doesn't work. If it did wo
I want to emphasis that I'm not really arguing that 0**0 should evaluate as
0. That's probably the least useful thing we can have out of the four
possibilities:
- return 1
- return NAN
- raise an exception
- return 0
But in the spirit of the Devil's Advocate, I mentioned that there was an
argumen
Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> mathematicians with a pragmatic bent
>
> You shouldn't call engineers and scientists mathematicians ("with a
> pragmatic bent"). Rigor is an absolute requirement for any mathematics.
I wasn't referring to engineers, scientists, short-order cooks or
On Fri, Jan 9, 2015 at 9:20 PM, Steven D'Aprano
wrote:
> On the basis that m**n means m multiplied by itself n times:
>
> 5**4 = 5*5*5*5 = 625
>
> that gives us:
>
> 0**0 = zero multiplied by itself zero times.
>
> You can multiply 0 by any number you like, and the answer will always be 0,
> not 1
I think we're in violent agreement here, nevertheless I think you're right
for the wrong reasons. See below...
Devin Jeanpierre wrote:
> On Fri, Jan 9, 2015 at 12:49 AM, Steven D'Aprano
> wrote:
>> Devin Jeanpierre wrote:
>>
>>> On Thu, Jan 8, 2015 at 6:43 PM, Dave Angel wrote:
What you d
Steven D'Aprano :
> Devin Jeanpierre wrote:
> No you can't -- that would make arithmetic inconsistent. 0**1 is
> perfectly well defined as 0 however you look at it:
You *could* leave 0**1 undefined. You *could* leave 7+0 undefined.
However, that would make mathematical proofs more complex as they
Steven D'Aprano :
> mathematicians with a pragmatic bent
You shouldn't call engineers and scientists mathematicians ("with a
pragmatic bent"). Rigor is an absolute requirement for any mathematics.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Chris Angelico :
> I'm not a mathematical expert, so I don't quite 'get' this. How does
> this justify 0**0 being equal to 0.5?
Many operations like this are defined in terms of some very strong
argument of uniqueness. Ultimately, the key point is safety in
mathematical deductions. One minimal re
On Fri, Jan 9, 2015 at 12:58 AM, Devin Jeanpierre
wrote:
>> Arguably, *integer* 0**0 could be zero, on the basis that you can't take
>> limits of integer-valued quantities, and zero times itself zero times
>> surely has to be zero.
I should have responded in more detail here, sorry.
If you aren'
Devin Jeanpierre writes:
[...]
> domain of the natural numbers. Knuth says that thought of
> combinatorially on the naturals, x**y counts the number of mappings
> from a set of x values to a set of y values.
It's the other way around, of course: from a set of y values to a set
of x values.
Whi
On Fri, Jan 9, 2015 at 12:49 AM, Steven D'Aprano
wrote:
> Devin Jeanpierre wrote:
>
>> On Thu, Jan 8, 2015 at 6:43 PM, Dave Angel wrote:
>>> What you don't say is which behavior you actually expected. Since 0**0
>>> is undefined mathematically, I'd expect either an exception or a NAN
>>> result.
Marko, your argument is "this function x**y(a, x) must be continuous
on [0, inf), and to be continuous at 0, 0**0 must be a". Since there
are many possible values of a, this is not a "justification", this is
a proof by contradiction that the premise was faulty: x**y(a, x)
doesn't have to be continu
Devin Jeanpierre wrote:
> On Thu, Jan 8, 2015 at 6:43 PM, Dave Angel wrote:
>> What you don't say is which behavior you actually expected. Since 0**0
>> is undefined mathematically, I'd expect either an exception or a NAN
>> result.
>
> It can be undefined, if you choose for it to be. You can a
On 01/09/2015 02:37 AM, Chris Angelico wrote:
On Fri, Jan 9, 2015 at 6:28 PM, Marko Rauhamaa wrote:
Devin Jeanpierre :
If 0**0 is defined, it must be 1.
You can "justify" any value a within [0, 1]. For example, choose
y(a, x) = log(a, x)
Then,
limy(a, x) = 0
x -> 0+
and
On Fri, Jan 9, 2015 at 6:28 PM, Marko Rauhamaa wrote:
> Devin Jeanpierre :
>
>> If 0**0 is defined, it must be 1.
>
> You can "justify" any value a within [0, 1]. For example, choose
>
>y(a, x) = log(a, x)
>
> Then,
>
> limy(a, x) = 0
>x -> 0+
>
> and:
>
>lim[x -> 0+] x**y(a, x
Devin Jeanpierre :
> If 0**0 is defined, it must be 1.
You can "justify" any value a within [0, 1]. For example, choose
y(a, x) = log(a, x)
Then,
limy(a, x) = 0
x -> 0+
and:
lim[x -> 0+] x**y(a, x) = a
For example,
>>> a = 0.5
>>> x = 1e-100
>>> y = math.log(a, x)
Dave Angel :
> What you don't say is which behavior you actually expected. Since 0**0
> is undefined mathematically, I'd expect either an exception or a NAN
> result.
IEEE 754 mandates that 0**0 should evaluate to 1:
http://en.wikipedia.org/wiki/NaN#Operations_generating_NaN>
The standar
Thanks Ben, with your encouragement I have filed
http://bugs.python.org/issue23201
-- Devin
On Thu, Jan 8, 2015 at 7:03 PM, Ben Finney wrote:
> Dave Angel writes:
>
>> What you don't say is which behavior you actually expected. Since
>> 0**0 is undefined mathematically, I'd expect either an ex
Dave Angel writes:
> What you don't say is which behavior you actually expected. Since
> 0**0 is undefined mathematically, I'd expect either an exception or a
> NAN result.
Do you think that the ‘int’ and ‘float’ types, which do produce a number
result for ‘0 ** 0’, are buggy and should be fixe
On Thu, Jan 8, 2015 at 6:43 PM, Dave Angel wrote:
> What you don't say is which behavior you actually expected. Since 0**0 is
> undefined mathematically, I'd expect either an exception or a NAN result.
It can be undefined, if you choose for it to be. You can also choose
to not define 0**1, of co
On Thu, Jan 8, 2015 at 6:33 PM, Devin Jeanpierre wrote:
> I noticed some very PHP-ish behavior today:
>
import decimal
x = 0
y = float(x)
z = decimal.Decimal(x)
x == y == z == x
> True
x ** x
> 1
y**y
> 1.0
z**z
> Traceback (most recent call last):
> File
On 01/08/2015 09:33 PM, Devin Jeanpierre wrote:
I noticed some very PHP-ish behavior today:
import decimal
x = 0
y = float(x)
z = decimal.Decimal(x)
x == y == z == x
True
x ** x
1
y**y
1.0
z**z
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/decimal
Devin Jeanpierre writes:
> decimal.InvalidOperation: 0 ** 0
>
> I'd file a bug report but I'm anticipating some rational (heh)
> explanation. Any ideas?
First note that it's explicitly documented as an invalid operation
.
So someone has at least thought about it and deliberately decided it
shoul
2008/8/3 CNiall <[EMAIL PROTECTED]>:
> However, with some, but not all, decimals, they do not seem to 'equal
> themselves'.
The golden rule is that working with decimals (in pretty much any
language) is like working with a pile of sand. Almost anything you do
leaves you with less sand and more di
On 3 Aug, 15:02, CNiall <[EMAIL PROTECTED]> wrote:
> However, with some, but not all, decimals, they do not seem to 'equal
> themselves'.
Back in my days studying electrical engineering I was pointed to this
reference about floating point arithmetic -
http://citeseer.ist.psu.edu/goldberg91what.ht
En Tue, 05 Aug 2008 11:50:43 -0300, schinckel <[EMAIL PROTECTED]> escribió:
> I had a class today which dealt with Decimal <-> IEE754 conversion,
> and
> whilst 0.1 was an example that was converted, and a representation was
> generated, no mention was made of the precision issue.
>
> I'm hoping t
On Aug 5, 3:26 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
> En Sun, 03 Aug 2008 19:57:10 -0300, Grant Edwards <[EMAIL PROTECTED]>
> escribi :
>
> > On 2008-08-03, Larry Bates <[EMAIL PROTECTED]> wrote:
>
> >> What are they teaching in computer science classes these days?
>
> > When I was
En Sun, 03 Aug 2008 19:57:10 -0300, Grant Edwards <[EMAIL PROTECTED]>
escribi�:
On 2008-08-03, Larry Bates <[EMAIL PROTECTED]> wrote:
What are they teaching in computer science classes these days?
When I was an undergrad the only courses that dealt with FP
issues were classes on numerica
CNiall wrote:
I am very new to Python (I started learning it just yesterday), but I
have encountered a problem.
I want to make a simple script that calculates the n-th root of a given
number (e.g. 4th root of 625--obviously five, but it's just an example
:P), and because there is no nth-root
On Sun, 03 Aug 2008 17:30:29 -0500, Larry Bates wrote:
>> As you can see, the last two decimals are very slightly inaccurate.
>> However, it appears that when n in 1/n is a power of two, the decimal
>> does not get 'thrown off'. How might I make Python recognise 0.2 as 0.2
>> and not 0.200
On 2008-08-03, Larry Bates <[EMAIL PROTECTED]> wrote:
>> However, it appears that when n in 1/n is a power of two, the decimal
>> does not get 'thrown off'. How might I make Python recognise 0.2 as 0.2
>> and not 0.20001?
>>
>> This discrepancy is very minor, but it makes the whole
On Aug 3, 3:02 pm, CNiall <[EMAIL PROTECTED]> wrote:
> I am very new to Python (I started learning it just yesterday), but I
> have encountered a problem.
>
> I want to make a simple script that calculates the n-th root of a given
> number (e.g. 4th root of 625--obviously five, but it's just an exa
CNiall wrote:
I am very new to Python (I started learning it just yesterday), but I
have encountered a problem.
I want to make a simple script that calculates the n-th root of a given
number (e.g. 4th root of 625--obviously five, but it's just an example
:P), and because there is no nth-root
On Aug 3, 9:02 am, CNiall <[EMAIL PROTECTED]> wrote:
> I am very new to Python (I started learning it just yesterday), but I
> have encountered a problem.
>
> I want to make a simple script that calculates the n-th root of a given
> number (e.g. 4th root of 625--obviously five, but it's just an exa
Jorgen Grahn schrieb:
On Sun, 03 Aug 2008 16:50:22 +0200, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
CNiall schrieb:
...
>>> 0.2
0.20001
...
Welcome to the wonderful world of IEEE754. Just because other languages
shield you from the gory details they still are there. Python ch
On Sun, 03 Aug 2008 16:50:22 +0200, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
> CNiall schrieb:
...
>> >>> 0.2
>> 0.20001
...
> Welcome to the wonderful world of IEEE754. Just because other languages
> shield you from the gory details they still are there. Python chose to
> not do
CNiall schrieb:
I am very new to Python (I started learning it just yesterday), but I
have encountered a problem.
I want to make a simple script that calculates the n-th root of a given
number (e.g. 4th root of 625--obviously five, but it's just an example
:P), and because there is no nth-roo
On 3 aug 2008, at 17.16, [EMAIL PROTECTED] wrote:
for nth square root: use math.sqrt n times for example
Ehum. The OP wants to compute the nth root ( not the nth square root)
import math
num = 625
how_many_sqrt = 2
for i in range(how_many_sqrt):
.. num = math.sqrt(num)
..
num
for nth square root: use math.sqrt n times for example
>>> import math
>>> num = 625
>>> how_many_sqrt = 2
>>> for i in range(how_many_sqrt):
.. num = math.sqrt(num)
..
>>> num
5.0
all comparisons work fine for arbitrary floating point numbers...
For readability print them with required prec
CNiall schrieb:
I am very new to Python (I started learning it just yesterday), but I
have encountered a problem.
I want to make a simple script that calculates the n-th root of a given
number (e.g. 4th root of 625--obviously five, but it's just an example
:P), and because there is no nth-roo
[EMAIL PROTECTED] wrote:
Hello. New to using Python. Python automatically round off watver i
calculate using the floor function. How wud i make the exact value
appear?
Tried out fabs() in the math library but still confused. Cud some1
elaborate on it.
[python]
---help(math.floor):
Help on buil
[EMAIL PROTECTED] wrote:
Hello. New to using Python. Python automatically round off watver i
calculate using the floor function. How wud i make the exact value
appear?
Tried out fabs() in the math library but still confused. Cud some1
elaborate on it.
If you're working with integers, the resul
Tim Roberts wrote:
> DECIMAL is an SQL thing. Unless the language has a native decimal type, it
> cannot possibly know how to display it in the same format as your SQL.
unless your database adapter returns everything as strings...
--
http://mail.python.org/mailman/listinfo/python-list
"Tgone" <[EMAIL PROTECTED]> wrote:
>Sybren Stuvel wrote:
>> Tgone enlightened us with:
>> > Sorry, when I print out the variable it displays as '15.0'. The
>> > price is '15.00' in the database though.
>>
>> That's the same thing, isn't it? 15.0 == 15.0
>
>Yes, they're both mathematically t
Tgone wrote:
> Sybren Stuvel wrote:
>> Tgone enlightened us with:
>> > Sorry, when I print out the variable it displays as '15.0'. The
>> > price is '15.00' in the database though.
>>
>> That's the same thing, isn't it? 15.0 == 15.0
>
> Yes, they're both mathematically the same. I never s
Tgone wrote:
> Sybren Stuvel wrote:
>
>>Tgone enlightened us with:
>>
>>>Sorry, when I print out the variable it displays as '15.0'. The
>>>price is '15.00' in the database though.
>>
>>That's the same thing, isn't it? 15.0 == 15.0
>
>
> Yes, they're both mathematically the same. I never
>> Try string formatting:
>>
>> print '%.2f' % product.price
>>
>
> That works. I expected Python to display the data exactly as it is in
> the database, like most languages.
It depends on what you get back from MySQLdb. Try this:
import decimal
d = decimal.Decimal("3.")
print d
Now tr
Sybren Stuvel wrote:
> Tgone enlightened us with:
> > Sorry, when I print out the variable it displays as '15.0'. The
> > price is '15.00' in the database though.
>
> That's the same thing, isn't it? 15.0 == 15.0
Yes, they're both mathematically the same. I never said they weren't...
> >
Laszlo Nagy wrote:
> Tgone írta:
> > Hello,
> >
> > I have a price column in a MySQL table: price decimal(5,2)
> >
> > When I access them in Python with SQLObject, prices display as 15.0
> > instead of 15.00. Why is this happening? I can't figure out why Python
> > is trimming off the hundredth pla
Tgone írta:
> Hello,
>
> I have a price column in a MySQL table: price decimal(5,2)
>
> When I access them in Python with SQLObject, prices display as 15.0
> instead of 15.00. Why is this happening? I can't figure out why Python
> is trimming off the hundredth place. I'm not doing any formatting...
55 matches
Mail list logo
