Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #83398 > unrolled thread

Re: Decimals and other numbers

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Decimals and other numbers Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-08 19:02 -0800
    Re: Decimals and other numbers Marko Rauhamaa <marko@pacujo.net> - 2015-01-09 09:28 +0200
      Re: Decimals and other numbers Chris Angelico <rosuav@gmail.com> - 2015-01-09 18:37 +1100
        Re: Decimals and other numbers Marko Rauhamaa <marko@pacujo.net> - 2015-01-09 11:31 +0200
      Re: Decimals and other numbers Dave Angel <davea@davea.name> - 2015-01-09 02:49 -0500
      Re: Decimals and other numbers Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-09 00:51 -0800
        Re: Decimals and other numbers Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-01-09 11:07 +0200
          [OT] x**y == y**x Peter Pearson <pkpearson@nowhere.invalid> - 2015-01-09 17:46 +0000
            Re: [OT] x**y == y**x Marko Rauhamaa <marko@pacujo.net> - 2015-01-09 23:41 +0200
              Re: [OT] x**y == y**x Peter Pearson <pkpearson@nowhere.invalid> - 2015-01-10 16:57 +0000
    Re: Decimals and other numbers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-09 19:49 +1100
      Re: Decimals and other numbers Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-09 00:58 -0800
        Re: Decimals and other numbers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-09 21:20 +1100
          Re: Decimals and other numbers Chris Angelico <rosuav@gmail.com> - 2015-01-09 21:39 +1100
            Re: Decimals and other numbers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-09 23:24 +1100
              Re: Decimals and other numbers Chris Angelico <rosuav@gmail.com> - 2015-01-09 23:34 +1100
          Re: Decimals and other numbers Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-09 17:25 -0800
          Re: Decimals and other numbers Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-10 16:08 +1300
      Re: Decimals and other numbers Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-09 01:11 -0800
      Re: Decimals and other numbers Marko Rauhamaa <marko@pacujo.net> - 2015-01-09 11:34 +0200
        Re: Decimals and other numbers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-09 22:03 +1100
      Re: Decimals and other numbers Marko Rauhamaa <marko@pacujo.net> - 2015-01-09 11:44 +0200
      Re: Decimals and other numbers Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-10 16:05 +1300
        Re: Decimals and other numbers Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-09 19:57 -0800

Page 2 of 2 — ← Prev page 1 [2]

#83426

Marko Rauhamaa wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> 
>> 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 cat walk
models. I was referring to mathematicians.

Mathematicians with a pragmatic bent. Or to put it another way, the
intersection between the set of pragmatic people and the set of
mathematicians.




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#83421

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> 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 would
be riddled with if/else branches.

That's the whole point of silly "no-op" definitions such as a+0 or b**1;
they make mathematical proofs much more concise and feasible. It is
precious to be able to have such "ideal" cases defined, and you'd like
to do it everywhere. Unfortunately, it is not possible everywhere so you
just have to supply the necessary if/else branches in your proof.


Marko

[toc] | [prev] | [next] | [standalone]

#83485

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 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
is 0, regardless of the value of x.

 > 5**4 = 5*5*5*5 = 625

No:

5**4 = 1*5*5*5*5
5**3 = 1*5*5*5
5**2 = 1*5*5
5**1 = 1*5
5**0 = 1

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#83490

On Fri, Jan 9, 2015 at 7:05 PM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> 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
> is 0, regardless of the value of x.
>
>> 5**4 = 5*5*5*5 = 625
>
> No:
>
> 5**4 = 1*5*5*5*5
> 5**3 = 1*5*5*5
> 5**2 = 1*5*5
> 5**1 = 1*5
> 5**0 = 1

I never liked that, it seemed too arbitrary. How about this explanation:

Assume that we know how to multiply a nonempty list numbers. so
product([a]) == a, product([a, b]) = a * b, and so on.

def product(nums):
    if len(nums) == 0:
        return ???
    return reduce(operator.mul, nums)

It should be the case that given a list of factors A and B,
product(A + B) == product(A) * product(B)   (associativity).
We should let this rule apply even if A or B is the empty list,
otherwise our rules are kind of stupid.

Therefore, product([] + X) == product([]) * product(X)
But since [] + X == X, product([] + X) == product(X)

There's only one number like that: product([]) == 1

(Of course if you choose not to have the full associativity rule for
empty products, then anything is possible.)

-- Devin

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web