Re: How about adding rational fraction to Python?

[Mark Dickinson]

On Mar 12, 7:20 am, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
> But if the answer is incorrect (in the float calculation) the error is
> limited. IEEE 754 prescribes that the error should be at most 1 LSB, IIRC.
> And then the number of errors is the proper measure.

There are two operations here, both of which can introduce error of
up to 0.5 ulp (ulp = unit in the last place).  Moreover, the second
operation (the multiplication) can magnify the error introduced by
the first (the division).

You're correct that for IEEE 754 binary floating-point arithmetic,
(x/y)*y and x will either be equal or differ by exactly 1ulp (except
perhaps in rarely-occurring corner cases).  But for decimal numbers,
(x/y)*y and x could be as much as 5 ulps apart.

Mark


> --
> Piet van Oostrum <[EMAIL PROTECTED]>
> URL:http://pietvanoostrum.com[PGP 8DAE142BE17999C4]
> Private email: [EMAIL PROTECTED]

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

Re: How about adding rational fraction to Python?

[Piet van Oostrum]

> "Gabriel Genellina" <[EMAIL PROTECTED]> (GG) wrote:

>GG> En Tue, 04 Mar 2008 11:46:48 -0200, NickC <[EMAIL PROTECTED]> escribió:
>>> A mildly interesting Py3k experiment:
>>> 
>>> Python 3.0a3+ (py3k:61229, Mar  4 2008, 21:38:15)
>>> [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>> from fractions import Fraction
>> from decimal import Decimal
>> def check_accuracy(num_type, max_val=1000):
>>> ... wrong = 0
>>> ... for x in range(1, max_val):
>>> ... for y in range(1, max_val):
>>> ... wrong += (x / num_type(y)) * y != x
>>> ... return wrong
>>> ...
>> check_accuracy(float)
>>> 101502
>> check_accuracy(Decimal)
>>> 310013
>> check_accuracy(Fraction)
>>> 0
>>> 
>>> 
>>> The conclusions I came to based on running that experiment are:
>>> - Decimal actually appears to suffer more rounding problems than float
>>> for rational arithmetic

>GG> Mmm, but I doubt that counting how many times the results are equal, is  
>GG> the right way to evaluate "accuracy".
>GG> A stopped clock shows the right time twice a day; a clock that loses one  
>GG> minute per day shows the right time once every two years. Clearly the  
>GG> stopped clock is much better!

But if the answer is incorrect (in the float calculation) the error is
limited. IEEE 754 prescribes that the error should be at most 1 LSB, IIRC.
And then the number of errors is the proper measure.
-- 
Piet van Oostrum <[EMAIL PROTECTED]>
URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
Private email: [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Mark Dickinson <[EMAIL PROTECTED]> writes:
> For randomly chosen(*) base B floats x and y, the probability that
> (x/y)*y == x is approximately given by

I remember hearing that IEEE 754 was carefully designed to make this
identity hold as often as possible when y is a small integer.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Mark Dickinson]

On Mar 4, 9:39 am, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> On Mar 4, 8:46 am, NickC <[EMAIL PROTECTED]> wrote:
>
> > The increased number of inaccurate answers with Decimal (31% vs 10%)
> > is probably due to the fact that it is actually more precise than
> > float
>
> I suspect it has more to do with the fact that 10 is bigger than 2,
> though I'm not sure I could precisely articulate the reasons why
> this matters.

Indeed, a quick lunchtime back-of-the-envelope calculation suggests
that precision is largely irrelevant:  it's the base that matters.
For randomly chosen(*) base B floats x and y, the probability that
(x/y)*y == x is approximately given by

1/2 + 1/log(B) - 1/log(B)**2 + 1/B/log(B)**2

For Decimal, this gives a probability of:

>>> 0.5 + 1/log(10) - 1/log(10)**2 + 1/10/log(10)**2
0.76454395459279922

while for randomly chosen floats it's the same thing with all 10s
replaced by 2s:

>>> 0.5 + 1/log(2) - 1/log(2)**2 + 1/2/log(2)**2
0.90201055038615952

(*) Here, randomly chosen means I'm assuming that log(x) and log(y)
are independent and uniformly distributed over some largish
interval.  Maybe not the most obvious definition of random, but
not unreasonable. (And it makes the analysis easier!)

A quick check, for floats:

#
from __future__ import division
from random import random
from math import exp

def random_float():
return exp(random()*400.-200.)

def test():
x = random_float()
y = random_float()
return (x/y)*y == x

print sum(test() for i in xrange(10**8))/10**8
#

produces (eventually):

0.90199129

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Gabriel Genellina]

En Tue, 04 Mar 2008 11:46:48 -0200, NickC <[EMAIL PROTECTED]> escribi�:

> A mildly interesting Py3k experiment:
>
> Python 3.0a3+ (py3k:61229, Mar  4 2008, 21:38:15)
> [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 from fractions import Fraction
 from decimal import Decimal
 def check_accuracy(num_type, max_val=1000):
> ... wrong = 0
> ... for x in range(1, max_val):
> ... for y in range(1, max_val):
> ... wrong += (x / num_type(y)) * y != x
> ... return wrong
> ...
 check_accuracy(float)
> 101502
 check_accuracy(Decimal)
> 310013
 check_accuracy(Fraction)
> 0
>
>
> The conclusions I came to based on running that experiment are:
> - Decimal actually appears to suffer more rounding problems than float
> for rational arithmetic

Mmm, but I doubt that counting how many times the results are equal, is  
the right way to evaluate "accuracy".
A stopped clock shows the right time twice a day; a clock that loses one  
minute per day shows the right time once every two years. Clearly the  
stopped clock is much better!
http://mybanyantree.wordpress.com/category/lewis-carrol/

-- 
Gabriel Genellina

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

Re: How about adding rational fraction to Python?

[Mark Dickinson]

On Mar 4, 8:46 am, NickC <[EMAIL PROTECTED]> wrote:
> The increased number of inaccurate answers with Decimal (31% vs 10%)
> is probably due to the fact that it is actually more precise than
> float

I suspect it has more to do with the fact that 10 is bigger than 2,
though I'm not sure I could precisely articulate the reasons why
this matters.  (A bigger base means a bigger 'wobble', the wobble
being the variation in the relationship between an error of 1ulp and
a relative error of base**-precision.)

Rerunning your example after a

getcontext().prec = 16

(i.e. with precision comparable to that of float) gives

>>> check_accuracy(Decimal)
310176

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[NickC]

On Mar 4, 7:11 am, Lie <[EMAIL PROTECTED]> wrote:
> On Mar 2, 11:36 pm, Paul Rubin  wrote:
> > > > Try with a=7, b=25
>
> > > They should still compare true, but they don't. The reason why they
> > > don't is because of float's finite precision, which is not exactly
> > > what we're talking here since it doesn't change the fact that
> > > multiplication and division are inverse of each other.
>
> > What?  Obviously they are not exact inverses for floats, as that test
> > shows.  They would be inverses for mathematical reals or rationals,
> > but Python does not have those.
>
> When I said multiplication and division are inverse, I was pointing
> out the fact that even though float's inexactness make them imperfect
> inverse, mult & div are still inverse of each other. In-practice, the
> inversing behavior is impossible unless we have a way to represent
> real number (which we don't), and the *workaround* to make them work
> is to do epsilon comparison.

A mildly interesting Py3k experiment:

Python 3.0a3+ (py3k:61229, Mar  4 2008, 21:38:15)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from fractions import Fraction
>>> from decimal import Decimal
>>> def check_accuracy(num_type, max_val=1000):
... wrong = 0
... for x in range(1, max_val):
... for y in range(1, max_val):
... wrong += (x / num_type(y)) * y != x
... return wrong
...
>>> check_accuracy(float)
101502
>>> check_accuracy(Decimal)
310013
>>> check_accuracy(Fraction)
0


The conclusions I came to based on running that experiment are:
- Decimal actually appears to suffer more rounding problems than float
for rational arithmetic
- Decimal appears to be significantly slower than Fraction for small
denominator rational arithmetic
- both Decimal and Fraction are significantly slower than builtin
floats

The increased number of inaccurate answers with Decimal (31% vs 10%)
is probably due to the fact that it is actually more precise than
float - for the builtin floats, the rounding error in the division
step may be cancelled out by a further rounding error in the
multiplication step (this can be seen happening in the case of ((1 /
3.0) * 3) == 1.0, where the result of the multiplication ends up being
1.0 despite the rounding error on division, due to the next smallest
floating value being 0.99989).

The speed difference between Decimal and Fraction is likely due to the
fact that Fraction can avoid actually doing any division most of the
time - it does addition and multiplication instead. The main reason
behind the overall speed advantage of builtin floats should hopefully
be obvious ;)

Regardless, the result of integer division is going to be a binary
floating point value in Py3k. For cases where that isn't adequate or
acceptable, the application should really be tightly controlling its
numeric types anyway and probably using a high performance math
library like numpy or gmpy instead of the standard numeric types (as
others have already noted in this thread).


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

Re: How about adding rational fraction to Python?

[Lie]

On Mar 2, 11:36 pm, Paul Rubin  wrote:
> Lie <[EMAIL PROTECTED]> writes:
> > You hit the right note, but what I meant is the numeric type
> > unification would make it _appear_ to consist of a single numeric type
> > (yeah, I know it isn't actually, but what appears from outside isn't
> > always what's inside).
>
> That is clearly not intended; floats and decimals and integers are
> really different from each other and Python has to treat them distinctly.

In certain operations it would, such as:
a = Decimal('32.324')
b = 90.3453
c = 43
d = a + b + c   <<< this should work without manual type casting

This behavior is what is intended in numeric type unification, floats
and decimals and integers should work together flawlessly without the
need for manual type casting. This gives the _impression_ of a single
numeric type (although programmers should still be aware that the
underlying type still exists). It's true Python have to treat them
differently, but programmers would be able to treat them all the same
(at least in most parts)

> > > Try with a=7, b=25
>
> > They should still compare true, but they don't. The reason why they
> > don't is because of float's finite precision, which is not exactly
> > what we're talking here since it doesn't change the fact that
> > multiplication and division are inverse of each other.
>
> What?  Obviously they are not exact inverses for floats, as that test
> shows.  They would be inverses for mathematical reals or rationals,
> but Python does not have those.

When I said multiplication and division are inverse, I was pointing
out the fact that even though float's inexactness make them imperfect
inverse, mult & div are still inverse of each other. In-practice, the
inversing behavior is impossible unless we have a way to represent
real number (which we don't), and the *workaround* to make them work
is to do epsilon comparison.

When I'm talking about things I usually talk in purely theoretical
condition first and considers practical implementations that doesn't
work that way as making up a workaround inside their limitations. In
this case, the theoretical condition is that multiplication and
division is inverse of each other. The practical consideration is
float is inexact and reals is impossible, and thus epsilon comparison
is necessary to walk around float's limitations so multiplication and
division could still be inverses.

Aside: Python would have rationals

> > One way to handle this situation is to do an epsilon aware
> > comparison (as should be done with any comparison involving floats),
> > but I don't do it cause my intention is to clarify the real problem
> > that multiplication is indeed inverse of division and I want to
> > avoid obscuring that with the epsilon comparison.
>
> I think you are a bit confused.  That epsilon aware comparison thing
> acknowledges that floats only approximate the behavior of mathematical
> reals.  

Yes, I realized that floats aren't the same as reals.

> When we do float arithmetic, we accept that "equal" often
> really only means "approximately equal".  But when we do integer
> arithmetic, we do not expect or accept equality as being approximate.
> Integer equality means equal, not approximately equal.  That is why
> int and float arithmetic cannot work the same way.

No, no, they don't work the same way, but they should appear to work
the same way as reals in pure mathematics do. Again, I'm talking in
theory first: ints and floats should work the same way, but since
practical considerations make them impossible, then they should at
least appear to work the same way (or they would have become
completely different things, remember duck typing?).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Arnaud Delobelle]

On Mar 3, 4:39 pm, Paul Rubin  wrote:
[...]
> You are right, C is even worse than I remembered.

It's good enough to be the language used for the reference
implementation of python :-)

[...]
--
Arnaud

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

Re: How about adding rational fraction to Python?

[Paul Rubin]

Jeff Schwab <[EMAIL PROTECTED]> writes:
> > User defined types in python are fairly heavyweight compared with the
> > built-in types,
> 
> Yet they continue to form the basis of almost all non-trivial Python
> programs.  Anyway, it's a bit soon to be optimizing. :)

Large python programs usually have some classes for complex data
structures, but it's not typical Pythonic practice to define new
classes for things as small as integers.

> > and a type like that is just another thing for the user to have to
> > remember.
> 
> How so?  A well-written function generally shouldn't depending on the
> exact types of its arguments, anyway.  

By "another thing to remember" I mean doing the right thing should
happen with the normal integers that result from writing literals like
1 and 2, without resorting to a nonstandard user defined type.  

> If someone has written a
> function to find (e.g.) the median of a collection of numbers, their
> code should already be prepared to accept values of user-defined
> numeric types.

It's important to be able to write such generic or polymorphic
functions, but most typical functions are monomorphic.

> If I want to call such a function with my hand-rolled
> DivisionSafeInteger type, it should just work,

Sure, however, the Pythonic approach is to make the defaults do the
right thing without requiring such user-written workarounds.  Of course
there is occasional unclarity about what the right thing is.

> > file) and size_t, so if you pass an off_t to a function that expects a
> > size_t as that arg, the compiler notices the error.
> 
> On what compiler?  I've never seen a C compiler that would mind any
> kind of calculation involving two native, unsigned types.

You are right, C is even worse than I remembered.

> > But they are
> > really just integers and they compile with no runtime overhead.
> 
> They do indeed have run-time overhead, as opposed to (e.g.) meta-types
> whose operations are performed at compile-time. 

Not sure what you mean; by "no runtime overhead" I just mean they
compile to the same code as regular ints, no runtime checks.  OK, it
turns out that for all intents and purposes it looks like they ARE
regular ints even at compile time, but in other languages it's not
like that.

> If you mean they have less overhead than types whose operations
> perform run-time checks, then yes, of course that's true.  You
> specifically stated (then snipped) that you "would be happier if
> int/int always threw an error."  The beauty of a language with such
> extensive support for user-defined types that can be used like
> built-in type is that you are free to define types that meet your
> needs. 

But those are not ints then.  We're discussing an issue of language
design, which is what the behavior of the ordinary, standard, default
ints should be.  My reason for suggesting int/int->error is that I
think it would increase program reliability in general.  But that is
only if it applies to all the ints by default, with int/int=float
being a possible result of a nonstandard user-defined type.  From the
zen list: "In the face of ambiguity, refuse the temptation to guess."

> My understanding is that Python will easily support lots of different
> types of just about anything.  That's the point.

No I don't think so.  Also from the zen list: "There should be one--
and preferably only one --obvious way to do it."

> > There's an interesting talk linked from LTU about future languages:
> >   http://lambda-the-ultimate.org/node/1277
> 
> Thanks, but that just seems to have links to the slides.  Is there a
> written article, or a video of Mr. Sweeney's talk?

I don't think there's an article.  There might be video somewhere.  I
thought the slides were enough to get the ideas across so I didn't
have much interest in sitting through a video.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Jeff Schwab]

Paul Rubin wrote:
> Jeff Schwab <[EMAIL PROTECTED]> writes:
>> Better yet, how hard would it be to define an otherwise int-like type
>> that did not define a non-flooring division operator?  Are there any
>> real use cases for such a type?
> 
> User defined types in python are fairly heavyweight compared with the
> built-in types,

Yet they continue to form the basis of almost all non-trivial Python 
programs.  Anyway, it's a bit soon to be optimizing. :)


> and a type like that is just another thing for the
> user to have to remember.

How so?  A well-written function generally shouldn't depending on the 
exact types of its arguments, anyway.  If someone has written a function 
to find (e.g.) the median of a collection of numbers, their code should 
already be prepared to accept values of user-defined numeric types.  If 
I want to call such a function with my hand-rolled DivisionSafeInteger 
type, it should just work, unless specifically documented to work only 
with a particular subset of Python data types.


> The C library has a bunch of different types like off_t (offset in a

off_t is vendor-specific extension, not part of the standard C library. 
  In gcc, it's a typedef for __off_t, which is a macro for _G_off_t, 
which is in turn a macro for a compiler-specific type called _IO_off_t. 
  Elsewhere, it may just be a typedef of long int.


> file) and size_t, so if you pass an off_t to a function that expects a
> size_t as that arg, the compiler notices the error.

On what compiler?  I've never seen a C compiler that would mind any kind 
of calculation involving two native, unsigned types.

 $ cat main.c
 #include 
 int main() { off_t ot = 0; long li = 3L; ot = li; }
 $ make
 cc -ansi -pedantic -Wall -std=c99main.c   -o main
 $


> But they are
> really just integers and they compile with no runtime overhead.

They do indeed have run-time overhead, as opposed to (e.g.) meta-types 
whose operations are performed at compile-time.  If you mean they have 
less overhead than types whose operations perform run-time checks, then 
yes, of course that's true.  You specifically stated (then snipped) that 
you "would be happier if int/int always threw an error."  The beauty of 
a language with such extensive support for user-defined types that can 
be used like built-in type is that you are free to define types that 
meet your needs.  The weight of such hand-rolled solutions may lead to 
performance problems at first, but C-linkable extensions go a long way 
to help; hence numpy et al.


> So, I think Python won't easily support lots of different types of
> integers, and we've got what we've got.

My understanding is that Python will easily support lots of different 
types of just about anything.  That's the point.  In theory at least, it 
supports programming in a way that lets the translator (compiler + 
interpreter) keep track of the exact types being used, so that the 
programmer doesn't have to.  The fact that the tracking is done 
dynamically, rather than statically, is a fundamental design decision 
that was made early in the language's development.


> There's an interesting talk linked from LTU about future languages:
> 
>   http://lambda-the-ultimate.org/node/1277

Thanks, but that just seems to have links to the slides.  Is there a 
written article, or a video of Mr. Sweeney's talk?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Jeff Schwab <[EMAIL PROTECTED]> writes:
> Better yet, how hard would it be to define an otherwise int-like type
> that did not define a non-flooring division operator?  Are there any
> real use cases for such a type?

User defined types in python are fairly heavyweight compared with the
built-in types, and a type like that is just another thing for the
user to have to remember.

The C library has a bunch of different types like off_t (offset in a
file) and size_t, so if you pass an off_t to a function that expects a
size_t as that arg, the compiler notices the error.  But they are
really just integers and they compile with no runtime overhead.

So, I think Python won't easily support lots of different types of
integers, and we've got what we've got.  

There's an interesting talk linked from LTU about future languages:

  http://lambda-the-ultimate.org/node/1277
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Jeff Schwab]

Paul Rubin wrote:
> I can live with int/int=float but
> find it sloppy and would be happier if int/int always threw an error
> (convert explicitly if you want a particular type result).

Better yet, how hard would it be to define an otherwise int-like type 
that did not define a non-flooring division operator?  Are there any 
real use cases for such a type?  Maybe a division operator could be 
defined to perform a run-time check that, for an operation n/d==q, 
n==q*d; else, throw an exception.  Code written to support duck-typed 
integers should work with such a UDT "out of the box."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Lie <[EMAIL PROTECTED]> writes:
> You hit the right note, but what I meant is the numeric type
> unification would make it _appear_ to consist of a single numeric type
> (yeah, I know it isn't actually, but what appears from outside isn't
> always what's inside).

That is clearly not intended; floats and decimals and integers are
really different from each other and Python has to treat them distinctly.

> > Try with a=7, b=25
> 
> They should still compare true, but they don't. The reason why they
> don't is because of float's finite precision, which is not exactly
> what we're talking here since it doesn't change the fact that
> multiplication and division are inverse of each other.

What?  Obviously they are not exact inverses for floats, as that test
shows.  They would be inverses for mathematical reals or rationals,
but Python does not have those.

> One way to handle this situation is to do an epsilon aware
> comparison (as should be done with any comparison involving floats),
> but I don't do it cause my intention is to clarify the real problem
> that multiplication is indeed inverse of division and I want to
> avoid obscuring that with the epsilon comparison.

I think you are a bit confused.  That epsilon aware comparison thing
acknowledges that floats only approximate the behavior of mathematical
reals.  When we do float arithmetic, we accept that "equal" often
really only means "approximately equal".  But when we do integer
arithmetic, we do not expect or accept equality as being approximate.
Integer equality means equal, not approximately equal.  That is why
int and float arithmetic cannot work the same way.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Lie]

On Mar 2, 10:02 pm, Paul Rubin  wrote:
> Lie <[EMAIL PROTECTED]> writes:
> > Anyway, I don't think Python should
> > work that way, because Python have a plan for numerical integration
> > which would unify all numerical types into an apparent single type,
> > which requires removal of operator's limitations.
>
> Well I think the idea is to have a hierarchy of nested numeric types,
> not a single type.

You hit the right note, but what I meant is the numeric type
unification would make it _appear_ to consist of a single numeric type
(yeah, I know it isn't actually, but what appears from outside isn't
always what's inside).

> > from __future import division
> > a = 10
> > b = 5
> > c = a / b
> > if c * b == a: print 'multiplication is inverse of division'
>
> Try with a=7, b=25

They should still compare true, but they don't. The reason why they
don't is because of float's finite precision, which is not exactly
what we're talking here since it doesn't change the fact that
multiplication and division are inverse of each other. One way to
handle this situation is to do an epsilon aware comparison (as should
be done with any comparison involving floats), but I don't do it cause
my intention is to clarify the real problem that multiplication is
indeed inverse of division and I want to avoid obscuring that with the
epsilon comparison.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Lie <[EMAIL PROTECTED]> writes:
> That's quite complex and restrictive, but probably it's because my
> mind is not tuned to Haskell yet.

That aspect is pretty straightforward, other parts like only being
able to do i/o in functions having a special type are much more confusing.

> Anyway, I don't think Python should
> work that way, because Python have a plan for numerical integration
> which would unify all numerical types into an apparent single type,
> which requires removal of operator's limitations.

Well I think the idea is to have a hierarchy of nested numeric types,
not a single type.

> from __future import division
> a = 10
> b = 5
> c = a / b
> if c * b == a: print 'multiplication is inverse of division'

Try with a=7, b=25

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

Re: How about adding rational fraction to Python?

[Lie]

On Mar 2, 2:02 pm, Paul Rubin  wrote:
> Lie <[EMAIL PROTECTED]> writes:
> > So basically they refused to satisfy everything that is still possible
> > individually but would conflict if done together.
>
> I can't understand that.
>
> > x = 1
> > a = x + 1<< decides it's an int
>
> No, so far a and x are both Num (indeterminate)
>
> > b = x + 1.0  << error? or redefine to be float?
>
> This determines that a, b, and x are all floats.  It's not "redefined"
> since the types were unknown prior to this.
>
> Actually, I'm slightly wrong, 1.0 is not a float, it's a "Fractional"
> which is a narrower class than Num but it could still be Float, Double,
> or Rational.  Nums support addition, subtraction, multiplication, but
> not necessarily division.  So int/int is an error.  Fractionals support
> division.
>
> > c = x + 1<< would this cause error while it worked in line 2?
>
> No, c is also a float (actually Fractional)
>
> > A slightly obfuscated example:
> > l = [1, 1.0, 1]
>
> This is the same as l = [1.0, 1.0, 1.0].  In Haskell, all elements
> of a list must have the same type, so the 1.0 determines that l is
> a list of fractionals.
>
> > x = 1
> > for n in l:
> >   c = x + n
>
> Haskell does not have loops, but if it did, all these values would be
> fractionals.

That's quite complex and restrictive, but probably it's because my
mind is not tuned to Haskell yet. Anyway, I don't think Python should
work that way, because Python have a plan for numerical integration
which would unify all numerical types into an apparent single type,
which requires removal of operator's limitations.

On Mar 2, 2:23 pm, Paul Rubin  wrote:
> Steven D'Aprano <[EMAIL PROTECTED]> writes:
> > def mean(data): return sum(data)/len(data)
>
> > That does the right thing for data, no matter of what it consists of:
> > floats, ints, Decimals, rationals, complex numbers, or a mix of all of
> > the above.
>
> One of those types is not like the others: for all of them except int,
> the quotient operation actually is the inverse of multiplication.
> So I'm unpersuaded that the "mean" operation above does the "right
> thing" for ints.  If the integers being averaged were prices
> in dollars, maybe the result type should even be decimal.

In __future__ Python or Python 3.0, that mean function would work for
all types. And divisions on int is also inverse of multiplications,
just like subtraction is the inverse of addition:
from __future import division
a = 10
b = 5
c = a / b
if c * b == a: print 'multiplication is inverse of division'
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
> def mean(data): return sum(data)/len(data)
> 
> That does the right thing for data, no matter of what it consists of: 
> floats, ints, Decimals, rationals, complex numbers, or a mix of all of 
> the above.

One of those types is not like the others: for all of them except int,
the quotient operation actually is the inverse of multiplication.
So I'm unpersuaded that the "mean" operation above does the "right
thing" for ints.  If the integers being averaged were prices
in dollars, maybe the result type should even be decimal.

For this reason I think // is a good thing and I've gotten accustomed
to using it for integer division.  I can live with int/int=float but
find it sloppy and would be happier if int/int always threw an error
(convert explicitly if you want a particular type result).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Lie <[EMAIL PROTECTED]> writes:
> So basically they refused to satisfy everything that is still possible
> individually but would conflict if done together. 

I can't understand that.

> x = 1
> a = x + 1<< decides it's an int

No, so far a and x are both Num (indeterminate)

> b = x + 1.0  << error? or redefine to be float?

This determines that a, b, and x are all floats.  It's not "redefined"
since the types were unknown prior to this.  

Actually, I'm slightly wrong, 1.0 is not a float, it's a "Fractional"
which is a narrower class than Num but it could still be Float, Double,
or Rational.  Nums support addition, subtraction, multiplication, but
not necessarily division.  So int/int is an error.  Fractionals support
division.

> c = x + 1<< would this cause error while it worked in line 2?

No, c is also a float (actually Fractional)

> A slightly obfuscated example:
> l = [1, 1.0, 1]

This is the same as l = [1.0, 1.0, 1.0].  In Haskell, all elements
of a list must have the same type, so the 1.0 determines that l is
a list of fractionals.

> x = 1
> for n in l:
>   c = x + n

Haskell does not have loops, but if it did, all these values would be
fractionals.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Lie]

On Feb 29, 5:33 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> > > And rightly rejected by many other programming languages, including
> > > modern Python, not to mention calculators, real mathematics and
> > > common sense.
>
> > Lost me again.  I was not aware that calculators, real mathematics
> > and common sense were programming languages.
>
> I didn't say they were. Please parse my sentence again.

In the widest sense of the term computer and programming language,
actually calculators and real mathematics are programming languages.
Programming languages is a way to communicate problems with computer.
Computer is anything that does computation (and that includes
calculator and a room full of a bunch of people doing calculation with
pencil and paper[1]). The expressions we write in a calculator is a
(very limited) programming language, while mathematics conventions is
a language to communicate a mathematician's problems with the
computers[2] and other mathematicians

[1] Actually the term computer was first used to refer to this bunch
of people
[2] The computers in this sense is people that does computation
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Lie]

On Mar 2, 2:32 am, Paul Rubin  wrote:
> Lie <[EMAIL PROTECTED]> writes:
> > I see, but the same arguments still holds true: the second line have
> > an implicit side-effect of redefining x's type into Fractional type.
> > If I were the designer of the language, I'd leave x's type as it is
> > (as Num) and coerce x for current calculation only.
>
> Num in Haskell is not a type, it is a class of types, i.e. if all you
> know about x is that it is a Num, then its actual type is
> indeterminate.  Types get inferred, they do not get coerced or
> "redefined".  The compiler looks at expressions referring to x, to
> deduce what x's type actually is.  If it is not possible to satisfy
> all constraints simultaneously, then the compiler reports an error.

So basically they refused to satisfy everything that is still possible
individually but would conflict if done together. (I know Haskell not
more than just its name so I don't understand the rationale behind the
language design at all) But I'm interested in how it handles these
cases:

x = 1
a = x + 1<< decides it's an int
b = x + 1.0  << error? or redefine to be float?
c = x + 1<< would this cause error while it worked in line 2?

A slightly obfuscated example:
l = [1, 1.0, 1]
x = 1
for n in l:
  c = x + n
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Lie <[EMAIL PROTECTED]> writes:
> I see, but the same arguments still holds true: the second line have
> an implicit side-effect of redefining x's type into Fractional type.
> If I were the designer of the language, I'd leave x's type as it is
> (as Num) and coerce x for current calculation only.

Num in Haskell is not a type, it is a class of types, i.e. if all you
know about x is that it is a Num, then its actual type is
indeterminate.  Types get inferred, they do not get coerced or
"redefined".  The compiler looks at expressions referring to x, to
deduce what x's type actually is.  If it is not possible to satisfy
all constraints simultaneously, then the compiler reports an error.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Anand Patil]

Not sure if this is common knowledge yet but Sympy,
http://code.google.com/p/sympy, has a rational type.

In [2]: from sympy import *

In [3]: Rational(21,4)
Out[3]: 21/4

In [4]: Rational(21,4)+Rational(3,4)
Out[4]: 6
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Lie]

On Mar 1, 11:23 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
(snip)
> But the type of `x` must be specialized somehow.  `x` doesn't start as
> `Int` or `Integer` but the very generic and AFAIK abstract type class `Num`.
>
> After seeing the second line the compiler finds an implementation for `+`
> and the type class `Fractional` for both operands and now thinks `x` must
> be a `Fractional`, a subclass of `Num`.
>
> Then comes the third line with `length` returning an `Int` and the
> `Fractional` `x` but there is no implementation for a `+` function on
> those types.

I see, but the same arguments still holds true: the second line have
an implicit side-effect of redefining x's type into Fractional type.
If I were the designer of the language, I'd leave x's type as it is
(as Num) and coerce x for current calculation only.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Marc 'BlackJack' Rintsch]

On Fri, 29 Feb 2008 17:29:32 -0800, Lie wrote:

> On Feb 28, 10:00 am, Paul Rubin  wrote:
>> More examples:
>>
>>x = 1
>>y = len(s) + x
>>
>> => ok, decides that x is an int
>>
>>x = 1
>>y = x + 3.0
>>
>> => ok, decides that x is a float
>>
>>x = 1
>>y = x + 3.0
>>z = len(s) + x
>>
>> => forbidden, x cannot be an int and float at the same time.
>>
>> > I am so glad you're not the designer of Python.
>>
>> This is how Haskell works and I don't notice much complaints about it.
> 
> Ok, that means the line "y = x + 3.0" have a side effect of "x =
> float(x)"? I think I would say that is an implicit behavior.

But the type of `x` must be specialized somehow.  `x` doesn't start as
`Int` or `Integer` but the very generic and AFAIK abstract type class `Num`.

After seeing the second line the compiler finds an implementation for `+`
and the type class `Fractional` for both operands and now thinks `x` must
be a `Fractional`, a subclass of `Num`.

Then comes the third line with `length` returning an `Int` and the
`Fractional` `x` but there is no implementation for a `+` function on
those types.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Arnaud Delobelle]

On Mar 1, 5:49 am, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> "Arnaud Delobelle" <[EMAIL PROTECTED]> wrote in message
>
> news:[EMAIL PROTECTED]
> | Perhaps it'll be like when I quit smoking six years ago.  I didn't
> | enjoy it although I knew it was good for me... And now I don't regret
> | it even though I still have the occasional craving.
>
> In following the development of Py3, there have been a few decisions that I
> wish had gone otherwise.  But I agree with more than the majority and am
> not going to deprive myself of what I expect to be an improved experience
> without giving Py3 a fair trial.

I realise that my comment can be easily misunderstood!  I wasn't
implying that I would be quitting python, rather that I would have to
adjust (with some discomfort) to a new division paradigm.

I know from experience that I end up as a staunch defender of most of
the design decisions in Python, particularly those that I disagreed
with at the start!

--
Arnaud

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

Re: How about adding rational fraction to Python?

[Terry Reedy]

"Arnaud Delobelle" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| Perhaps it'll be like when I quit smoking six years ago.  I didn't
| enjoy it although I knew it was good for me... And now I don't regret
| it even though I still have the occasional craving.

In following the development of Py3, there have been a few decisions that I 
wish had gone otherwise.  But I agree with more than the majority and am 
not going to deprive myself of what I expect to be an improved experience 
without giving Py3 a fair trial.

tjr



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

Re: How about adding rational fraction to Python?

[Steve Holden]

Dan Bishop wrote:
> On Feb 29, 12:55 am, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
>> On Thu, 28 Feb 2008 10:39:51 -, Steven D'Aprano
>> <[EMAIL PROTECTED]> declaimed the following in
>> comp.lang.python:
>>
>>> By that logic, we should see this:
>> len("a string")
>>> '8'
>> Why? len() is a function that /counts/ the elements of the argument
>> -- said count remains in integral value (I presume we don't have a 1.5
>> character long string)
> 
> The relevant point is that len() is a function that returns a
> DIFFERENT type than its argument, and nobody ever complains about is.
> 
A language that restricted its functions to returning the same types as 
its arguments wouldn't be very much use, would it? And what about 
functions that have multiple arguments of different types?

>>> And rightly rejected by many other programming languages, including
>>> modern Python, not to mention calculators, real mathematics and common
>>> sense.
>> I know of no calculator that has "integers" for normal math -- and
>> the HP50 even emphasizes this by putting a decimal point into "integer"
>> quantities. Heck -- most calculators work in BCD floats. Most merely
>> suppress the decimal point if the trailing digits are all 0s
> 
> My TI-89 treats them differently: 1.0/2.0 is 0.5, while 1/2 is the
> symbolic expression 1/2.

Any you don't even have to import anything from __future__!

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

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

Re: How about adding rational fraction to Python?

[Dan Bishop]

On Feb 29, 12:55 am, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On Thu, 28 Feb 2008 10:39:51 -, Steven D'Aprano
> <[EMAIL PROTECTED]> declaimed the following in
> comp.lang.python:
>
> > By that logic, we should see this:
>
> > >>> len("a string")
> > '8'
>
> Why? len() is a function that /counts/ the elements of the argument
> -- said count remains in integral value (I presume we don't have a 1.5
> character long string)

The relevant point is that len() is a function that returns a
DIFFERENT type than its argument, and nobody ever complains about is.

> > And rightly rejected by many other programming languages, including
> > modern Python, not to mention calculators, real mathematics and common
> > sense.
>
> I know of no calculator that has "integers" for normal math -- and
> the HP50 even emphasizes this by putting a decimal point into "integer"
> quantities. Heck -- most calculators work in BCD floats. Most merely
> suppress the decimal point if the trailing digits are all 0s

My TI-89 treats them differently: 1.0/2.0 is 0.5, while 1/2 is the
symbolic expression 1/2.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Lie]

On Feb 28, 10:00 am, Paul Rubin  wrote:
> More examples:
>
>x = 1
>y = len(s) + x
>
> => ok, decides that x is an int
>
>x = 1
>y = x + 3.0
>
> => ok, decides that x is a float
>
>x = 1
>y = x + 3.0
>z = len(s) + x
>
> => forbidden, x cannot be an int and float at the same time.
>
> > I am so glad you're not the designer of Python.
>
> This is how Haskell works and I don't notice much complaints about it.

Ok, that means the line "y = x + 3.0" have a side effect of "x =
float(x)"? I think I would say that is an implicit behavior.


On Feb 28, 11:22 pm, "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
> > You people can't tell the difference between "obvious" and "learned
> > conventions that came about because in limitations in the hardware at
> > the time".  Nobody would have come up with a silly rule like "x op y
> > must always have the same type as x and y" if computer hardware had
> > been up to the task when these languages were created.
>
> What makes you say they weren't?  Calculating machines that handled
> floating point are older than Python by far.
>

But much younger than the first programming language (if it could be
called as a language) that set the convention of int op int should
result in int 'cause our hardware can't handle floats.

On Feb 29, 6:15 am, Paul Rubin  wrote:
> Can you name an example of a calculating machine that both:
>   2) says 1/2 = 0.5 ?

Any pocket calculator to scientific calculator. Except perhaps my
calculator which is fraction scientific calculator where it stores 1/2
as rational and have another division operator for 1/2 == 0.5

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

Re: How about adding rational fraction to Python?

[Arnaud Delobelle]

On Feb 29, 10:10 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> "Arnaud Delobelle" <[EMAIL PROTECTED]> wrote in message
>
> | What screws me is that I'm going to have to type p//q in the future.
>
> When I compare that pain to the gain of not having to type an otherwise
> extraneous 'float(...)', and the gain of disambiguating the meaning of a/b
> (for builtin numbers at least), I think there will be a net gain for the
> majority.

You may be right.  I can see the rationale for this change (although
many aspects feel funny, such as doing integral arithmetic with
floats, i.e. 3.0//2.0).

Perhaps it'll be like when I quit smoking six years ago.  I didn't
enjoy it although I knew it was good for me... And now I don't regret
it even though I still have the occasional craving.

--
Arnaud

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

Re: How about adding rational fraction to Python?

[Terry Reedy]

"Arnaud Delobelle" <[EMAIL PROTECTED]> wrote in message

| What screws me is that I'm going to have to type p//q in the future.

When I compare that pain to the gain of not having to type an otherwise 
extraneous 'float(...)', and the gain of disambiguating the meaning of a/b 
(for builtin numbers at least), I think there will be a net gain for the 
majority.

tjr



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

Re: How about adding rational fraction to Python?

[Terry Reedy]

"Ross Ridge" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| Ross Ridge wrote:
| > You're just going to have to accept that there that there is no
| > concensus on this issue and there never was.
|
| Steven D'Aprano  <[EMAIL PROTECTED]> wrote:
| >But that's not true.  The consensus, across the majority of people (both
| >programmers and non-programmers alike) is that 1/2 should return 0.5.
|
| You're deluding yourself.

As a major participant in the discussion, who initially opposed the change, 
I think Steven is right.

| If there were a concensus then this issue then
| it wouldn't be so controversial.

The controversy was initially inflamed by issues that did not directly bear 
on the merit of the proposal.  Worst was its cloaking it in a metaphysical 
argument about the nature of integers.  It also did not help that Guido 
initially had trouble articulating the *practical*, Pythonic reason for the 
proposal.

To me, the key is  this (very briefly):  The current overloading of '/' was 
copied from C.  But Python is crucially different from C in that 
expressions can generally be generic, with run-time rather than compile 
time typing of variables.  But there are no practical use cases that anyone 
ever presented for expr_a / expr_b having two different numerical values, 
giving fixed numerical values for expr_a and expr_b, depending on the 
number types of the two expressions.

Beyond the change itself, another issue was its timing.  When I proposed 
that the version making 1/2=.5 the default be called 3.0, and Guido agreed, 
many who agreed with the change in theory but were concerned with stability 
of the 2.x series agreed that that would make it more palatable.

A third issue was the work required to make the change.  The future 
mechanism eased that, and the 2to3 conversion program will also issue 
warnings.

Terry Jan Reedy



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

Re: How about adding rational fraction to Python?

[Ross Ridge]

Ross Ridge wrote:
> You're just going to have to accept that there that there is no
> concensus on this issue and there never was.

Steven D'Aprano  <[EMAIL PROTECTED]> wrote:
>But that's not true.  The consensus, across the majority of people (both 
>programmers and non-programmers alike) is that 1/2 should return 0.5. 

You're deluding yourself.  If there were a concensus then this issue then
it wouldn't be so controversial.  Even the Python developers admitted
that in the documentation for Python 2.2 when the feature was first
introduced:

(The controversy is over whether this is really a design flaw,
and whether it's worth breaking existing code to fix this. It's
caused endless discussions on python-dev, and in July 2001 erupted
into an storm of acidly sarcastic postings on comp.lang.python. I
won't argue for either side here and will stick to describing
what's implemented in 2.2. Read PEP 238 for a summary of arguments
and counter-arguments.)

The decision to change Python's behavior wasn't made by consensus,
or by popular vote.  It was made by fiat.

Ross Ridge

-- 
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  [EMAIL PROTECTED]
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //   
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Arnaud Delobelle]

On Feb 28, 10:41 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
[...]
> The interesting case is -1/2. According to the argument that "2 doesn't
> go into 1", -1/2 should also return 0. But that's not what Python
> returns, so it looks like the "int division" camp is screwed no matter
> whether Python keeps the status quo or the other status quo.

I'm in the "int division camp" and I like that -1 / 2 is -1.  It's
nice because I can be sure that for any p and q:

* 0 <= p%q < q
* p = q*(p/q) + p%q

In other words, p/q is the largest r such that rq <= p.

It ensures that / and % are well behaved in a lot of situations, e.g:

* (x - y)%n == 0 if and only if x%n == y%n
* if a/n == b/n then abs(a - b) < n
...

So that doesn't screw me, on the contrary I find it a mathematically
very sound decision.  What screws me is that I'm going to have to type
p//q in the future.

--
Arnaud
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
> > Calculating machines that handled
> > floating point are older than Python by far.
> 
> Yes, and they almost universally give the result 1/2 -> 0.5.

Can you name an example of a calculating machine that both:
  1) represents the integer 1 and the real number 1.0 as distinct objects;
and
  2) says 1/2 = 0.5 ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
>  any restriction that functions must return the same
> type as all its arguments is just crazy.

I don't think anyone is saying that they should necessarily do that
in general.  Just in some specific cases.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Steven D'Aprano]

On Thu, 28 Feb 2008 14:41:56 -0500, Ross Ridge wrote:

> You're just going to have to accept that there that there is no
> concensus on this issue and there never was.

But that's not true. The consensus, across the majority of people (both 
programmers and non-programmers alike) is that 1/2 should return 0.5. 
There's a small minority that argue for a rational result, and a bigger 
minority who argue for 0.

The interesting case is -1/2. According to the argument that "2 doesn't 
go into 1", -1/2 should also return 0. But that's not what Python 
returns, so it looks like the "int division" camp is screwed no matter 
whether Python keeps the status quo or the other status quo.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Steven D'Aprano]

On Thu, 28 Feb 2008 11:22:43 -0500, D'Arcy J.M. Cain wrote:

> Calculating machines that handled
> floating point are older than Python by far.

Yes, and they almost universally give the result 1/2 -> 0.5.

-- 
Steven

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

Re: How about adding rational fraction to Python?

[Steven D'Aprano]

On Thu, 28 Feb 2008 11:13:27 -0500, D'Arcy J.M. Cain wrote:

>> >Automatic conversions, okay... but converting a result when all
>> > inputs are of one time, NO...
>> 
>> What? How does that make any sense?
>> 
>> By that logic, we should see this:
>> 
>> >>> len("a string")
>> '8'
>> >>> len([2, 4, 6])
>> [3]
>> >>> len({'key': 'value'})
>> {1: None}
> 
> I think that you have to show your work here.  How does the above
> statement about operators imply that the len method should return the
> type of its argument?


Consider the argument list to the function call len("a string").

>>> args = ["a string"]  # all the arguments
>>> all(type(arg) == str for arg in args)
True

So therefore all the arguments to len() in this case are of a single 
type, namely str, and by Dennis' assertion, "converting a result when all 
inputs are of one [type], NO...", should return the same type as all the 
arguments. Which for the avoidance of all doubt is str.


Similarly for the case len([2, 4, 6]), except this time all the arguments 
(all one of them) are lists, and therefore len() should return a list.

Naturally it's a crazy argument. Which is my point. Operators are merely 
a different syntax for functions of two arguments, and any restriction 
that functions must return the same type as all its arguments is just 
crazy.



> > And rightly rejected by many other programming languages, including 
> > modern Python, not to mention calculators, real mathematics and
> > common sense.
> 
> Lost me again.  I was not aware that calculators, real mathematics 
> and common sense were programming languages.

I didn't say they were. Please parse my sentence again.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[D'Arcy J.M. Cain]

On 28 Feb 2008 12:25:14 -0800
Paul Rubin <"http://phr.cx"@NOSPAM.invalid> wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > > I'd like to point out that now you are talking about int OP int
> > > returning a tuple, not an int.
> > 
> > Which would be stupid.  Good thing I don't think that "obvious" should
> > be the criteria.
> 
> We already have that function (divmod) and it is very useful.

Yes it is and has nothing to do with this discussion.  I don't think
that anyone here has suggested that methods should return the type of
their arguments although there have been a few suggestions that the
suggestions were made.

-- 
D'Arcy J.M. Cain <[EMAIL PROTECTED]> |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > I'd like to point out that now you are talking about int OP int
> > returning a tuple, not an int.
> 
> Which would be stupid.  Good thing I don't think that "obvious" should
> be the criteria.

We already have that function (divmod) and it is very useful.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[D'Arcy J.M. Cain]

On Thu, 28 Feb 2008 13:32:06 -0500
"J. Cliff Dyer" <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-02-28 at 11:22 -0500, D'Arcy J.M. Cain wrote:
> > Not obvious to you.  You are using subjective perception as if it was
> > a
> > law of nature.  If "obvious" was the criteria then I would argue that
> > the only proper result of integer division is (int, int).  Give me the
> > result and the remainder and let me figure it out. 
> 
> I'd like to point out that now you are talking about int OP int
> returning a tuple, not an int.

Which would be stupid.  Good thing I don't think that "obvious" should
be the criteria.

-- 
D'Arcy J.M. Cain <[EMAIL PROTECTED]> |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Ross Ridge]

D'Arcy J.M. Cain wrote:
> Not obvious to you.  You are using subjective perception as if it was
> a law of nature.  If "obvious" was the criteria then I would argue that
> the only proper result of integer division is (int, int).  Give me the
> result and the remainder and let me figure it out. 

J. Cliff Dyer <[EMAIL PROTECTED]> wrote:
> I'd like to point out that now you are talking about int OP int
> returning a tuple, not an int.

No, D'Arcy's point was that "obvious" isn't the criteria because it
would lead to behaviour that no one wants.

No one is going to win this argument by using words like "natural" or
"obvious".  You're just going to have to accept that there that there
is no concensus on this issue and there never was.  In the end only one
person's opinion of what was natural and obvious really matters.

Ross Ridge

-- 
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  [EMAIL PROTECTED]
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //   
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[J. Cliff Dyer]

On Thu, 2008-02-28 at 11:22 -0500, D'Arcy J.M. Cain wrote:
> Not obvious to you.  You are using subjective perception as if it was
> a
> law of nature.  If "obvious" was the criteria then I would argue that
> the only proper result of integer division is (int, int).  Give me the
> result and the remainder and let me figure it out. 

I'd like to point out that now you are talking about int OP int
returning a tuple, not an int.



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

Re: How about adding rational fraction to Python?

[D'Arcy J.M. Cain]

On Thu, 28 Feb 2008 06:10:13 -0800 (PST)
Carl Banks <[EMAIL PROTECTED]> wrote:
> On Feb 28, 3:30 am, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> > Automatic conversions, okay... but converting a result when all
> > inputs are of one time, NO...
> 
> People, this is so cognitive dissonance it's not even funny.

I'll say.

> There is absolutely nothing obvious about 1/2 returning a number that
> isn't at least approximately equal to one half.  There is nothing self-
> evident about operations maintaining types.

Not obvious to you.  You are using subjective perception as if it was a
law of nature.  If "obvious" was the criteria then I would argue that
the only proper result of integer division is (int, int).  Give me the
result and the remainder and let me figure it out.

> You people can't tell the difference between "obvious" and "learned
> conventions that came about because in limitations in the hardware at
> the time".  Nobody would have come up with a silly rule like "x op y
> must always have the same type as x and y" if computer hardware had
> been up to the task when these languages were created.

What makes you say they weren't?  Calculating machines that handled
floating point are older than Python by far.

-- 
D'Arcy J.M. Cain <[EMAIL PROTECTED]> |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[D'Arcy J.M. Cain]

On Thu, 28 Feb 2008 10:39:51 -
"Steven D'Aprano" <[EMAIL PROTECTED]> wrote:
> On Thu, 28 Feb 2008 00:30:11 -0800, Dennis Lee Bieber wrote:
> > Automatic conversions, okay... but converting a result when all
> > inputs are of one time, NO...
> 
> What? How does that make any sense?
> 
> By that logic, we should see this:
> 
> >>> len("a string")
> '8'
> >>> len([2, 4, 6])
> [3]
> >>> len({'key': 'value'})
> {1: None}

I think that you have to show your work here.  How does the above
statement about operators imply that the len method should return the
type of its argument?

> > The only rule needed is very simple: promote simpler types to the
> > more complex type involved in the current expression (with expression
> > defined as "value operator value" -- so (1/2) * 3.0 is INTEGER 1/2,
> > resultant 0 then promoted to float 0.0 to be compatible with 3.0).
> > 
> > Very simple rule, used by very many traditional programming
> > languages.
> 
> And rightly rejected by many other programming languages, including 
> modern Python, not to mention calculators, real mathematics and common 
> sense.

Lost me again.  I was not aware that calculators, real mathematics and
common sense were programming languages.  Check out the definition in
http://en.wikipedia.org/wiki/Programming_language and others if you are
unclear.  PLs are designed to communicate with machines.  Even a
calculator is an application, not a language.  This is an important
difference.

-- 
D'Arcy J.M. Cain <[EMAIL PROTECTED]> |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Carl Banks]

On Feb 28, 9:36 am, Grant Edwards <[EMAIL PROTECTED]> wrote:
> On 2008-02-28, Carl Banks <[EMAIL PROTECTED]> wrote:
>
> >> Automatic conversions, okay... but converting a result when
> >> all inputs are of one time, NO...
>
> > People, this is so cognitive dissonance it's not even funny.
>
> > There is absolutely nothing obvious about 1/2 returning a number that
> > isn't at least approximately equal to one half.
>
> I guess obviousness is in the eye of the beholder.  To me it's
> obvious that "1" and "2" are integers, and it's also obvious
> that 2 goes into 1 zero times.

2 goes into 1 0.5 times.

> > There is nothing self-evident about operations maintaining
> > types.
>
> By that logic, there's no reason for 1 + "two" shouldn't
> convert one operand or the other.

False dilemma, chief.  That preserving type is not self-evident
doesn't make all operations that don't preserve type a good idea.


> > You people can't tell the difference between "obvious" and "learned
> > conventions that came about because in limitations in the hardware at
> > the time".
>
> It seems to me that the expectation that 1/2 yield 0.5 is just
> as much a convention as that it yield 0 or a true rational.

Sure it is, but unlike the old convention, it's the obvious one.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Torsten Bronger]

Hallöchen!

Grant Edwards writes:

> [...]
>
>> You people can't tell the difference between "obvious" and
>> "learned conventions that came about because in limitations in
>> the hardware at the time".
>
> It seems to me that the expectation that 1/2 yield 0.5 is just as
> much a convention as that it yield 0 or a true rational.

Should be set up a poll?  Do you really think that less than 90% of
the voters would enter something else than 0.5 in the result edit
field?

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
  Jabber ID: [EMAIL PROTECTED]
   (See http://ime.webhop.org for further contact info.)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Grant Edwards]

On 2008-02-28, Carl Banks <[EMAIL PROTECTED]> wrote:

>> Automatic conversions, okay... but converting a result when
>> all inputs are of one time, NO...
>
> People, this is so cognitive dissonance it's not even funny.
>
> There is absolutely nothing obvious about 1/2 returning a number that
> isn't at least approximately equal to one half.

I guess obviousness is in the eye of the beholder.  To me it's
obvious that "1" and "2" are integers, and it's also obvious
that 2 goes into 1 zero times.

> There is nothing self-evident about operations maintaining
> types.

By that logic, there's no reason for 1 + "two" shouldn't
convert one operand or the other.

> You people can't tell the difference between "obvious" and "learned
> conventions that came about because in limitations in the hardware at
> the time".

It seems to me that the expectation that 1/2 yield 0.5 is just
as much a convention as that it yield 0 or a true rational.

-- 
Grant Edwards   grante Yow! I am covered with
  at   pure vegetable oil and I am
   visi.comwriting a best seller!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Carl Banks]

On Feb 28, 3:30 am, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> Automatic conversions, okay... but converting a result when all
> inputs are of one time, NO...

People, this is so cognitive dissonance it's not even funny.

There is absolutely nothing obvious about 1/2 returning a number that
isn't at least approximately equal to one half.  There is nothing self-
evident about operations maintaining types.

You people can't tell the difference between "obvious" and "learned
conventions that came about because in limitations in the hardware at
the time".  Nobody would have come up with a silly rule like "x op y
must always have the same type as x and y" if computer hardware had
been up to the task when these languages were created.


>Very simple rule, used by very many traditional >programming languages.

I'd be interested in hearing what languages those are.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Steven D'Aprano]

On Thu, 28 Feb 2008 00:30:11 -0800, Dennis Lee Bieber wrote:

> On Thu, 28 Feb 2008 01:25:32 -, Steven D'Aprano
> <[EMAIL PROTECTED]> declaimed the following in
> comp.lang.python:
> 
>> When it comes to mixed arithmetic, it's just too darn inconvenient to
>> forbid automatic conversions. Otherwise you end up either forbidding
>> things like 1 + 1.0 on the basis that it isn't clear whether the
>> programmer wants an int result or a float result, or else even more
>> complex rules ("if the left operator is an int, and the result of the
>> addition has a zero floating-point part, then the result is an int,
>> otherwise it's an error, but if the left operator is a float, the
>> result is always a float"). Or a proliferation of operators, with
>> integer and floating point versions of everything.
> 
>   Automatic conversions, okay... but converting a result when all
> inputs are of one time, NO...

What? How does that make any sense?

By that logic, we should see this:

>>> len("a string")
'8'
>>> len([2, 4, 6])
[3]
>>> len({'key': 'value'})
{1: None}



>   The only rule needed is very simple: promote simpler types to the
> more complex type involved in the current expression (with expression
> defined as "value operator value" -- so (1/2) * 3.0 is INTEGER 1/2,
> resultant 0 then promoted to float 0.0 to be compatible with 3.0).
> 
>   Very simple rule, used by very many traditional programming
> languages.

And rightly rejected by many other programming languages, including 
modern Python, not to mention calculators, real mathematics and common 
sense.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> writes:
> For implementing this in Python you have to carry an "is allowed to be
> coerced to float" flag with every integer object to decide at run time if
> it is an error to add it to a float or not.

Yeah, I guess it's not workable in a dynamic language.  Hmm.  Well I
could think of some crazy ways to do it.  

> Or you make Python into a statically typed language like Haskell.
> But then it's not Python anymore IMHO.

There are some languages like Boo, that are sort of halfway between
Python and Haskell, so maybe that kind of idea could be used in them.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Marc 'BlackJack' Rintsch]

On Wed, 27 Feb 2008 19:00:19 -0800, Paul Rubin wrote:

> Steven D'Aprano <[EMAIL PROTECTED]> writes:
>> Okay, that's just insane, making distinctions between literals and 
>> variables like that.
>> 
>> 1 + 1.0  # okay
> 
> => Yes
> 
>> x = 1
>> x + 1.0  # is this okay or not? who knows?
> 
> => Yes, ok
> 
>> len('s') + 1.0  # forbidden
> 
> Yes, forbidden.  
> 
> More examples:
> 
>x = 1
>y = len(s) + x
> 
> => ok, decides that x is an int
> 
>x = 1
>y = x + 3.0
> 
> => ok, decides that x is a float
> 
>x = 1
>y = x + 3.0
>z = len(s) + x
> 
> => forbidden, x cannot be an int and float at the same time.
> 
>> I am so glad you're not the designer of Python.
> 
> This is how Haskell works and I don't notice much complaints about it.

Complain!  :-)

For implementing this in Python you have to carry an "is allowed to be
coerced to float" flag with every integer object to decide at run time if
it is an error to add it to a float or not.  Or you make Python into a
statically typed language like Haskell.  But then it's not Python anymore
IMHO.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Steven D'Aprano]

On Wed, 27 Feb 2008 18:43:24 -0800, Paul Rubin wrote:

> Steven D'Aprano <[EMAIL PROTECTED]> writes:
>> def pmean(data):  # Paul Rubin's mean
>> """Returns the arithmetic mean of data, unless data is all ints, in
>> which case returns the mean rounded to the nearest integer less
>> than the arithmetic mean."""
>> s = sum(data)
>> if isinstance(s, int): return s//len(data)
>> else: return s/len(data)
> 
> Scheme and Common Lisp do automatic conversion and they thought out the
> semantics rather carefully, and I think both of them return exact
> rationals in this situation (int/int division).

Potentially better than returning a float, but equally objectionable to 
all those insisting that int  int should only return an int.


> I agree with you that
> using // as above is pretty weird and it may be preferable to raise
> TypeError on any use of int/int (require either an explicit conversion,
> or use of //).


Then you have completely misunderstood my objection.

It's not that // is weird, but that the semantics that you want by 
default:

"return the mean for arbitrary numeric data, except for all ints, in 
which case return the mean rounded to the next smaller integer"

is weird. Weird or not, if you want those semantics, Python gives you the 
tools to create it, as above. It's not even very much more work.

But the normal semantics:

"return the mean for arbitrary numeric data"

should be easier, and with Python it is:

def mean(data): return sum(data)/len(data)

That does the right thing for data, no matter of what it consists of: 
floats, ints, Decimals, rationals, complex numbers, or a mix of all of 
the above.

You want the pmean() case to be easy, and the mean() case to be hard, and 
that's what boggles my brain.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
> Okay, that's just insane, making distinctions between literals and 
> variables like that.
> 
> 1 + 1.0  # okay

=> Yes

> x = 1
> x + 1.0  # is this okay or not? who knows?

=> Yes, ok

> len('s') + 1.0  # forbidden

Yes, forbidden.  

More examples:

   x = 1
   y = len(s) + x

=> ok, decides that x is an int

   x = 1
   y = x + 3.0

=> ok, decides that x is a float

   x = 1
   y = x + 3.0
   z = len(s) + x

=> forbidden, x cannot be an int and float at the same time.

> I am so glad you're not the designer of Python.

This is how Haskell works and I don't notice much complaints about it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Steven D'Aprano]

On Wed, 27 Feb 2008 18:08:29 -0800, Paul Rubin wrote:

> Steven D'Aprano <[EMAIL PROTECTED]> writes:
>> When it comes to mixed arithmetic, it's just too darn inconvenient to
>> forbid automatic conversions. Otherwise you end up either forbidding
>> things like 1 + 1.0 on the basis that it isn't clear whether the
>> programmer wants an int result or a float result,
> 
> You can parse 1 as either an integer or a floating 1, so 1 + 1.0 can be
> correctly typed as a float.  However (for example), len(x) is always an
> int so len(x) + 1.0 would be forbidden.

Okay, that's just insane, making distinctions between literals and 
variables like that.

1 + 1.0  # okay

x = 1
x + 1.0  # is this okay or not? who knows?

len('s') + 1.0  # forbidden


I am so glad you're not the designer of Python.




>> or else even more complex rules ("if the left operator is an int, and
>> the result of the addition has a zero floating-point part, then the
>> result is an int,
> 
> That is ugly and unnecessary.

Which was my point.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Dan Bishop]

On Feb 26, 11:21 pm, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> On Feb 26, 11:55 pm, Paul Rubin  wrote:
>
> > So use:  return sum(number_list) / float(len(number_list))
> > That makes it somewhat more explicit what you want.  Otherwise
>
> But that fails for a list of Decimals...
>
> Mark

Or complex.  Or for rationals if you aren't expecting a conversion to
float.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
> def pmean(data):  # Paul Rubin's mean
> """Returns the arithmetic mean of data, unless data is all 
> ints, in which case returns the mean rounded to the nearest 
> integer less than the arithmetic mean."""
> s = sum(data)
> if isinstance(s, int): return s//len(data)
> else: return s/len(data)

Scheme and Common Lisp do automatic conversion and they thought out
the semantics rather carefully, and I think both of them return
exact rationals in this situation (int/int division).  I agree
with you that using // as above is pretty weird and it may be
preferable to raise TypeError on any use of int/int (require
either an explicit conversion, or use of //).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Steven D'Aprano]

On Wed, 27 Feb 2008 17:07:37 -0800, Paul Rubin wrote:

> Steven D'Aprano <[EMAIL PROTECTED]> writes:
>> Oh come on. With a function named "mean" that calculates the sum of a
>> list of numbers and then divides by the number of items, what else
>> could it be?
> 
> You have a bunch of marbles you want to put into bins.  The division
> tells you how many marbles to put into each bin.  That would be an
> integer since you cannot cut up individual marbles.

(Actually you can. As a small child, one of my most precious possessions 
was a marble which had cracked into two halves.)

No, that doesn't follow, because you don't get the result you want if the 
number of marbles is entered as Decimals or floats. Maybe the data came 
from a marble-counting device that always returns floats.

You're expecting the function to magically know what you want to do with 
the result and return the right kind of answer, which is the wrong way to 
go about it. For example, there are situations where your data is given 
in integers, but the number you want is a float.

# number of 20kg bags of flour per order
>>> data = [5, 7, 20, 2, 7, 6, 1, 37, 3]
>>> weights = [20*n for n in data]
>>> mean(weights)
195.54

If I was using a library that arbitrarily decided to round the mean 
weight per order to 195kg, I'd report that as a bug. Maybe I want the 
next highest integer, not lowest. Maybe I do care about that extra 5/9th 
of a kilo. It simply isn't acceptable for the function to try to guess 
what I'm going to do with the result.


 
>> You can always imagine corner cases where some programmer, somewhere,
>> has some bizarre need for a mean() function that truncates when given a
>> list of integers but not when given a list of floats.  Making that the
>> default makes life easy for the 0.1% corner cases and life harder for
>> the 99.9% of regular cases, which is far from the Python philosophy.
> 
> I think it's more important that a program never give a wrong answer,
> than save a few keystrokes.  So, that polymorphic mean function is a bit
> scary. It might be best to throw an error if the args are all integers.
> There is no definitely correct way to handle it so it's better to
> require explicit directions.

Of course there's a correct way to handle it. You write a function that 
returns the mathematical mean. And then, if you need special processing 
of that mean, (say) truncating if the numbers are all ints, or on 
Tuesdays, you do so afterwards:

x = mean(data)
if all(isinstance(n, int) for n in data) or today() == Tuesday:
x = int(x)


I suppose that if your application is always going to truncate the mean 
you might be justified in writing an optimized function that does that. 
But don't call it "truncated_mean", because that has a specific meaning 
to statisticians that is not the same as what you're talking about.

Paul, I'm pretty sure you've publicly defended duck typing before. Now 
you're all scared of some imagined type non-safety that results from 
numeric coercions. I can't imagine why you think that this should be 
allowed:

class Float(float): pass
x = Float(1.0)
mean([x, 2.0, 3.0, 5.0])

but this gives you the heebie-geebies:

mean([1, 2.0, 3.0, 5.0])


As a general principle, I'd agree that arbitrarily coercing any old type 
into any other type is a bad idea. But in the specific case of numeric 
coercions, 99% of the time the Right Way is to treat all numbers 
identically, and then restrict the result if you want a restricted 
result, so the language should make that the easy case, and leave the 1% 
to the developer to write special code:

def pmean(data):  # Paul Rubin's mean
"""Returns the arithmetic mean of data, unless data is all 
ints, in which case returns the mean rounded to the nearest 
integer less than the arithmetic mean."""
s = sum(data)
if isinstance(s, int): return s//len(data)
else: return s/len(data)



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
> When it comes to mixed arithmetic, it's just too darn inconvenient to 
> forbid automatic conversions. Otherwise you end up either forbidding 
> things like 1 + 1.0 on the basis that it isn't clear whether the 
> programmer wants an int result or a float result,

You can parse 1 as either an integer or a floating 1, so 1 + 1.0 can
be correctly typed as a float.  However (for example), len(x) is
always an int so len(x) + 1.0 would be forbidden.

> or else even more complex rules ("if the left operator is an int,
> and the result of the addition has a zero floating-point part, then
> the result is an int,

That is ugly and unnecessary.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Steven D'Aprano]

On Tue, 26 Feb 2008 21:41:16 -0800, Paul Rubin wrote:

> Mark Dickinson <[EMAIL PROTECTED]> writes:
>> > So use:  return sum(number_list) / float(len(number_list)) That makes
>> > it somewhat more explicit what you want.  Otherwise
>> 
>> But that fails for a list of Decimals...
> 
> Again, that depends on what your application considers to be failure.
> Heck, int/int = float instead of decimal might be a failure.
> 
> FWIW, I just checked Haskell: int/int is not allowed (compile time type
> error).  There is an integer division function `div`, like Python's //,
> . that you can use if you want an integer quotient. If you want a
> floating or rational quotient, you have to coerce the operands manually.
>  Explicit is better than implicit.

Argument by platitude now? I can play that game too. You forget that 
practicality beats purity.

When it comes to mixed arithmetic, it's just too darn inconvenient to 
forbid automatic conversions. Otherwise you end up either forbidding 
things like 1 + 1.0 on the basis that it isn't clear whether the 
programmer wants an int result or a float result, or else even more 
complex rules ("if the left operator is an int, and the result of the 
addition has a zero floating-point part, then the result is an int, 
otherwise it's an error, but if the left operator is a float, the result 
is always a float"). Or a proliferation of operators, with integer and 
floating point versions of everything.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
> Oh come on. With a function named "mean" that calculates the sum of a 
> list of numbers and then divides by the number of items, what else could 
> it be?

You have a bunch of marbles you want to put into bins.  The division
tells you how many marbles to put into each bin.  That would be
an integer since you cannot cut up individual marbles.

> You can always imagine corner cases where some programmer, somewhere, has 
> some bizarre need for a mean() function that truncates when given a list 
> of integers but not when given a list of floats.  Making that the default 
> makes life easy for the 0.1% corner cases and life harder for the 99.9% 
> of regular cases, which is far from the Python philosophy.

I think it's more important that a program never give a wrong answer,
than save a few keystrokes.  So, that polymorphic mean function is
a bit scary.  It might be best to throw an error if the args are
all integers.  There is no definitely correct way to handle it so
it's better to require explicit directions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Steven D'Aprano]

On Tue, 26 Feb 2008 20:55:14 -0800, Paul Rubin wrote:

> Mark Dickinson <[EMAIL PROTECTED]> writes:
>> def mean(number_list):
>> return sum(number_list)/len(number_list)
>> 
>> If you pass a list of floats, complex numbers, Fractions, or Decimal
>> instances to mean() then it'll work just fine.  But if you pass
>>  a list of ints or longs, it'll silently return the wrong result.
> 
> So use:  return sum(number_list) / float(len(number_list)) That makes it
> somewhat more explicit what you want.  Otherwise I wouldn't be so sure
> the integer result is "wrong".

Oh come on. With a function named "mean" that calculates the sum of a 
list of numbers and then divides by the number of items, what else could 
it be?

You can always imagine corner cases where some programmer, somewhere, has 
some bizarre need for a mean() function that truncates when given a list 
of integers but not when given a list of floats. Making that the default 
makes life easy for the 0.1% corner cases and life harder for the 99.9% 
of regular cases, which is far from the Python philosophy.

It's better to reverse the burden, as Python does. Not that it is much 
harder to write truncating_mean_for_ints_but_not_floats(): just use 
the // int operator instead of /. At which point somebody will chime up 
that int division gives the wrong result with one negative operand, 
because in *their* opinion it should truncate rather than round to floor:

>>> 1//3
0
>>> -1//3  # expect 0
-1


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Ross Ridge]

Mark Dickinson  <[EMAIL PROTECTED]> wrote:
>True division and floor division are different operations.  It doesn't
>seem ridiculous to use different operators for them.

I don't have a problem with there being different operators for integer
and floating-point division.  I have a problem with the behviour of the
slash (/) operator changing.

Ross Ridge

-- 
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  [EMAIL PROTECTED]
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //   
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

"Gabriel Genellina" <[EMAIL PROTECTED]> writes:
> They exist since this semantic change was introduced *seven* *years*
> ago,  in 2001, so it's not that suddenly the Python world is going to
> be upside  down... I can't believe how long this thread is by now...

I don't think it's a sudden uproar about int/int being float, it's
just one of the periodic discussions about introducing a rational
type, like we not that long ago got a decimal type.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Mark Dickinson <[EMAIL PROTECTED]> writes:
> > So use:  return sum(number_list) / float(len(number_list))
> > That makes it somewhat more explicit what you want.  Otherwise
> 
> But that fails for a list of Decimals...

Again, that depends on what your application considers to be failure.
Heck, int/int = float instead of decimal might be a failure.

FWIW, I just checked Haskell: int/int is not allowed (compile time
type error).  There is an integer division function `div`, like
Python's //, . that you can use if you want an integer quotient. If
you want a floating or rational quotient, you have to coerce the
operands manually.  Explicit is better than implicit.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Gabriel Genellina]

En Wed, 27 Feb 2008 00:39:09 -0200, Mark Dickinson <[EMAIL PROTECTED]>  
escribió:
> On Feb 26, 9:00 pm, Paul Rubin  wrote:
>> Certainly, I'd expect that if x and y are both integers and x is an
>> exact multiple of y, then x/y will be computable and not overflow.
>> But try computing 10**5000 / 10**4000 under future division (that is
>> supposed to give a float).
>
> And smaller numbers are problematic too:
>
 from __future__ import division
 10**50/10**40
> 100.0
 10**60/10**50
> 99.981
>
> This despite the fact that the quotient *is* exactly representable
> as a float...

But:
py> 10**60//10**50
100L

Nobody has menctioned yet the -Q command line option: -Qwarn will issue a  
warning when 3/4 is executed.
And there is a helper script, Tools\scripts\fixdiv.py, that helps on  
locating and replacing / operators.  It works by analyzing the warnings  
issued when the target program is actually executed with -Qwarnall.
There is also a companion script, finddiv.py, that just scans the source  
looking for / and /= operators.
They exist since this semantic change was introduced *seven* *years* ago,  
in 2001, so it's not that suddenly the Python world is going to be upside  
down... I can't believe how long this thread is by now...

-- 
Gabriel Genellina

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

Re: How about adding rational fraction to Python?

[Mark Dickinson]

On Feb 26, 11:55 pm, Paul Rubin  wrote:
> So use:  return sum(number_list) / float(len(number_list))
> That makes it somewhat more explicit what you want.  Otherwise

But that fails for a list of Decimals...

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Mark Dickinson <[EMAIL PROTECTED]> writes:
> def mean(number_list):
> return sum(number_list)/len(number_list)
> 
> If you pass a list of floats, complex numbers, Fractions, or Decimal
> instances to mean() then it'll work just fine.  But if you pass
>  a list of ints or longs, it'll silently return the wrong result.

So use:  return sum(number_list) / float(len(number_list))
That makes it somewhat more explicit what you want.  Otherwise
I wouldn't be so sure the integer result is "wrong".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Jeff Schwab]

Mark Dickinson wrote:
> On Feb 26, 9:00 pm, Paul Rubin  wrote:
>> Certainly, I'd expect that if x and y are both integers and x is an
>> exact multiple of y, then x/y will be computable and not overflow.
>> But try computing 10**5000 / 10**4000 under future division (that is
>> supposed to give a float).
> 
> And smaller numbers are problematic too:
> 
 from __future__ import division
 10**50/10**40
> 100.0
 10**60/10**50
> 99.981
> 
> This despite the fact that the quotient *is* exactly representable

You know what I find weird about this?  The result of truncating 
division in this case is not just less accurate than it could be; it's 
actually greater than the result of non-truncating division.

 >>> (10**60//10**50) > (10**60/10**50)
True

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

Re: How about adding rational fraction to Python?

[Gabriel Genellina]

En Tue, 26 Feb 2008 15:01:57 -0200, Jeff Schwab <[EMAIL PROTECTED]>  
escribió:
> J. Cliff Dyer wrote:

>> Of course.  That's why I think you ought to spell it 3//4.  Nobody gets
>> confused when a strange operator that they've never seen before does
>> something unusual.  Average Jo off the street looks at python code and
>> sees 3/4, and immediately thinks "aha! .75!"  Show the same person 3//4,
>> and she'll think, "A double slash?  I'd better check the
>> documentation--or better yet, play with it a little in the interactive
>> interpreter."
>
> Or Jo thinks // is a typo, and helpfully "fixes" it.

...like someone who "fixed" a raw string by removing the "r", and the  
script mysteriously stopped working...

-- 
Gabriel Genellina

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

Re: How about adding rational fraction to Python?

[Mark Dickinson]

On Feb 26, 4:59 pm, Ross Ridge <[EMAIL PROTECTED]>
wrote:
> No, the discussion has been about the behaviour of the division operator
> in Python when used with Python's integral and floating-point data types.
> These data types include many numbers that are not natural numbers.

I'm surprised that no-one has mentioned duck-typing so far in this
discussion.  After all, as I understand it the number one reason
for changing / in Python 3.0 is that the 2.x behaviour breaks duck
typing.  Consider:

def mean(number_list):
return sum(number_list)/len(number_list)

If you pass a list of floats, complex numbers, Fractions, or Decimal
instances to mean() then it'll work just fine.  But if you pass
 a list of ints or longs, it'll silently return the wrong result.

True division and floor division are different operations.  It doesn't
seem ridiculous to use different operators for them.

Mark

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

Re: How about adding rational fraction to Python?

[Mark Dickinson]

On Feb 26, 9:00 pm, Paul Rubin  wrote:
> Certainly, I'd expect that if x and y are both integers and x is an
> exact multiple of y, then x/y will be computable and not overflow.
> But try computing 10**5000 / 10**4000 under future division (that is
> supposed to give a float).

And smaller numbers are problematic too:

>>> from __future__ import division
>>> 10**50/10**40
100.0
>>> 10**60/10**50
99.981

This despite the fact that the quotient *is* exactly representable
as a float...

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Grant Edwards]

On 2008-02-27, J. Clifford Dyer <[EMAIL PROTECTED]> wrote:

> But I don't think that *was* the issue in the first place. The
> issue is whether python's division should only yield integers
> when given integer inputs.  "Natural" is a polemical term no
> matter who is using it in this argument, so lets drop it
> altogether.  If the issue is that it should remain an integer
> because that mimics how the computer works, than I think it is
> worth pointing out that allowing a conversion to a long also
> goes against how the computer works;

I would have preferred that didn't happen either.  I just don't
like implicit/automatic conversions from one type to another.

  "If I wanted a long, I'd have used a long."

> the computer would have a register overflow.  If the issue is
> that in python the division operator has always performed
> integer division, and should not change, then I think we're
> talking about a philosophical opposition to Python 3 that goes
> far deeper than just how integer division behaves.
>
> At any rate, the whole argument is irrelevant

Certainly.  The decision has been made and it's not going to
change -- at least not until the next time it changes. :)


-- 
Grant Edwards   grante Yow!  Is this ANYWHERE,
  at   USA?
   visi.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

"J. Clifford Dyer" <[EMAIL PROTECTED]> writes:
> If the issue is that it should
> remain an integer because that mimics how the computer works, than I
> think it is worth pointing out that allowing a conversion to a long also
> goes against how the computer works; the computer would have a register
> overflow.  If the issue is that in python the division operator has
> always performed integer division, and should not change, then I think
> we're talking about a philosophical opposition to Python 3 that goes far
> deeper than just how integer division behaves.

The issue is that python ints mostly act like mathematical integers
(modulo the artifact of the int/long dichotomy which is gradually
going away).  

Certainly, I'd expect that if x and y are both integers and x is an
exact multiple of y, then x/y will be computable and not overflow.
But try computing 10**5000 / 10**4000 under future division (that is
supposed to give a float).

> At any rate, the whole argument is irrelevant--python already supports
> floating point results for integer division, and that isn't going away,
> but neither is integer division that always results in integer results,
> so if you don't like getting floating point results, you never have to
> use the / operator.  

I don't know of any other languages that support exact integers but
give you a floating point quotient.  CL, Scheme, Haskell, and I think
ML all have exact rationals, which is what the thread is about.  All
those scary pitfalls of intermediate results becoming unboundedly
complex simply don't seem to happen.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[J. Clifford Dyer]

On Tue, 2008-02-26 at 14:08 -0800, Jeff Schwab wrote:
> J. Cliff Dyer wrote:
> > On Tue, 2008-02-26 at 13:51 -0500, D'Arcy J.M. Cain wrote:
> >> On Tue, 26 Feb 2008 13:39:38 -0500
> >> "J. Cliff Dyer" <[EMAIL PROTECTED]> wrote:
> >> a = 2 * 2
> >> b = 20 * 20
> >> type(a)
> >>> 
> >> type(b)
> >>> 
> >> A long int is still integral which is the crux of the issue.
> >>
> > 
> > So do you believe that you should not be able to do natural division
> > without explicitly casting ints as floats, or is your concern just that
> > you want to still be able to to integer division simply?
> 
> I think the issue is whether this qualifies as "natural" division in the 
> first place.  (For the record, I'm only semi-old-school.)

OK.  My use of the word "natural" was ill advised.

Sorry.

But I don't think that *was* the issue in the first place.  The issue is
whether python's division should only yield integers when given integer
inputs.  "Natural" is a polemical term no matter who is using it in this
argument, so lets drop it altogether.  If the issue is that it should
remain an integer because that mimics how the computer works, than I
think it is worth pointing out that allowing a conversion to a long also
goes against how the computer works; the computer would have a register
overflow.  If the issue is that in python the division operator has
always performed integer division, and should not change, then I think
we're talking about a philosophical opposition to Python 3 that goes far
deeper than just how integer division behaves.

At any rate, the whole argument is irrelevant--python already supports
floating point results for integer division, and that isn't going away,
but neither is integer division that always results in integer results,
so if you don't like getting floating point results, you never have to
use the / operator.  

Practicality beats purity.  

Cheers,
Cliff

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

Re: How about adding rational fraction to Python?

[Jeff Schwab]

Grant Edwards wrote:
> On 2008-02-26, Jeff Schwab <[EMAIL PROTECTED]> wrote:
>> Grant Edwards wrote:
>>
>>> I guess it must depend on where you went to shool.
>> Temple Israel.  You?
> 
> Good one. :)

I make a lot of typo's on Usenet, so I'm always secretly relieved when 
other people do, too.  (IOW, thanks for being a good sport about it.)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Jeff Schwab]

Paul Rubin wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
>>> http://en.wikipedia.org/wiki/Natural_number
>> Recheck the context.  I was talking about the natural result, not
>> natural numbers.
> 
> The natural result of doing arithmetic with natural numbers is more
> natural numbers.  

Back when I was just a wee little developer, I was taught that division 
over the natural number was *not* a closed operation.  (I still like 
integer division, and I'm OK with the fact that it truncates.)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Jeff Schwab]

J. Cliff Dyer wrote:
> On Tue, 2008-02-26 at 13:51 -0500, D'Arcy J.M. Cain wrote:
>> On Tue, 26 Feb 2008 13:39:38 -0500
>> "J. Cliff Dyer" <[EMAIL PROTECTED]> wrote:
>> a = 2 * 2
>> b = 20 * 20
>> type(a)
>>> 
>> type(b)
>>> 
>> A long int is still integral which is the crux of the issue.
>>
> 
> So do you believe that you should not be able to do natural division
> without explicitly casting ints as floats, or is your concern just that
> you want to still be able to to integer division simply?

I think the issue is whether this qualifies as "natural" division in the 
first place.  (For the record, I'm only semi-old-school.)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Steven D'Aprano]

On Tue, 26 Feb 2008 14:46:04 -0500, D'Arcy J.M. Cain wrote:

> I am really having a hard time accepting that "TRUTH (tm)" is determined
> by election.

But you're apparently perfectly comfortable that "TRUTH (tm)" is decided 
by fiat.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Arnaud Delobelle]

On Feb 26, 9:47 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Tue, 26 Feb 2008 11:43:56 -0500, D'Arcy J.M. Cain wrote:
> > Integer division means integer result to me in a very real sense.
>
> So, when you have five children over for a birthday party, and one cake,
> do you say "Sorry kids, no cake for you: one cake divided by five is
> zero"?
>
> Of course you do, you big meanie. I think you catered for my 12th
> birthday party.

Whereas I bet you would be able to share the cake equally and each
child would get 0.20001 of a cake :)

Or perhaps it would be better to have 2**n guests...
Or maybe one should think of the cake as 1.0 cake, as experience shows
that cakes can be cut...

--
Arnaud

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

Re: How about adding rational fraction to Python?

[Ross Ridge]

Ross Ridge <[EMAIL PROTECTED]> writes:
> D'Arcy said nothing about natural numbers, and bringing them up adds
> nothing to this discussion.

Paul Rubin   wrote:
> The numbers D'Arcy is proposing to operate on that way are natural
> numbers whether he says so or not.

No, the discussion has been about the behaviour of the division operator
in Python when used with Python's integral and floating-point data types.
These data types include many numbers that are not natural numbers.

>Really, the "natural" division operation on integers, if there is one,
>is divmod (which returns a quotient and remainder).

Then either your definition of "natural" is wrong, or the fact that
something is the "natural" way of doing something doesn't mean it should
be done that way in Python.

Ross Ridge

-- 
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  [EMAIL PROTECTED]
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //   
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Torsten Bronger]

Hallöchen!

Grant Edwards writes:

> On 2008-02-26, Torsten Bronger <[EMAIL PROTECTED]> wrote:
>
>> Grant Edwards writes:
>>
>>> [...]
>>>
>>> Nope.  I would prefer that int OP int always produce an int.
>>
>> And 2**-1?
>
> An error.

?  Not here.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
  Jabber ID: [EMAIL PROTECTED]
   (See http://ime.webhop.org for further contact info.)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Steven D'Aprano]

On Tue, 26 Feb 2008 11:43:56 -0500, D'Arcy J.M. Cain wrote:

> Integer division means integer result to me in a very real sense.

So, when you have five children over for a birthday party, and one cake, 
do you say "Sorry kids, no cake for you: one cake divided by five is 
zero"?

Of course you do, you big meanie. I think you catered for my 12th 
birthday party.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Grant Edwards]

On 2008-02-26, Torsten Bronger <[EMAIL PROTECTED]> wrote:
> Hallöchen!
>
> Grant Edwards writes:
>
>> [...]
>>
>> Nope.  I would prefer that int OP int always produce an int.
>
> And 2**-1?

An error.

> Your formulation tries to suggest some sort of logical
> consequence but in my opinion, it's still a mere matter of
> taste and habits.  I remember my first steps in C++ 12 years
> ago when I tried to implement a couple of astronomical
> formulae, always getting false results because C++ calculated
> 3/4=0.
>
> I think the only real reason for people prefering int/int=int
> is that computers can deal with inteters better than with
> floats, resulting in int-only arithmetic in computer
> languages.  However, I don't consider this a particularly good
> reason.

Well, another reason is that there is existing code that
depends on int/int => int.

-- 
Grant Edwards   grante Yow! What a COINCIDENCE!
  at   I'm an authorized "SNOOTS
   visi.comOF THE STARS" dealer!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Grant Edwards]

On 2008-02-26, Paul Rubin  wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
>> > http://en.wikipedia.org/wiki/Natural_number
>> Recheck the context.  I was talking about the natural result, not
>> natural numbers.
>
> The natural result of doing arithmetic with natural numbers is more
> natural numbers.  

OK, but I thought we were talking about computer integers.

-- 
Grant Edwards   grante Yow! My mind is a potato
  at   field ...
   visi.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

Ross Ridge <[EMAIL PROTECTED]> writes:
> > The natural result of doing arithmetic with natural numbers is more
> > natural numbers.  
> 
> D'Arcy said nothing about natural numbers, and bringing them up adds
> nothing to this discussion.

The numbers D'Arcy is proposing to operate on that way are natural
numbers whether he says so or not.

Really, the "natural" division operation on integers, if there is one,
is divmod (which returns a quotient and remainder).  The / (now called
//) operator simply throws away the remainder.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Ross Ridge]

Paul Rubin   wrote:
> http://en.wikipedia.org/wiki/Natural_number

"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> Recheck the context.  I was talking about the natural result, not
> natural numbers.

Paul Rubin   wrote:
> The natural result of doing arithmetic with natural numbers is more
> natural numbers.  

D'Arcy said nothing about natural numbers, and bringing them up adds
nothing to this discussion.

Ross Ridge

-- 
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  [EMAIL PROTECTED]
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //   
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > http://en.wikipedia.org/wiki/Natural_number
> Recheck the context.  I was talking about the natural result, not
> natural numbers.

The natural result of doing arithmetic with natural numbers is more
natural numbers.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Ross Ridge]

D'Arcy J.M. Cain <[EMAIL PROTECTED]> wrote:
>I don't think that it is a travesty either.  I would also not be so
>offended if the language treated it that way from the start although I
>would still have had to get used to it having spent so much time in C
>and assembler which has natural results.  The real problem here is that
>it is an arbitrary, fundamental change to the way the language works.  I
>would be almost as upset if the change was happening the other way.

I feel pretty much the same way.  This change in behaviour is likely to be
the sole reason keeping me from switching to Python 3 for a long time.
If the slash (/) operator had always been defined as floating point
division then I would've gotten used to it.  Now however, there's no
compelling reason for me to try to adjust to this new behaviour.

Ross Ridge

-- 
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  [EMAIL PROTECTED]
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //   
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Terry Reedy]

"Arnaud Delobelle" <[EMAIL PROTECTED]> wrote in message
| >>> 3/5
| 0.59998

I think this either changed in 3.0a2 or may in upcoming releases.




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

Re: How about adding rational fraction to Python?

[D'Arcy J.M. Cain]

On 26 Feb 2008 12:53:48 -0800
Paul Rubin <"http://phr.cx"@NOSPAM.invalid> wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > Note, I use the word "natural" above.  Natural is an opinion and that
> > happens to be mine.  
> 
> http://en.wikipedia.org/wiki/Natural_number

Recheck the context.  I was talking about the natural result, not
natural numbers.

-- 
D'Arcy J.M. Cain <[EMAIL PROTECTED]> |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Paul Rubin]

"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> Note, I use the word "natural" above.  Natural is an opinion and that
> happens to be mine.  

http://en.wikipedia.org/wiki/Natural_number
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Torsten Bronger]

Hallöchen!

Grant Edwards writes:

> [...]
>
> Nope.  I would prefer that int OP int always produce an int.

And 2**-1?

Your formulation tries to suggest some sort of logical consequence
but in my opinion, it's still a mere matter of taste and habits.  I
remember my first steps in C++ 12 years ago when I tried to
implement a couple of astronomical formulae, always getting false
results because C++ calculated 3/4=0.

I think the only real reason for people prefering int/int=int is
that computers can deal with inteters better than with floats,
resulting in int-only arithmetic in computer languages.  However, I
don't consider this a particularly good reason.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
  Jabber ID: [EMAIL PROTECTED]
   (See http://ime.webhop.org for further contact info.)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[D'Arcy J.M. Cain]

On Tue, 26 Feb 2008 14:16:20 -0500
"J. Cliff Dyer" <[EMAIL PROTECTED]> wrote:
> I agree that integer division is useful and important, but I don't think
> it's a travesty to support other kinds of division, especially when
> integer division still has its own operator.

I don't think that it is a travesty either.  I would also not be so
offended if the language treated it that way from the start although I
would still have had to get used to it having spent so much time in C
and assembler which has natural results.  The real problem here is that
it is an arbitrary, fundamental change to the way the language works.  I
would be almost as upset if the change was happening the other way.

Note, I use the word "natural" above.  Natural is an opinion and that
happens to be mine.  I am really having a hard time accepting that
"TRUTH (tm)" is determined by election.  See signature.

-- 
D'Arcy J.M. Cain <[EMAIL PROTECTED]> |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Grant Edwards]

On 2008-02-26, J. Cliff Dyer <[EMAIL PROTECTED]> wrote:

> So do you believe that you should not be able to do natural
> division without explicitly casting ints as floats,

IMO, you're begging the question by using the phrase "natural
division" when what you mean is "floating point division", but
yes, I prefer requiring explicit conversion to floating point.

> or is yourw concern just that you want to still be able to to
> integer division simply?

Nope.  I would prefer that  int OP int always produce an int.

> For me personally, I'm happy knowing that integer division is
> still available through the // operator.  I'm not offended
> that other, highly useful forms of division would be given
> operator status.  Granted, I'm not old school like you, but I
> do appreciate clean design, and typing:
>
> float(3)/4 always struck me as an ugly hack to get integers to do
> something that comes naturally to them--divide into a result outside the
> set of integral numbers.

Again, you're begging the question by using the term "natural"
to describe your opinion. I find int OP int => float to be
unnatural.  It's much too "implicit" for me.

> I agree that integer division is useful and important, but I
> don't think it's a travesty to support other kinds of
> division, especially when integer division still has its own
> operator.

If integer division is going to have it's own operator, why not
the same for integer subtraction or integer multiplication?
Yes, I know the theoretical answer, but from a computer
architecture POV, integer addition and floating point addition
are completely separate and unrelated things.

-- 
Grant Edwards   grante Yow! Well, O.K.
  at   I'll compromise with my
   visi.comprinciples because of
   EXISTENTIAL DESPAIR!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Grant Edwards]

On 2008-02-26, Mensanator <[EMAIL PROTECTED]> wrote:

>> How soon before 2.x is completely deprecated and I have to become a
>> Walmart greeter?
>
> Personally, I plan to drop Python if support for the gmpy module
> ever dries up. But I won't be a quitter, just have to start using
> C which will suck the life out of the room. But what else can I do?

Fork?

-- 
Grant Edwards   grante Yow! The entire CHINESE
  at   WOMEN'S VOLLEYBALL TEAM all
   visi.comshare ONE personality --
   and have since BIRTH!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[Grant Edwards]

On 2008-02-26, Jeff Schwab <[EMAIL PROTECTED]> wrote:
> Grant Edwards wrote:
>
>> I guess it must depend on where you went to shool.
>
> Temple Israel.  You?

Good one. :)

-- 
Grant Edwards   grante Yow! Do you think the
  at   "Monkees" should get gas on
   visi.comodd or even days?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[J. Cliff Dyer]

On Tue, 2008-02-26 at 13:51 -0500, D'Arcy J.M. Cain wrote:
> On Tue, 26 Feb 2008 13:39:38 -0500
> "J. Cliff Dyer" <[EMAIL PROTECTED]> wrote:
> > >>> a = 2 * 2
> > >>> b = 20 * 20
> > >>> type(a)
> > 
> > >>> type(b)
> > 
> 
> A long int is still integral which is the crux of the issue.
> 

So do you believe that you should not be able to do natural division
without explicitly casting ints as floats, or is your concern just that
you want to still be able to to integer division simply?

For me personally, I'm happy knowing that integer division is still
available through the // operator.  I'm not offended that other, highly
useful forms of division would be given operator status.  Granted, I'm
not old school like you, but I do appreciate clean design, and typing:

float(3)/4 always struck me as an ugly hack to get integers to do
something that comes naturally to them--divide into a result outside the
set of integral numbers.

I agree that integer division is useful and important, but I don't think
it's a travesty to support other kinds of division, especially when
integer division still has its own operator.

Cheers,
Cliff


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