subject:"\[Python\-ideas\] Re\: division of integers should result in fractions not floats"

On Sat, 15 May 2021 at 20:52, David Mertz  wrote:
>
> On Sat, May 15, 2021, 3:13 PM Oscar Benjamin
>>
>> That would mean that a simple statement like x = -1.01d could assign 
>> different values depending on the context. Maybe with the new parser it is 
>> easier to change this so that an unary +/- can be part of the literal.
>
> Steven, at least, stated he assumed this decimal literal would be either 
> decimal64 or decimal128. That would remove this exact concern you state.
>
> But decimal64 behaves differently that decimal128, and both have different 
> semantics than Decimal. I don't disagree that decimal128 is a useful data 
> type, but it's definitely a wrinkle for various flavors of "decimal" to arise 
> in various ways. For example, how does this change the numeric tower?

Decimal is not really in the numeric tower:
https://bugs.python.org/issue43602

The question is really what exactly is the rationale for having a new
Decimal type? I guess it's something like:
"""
The decimal module is well suited to more advanced needs but is hard
to use for less experienced users who just want to do some simple
calculation and expect that the arithmetic should work intuitively
unlike binary floating point. We therefore introduce a new decimal
type that is simpler and add literal syntax for that type so that the
barrier to using decimal-based calculations is as low as possible.
"""
Then you need to consider how much easier you are really making things
e.g. 0.1d vs D('0.1'). To what extent can the "hard to use" claim be
countered by improving the docs e.g. by making a simpler explanation
of how to use Decimal for basic calculations and perhaps adding a
brief section to the tutorial?

Most importantly: who is prepared to implement and maintain any of this?

If the proposal is having 0.1d be Decimal('0.1') then that's a lot
easier than introducing a new decimal128 type. If anyone wants to take
this forward then I think that for that version of the proposal a
usable C implementation of e.g. decimal128 is what is needed. I expect
that making a conforming C implementation of decimal128 will be a lot
harder than making a C implementation of Fraction. Making a really
good implementation of either is hard but the "spec" for rational
numbers is much simpler than for decimal floating point.

--
Oscar
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/H7UUQAK6P62TS45RIM34ZHLS3AFYZADH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-15 Thread David Mertz

On Sat, May 15, 2021, 3:13 PM Oscar Benjamin

> That would mean that a simple statement like x = -1.01d could assign
> different values depending on the context. Maybe with the new parser it is
> easier to change this so that an unary +/- can be part of the literal.


Steven, at least, stated he assumed this decimal literal would be either
decimal64 or decimal128. That would remove this exact concern you state.

But decimal64 behaves differently that decimal128, and both have different
semantics than Decimal. I don't disagree that decimal128 is a useful data
type, but it's definitely a wrinkle for various flavors of "decimal" to
arise in various ways. For example, how does this change the numeric tower?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MVDCIMRSYBFJNQ5DVVQV6BTKW3ZJG6QP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

On Sat, 15 May 2021 at 05:54, Steven D'Aprano  wrote:
>
> On Sat, May 15, 2021 at 01:57:29AM +1000, Chris Angelico wrote:
>
> > Decimal literals have a number of awkward wrinkles, so I'd leave them
> > aside for now;
>
> I'm surprised at this.
>
> Decimal literals have come up at least twice in the past, with a general
> consensus that they are a good idea. This is a the first time I've seen
> anyone suggest fraction literals (that I recall). The use of decimal
> literals have a major and immediate benefit to nearly everyone who uses
> Python for calculations: the elimination of rounding error from base-10
> literals like `0.1` and the internal binary representation.

Fraction also has this benefit except in a much more complete way
since *all* arithmetic can be exact. The discussion above has
mentioned the idea that you could write a fraction like `1/10F` or
`1F/10` but I would also want to be able to do something like `0.1F`
to use a decimal literal to represent an exact rational number.

In my experience direct language support for exact rationals is more
common than for decimal floating point. Computing things exactly is a
widely applicable feature whereas wanting a different kind of rounding
error is a more niche application. You mention that in some cases
Decimal gives exactness but if you follow this idea of exact
arithmetic to its conclusion you end up with something like Fraction
rather than something like Decimal.

I suspect that the fact that Python has a more extensively developed
decimal module has probably led many of us familiar with Python to
think that decimal arithmetic is somehow more useful or more commonly
needed or used than rational arithmetic.

> What are these awkward wrinkles for decimal literals?

They are not insurmountable but the main issues to resolve are about
the fact that Python's decimal implementation is a multiprecision
library. Not all decimal implementations are but Python's is. The
precision is controlled by a global context and affects all
operations. The simple way to implement decimal literals would be to
say that 1.001d is the same as Decimal('1.001') but then what about
-1.001d?

The minus sign is not part of the literal but rather an unary
operation so whereas the Decimal(...) constructor is always exact an
unary minus is an "operation" with a behaviour that is context
dependent e.g.:

>>> from decimal import Decimal as D, getcontext
>>> getcontext().prec = 3
>>>
>>> D('0.')
Decimal('0.')
>>> D('-0.')
Decimal('-0.')
>>> -D('0.')
Decimal('-1.00')
>>> +D('0.')
Decimal('1.00')

That would mean that a simple statement like x = -1.01d could assign
different values depending on the context. Maybe with the new parser
it is easier to change this so that an unary +/- can be part of the
literal. The context dependence here also undermines other benefits of
literals like the possibility of constant-folding in e.g. 0.01d +
1.00d (depending on the context this might compute different values or
it might raise an exception or set flags).

The other question is about which other languages to line up with. For
example C might gain a _Decimal128 type and maybe even hardware
support would become widespread for calculations with decimal in these
fixed width formats. Python would be able to leverage those if it
defines its decimals in the same way but that would mean departing
from the multiprecision model that the decimal module currently has.

These and other questions about how to implement decimal literals are
not necessarily hard to overcome but it naturally leads to ideas like:

> The implementation would not support the full General Decimal Arithmetic 
> specification -- for that,
> users would continue to use the decimal module.

Then you have this kind of hybrid where you have two different kinds
of decimal type. Presumably that means that the decimal literals
aren't really there for power users because they need to use the
decimal module with all of its extra features. If the decimal literals
aren't for users of the decimal module then who are they for?

I started trying to write a PEP about decimal literals some time ago
but what I found was that most arguments I could come up with for
decimal literals were really arguments for using decimal floating
point instead of binary floating point in the first place. In other
words if Python did not currently have float types then I would
advocate for using decimal as the *default* float type for literals
like `0.1`. It is problematic that the only non-integer literals in
Python are decimal literals that are converted into binary floating
point format when the vast majority of possible non-integer decimal
literals like `0.12345` can not be represented exactly in binary. Many
humans can understand decimal rounding much easier than binary
rounding so using decimal rounding for non-integer arithmetic would
make Python itself more understandable and intuitive.

We already have float though and it uses binary

[Python-ideas] Re: division of integers should result in fractions not floats

On Sat, 15 May 2021 at 12:52, Steven D'Aprano  wrote:
>
> On Fri, May 14, 2021 at 09:39:33PM +0100, Oscar Benjamin wrote:
>
> > Yes, but having a faster fraction type would be great. SymPy doesn't
> > actually use the fractions module because it's too slow. Instead SymPy
> > has its own pure Python implementation that is a little faster and
> > will use gmpy2's mpq type if gmpy2 is installed. The mpq type is
> > something like 30x faster than Fraction. The fmpq type from
> > python_flint is around twice as fast again and is particularly fast
> > for small rationals.
>
> Can we not improve the implementation of Fraction? What do the non-gmpy
> versions do that makes them faster?
>
> The statistics module relies on Fraction for much of its calculations,
> improving Fraction would have a direct benefit for that. Just sayin'...

SymPy's fallback PythonMPQ class is here:
https://github.com/sympy/sympy/blob/e30fcee96c3dbec337bc665229e5ef685277d56e/sympy/external/pythonmpq.py#L9-L16
It isn't intended to be a public API so for example it doesn't enforce
immutability. That makes accessing numerator and denominator more
efficient than having a property method but this is probably not that
significant. Care is taken to structure operations so that it can
avoid unnecessary gcd calls but that's true of Fraction as well.

The main difference when I checked seemed to be the arithmetic
algorithms but looking now I can see that Fraction was recently
changed to use the same algorithms as SymPy:
https://github.com/python/cpython/commit/690aca781152a498f5117682524d2cd9aa4d7657
It looks like Sergey saw my comments when refactoring the PythonMPQ
code and upstreamed the algorithms.

Maybe it will now be possible to eliminate PythonMPQ which is
redundant with Fraction if Fraction is made faster (once support for
Python 3.9 is dropped).

Oscar
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UV4GVY4MMI6CNZDS3BBR27QZICPUJZZC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-15 Thread Steven D'Aprano

On Fri, May 14, 2021 at 09:39:33PM +0100, Oscar Benjamin wrote:

> Yes, but having a faster fraction type would be great. SymPy doesn't
> actually use the fractions module because it's too slow. Instead SymPy
> has its own pure Python implementation that is a little faster and
> will use gmpy2's mpq type if gmpy2 is installed. The mpq type is
> something like 30x faster than Fraction. The fmpq type from
> python_flint is around twice as fast again and is particularly fast
> for small rationals.

Can we not improve the implementation of Fraction? What do the non-gmpy 
versions do that makes them faster?

The statistics module relies on Fraction for much of its calculations, 
improving Fraction would have a direct benefit for that. Just sayin'...



-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4QFTXHMHIUA6V5IQJT6XC45GXMIFMVC3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

On Sat, 15 May 2021 at 09:55, Steven D'Aprano  wrote:
>
> On Sat, May 15, 2021 at 07:14:47AM -, Martin Teichmann wrote:
>
> > In general, doing symbolic math in Python is not very beautiful.
> [...]
> > It could be fruitful to add syntax for symbolic math, but this is a
> > whole new topic. Looking around there also seems to be not much out
> > there, even dedicated languages like mathematica are honestly pretty
> > ugly.
>
> I think that is unavoidable.
>
> Symbolic maths is a 2D format. It doesn't map easily to a line-based
> format like programming languages. Think of things like summation and
> integration. You need subscripts, superscripts and a two dimensional
> layout of expressions.

SymPy in particular has the property that it is implemented within
Python and is (often) used from Python so for most users there is no
separation between the user-language and the language of
implementation and that constrains what it can provide syntactically.
This is both a strength and a weakness. The strength is that power
users can use a powerful programming language as part of symbolic
manipulation and can build their own primitive routines, subclass the
basic types etc. The weaknesses are things like not being able to make
1/2 be an exact rational.

Of course SymPy is also a library rather than an application and is
used as the backend for many different symbolic applications and has
bindings to other languages so there are also users who use sympy from
e.g. Julia or Octave which use the syntax from those languages so e.g.
you can do something like 2x rather than 2*x in Julia. SymPy is also
used internally as part of Sage which is an application that has a
Python-like syntax but with changes like 1/2 being exact and 2^3 being
the same as 2**3. There are also projects like Mathics which is a
Python project based on SymPy that implements the Mathematica
language.

The issue with float and SymPy is not just about division of ints
though because it's also very common for users to write things like
0.5*m*v**2 without realising that using 0.5 creates a float and that
SymPy will treat that float differently from an exact rational. This
is partly a problem of SymPy's own making and it can be at least
partially solved in SymPy though. In an expression like 0.5*m where m
is a SymPy expression __rmul__ will call sympify which converts the
builtin float to SymPy's symbolic Float type. The majority of users
would be better served if the sympify function would actually convert
the float to an exact Rational and it would be possible to provide a
mode that can do that like:

import sympy
sympy.init_session(auto_float_to_rational=True)

SymPy already has a function that can do this and that can also undo
the rounding errors caused in decimal to binary conversion for
expressions like 0.1:

>>> from sympy import nsimplify
>>> nsimplify(0.1)
1/10

Actually this function goes a bit too far so a more limited form of it
should probably be used:

>>> from math import e
>>> e
2.718281828459045
>>> nsimplify(e)
E
>>> nsimplify(2**0.5)
sqrt(2)

So I don't think changes in Python core are needed for this use case
as the basic issue can be fixed in SymPy itself.

--
Oscar
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2NTNSS7HONNSDIVPZQFPEV44RHO2C4EY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-15 Thread Jonathan Fine

Martin wrote:

In general, doing symbolic math in Python is not very beautiful.

I think this is a problem worth investigating. (Disclaimer: I do research
in pure mathematics.)

> The number of hoops you have to jump through is large, mostly because
> syntax is abused for things it was not actually meant for.
>

I don't completely agree with this diagnosis. I think there are more
serious difficulties. I'd be interested in a discussion on symbolic math in
Python sometime, but perhaps not on this list. I'd like the people who use
and develop https://www.sagemath.org/ to be involved.

-- 
Jonathan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SVTZM6OISSEJ7737WER5I6K4UNGMYYVR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-15 Thread André Roberge

On Sat, May 15, 2021 at 4:18 AM Martin Teichmann 
wrote:

> Hi Chris, Hi List,
>
> having slept over it, I think I have to take back my offer to write a PEP.
> Why? Well, I am actually sure that it will get rejected anyways.
>
> [SNIP]
>
> I see that you would like to sum up the discussion in a PEP so you can
> point future requesters there. But given that there are repeatedly requests
> here, and over at sympy I learned they even wrote a pre-parser, not to
> forget André's efforts presented here, shows that there seems to be an
> actual need.

Sorry if I gave the wrong impression.

I implemented this 1) because I find it fun to experiment with unusual
syntax, and, more importantly 2) because this idea (literal fractions, and
similarly for literal decimal) often comes up on this list and we get
abstract discussions about the (supposed) benefit of such syntax.  I
personally find that actual experimentation with working code is often much
more illuminating when it comes to highlighting the strength and weaknesses
of proposals compared with near-endless mostly abstract discussions often
based on preconceived opinions (at least, that's how I interpret them).

I definitely do not believe that there is a need for fraction literals in
Python, and even less when it comes to having "fractions by default"
without special syntax (or, even worse in my opinion, with syntax that rely
on space surrounding operators.)  Again, sorry if I gave the wrong
impression.

A while ago, I attempted to summarize various discussions on having literal
decimals in Python, with the thought of doing the same for fraction
literals, but did not finish. For those curious, the "summary" so far can
be found at
https://github.com/aroberge/python-ideas-summaries/blob/master/literal-number-types.md
I do think that, if I (or someone else) could complete this summary, it
would be worthwhile writing a PEP and, if it is rejected, we could refer
people to it rather than restarting a new discussion thread on such
recurring topic.  Rejected PEPs can potentially be huge time savers for the
community ...

André Roberge

> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/LFNXM5CILWEF3FQXR6H3KOBL5FUJVOCA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PT5UF2AHLMUNI7HBJSCAYOURW6VLAGZM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-15 Thread Steven D'Aprano

On Sat, May 15, 2021 at 07:14:47AM -, Martin Teichmann wrote:

> In general, doing symbolic math in Python is not very beautiful.
[...]
> It could be fruitful to add syntax for symbolic math, but this is a 
> whole new topic. Looking around there also seems to be not much out 
> there, even dedicated languages like mathematica are honestly pretty 
> ugly.

I think that is unavoidable.

Symbolic maths is a 2D format. It doesn't map easily to a line-based 
format like programming languages. Think of things like summation and 
integration. You need subscripts, superscripts and a two dimensional 
layout of expressions.

CAS calculators like the Nspire and Classpad that support symbolic maths 
also support 2D entry methods. Python would need a GUI IDE to support 
something like that.

We could come up with a preprocessor that would allow you to write 
1/(2π) and get a symbolic expression but its still going to be 
line-oriented and share the same weaknesses as Mathematica syntax.

-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2AL2AGAOKDESGFTIMIMRG7BGYTWM3REY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-15 Thread Chris Angelico

On Sat, May 15, 2021 at 6:24 PM Steven D'Aprano  wrote:
>
> On Sat, May 15, 2021 at 05:28:39PM +1000, Chris Angelico wrote:
>
> > Wouldn't be the first time a PEP has been written with full
> > expectation of it being rejected, though!
>
> Nor the first time that someone wrote a PEP initionally expecting it to
> be rejected, and had it accepted.
>
> *cough* dict union operator *cough*
>

Nor the first time someone wrote a PEP intending for it to be
rejected, and came around to actually liking the idea himself...

Documenting the pros and cons has consequences (and prosequences??)
far beyond our meagre expectations!

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/F2LTH2BW2G6ZKG2B3NIBJFGHCYDL5BXK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-15 Thread Steven D'Aprano

On Sat, May 15, 2021 at 05:28:39PM +1000, Chris Angelico wrote:

> Wouldn't be the first time a PEP has been written with full
> expectation of it being rejected, though!

Nor the first time that someone wrote a PEP initionally expecting it to 
be rejected, and had it accepted.

*cough* dict union operator *cough*


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZITIRF7XO467PQ36TGDSCYVW5PQTE3UX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-15 Thread Chris Angelico

On Sat, May 15, 2021 at 5:15 PM Martin Teichmann
 wrote:
>
> Hi Chris, Hi List,
>
> having slept over it, I think I have to take back my offer to write a PEP. 
> Why? Well, I am actually sure that it will get rejected anyways.

Wouldn't be the first time a PEP has been written with full
expectation of it being rejected, though!

> I see that you would like to sum up the discussion in a PEP so you can point 
> future requesters there. But given that there are repeatedly requests here, 
> and over at sympy I learned they even wrote a pre-parser, not to forget 
> André's efforts presented here, shows that there seems to be an actual need. 
> Telling people: "look at that PEP, we solved that ages ago" would be 
> dishonest, because we did not.
>

A PEP doesn't mean that we've solved anything; it means that there is
a single place where the arguments for and against have been gathered,
rather than searching through email archives.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OVFB5W734JPZXT4FYO2N6FXE327KF6Q2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-15 Thread Martin Teichmann

Hi Chris, Hi List,

having slept over it, I think I have to take back my offer to write a PEP. Why?
Well, I am actually sure that it will get rejected anyways.

What I would like to have is that you can write 1/2 * m * v**2, and that can be
treated symbolically. Writing 1/2F instead looks ugly to me, and then there is
a much easier way to achieve that:

F = Fraction(1)
F*1/2 * m * v**2

that's equally ugly, but I do not need to write a single line of code.

I see that you would like to sum up the discussion in a PEP so you can point
future requesters there. But given that there are repeatedly requests here, and
over at sympy I learned they even wrote a pre-parser, not to forget André's
efforts presented here, shows that there seems to be an actual need. Telling
people: "look at that PEP, we solved that ages ago" would be dishonest, because
we did not.

In general, doing symbolic math in Python is not very beautiful. The number of
hoops you have to jump through is large, mostly because syntax is abused for
things it was not actually meant for.

It could be fruitful to add syntax for symbolic math, but this is a whole new
topic. Looking around there also seems to be not much out there, even dedicated
languages like mathematica are honestly pretty ugly.

Cheers

Martin
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/LFNXM5CILWEF3FQXR6H3KOBL5FUJVOCA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

On Sat, May 15, 2021 at 2:55 PM Steven D'Aprano  wrote:
>
> On Sat, May 15, 2021 at 01:57:29AM +1000, Chris Angelico wrote:
>
> > Decimal literals have a number of awkward wrinkles, so I'd leave them
> > aside for now;
>
> I'm surprised at this.
>
> Decimal literals have come up at least twice in the past, with a general
> consensus that they are a good idea. This is a the first time I've seen
> anyone suggest fraction literals (that I recall).

Well, they've definitely both come up :)

> What are these awkward wrinkles for decimal literals? The past proposals
> have come down to a "d" or "D" suffix, e.g.:
>
> 2.456d
>
> would be a decimal rather than a float.

That part isn't a problem, yep. I'm pretty sure everyone's in
agreement on that (with the possible exception of bikeshedding about
whether it's "d" or "D" or either).

> So as I see it, the only wrinkles would be:
>
> - the choice of a 64- or 128-bit;
> - the internal format (binary or decimal coded);
> - and the coercion rules for arithmetic between mixed types;
>
> but I wouldn't call them *awkward*. They will of course allow for plenty
> of bike-shedding, but the decision should be quite tractable.
>

Mainly it comes down to the fact that there's an implicit set of rules
governing the Decimal constructor (the default context), and literals
cannot follow those. That would mean that a Decimal literal 1.234d
might mean something sneakily and subtly different from
Decimal("1.234"), due to a distinction that might have taken place
long, long ago in a module far, far away (since the default context is
global). I'm going largely on memory here, as a search through
python-ideas history for "decimal literal" produced a couple of
monster threads that were talking about a variety of numeric-related
matters (including Decimal literals, but also including a ton of other
stuff), and I can't find the exact posts in question.

So, let me put it this way: I'm +3/4F on adding a Fraction literal,
-0.25D on adding a Decimal literal, and +1 (the integer!) on writing a
PEP regarding either or both.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XW5OX7ZLJGEHY3KEGOEAJP4WFDTQBYUF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

On Fri, May 14, 2021 at 05:49:57PM -, Martin Teichmann wrote:

> 2/3 would just be the constant 
> two-thirds. 2 / 3 would then mean the same as it used to: divide 2 by 
> 3, giving some 0.666ish.

I don't like your changes of getting a core developer to champion the 
introduction of significant whitespace around operators like that.



-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IKOPSQWVKIELUCGWHEBNL3QWEF3KAK5J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

On Sat, May 15, 2021 at 01:57:29AM +1000, Chris Angelico wrote:

> Decimal literals have a number of awkward wrinkles, so I'd leave them
> aside for now;

I'm surprised at this.

Decimal literals have come up at least twice in the past, with a general
consensus that they are a good idea. This is a the first time I've seen
anyone suggest fraction literals (that I recall). The use of decimal
literals have a major and immediate benefit to nearly everyone who uses
Python for calculations: the elimination of rounding error from base-10
literals like `0.1` and the internal binary representation.

I don't see that literal fractions have anywhere close to the same
immediate benefit for the average user. If anything, I think that it
could be surprising. If somebody uses Python to, e.g., calculate the GST
(Goods and Services Tax) inclusive value of something costing $17.00 ex:

17*11/10

they're probably expecting an answer of 18.7 not Fraction(187, 10).

What are these awkward wrinkles for decimal literals? The past proposals
have come down to a "d" or "D" suffix, e.g.:

2.456d

would be a decimal rather than a float. The implementation would not
support the full General Decimal Arithmetic specification -- for that,
users would continue to use the decimal module.

http://speleotrove.com/decimal/decarith.html

The builtin decimals would be a fixed 64- or 128-bit decimal
implementation.

https://en.wikipedia.org/wiki/Decimal64_floating-point_format

https://en.wikipedia.org/wiki/Decimal128_floating-point_format

Like float, it would support only a minimal set of functionality, e.g.
no context objects with user-configurable traps, precision or rounding
modes.

So as I see it, the only wrinkles would be:

- the choice of a 64- or 128-bit;
- the internal format (binary or decimal coded);
- and the coercion rules for arithmetic between mixed types;

but I wouldn't call them *awkward*. They will of course allow for plenty
of bike-shedding, but the decision should be quite tractable.

--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/JRHSUYUVIJ2O5WEMG7HOYWJOHEBDM4BP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

On Fri, May 14, 2021 at 07:05:43PM -, Martin Teichmann wrote:
> Hi Paul,
> 
> > Also consider the section in the PEP format "How would we teach this?"
> > How would you explain to someone with no programming background, maybe
> > a high school student, that 3/4 and 3 / 4 mean different things in
> > Python? Your audience might not even know that there is a difference
> > between "fraction", "decimal" and "float" at this stage.
> 
> Well, I think a high school student would be the one with the least 
> problems: s/he would just realize "wow, that thing can do fractions! I 
> can do my math homework with that!" And I can tell you, kids will be 
> the first ones to figure out that if you type spaces you get decimals, 
> if you do not type spaces you get fractions. They are used to this 
> kind of stuff from their math class, from calculators (or their 
> phones, I guess).

*raises hand*

Not any students I work with.

No text book I've seen teaches that `1 / 2` and `1/2` are different 
things (one a rational fraction and the other a decimal). And no 
calculator I've seen, and I've seen a lot (I'm a bit of a calculator 
geek...) treats them differently. Most scientific calculators don't even 
have a way of entering spaces.

Both the Texas Instruments "Nspire" and Casio "Classpad" have a global 
setting that controls whether calculations between integers result in 
exact fractional, or symbolic, values, or a potentially inexact decimal 
approximation. The Nspire also allows the user to force a decimal by 
using a decimal point in any of the input values. Spaces make no 
difference in either.

In Python it would be odd to have space sensitivity for operators. For 
every operator ⊕, the presence or absence of surrounding spaces makes no 
difference, provided the operator can be unambiguously parsed:

>>> []or{}
{}

And it applies to the dot pseudo-operator, with the same restriction:

>>> str . find

There's really only one common case where spaces make a difference: 
float literals cannot contain spaces, so `1 .` is interpreted as the 
dot pseudo-operator applied to the int 1, rather than the float `1.`

But that's a consequence of the parsing rules, not a difference in the 
operator.

-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JTSGYHQVRLJRVHIBQBTPHBU6YXAMDBDF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

On Fri, May 14, 2021 at 04:58:08PM -, Martin Teichmann wrote:

> Could I please see an example? This is a real question, by now I ran 
> my prototyped interpreter through quite some libraries, and none made 
> problems like this.

Any script or application that does calculations and formats them for 
display to the user which uses print() or equivalent string formatting 
such as `%s` etc will suddenly start producing output like this:

Fraction(3135227393067235, 17592186044416)

instead of the expected output:

178.217043928

Any library that uses doctests will also suffer similar issues.


> Real world examples I am talking about. Sure, I can easily code an 
> approximation for pi which goes out of hand quickly, but doing this in 
> Python would be just wrong unless you are writing a text book.

An approximation to pi accurate to 15 decimal places is just 
Fraction(884279719003555, 281474976710656), which calculates almost 
instantly and takes only 48 bytes:

>>> sys.getsizeof(Fraction(math.pi))
48

plus another 64 bytes for the numerator and denominator ints themselves.


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BGHD63AI4ETGY2BBKV43C6CNHYOLBG3H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Rob Cliffe via Python-ideas




On 14/05/2021 22:34, Eric V. Smith wrote:


My understanding of the proposal is that OP is only talking about 
 /  becomes a Fraction. So:


x=1
x/2 # unchanged, still yields a float.

It's only literals like "1/2" that would become Fraction(1,2).

This would appear to limit the usefulness of the proposal.  If you 
actually wanted x/y to yield a fraction when x and y were integers, you 
would need an explicit syntax such as Fraction(x,y) or F(x,y) anyway.  
So what's the big deal about having to write Fraction(1,2) or F(1,2) ?

Rob Cliffe
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/46U4V4PPFBDLI4357B4ZDYFZKL5JDAZB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Ethan Furman


On 5/14/21 2:34 PM, Eric V. Smith wrote:

> My understanding of the proposal is that OP is only talking about  
/  becomes a
> Fraction. So:
>
> x=1
> x/2 # unchanged, still yields a float.
>
> It's only literals like "1/2" that would become Fraction(1,2).

Ah -- which means we end up with fractions and fraction math which results in memory and time issues, since most 
fraction/fraction operations return, unsurprisingly, fractions.


--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LO2S4OYQA3PMDBYSPAOLZI4Y36FFGGSH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Eric V. Smith

On 5/14/2021 5:29 PM, Ethan Furman wrote:

On 5/14/21 5:12 AM, Martin Teichmann wrote:

> In order to showcase how that would look like, let me give an 
example session:

>
>  >>> 5/6-4/15
>  17/30
>  >>> a=22/7
>  >>> f"{a}"
>  '22/7'
>  >>> f"{a:f}"
>  '3.142857'
>  >>> from decimal import Decimal
>  >>> Decimal(1/3)
>  Decimal('0.')

This looks very interesting!  I see some confusion on all sides on 
what, exactly, you are proposing.  As best as I can figure, the rules 
for your conversions are something like (where .div. is division and 
.op. is any other operation):

1)  int  .div.  int  --> fraction

2)  int  .op.  fraction  --> fraction

3)  fraction  .op.  non-fraction  --> float

What I am not sure of:

4)  fraction  .op.  fraction  --> ???

5)  fraction  .op.  non-fraction  --> ???

Am I correct on 1-3?  What are you proposing as regards 4 and 5? 

My understanding of the proposal is that OP is only talking about 
 /  becomes a Fraction. So:

x=1
x/2 # unchanged, still yields a float.

It's only literals like "1/2" that would become Fraction(1,2).

Eric

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OHNM7A2NJHTYEAUFGFJPDDPQLRDASCKJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread David Mertz

On Fri, May 14, 2021, 4:31 PM Jonathan Fine  wrote:

> >>> 1/2 + 1/3
>> 5/6
>>  1 / 2 + 1 / 3
>> 0.83
>>
>
> I'm sighted. I can see the difference. I suspect a blind person using a
> screen reader would struggle a lot to spot the difference. (I don't know
> enough about screen readers to be sure.)
>

There's also the fact that approximately 50% of the Python code I've
written will now be broken. If you reverse the meaning, it will be the
complementary 50%.

-100 on this idea.

Actually, even though I suggested before that I liked `1F/3` before, or
perhaps `1/3F` (or either with type coercion rules), I think I've gone to
-0.5 for that also.

Basically, the fact I can do (and often have done) this makes it needless:

from fractions import Fraction as F
x = F(1, 3)

Yours, David...

P.S. A very long time ago, Python only had floor division of ints. I wrote
plenty of `1.0*x/y` code to work around that. It wasn't the worst thing,
but I understand the convenience of promotion to float.

However, the existing `/` was given a backwards incompatible meaning of
"true division" and the new `//` operator took on floor division. I still
believe that was the wrong way around. I thought the existing operator
should keep the same meaning, and a new operator could mean something else.
But so it goes; I adjusted, of course.

Nowadays I remember the distinction by thinking of the first slash as
division, and the second one as the "floor operator." It's a mnemonic, not
the actual machinery, but it works for my brain.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XW6BM6DETD6D34D5WKRUOJVVSN4BDGO7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Ethan Furman

On 5/14/21 5:12 AM, Martin Teichmann wrote:

> In order to showcase how that would look like, let me give an example session:
>
>  >>> 5/6-4/15
>  17/30
>  >>> a=22/7
>  >>> f"{a}"
>  '22/7'
>  >>> f"{a:f}"
>  '3.142857'
>  >>> from decimal import Decimal
>  >>> Decimal(1/3)
>  Decimal('0.')

This looks very interesting!  I see some confusion on all sides on what, exactly, you are proposing.  As best as I can 
figure, the rules for your conversions are something like (where .div. is division and .op. is any other operation):

1)  int  .div.  int  --> fraction

2)  int  .op.  fraction  --> fraction

3)  fraction  .op.  non-fraction  --> float

What I am not sure of:

4)  fraction  .op.  fraction  --> ???

5)  fraction  .op.  non-fraction  --> ???

Am I correct on 1-3?  What are you proposing as regards 4 and 5?

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GIHYCE2R32FXCNAWYJR3S3ICAH7KMCED/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Ethan Furman


On 5/14/21 1:07 PM, Paul Moore wrote:

> All I'm trying to say is "I think that having 1/2
> mean something different than 1 / 2 is unacceptable, because it's too
> easy for people to misunderstand".

Agreed.  Significant white space for control flow is great; for specifying data 
types it's horrible.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3M7Z6ES7Y4MOFIHDESUGRWELCENYXAD5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Oscar Benjamin

On Fri, 14 May 2021 at 19:41, Paul Moore  wrote:
>
> On Fri, 14 May 2021 at 16:54, Martin Teichmann
>  wrote:
> > That is absolutely what I would like to have. The fractions module is very 
> > small, it can easily be made a builtin. This would also speed it up 
> > significantly, I hope. Probably close to the speed of floats, given that 
> > most of the time spent for floats is whithin the interpreter anyways.

Exact rational arithmetic is much slower than floating point because
of the gcd calculations and because of bit growth. Even with CPython
interpreter overhead and a highly optimised C implementation
calculations with simple rationals would still be noticeably slower
than float. That's with simple rationals though: once you start doing
arithmetic with rationals the bitcount typically grows and the
computational cost of elementary operations is unbounded if there is
no limit on the bit count.

As an example consider something like Gaussian elimination which is a
basic algorithm for solving systems of equations or for inverting
matrices etc. The algorithm is O(n^3) in the number of elementary
add/multiply operations and if you write that algorithm for
fixed-width floating point and time it with random matrices then you
will be able to see the n^3 performance. When you write the same
algorithm using exact rationals the complexity in terms of bit
operations can grow exponentially. Leaving aside rationals, just
applying Gaussian elimination to a matrix of exact integers can be
done with modified algorithms but those are still O(n^5) because of
bit growth. This is the basic reason why floating point is more
commonly used than exact rational arithmetic: it provides bounded
computational cost for elementary operations. For most numerical
applications it is better to have bounded computation in exchange for
all of the other problems that rounding errors and inexact arithmetic
lead to.

> Builtins have to be in C, with very few exceptions. That makes it
> harder for alternative implementations, who now have to write their
> own implementation rather than just grabbing the pure Python stdlib
> version. It also makes maintenance harder, and means that bugs take
> longer to get fixed, as fewer people know how to maintain the code.

Yes, but having a faster fraction type would be great. SymPy doesn't
actually use the fractions module because it's too slow. Instead SymPy
has its own pure Python implementation that is a little faster and
will use gmpy2's mpq type if gmpy2 is installed. The mpq type is
something like 30x faster than Fraction. The fmpq type from
python_flint is around twice as fast again and is particularly fast
for small rationals. I'm referring to the time difference for small
fractions but more efficient integer implementations used in these
libraries mean that the speed difference increases for larger bit
counts. For some operations in SymPy this speed ratio translates
directly to the time taken for a slow user-level calculation.

The increased inherent cost of rational arithmetic actually means that
with an efficient implementation of a fraction class pure Python code
can compete for speed with code written in C. Maybe SymPy is a
specialist library that should use other specialist libraries for
faster integer and rational arithmetic but to me the Fraction class is
clearly the kind of thing that should be on the C side of the
implementation. The current Fraction class is great for basic use but
too slow for larger calculations.

--
Oscar
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PUOJFSZR5UFTVRBUEY7RV37MT5VFNM3V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Jonathan Fine

Martin wrote

So, if you show them (the following is fake)
>
> >>> 1/2 + 1/3
> 5/6
>  1 / 2 + 1 / 3
> 0.83
>
> They will immediately spot what's going on.
>

I'm sighted. I can see the difference. I suspect a blind person using a
screen reader would struggle a lot to spot the difference. (I don't know
enough about screen readers to be sure.)

-- 
Jonathan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XYI6GUEN3IQUGG24ABO4Q4R677SGM3SL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Paul Moore

On Fri, 14 May 2021 at 20:06, Martin Teichmann
 wrote:
> > Also consider the section in the PEP format "How would we teach this?"
> > How would you explain to someone with no programming background, maybe
> > a high school student, that 3/4 and 3 / 4 mean different things in
> > Python? Your audience might not even know that there is a difference
> > between "fraction", "decimal" and "float" at this stage.
>
> Well, I think a high school student would be the one with the least problems: 
> s/he would just realize "wow, that thing can do fractions! I can do my math 
> homework with that!" And I can tell you, kids will be the first ones to 
> figure out that if you type spaces you get decimals, if you do not type 
> spaces you get fractions. They are used to this kind of stuff from their math 
> class, from calculators (or their phones, I guess).

OK, maybe I chose a bad example. Maybe I should have said "PL/SQL
programmers who don't really understand much of the theory behind
programming, but are just interested in getting the job done, who have
picked up some Python code written by someone else and have to fix it
because the automation script broke and the normal guy isn't in the
office today". I can give you names, if you want :-)

> So, if you show them (the following is fake)
>
> >>> 1/2 + 1/3
> 5/6
>  1 / 2 + 1 / 3
> 0.83
>
> They will immediately spot what's going on.

In effect you're saying "we don't need to teach it because it's
obvious". I disagree. There's certainly some audiences who won't find
it intuitive. How do we teach it to them?

But I'm not really interested in going into ever more detail on this
point to be honest. All I'm trying to say is "I think that having 1/2
mean something different than 1 / 2 is unacceptable, because it's too
easy for people to misunderstand". You may choose to disagree with me,
which is fine. But at some point, the responsibility has to be on you
to persuade people that your idea is good, so you can't do that
indefinitely.

I'd still like to see a more precise explanation of your proposal. I'm
finding that every time I try to guess details of what you mean, I'm
guessing wrong, and that's not productive (for me or for you).

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/D2EPU33EPKEWQLZPN4EJXMPC3A4PH3H2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

Hi Paul,

> Also consider the section in the PEP format "How would we teach this?"
> How would you explain to someone with no programming background, maybe
> a high school student, that 3/4 and 3 / 4 mean different things in
> Python? Your audience might not even know that there is a difference
> between "fraction", "decimal" and "float" at this stage.

Well, I think a high school student would be the one with the least problems: 
s/he would just realize "wow, that thing can do fractions! I can do my math 
homework with that!" And I can tell you, kids will be the first ones to figure 
out that if you type spaces you get decimals, if you do not type spaces you get 
fractions. They are used to this kind of stuff from their math class, from 
calculators (or their phones, I guess).

So, if you show them (the following is fake)

>>> 1/2 + 1/3
5/6
 1 / 2 + 1 / 3
0.83

They will immediately spot what's going on.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7KD7D3GVDMGQ2FVQXMTUQZU4GDL2W3Y4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

Hi Chris,

> Not seeing anything there about decoupling the two modules?

Well, the PR removes the line "from decimal import Decimal", I think that is 
quite some decoupling. The other place decimal is imported is in a classmethod 
only existing for backwards compatibility, so with this patch the decimal 
module does not need to be imported anymore.

Cheers

Martin
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LIM6QIOBYSSTNEB4C65YK3O676E6YLBZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Guido van Rossum

I should probably explain (again) why I am not a fan of such a change. I
blogged about this before -- this is mostly a treatise about / vs. //, but
it explains my reservations about this proposal as well:
http://python-history.blogspot.com/2009/03/problem-with-integer-division.html

In particular:

"""
For example, in ABC, when you divided two integers, the result was an exact
rational number representing the result. [...]

In my experience, rational numbers didn't pan out as ABC's designers had
hoped. A typical experience would be to write a simple program for some
business application (say, doing one’s taxes), and find that it was running
much slower than expected. After some debugging, the cause would be that
internally the program was using rational numbers with thousands of digits
of precision to represent values that would be truncated to two or three
digits of precision upon printing. This could be easily fixed by starting
an addition with an inexact zero, but this was often non-intuitive and hard
to debug for beginners.
"""

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3J5DRJLHZYL33ZBTN4SOR7PNYEZ3IKYC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Paul Moore

On Fri, 14 May 2021 at 16:54, Martin Teichmann
 wrote:
> That is absolutely what I would like to have. The fractions module is very 
> small, it can easily be made a builtin. This would also speed it up 
> significantly, I hope. Probably close to the speed of floats, given that most 
> of the time spent for floats is whithin the interpreter anyways.

Builtins have to be in C, with very few exceptions. That makes it
harder for alternative implementations, who now have to write their
own implementation rather than just grabbing the pure Python stdlib
version. It also makes maintenance harder, and means that bugs take
longer to get fixed, as fewer people know how to maintain the code.

> This is why I proposed not to make a new literal. With my proposal, I already 
> served two of your proposed use cases: fractions and decimal. Decimal(1/3) 
> would be perfectly fine. Plus symbolic math.

But I don't want Decimal(1/3), I want Decimal(0.01).

> Effectively what I am proposing is lazy evaluation of the divison operator, 
> using fractions as a mathematical tool.

Well, you don't need fractions (as in the fractions *module* and the
Fraction *type*) for lazy evaluation. You can just use a tuple of
numerator and denominator. But that's just details. What's more
critical is when you do the actual conversion to float. In other
words, how lazy would this be in reality?

What about

isinstance(1/3, float)
Decimal(1/3)

If you convert to float too quickly, there's no benefit. If you delay,
there's a period where the difference is detectable. And that's a
breaking change. I'm very impressed that you made the actual
interpreter change and checked both the test suite and real-world code
like numpy, but that doesn't mean nothing changed.

At a minimum, I'd suggest that you need to specify *exactly* when the
division is actually executed.

But actually, I suspect that you really *do* want 1/3 to be a
`fractions.Fraction` object. So see above. And in addition, you still
have the question about when, and how, the conversion to float
happens. Because Fraction doesn't magically convert to a float - so
the behaviour of the object returned from the expression 1/3 very
definitely *isn't* the behaviour of Fraction(1,3).

I guess I'm confused. I'm -1 on a proposal that I don't understand, so
I'll have to wait for a clearer explanation of what you're suggesting.

>From other emails:

> actually have a new idea about how a fraction literal could look like: just 
> write 2/3 as opposed to 2 / 3, and you get a fraction. So: no spaces: 
> fraction, with spaces: float.

That would break code that currently writes 2/3 and expects a float.

I'm fine with speculation, but I think you need to be a *lot* more
conscious of what counts as backward incompatibility here. I'm not
saying we can't break backward compatibility, but we need to do so
consciously, and having assessed the consequences, not just because we
assumed "no-one will do that".

Also consider the section in the PEP format "How would we teach this?"
How would you explain to someone with no programming background, maybe
a high school student, that 3/4 and 3 / 4 mean different things in
Python? Your audience might not even know that there is a difference
between "fraction", "decimal" and "float" at this stage.

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QCZZN3N2Z6QAHC3IV2BZOMGFMJPGUOOU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Richard Damon

On 5/14/21 12:58 PM, Martin Teichmann wrote:
> Hi Richard,
>
>> I would say that I have enough code that does division of numbers that
>> might be integers that expect it to be relatively efficient as floats,
>> and I suspect so do others, that the backwards breaks would be
>> significant.
> Could I please see an example? This is a real question, by now I ran my 
> prototyped interpreter through quite some libraries, and none made problems 
> like this.
>
> Real world examples I am talking about. Sure, I can easily code an 
> approximation for pi which goes out of hand quickly, but doing this in Python 
> would be just wrong unless you are writing a text book.
>
> Cheers
>
> Martin

Do to company rules, I can't publish the actual code, but the input data
is all integers, and I am building up a curve fit where I sum thousands
of distinct values, some of which are ratios of data. If that division
became an fraction, because the denominators are all different values,
the resultant sum would get to be very big numbers (basiclly the least
common multiple of hundreds of numbers in the range of thousands.

As floats, this sumation is quick. If done with 'exact fractional' math,
I suspect it slows down by several orders of magnitude, going from sub
second to maybe an hour. That would be totally unacceptable.

Yes, the fix would likely be changing one line of the program to force
the results to be a float, but if the program is on the factory floor
and just working. If IT at some point updates the version of python
being used due to some security release being needed, suddenly programs
like this just stop running as they grind to a halt.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/M2QCN47WWUAIYWWKYO4OMN3UB54KFMRM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

On Sat, May 15, 2021 at 4:18 AM Ricky Teachey  wrote:
>
> On Fri, May 14, 2021 at 2:09 PM Ricky Teachey  wrote:
>>
>> On Fri, May 14, 2021 at 1:14 PM André Roberge  
>> wrote:
>>>
>>>
>>> You can already experiment with this.
>>>
>>
>> Thanks Andre I tried it out and it works great.
>>
>> Do the appended capital Fs make these numbers look like some kind of 
>> hexadecimal representation or is it just me?
>
>
> Actually it just hit me: I don't know if this will be considered a big 
> difficulty or not, but currently you can write division operations using 
> hexadecimal numbers:
>
>  >>> 0xF / 0xF
>  1.0
>
> And this works in Andre's experimental implementation like so for fractions 
> of hex numbers:
>
>  >>> 0xF / 0xF F
>  Fraction(1, 1)
>
> But it looks... funny. I don't know if is is good or bad. It just is.
>

I can't imagine that this would be a normal thing, and I wouldn't be
averse to specifying that a Fraction literal consist of a sequence of
digits (and optionally underscores) followed immediately, without
whitespace, by the letter F. Basically the same kinds of rules as for
an imaginary literal, only without the decimal point. Keep it simple,
keep it easy.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HCYCCMBSX6NWVU2TVLTL4FASH7OYEEJG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread André Roberge

On Fri, May 14, 2021 at 3:09 PM Ricky Teachey  wrote:

> On Fri, May 14, 2021 at 1:14 PM André Roberge 
> wrote:
>
>>
>> You can already experiment with this.
>>
>>
>> First, install a few packages
>>
>> python -m pip install ideas  # will also install token-utils
>> python -m pip install fraction-literal
>>
>>
>> Next, start your standard Python interpreter and do the following:
>>
>> >>> from ideas import experimental_syntax_encoding
>> >>> from ideas import console
>> >>> console.start()
>> Configuration values for the console:
>> transform_source: 
>> --
>> Ideas Console version 0.0.19. [Python version: 3.7.8]
>>
>> ~>> from experimental-syntax import fraction_literal
>> ~>> 2/3F
>> Fraction(2, 3)
>> ~>>
>>
>> Appending an "F" after integer fractions literal is all that is needed.
>>
>> André Roberge
>>
>
> Thanks Andre I tried it out and it works great.
>
> Do the appended capital Fs make these numbers look like some kind of
> hexadecimal representation or is it just me?
>
No, it was F for Fraction.  Any integer followed by "F" will be transformed
into a fraction.Fraction instance.

You can also install decimal-literal as use D as a suffix.

I had mentioned this in a previous message on this list (See
https://www.mail-archive.com/python-ideas@python.org/msg24946.html)

André


>
> ---
> Ricky.
>
> "I've never met a Kentucky man who wasn't either thinking about going home
> or actually going home." - Happy Chandler
>
>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HA6VRSSKUBCQF57ULEY27SFPDO3WU4TY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

s/non-integer/non-decimal-integer/

On Fri, 2021-05-14 at 11:23 -0700, Paul Bryan wrote:
> I'll vote: bad. I don't think non-integer representations of fraction
> attributes should be considered valid when expressing as a literal.
> 
> On Fri, 2021-05-14 at 14:17 -0400, Ricky Teachey wrote:
> > On Fri, May 14, 2021 at 2:09 PM Ricky Teachey 
> > wrote:
> > > On Fri, May 14, 2021 at 1:14 PM André Roberge
> > >  wrote:
> > > > 
> > > > You can already experiment with this.
> > > > 
> > > > 
> > > 
> > > 
> > > Thanks Andre I tried it out and it works great.
> > > 
> > > Do the appended capital Fs make these numbers look like some kind
> > > of hexadecimal representation or is it just me?
> > > 
> > 
> > 
> > Actually it just hit me: I don't know if this will be considered a
> > big difficulty or not, but currently you can write division
> > operations using hexadecimal numbers:
> > 
> >  >>> 0xF / 0xF
> >  1.0
> > 
> > And this works in Andre's experimental implementation like so for
> > fractions of hex numbers:
> > 
> >  >>> 0xF / 0xF F
> >  Fraction(1, 1)
> > 
> > But it looks... funny. I don't know if is is good or bad. It just
> > is.
> >  
> > 
> > ---
> > Ricky.
> > 
> > "I've never met a Kentucky man who wasn't either thinking about
> > going home or actually going home." - Happy Chandler
> > 
> > 
> > ___
> > Python-ideas mailing list -- python-ideas@python.org
> > To unsubscribe send an email to python-ideas-le...@python.org
> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > Message archived at
> > https://mail.python.org/archives/list/python-ideas@python.org/message/JRRIRYO45UFLF5XTDK6PQQFW2GNX6J4X/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> 
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/NBRDJPMW7D22VZIVUKXBHBAQ7UBQJXGJ/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/M5VEVJI3UZHJXJ6IC7F3QML5ZJXDZ6ZA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

I'll vote: bad. I don't think non-integer representations of fraction
attributes should be considered valid when expressing as a literal.

On Fri, 2021-05-14 at 14:17 -0400, Ricky Teachey wrote:
> On Fri, May 14, 2021 at 2:09 PM Ricky Teachey 
> wrote:
> > On Fri, May 14, 2021 at 1:14 PM André Roberge
> >  wrote:
> > > 
> > > You can already experiment with this.
> > > 
> > > 
> > 
> > 
> > Thanks Andre I tried it out and it works great.
> > 
> > Do the appended capital Fs make these numbers look like some kind
> > of hexadecimal representation or is it just me?
> > 
> 
> 
> Actually it just hit me: I don't know if this will be considered a
> big difficulty or not, but currently you can write division
> operations using hexadecimal numbers:
> 
>  >>> 0xF / 0xF
>  1.0
> 
> And this works in Andre's experimental implementation like so for
> fractions of hex numbers:
> 
>  >>> 0xF / 0xF F
>  Fraction(1, 1)
> 
> But it looks... funny. I don't know if is is good or bad. It just is.
>  
> 
> ---
> Ricky.
> 
> "I've never met a Kentucky man who wasn't either thinking about going
> home or actually going home." - Happy Chandler
> 
> 
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/JRRIRYO45UFLF5XTDK6PQQFW2GNX6J4X/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NBRDJPMW7D22VZIVUKXBHBAQ7UBQJXGJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Ricky Teachey

On Fri, May 14, 2021 at 2:09 PM Ricky Teachey  wrote:

> On Fri, May 14, 2021 at 1:14 PM André Roberge 
> wrote:
>
>>
>> You can already experiment with this.
>>
>>
> Thanks Andre I tried it out and it works great.
>
> Do the appended capital Fs make these numbers look like some kind of
> hexadecimal representation or is it just me?
>

Actually it just hit me: I don't know if this will be considered a big
difficulty or not, but currently you can write division operations using
hexadecimal numbers:

 >>> 0xF / 0xF
 1.0

And this works in Andre's experimental implementation like so for fractions
of hex numbers:

 >>> 0xF / 0xF F
 Fraction(1, 1)

But it looks... funny. I don't know if is is good or bad. It just is.


---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JRRIRYO45UFLF5XTDK6PQQFW2GNX6J4X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Ricky Teachey

On Fri, May 14, 2021 at 1:14 PM André Roberge 
wrote:

>
> You can already experiment with this.
>
>
> First, install a few packages
>
> python -m pip install ideas  # will also install token-utils
> python -m pip install fraction-literal
>
>
> Next, start your standard Python interpreter and do the following:
>
> >>> from ideas import experimental_syntax_encoding
> >>> from ideas import console
> >>> console.start()
> Configuration values for the console:
> transform_source: 
> --
> Ideas Console version 0.0.19. [Python version: 3.7.8]
>
> ~>> from experimental-syntax import fraction_literal
> ~>> 2/3F
> Fraction(2, 3)
> ~>>
>
> Appending an "F" after integer fractions literal is all that is needed.
>
> André Roberge
>

Thanks Andre I tried it out and it works great.

Do the appended capital Fs make these numbers look like some kind of
hexadecimal representation or is it just me?

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NTSDSIOCNQSVU7BHZGUY6FEC72ZDDS6V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

On Sat, May 15, 2021 at 3:51 AM Martin Teichmann
 wrote:
>
> Hi Chris,
>
> I think you did not get my point. I do not want to allow x/y. I want to only 
> allow literals, as in 3/2. This would then be a new kind of literal, that has 
> the type of Fraction. Much like 2.5 is a float, but x.y means something 
> completely different, even though it has no spaces. So x/y would mean "divide 
> x by y" or actually call __truediv__ on x plus some details, while 2/3 would 
> just be the constant two-thirds. 2 / 3 would then mean the same as it used 
> to: divide 2 by 3, giving some 0.666ish.
>

Ahhh, I see what you mean.

That's more plausible than what I was thinking of, but I think it'd
still be cleaner to just adorn an integer with a letter to mark that
it should be a Fraction instead (since Fraction divided by int, or int
divided by Fraction, will yield the correct Fraction result).

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WJVXHMUPJFFJGI4XAJJKU2Z5WI7QJVK7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

Hi Chris,

I think you did not get my point. I do not want to allow x/y. I want to only 
allow literals, as in 3/2. This would then be a new kind of literal, that has 
the type of Fraction. Much like 2.5 is a float, but x.y means something 
completely different, even though it has no spaces. So x/y would mean "divide x 
by y" or actually call __truediv__ on x plus some details, while 2/3 would just 
be the constant two-thirds. 2 / 3 would then mean the same as it used to: 
divide 2 by 3, giving some 0.666ish.

Cheers

Martin
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SFQ2TOYXN6F2RKIKJRDW57AYXKVJ5AMB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Serhiy Storchaka

14.05.21 15:12, Martin Teichmann пише:
> when dividing two integers, the result is a float, which means we immediately 
> lose precision. This is not good if you want to use code which supports 
> higher precision. Decimals come to mind, but also sympy. This loss of 
> precision could be avoided if the result of a division is a fraction instead: 
> a fraction is exact.

Please read
http://python-history.blogspot.com/2009/03/problem-with-integer-division.html
.

In short, it was a feature of Python's predecessor, ABC. But it turned
out to be not as good as it seemed at first glance. Fixing this mistake
was one of causes of creating Python.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GU56CA7VEE2QFENSGO4HMZOORR22MOUX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread André Roberge

On Fri, May 14, 2021 at 12:40 PM Martin Teichmann <
martin.teichm...@gmail.com> wrote:

> Hi Paul,
>
> I would be fine with a new division operator or fraction literal as well,
> and in the beginning this is what I actually wanted to propose.
>

You can already experiment with this.


First, install a few packages

python -m pip install ideas  # will also install token-utils
python -m pip install fraction-literal


Next, start your standard Python interpreter and do the following:

>>> from ideas import experimental_syntax_encoding
>>> from ideas import console
>>> console.start()
Configuration values for the console:
transform_source: 
--
Ideas Console version 0.0.19. [Python version: 3.7.8]

~>> from experimental-syntax import fraction_literal
~>> 2/3F
Fraction(2, 3)
~>>

Appending an "F" after integer fractions literal is all that is needed.

André Roberge



>
> But then I started prototyping, and given that it is not so easy to change
> the parser, I just changed the normal division operator. And interestingly,
> nearly nothing broke.
>
> The biggest compatibility problem I actually experienced was the
> completely unrelated breaking of PyCode_New in recent commits of CPython,
> which made using cython and thus numpy impossible. That was so hard to
> tackle I actually gave up and simply branched of an older version of
> CPython. What I want to say with that is: we are happily breaking
> compatibility for more minor stuff. I think my proposal would be a major
> improvement, which would warrant breaking of compatiblity, especially
> because this break of compatibility is astonishingly small. As said above,
> I already installed unmodified numpy, sympy, cython and all their tool
> chains.
>
> Cheers
>
> Martin
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/ZAB5CTTFQ2FOUZQOCYCZZ7EEDJ3P2SPR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SEGXOKXCIGFU636JZEDI53NATUP65FJG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

Premature send with incomplete info, sorry!

On Sat, May 15, 2021 at 3:01 AM Chris Angelico  wrote:
>
> On Sat, May 15, 2021 at 2:55 AM Martin Teichmann
>  wrote:
> >
> > Hi Chris,
> >
> > I would be willing to write such a PEP. It will take a while though, I am 
> > not fast at those kinda things.
>
> Cool cool. Feel free to email me off-list about getting started;
> here's some handy info to read:

https://www.python.org/dev/peps/pep-0001/
https://www.python.org/dev/peps/pep-0012/

> > I actually have a new idea about how a fraction literal could look like: 
> > just write 2/3 as opposed to 2 / 3, and you get a fraction. So: no spaces: 
> > fraction, with spaces: float.
> >
> > I hear you crying "but that's illegal, whitespace should not matter!", to 
> > which I respond:
> >
> > >>> 3.real
> >   File "", line 1
> > 3.real
> >  ^
> > SyntaxError: invalid syntax
> > >>> 3 . real
> > 3

That's a syntactic matter, and it's not actually whitespace
necessarily that does it.

>>> (3).real
3
>>> x = 3
>>> x.real
3
>>> x . real
3

So, no, whitespace or lack thereof should not drastically change the
behaviour. In any case, this would still need to be defined as a new
operator, so that different types can react appropriately, so you
don't really gain much in return for sacrificing readability by having
x/y be different from x / y !

But there's no real reason to create a new operator if it can be done
in a simpler way.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SKD7RGYY2VNMHVFSEJZA4HZ34DZ53R6L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

On Sat, May 15, 2021 at 2:55 AM Martin Teichmann
 wrote:
>
> Hi Chris,
>
> I would be willing to write such a PEP. It will take a while though, I am not 
> fast at those kinda things.

Cool cool. Feel free to email me off-list about getting started;
here's some handy info to read:

https://www.python.org/dev/peps/pep-0012/

> > Currently, fractions.py imports decimal.py, mainly (purely?) for the
> > sake of being able to construct a Fraction from a Decimal. The decimal
> > module is *large* and has other reasons for not becoming builtin too,
> > so ideally, the two should be decoupled.
>
> I started the decoupling as bpo-44115, aka GH-26064 
> https://github.com/python/cpython/pull/26064
> I would be happy about your comments there.

Not seeing anything there about decoupling the two modules?

> I actually have a new idea about how a fraction literal could look like: just 
> write 2/3 as opposed to 2 / 3, and you get a fraction. So: no spaces: 
> fraction, with spaces: float.
>
> I hear you crying "but that's illegal, whitespace should not matter!", to 
> which I respond:
>
> >>> 3.real
>   File "", line 1
> 3.real
>  ^
> SyntaxError: invalid syntax
> >>> 3 . real
> 3
>
> Cheers
>
> Martin
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/3XWRLCHB4UQT25Z7RKU2DE2NE7ALC26D/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/K3XSI3A4YZQKKANZVEDDGLODQLSQGWUM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

Hi Richard,

> I would say that I have enough code that does division of numbers that
> might be integers that expect it to be relatively efficient as floats,
> and I suspect so do others, that the backwards breaks would be
> significant.

Could I please see an example? This is a real question, by now I ran my 
prototyped interpreter through quite some libraries, and none made problems 
like this.

Real world examples I am talking about. Sure, I can easily code an 
approximation for pi which goes out of hand quickly, but doing this in Python 
would be just wrong unless you are writing a text book.

Cheers

Martin
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DZ45KK3KHW3Y3UQZGFJZTDCY5JYE7RE4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

Hi Chris,

I would be willing to write such a PEP. It will take a while though, I am not 
fast at those kinda things.

> Currently, fractions.py imports decimal.py, mainly (purely?) for the
> sake of being able to construct a Fraction from a Decimal. The decimal
> module is *large* and has other reasons for not becoming builtin too,
> so ideally, the two should be decoupled.

I started the decoupling as bpo-44115, aka GH-26064 
https://github.com/python/cpython/pull/26064
I would be happy about your comments there.

I actually have a new idea about how a fraction literal could look like: just 
write 2/3 as opposed to 2 / 3, and you get a fraction. So: no spaces: fraction, 
with spaces: float.

I hear you crying "but that's illegal, whitespace should not matter!", to which 
I respond:

>>> 3.real
  File "", line 1
3.real
 ^
SyntaxError: invalid syntax
>>> 3 . real
3

Cheers

Martin
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3XWRLCHB4UQT25Z7RKU2DE2NE7ALC26D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Richard Damon

On 5/14/21 12:16 PM, Ricky Teachey wrote:
> On Fri, May 14, 2021 at 12:02 PM Chris Angelico  > wrote:
>
> On Sat, May 15, 2021 at 1:47 AM Martin Teichmann
> mailto:martin.teichm...@gmail.com>>
> wrote:
> >
> > Hi David,
> >
> > > A toy example with a half dozen operations won't make huge
> fractions. A
> > > loop over a million operations will often be a gigantic memory
> hog.
> >
> > I do not propose to do that, and I agree that it would be
> stupid. Usually, the fraction gets very quickly converted into a
> float, and your millions of operations will be done with floats.
> >
>
> But if integer division gave a Fraction, then at what point would it
> be converted into a float? As long as all the literals are integers,
> it would remain forever a rational, and adding fractions does get
> pretty costly.
>
> ChrisA
>
>
> I think most of the time, people just want to do an accurate enough
> division operation and don't really have an opinion what the output
> type is (so long as it works), but for the situations where the type
> really really does matter, you can choose the type by using
> Fraction(1,2) or 1/2. If precision is critical, you can already have
> it with the Fraction choice.
>
> But I would also assume there are probably some fraction (tee hee) of
> situations where people specifically want/need a float from an integer
> division operation and NOT a fraction, and would either have to take
> the extra step to convert it. If you're in a loop doing millions of
> conversions, seems like that could get slow. 
>
> A way around this would be to add a new integer division operation
> that returns float:
>
>     >>> 1/2
>     Fraction(1, 2)
>     >>> 1//2
>     0
>     >>> 1///2  # new float division operator
>     0.5
>
> But that doesn't seem like a very optimal solution to me.
>
> So +1 for fraction literal PEP (not sure I would want it approved or
> not, but it should get a full hearing), -1 for changing the output
> type of integer division.
>
> ---
> Ricky.
>
> "I've never met a Kentucky man who wasn't either thinking about going
> home or actually going home." - Happy Chandler
>
If anything like this was done, the NEW operator needs to be the
fraction and the original / the float, for backwards compatibility.

I would say that I have enough code that does division of numbers that
might be integers that expect it to be relatively efficient as floats,
and I suspect so do others, that the backwards breaks would be
significant. The cases where you really need the fraction are much
smaller, and if you do, having a convenient way to ask for it could be
useful, but not so useful that it is worth breaking all the code that
expects floats.

It wouldn't be quite as bad as the python2 -> python3 string/bytes
changes, but the comparison isn't totally out of line.

-- 
Richard Damon

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WHXATVLUK33YROFZNC3U3ALMLQWIVURP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Ricky Teachey

On Fri, May 14, 2021 at 12:02 PM Chris Angelico  wrote:

> On Sat, May 15, 2021 at 1:47 AM Martin Teichmann
>  wrote:
> >
> > Hi David,
> >
> > > A toy example with a half dozen operations won't make huge fractions. A
> > > loop over a million operations will often be a gigantic memory hog.
> >
> > I do not propose to do that, and I agree that it would be stupid.
> Usually, the fraction gets very quickly converted into a float, and your
> millions of operations will be done with floats.
> >
>
> But if integer division gave a Fraction, then at what point would it
> be converted into a float? As long as all the literals are integers,
> it would remain forever a rational, and adding fractions does get
> pretty costly.
>
> ChrisA
>

I think most of the time, people just want to do an accurate enough
division operation and don't really have an opinion what the output type is
(so long as it works), but for the situations where the type really really
does matter, you can choose the type by using Fraction(1,2) or 1/2. If
precision is critical, you can already have it with the Fraction choice.

But I would also assume there are probably some fraction (tee hee) of
situations where people specifically want/need a float from an integer
division operation and NOT a fraction, and would either have to take the
extra step to convert it. If you're in a loop doing millions of
conversions, seems like that could get slow.

A way around this would be to add a new integer division operation that
returns float:

>>> 1/2
Fraction(1, 2)
>>> 1//2
0
>>> 1///2  # new float division operator
0.5

But that doesn't seem like a very optimal solution to me.

So +1 for fraction literal PEP (not sure I would want it approved or not,
but it should get a full hearing), -1 for changing the output type of
integer division.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EYXENNUN5KCIUE2XB3DT3EZ5YXGQINIO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

On Sat, May 15, 2021 at 1:47 AM Martin Teichmann
 wrote:
>
> Hi David,
>
> > A toy example with a half dozen operations won't make huge fractions. A
> > loop over a million operations will often be a gigantic memory hog.
>
> I do not propose to do that, and I agree that it would be stupid. Usually, 
> the fraction gets very quickly converted into a float, and your millions of 
> operations will be done with floats.
>

But if integer division gave a Fraction, then at what point would it
be converted into a float? As long as all the literals are integers,
it would remain forever a rational, and adding fractions does get
pretty costly.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6SI5N4JJ352IZ5OHOL4YRPHPA3SJZ2DY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

On Sat, May 15, 2021 at 1:39 AM Paul Moore  wrote:
>
> On Fri, 14 May 2021 at 16:29, David Mertz  wrote:
> > That said, Chris's idea for a literal spelling of "Fraction" is very 
> > appealing. One extra letter or symbol could indicate that you want to work 
> > in the Fraction domain rather than floating point. That's a perfectly 
> > reasonable decision for a user to make.
>
> Agreed, it is appealing. The problem (and this is not a new
> suggestion, it's come up a number of times)

Interestingly, even though it's definitely been proposed periodically,
it actually hasn't been codified into a PEP except for PEP 240, which
was associated with PEP 239, which was rejected:

https://www.python.org/dev/peps/pep-0239/
https://www.python.org/dev/peps/pep-0240/

So we actually haven't had a proper PEP about adding a Fraction
literal since the Fraction type itself was added. Whether it gets
accepted or not, I think having a PEP would be a good thing here.

> is that of having language
> syntax depend on non-builtin classes. So either you have to *also*
> propose making the fractions module a builtin, or you very quickly get
> sucked into "why not make this mechanism more general, so that
> libraries can define their own literals?"

Yes, fractions would have to become built-in. The consequences of
doing so would have to be explored; I'd start by looking at:

* Interpreter startup time
* Memory usage
* Subprocess creation time (only significant on Windows, I think -
every other platform forks)
* Possible interactions with decimal.Decimal (see below)
* Whether Fraction would need to become a builtin name

Currently, fractions.py imports decimal.py, mainly (purely?) for the
sake of being able to construct a Fraction from a Decimal. The decimal
module is *large* and has other reasons for not becoming builtin too,
so ideally, the two should be decoupled. A solid proposal would need
to explore decoupling the modules, figure out whether it's feasible,
or if not, why not, and figure out how these constructors should be
implemented. (For instance, should Fraction.from_decimal(123) cause
the decimal module to be imported?)

> Scope creep is nearly always what kills these proposals. Or the base
> proposal is too specialised to gain enough support.
>
> Personally, I can see value in fraction, decimal and regex literals.
> But I can live without them.
>

Decimal literals have a number of awkward wrinkles, so I'd leave them
aside for now; but if Fraction literals gain traction, it may be
possible to figure out a similar proposal. But the two would be
independent.

IMO regex literals are less valuable in Python than in some other
languages due to Python's rich set of string manipulation features,
but if they existed, I'd probably use them.

Anyone want to run with this? I'd be happy to help out with any PEP questions.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6FIY7BMCJ7TTVQCXOT47PMCL363PCYYC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread David Mertz

In truth, when I want fractions, I write:

from fractions import Fraction as F

So a literal doesn't really save many characters anyway. I guess 2
characters during first use. E.g.

x = F(1, 3)

vs. a possible future:

x = 1F / 3

The next stuff comes free either way:

y = ((x / 7) + 13) * 11

On Fri, May 14, 2021, 11:38 AM Paul Moore  wrote:

> On Fri, 14 May 2021 at 16:29, David Mertz  wrote:
> >
> > The memory simply blows up too fast for this to be practical (at least
> as a default) a float is always 64 bits, a fraction is unboundedly large if
> numerator and denominator are coprime.
> >
> > A toy example with a half dozen operations won't make huge fractions. A
> loop over a million operations will often be a gigantic memory hog.
>
> +1 on this. My experience has been that fraction classes are a lot
> less useful in (general) practical situations than people
> instinctively assume.
>
> > That said, Chris's idea for a literal spelling of "Fraction" is very
> appealing. One extra letter or symbol could indicate that you want to work
> in the Fraction domain rather than floating point. That's a perfectly
> reasonable decision for a user to make.
>
> Agreed, it is appealing. The problem (and this is not a new
> suggestion, it's come up a number of times) is that of having language
> syntax depend on non-builtin classes. So either you have to *also*
> propose making the fractions module a builtin, or you very quickly get
> sucked into "why not make this mechanism more general, so that
> libraries can define their own literals?"
>
> Scope creep is nearly always what kills these proposals. Or the base
> proposal is too specialised to gain enough support.
>
> Personally, I can see value in fraction, decimal and regex literals.
> But I can live without them.
>
> Paul
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AGO6FCHSKC5OR6O2F7RBXZIFMCNQQDHR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

Hi Paul,

> Agreed, it is appealing. The problem (and this is not a new
> suggestion, it's come up a number of times) is that of having language
> syntax depend on non-builtin classes. So either you have to *also*
> propose making the fractions module a builtin

That is absolutely what I would like to have. The fractions module is very 
small, it can easily be made a builtin. This would also speed it up 
significantly, I hope. Probably close to the speed of floats, given that most 
of the time spent for floats is whithin the interpreter anyways.

> Personally, I can see value in fraction, decimal and regex literals.
> But I can live without them.

This is why I proposed not to make a new literal. With my proposal, I already 
served two of your proposed use cases: fractions and decimal. Decimal(1/3) 
would be perfectly fine. Plus symbolic math.

Effectively what I am proposing is lazy evaluation of the divison operator, 
using fractions as a mathematical tool.

Cheers

Martin
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XGCW7SFBQAB6LO5ASGIE6JMGMLNCTMMH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

Hi David,

> A toy example with a half dozen operations won't make huge fractions. A
> loop over a million operations will often be a gigantic memory hog.

I do not propose to do that, and I agree that it would be stupid. Usually, the 
fraction gets very quickly converted into a float, and your millions of 
operations will be done with floats.

Now I cannot guarantee that this is always the case, but doing millions of 
operations in Python directly is usually very slow anyways, so people tend to 
use numpy or alike. And those use floats, and I am not proposing to change that.

But maybe I am all wrong and there is loads of code out there that would suffer 
from your problem, in this case, could you show me an example?

Cheers

Martin
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7GOCRAANWQL3G7XUSTPXBZSZ4IG5FIPC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Jonathan Fine

Hi Martin

I think it important to realise there are at least two issues. The first is
whether sometimes fraction is better than float, and vice versa. The second
is whether the default behaviour for int / int should be changed.

A third issue is whether some of the benefits you are seeking can be
achieved in some other way. Finally, well done for changing the Python
source to implement your idea. That's something I wouldn't have the courage
to do.

-- 
Jonathan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EBWTTLAPUBUDFGYYVCQZOBSMOS7SXJMD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

Hi Paul,

I would be fine with a new division operator or fraction literal as well, and 
in the beginning this is what I actually wanted to propose.

But then I started prototyping, and given that it is not so easy to change the 
parser, I just changed the normal division operator. And interestingly, nearly 
nothing broke.

The biggest compatibility problem I actually experienced was the completely 
unrelated breaking of PyCode_New in recent commits of CPython, which made using 
cython and thus numpy impossible. That was so hard to tackle I actually gave up 
and simply branched of an older version of CPython. What I want to say with 
that is: we are happily breaking compatibility for more minor stuff. I think my 
proposal would be a major improvement, which would warrant breaking of 
compatiblity, especially because this break of compatibility is astonishingly 
small. As said above, I already installed unmodified numpy, sympy, cython and 
all their tool chains.

Cheers

Martin
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZAB5CTTFQ2FOUZQOCYCZZ7EEDJ3P2SPR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Paul Moore

On Fri, 14 May 2021 at 16:29, David Mertz  wrote:
>
> The memory simply blows up too fast for this to be practical (at least as a 
> default) a float is always 64 bits, a fraction is unboundedly large if 
> numerator and denominator are coprime.
>
> A toy example with a half dozen operations won't make huge fractions. A loop 
> over a million operations will often be a gigantic memory hog.

+1 on this. My experience has been that fraction classes are a lot
less useful in (general) practical situations than people
instinctively assume.

> That said, Chris's idea for a literal spelling of "Fraction" is very 
> appealing. One extra letter or symbol could indicate that you want to work in 
> the Fraction domain rather than floating point. That's a perfectly reasonable 
> decision for a user to make.

Agreed, it is appealing. The problem (and this is not a new
suggestion, it's come up a number of times) is that of having language
syntax depend on non-builtin classes. So either you have to *also*
propose making the fractions module a builtin, or you very quickly get
sucked into "why not make this mechanism more general, so that
libraries can define their own literals?"

Scope creep is nearly always what kills these proposals. Or the base
proposal is too specialised to gain enough support.

Personally, I can see value in fraction, decimal and regex literals.
But I can live without them.

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WYPIPADOCZ724W3CLP6X4ASMWWH7SWDX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread David Mertz

The memory simply blows up too fast for this to be practical (at least as a
default) a float is always 64 bits, a fraction is unboundedly large if
numerator and denominator are coprime.

A toy example with a half dozen operations won't make huge fractions. A
loop over a million operations will often be a gigantic memory hog.

That said, Chris's idea for a literal spelling of "Fraction" is very
appealing. One extra letter or symbol could indicate that you want to work
in the Fraction domain rather than floating point. That's a perfectly
reasonable decision for a user to make.

On Fri, May 14, 2021, 11:18 AM Martin Teichmann 
wrote:

> Hi Jonathan,
>
> I would agree with you if what I was asking was arbitrary precision math.
> But this is not what I am asking for, what I am asking for is that integer
> true division should result in a Fraction. The difference is huge:
> arbitrary precision math is costly, and while arbitrarily precise, that
> "arbitrary" does not include "exact". Fractions, on the other hand, are
> exact.
>
> The speed argument also does not hold: whenever you do actual math on the
> fractions, they will be seemlessly converted to floats. Anybody doing
> anything speed will use something like numpy anyways, and there is no
> discussion there, numpy uses floats, and I am not proposing to change that.
>
> To illustrate what I am talking about, see how it looks like in reality
> (yes, this is the actual Python interpreter with my changes, not
> artificially generated stuff):
>
> >>> from math import sin, sqrt
> >>> sin(1/2)
> 0.479425538604203
> >>> sqrt(1/4)
> 0.5
> >>> (1/2)**2
> 1/4
> >>> (1/4)**(1/2)
> 0.5
> >>> (1/2)**-2
>4
>
> Now you can ask, if everything is converted to floats anyways, where is
> the benefit? The benefit is when you use symbolic math (or, indeed,
> arbitrary precision math like the Decimal example I already mentioned):
>
> >>> from sympy import symbols, sqrt, sin
> >>> x = symbols("x")
> >>> sin(1/2)
> sin(1/2)
> >>> 1/2 + x
> x + 1/2
> >>> 2/3 * x
> 2*x/3
> >>> sqrt(1/4)
> 1/2
>
> So, my argument is, this change will benefit many people, and be of only a
> small disadvantage to others. That disadvantage is that yes, there will be
> places where it does not work, so libraries need to get fixed. But this is
> the case with every Python update. Once it will be working, there will be
> no disadvantage anymore.
>
> Cheers
>
> Martin
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/UPHKJPGK4BGG4DRYLZFKKAJNRPIH6LVP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ODXXRDDFPSTOBZWX72PU5JO56QH7S2EM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

On Fri, 2021-05-14 at 15:15 +, Martin Teichmann wrote:

> So, my argument is, this change will benefit many people, and be of
> only a small disadvantage to others. That disadvantage is that yes,
> there will be places where it does not work, so libraries need to get
> fixed. But this is the case with every Python update. Once it will be
> working, there will be no disadvantage anymore.

Why not support a new division operator and/or fraction literal to
avoid breakage altogether?

Paul

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HLUMXVLNLMOFGJOYYOUTLKZVOE7E7JQF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

On Sat, May 15, 2021 at 1:16 AM Michael Smith  wrote:
>
> Jonathan Fine said
> > But here there is a cost. Arbitrary precision arithmetic (and roots) uses 
> > more memory and takes longer.
>
> I think a wider (perhaps naive) interpretation of the idea could be, "can we 
> defer certain lossy calculations until they have to be done?"
>
> Fraction may do eager arbitrary precision arithmetic (I don't know), but is 
> it necessarily the case that integer division has to be eager? Could we have 
> our cake and eat it, too?

Well, integer division has to return *something*, there has to be a
value for it. So the only benefit you might get would be that 10/8
could be stored as the fraction 10/8 instead of reducing it to 5/4,
which would save some effort at the time of division at the cost of
worsening addition.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/M2G56U35HRMKTT36AHGNVFSORQVALWBW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

Hi Jonathan,

I would agree with you if what I was asking was arbitrary precision math. But 
this is not what I am asking for, what I am asking for is that integer true 
division should result in a Fraction. The difference is huge: arbitrary 
precision math is costly, and while arbitrarily precise, that "arbitrary" does 
not include "exact". Fractions, on the other hand, are exact.

The speed argument also does not hold: whenever you do actual math on the 
fractions, they will be seemlessly converted to floats. Anybody doing anything 
speed will use something like numpy anyways, and there is no discussion there, 
numpy uses floats, and I am not proposing to change that.

To illustrate what I am talking about, see how it looks like in reality (yes, 
this is the actual Python interpreter with my changes, not artificially 
generated stuff):

>>> from math import sin, sqrt
>>> sin(1/2)
0.479425538604203
>>> sqrt(1/4)
0.5
>>> (1/2)**2
1/4
>>> (1/4)**(1/2)
0.5
>>> (1/2)**-2
   4

Now you can ask, if everything is converted to floats anyways, where is the 
benefit? The benefit is when you use symbolic math (or, indeed, arbitrary 
precision math like the Decimal example I already mentioned):

>>> from sympy import symbols, sqrt, sin
>>> x = symbols("x")
>>> sin(1/2)
sin(1/2)
>>> 1/2 + x
x + 1/2
>>> 2/3 * x
2*x/3
>>> sqrt(1/4)
1/2

So, my argument is, this change will benefit many people, and be of only a 
small disadvantage to others. That disadvantage is that yes, there will be 
places where it does not work, so libraries need to get fixed. But this is the 
case with every Python update. Once it will be working, there will be no 
disadvantage anymore.

Cheers

Martin
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UPHKJPGK4BGG4DRYLZFKKAJNRPIH6LVP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Michael Smith

Jonathan Fine said
> But here there is a cost. Arbitrary precision arithmetic (and roots) uses
more memory and takes longer.

I think a wider (perhaps naive) interpretation of the idea could be, "can
we defer certain lossy calculations until they have to be done?"

Fraction may do eager arbitrary precision arithmetic (I don't know), but is
it necessarily the case that integer division has to be eager? Could we
have our cake and eat it, too?

(Sorry for the dupe, Jonathan, I need to dig through my email configuration
to learn why "reply" doesn't do what I think it should do.)

On Fri, May 14, 2021 at 10:48 AM Jonathan Fine  wrote:

> Martin wrote:
>
> when dividing two integers, the result is a float, which means we
>> immediately lose precision. This is not good if you want to use code which
>> supports higher precision.
>
>
> I am of course in favour of keeping precision, if there is no cost. But
> here there is a cost. Arbitrary precision arithmetic (and roots) uses more
> memory and takes longer. Therefore, the system must allow the programmer to
> choice what's wanted (either explicitly or implicitly).
>
> Python has been set up to make 1/3 evaluate to a float (an implicit
> choice), and have Fraction(1, 3) be a fraction (an explicit choice).
>
> I don't think it fair to say that this decision is "not good". Rather,
> it's good for some use cases and not so good for others. On balance, I'm
> happy with that decision.
>
> That said, as a pure mathematician who does integer calculations, I'd like
> numpy to have better capabilities for integer linear algebra.
>
> I hope Martin that you agree with me, that this change would not be an
> improvement for everyone.
>
> --
> Jonathan
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/HJXX2MYDP32PYJGJMTCPYLHL47ZF35BV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AVGCINMCXQXF7XMUJGKSW3PYXGZ3LBDP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread Jonathan Fine

Martin wrote:

when dividing two integers, the result is a float, which means we
> immediately lose precision. This is not good if you want to use code which
> supports higher precision.

I am of course in favour of keeping precision, if there is no cost. But
here there is a cost. Arbitrary precision arithmetic (and roots) uses more
memory and takes longer. Therefore, the system must allow the programmer to
choice what's wanted (either explicitly or implicitly).

Python has been set up to make 1/3 evaluate to a float (an implicit
choice), and have Fraction(1, 3) be a fraction (an explicit choice).

I don't think it fair to say that this decision is "not good". Rather, it's
good for some use cases and not so good for others. On balance, I'm happy
with that decision.

That said, as a pure mathematician who does integer calculations, I'd like
numpy to have better capabilities for integer linear algebra.

I hope Martin that you agree with me, that this change would not be an
improvement for everyone.

-- 
Jonathan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HJXX2MYDP32PYJGJMTCPYLHL47ZF35BV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

And I've just learned something. 

On Fri, 2021-05-14 at 11:28 -0300, André Roberge wrote:
> 
> 
> On Fri, May 14, 2021 at 11:23 AM Paul Bryan  wrote:
> > I like the idea of supporting fractions to maintain more precision
> > in calculations. I wonder if this should fall outside the scope of
> > a standard library and be implemented in an external library. I'd
> > lean toward inclusion in stdlib.
> > 
> 
> 
> It already exists.
> 
> https://docs.python.org/3/library/fractions.html
> 
> André Roberge
>  
> > 
> > ___
> > Python-ideas mailing list -- python-ideas@python.org
> > To unsubscribe send an email to python-ideas-le...@python.org
> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > Message archived at
> >
> https://mail.python.org/archives/list/python-ideas@python.org/message/HUMMOSBZYLSPP7NOMBD3Z4MSQ3VBDKBK/
> > Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HJRILYF5K5DMSTZOQYE3ELX6WOHP7IRB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

On Sat, May 15, 2021 at 12:23 AM Paul Bryan  wrote:
>
> I like the idea of supporting fractions to maintain more precision in 
> calculations. I wonder if this should fall outside the scope of a standard 
> library and be implemented in an external library. I'd lean toward inclusion 
> in stdlib.
>
> A couple of thoughts, which should result in zero breakage of existing code:
>
> 1. Mirror `decimal.Decimal`, allowing expression of fraction with something 
> like `fraction.Fraction(numerator, denominator)`.

That can already be done (btw it's "fractions.Fraction"), although I
tend to write it as Fraction(numerator) / denominator, since division
of a Fraction and an integer works as expected.

> 2. Add a new division operator that yields `fraction.Fraction`.

Alternatively: Add a Fraction literal. Like an imaginary literal, this
would be attached to one half or the other, so what most humans would
think of as a literal is actually two of them. It could be something
like:

>>> 1F / 3

or

>>> 1 / 3F

It would work just as well either way, but the stdlib would pick one
of them to recommend (and then change the repr of a Fraction to
produce this).

The downside would be that Fraction code would no longer be buried
away in the stdlib - it'd be a mandatory part of the running
interpreter. I'm not sure how much impact this would have on startup
time.

This has been suggested a number of times, and IMO it'd be a far
easier path forward than either redefining integer division or
creating a new operator.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JCFFFD42KBW52UTW4UZVHIRVYYZU7WQ6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-14 Thread André Roberge

On Fri, May 14, 2021 at 11:23 AM Paul Bryan  wrote:

> I like the idea of supporting fractions to maintain more precision in
> calculations. I wonder if this should fall outside the scope of a standard
> library and be implemented in an external library. I'd lean toward
> inclusion in stdlib.
>

It already exists.

https://docs.python.org/3/library/fractions.html

André Roberge


>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/HUMMOSBZYLSPP7NOMBD3Z4MSQ3VBDKBK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JLOUBF47UDTQXAU2DIZS22IY5QBZMGSV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

I like the idea of supporting fractions to maintain more precision in
calculations. I wonder if this should fall outside the scope of a
standard library and be implemented in an external library. I'd lean
toward inclusion in stdlib.

A couple of thoughts, which should result in zero breakage of existing
code:

1. Mirror `decimal.Decimal`, allowing expression of fraction with
something like `fraction.Fraction(numerator, denominator)`. 
2. Add a new division operator that yields `fraction.Fraction`.

Paul


On Fri, 2021-05-14 at 12:12 +, Martin Teichmann wrote:
> Hi list,
> 
> when dividing two integers, the result is a float, which means we
> immediately lose precision. This is not good if you want to use code
> which supports higher precision. Decimals come to mind, but also
> sympy. This loss of precision could be avoided if the result of a
> division is a fraction instead: a fraction is exact.
> 
> So when writing Decimal(1/3), currently we lose the precision in the
> division, something that the Decimal module cannot undo. With my
> proposal, the entire precision is retained, and it works as expected.
> This is even more clear for sympy, a Package for symbolic
> calculations: currently, sympy cannot do much about "1/2 * m * v**2",
> although it looks like a perfectly fine formula. But sympy only sees
> "0.5" instead of "1/2", which is not usable in symbolic calculations.
> 
> I am aware that this would be a huge change. But we have had such a
> change in the past, from integers having a floor division in Python
> 2, to a float in Python 3. Compared to this, this is actually a small
> change: the value of the result is only different by the small
> pecision loss of floats. The bigger problem is caused by the fact
> that some code may rely on the fact that a value is a float. This can
> be fixed easily by simply calling float(), which is also backwards-
> compatible, it will work on older versions of Python as well.
> 
> I have prototyped this here:
> https://github.com/tecki/cpython/tree/int-divide-fraction
> The prototype uses the fractions.Fraction class written in Python as
> result for integer true divisions. I expected that to go horribly
> wrong, but astonishingly it did not. Only a small number of tests of
> Python fail, mostly those where it is explicitly tested whether an
> object is a float. So I lowered the bar even more and tried to
> compile and test numpy. And also there, except some tests that very
> explicitly require floats, it worked fine.
> 
> In order to showcase how that would look like, let me give an example
> session:
> 
>     >>> 5/6-4/15
>     17/30
>     >>> a=22/7
>     >>> f"{a}"
>     '22/7'
>     >>> f"{a:f}"
>     '3.142857'
>     >>> from decimal import Decimal
>     >>> Decimal(1/3)
>     Decimal('0.')
> 
> As a comparison, the same with current Python:
> 
>     >>> 5/6-4/15
>     0.5667
>     >>> a=22/7
>     >>> f"{a}"
>     '3.142857142857143'
>     >>> f"{a:f}"
>     '3.142857'
>     >>> from decimal import Decimal
>     >>> Decimal(1/3)
>    
> Decimal('0.14829616256247390992939472198486328125')
> 
> Cheers
> 
> Martin
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/RM4JDTGQCOW3MGIKIGEP2BIFOTFFAZI4/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HUMMOSBZYLSPP7NOMBD3Z4MSQ3VBDKBK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats