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

[Chris Angelico]

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

[Steven D'Aprano]

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

[Steven D'Aprano]

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

[Steven D'Aprano]

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

[Steven D'Aprano]

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[Martin Teichmann]

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

[Martin Teichmann]

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

[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

[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

[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

[Chris Angelico]

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

[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

[Paul Bryan]

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

[Paul Bryan]

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

[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

[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

[Chris Angelico]

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

[Martin Teichmann]

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

[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

[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

[Chris Angelico]

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

[Chris Angelico]

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

[Martin Teichmann]

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

[Martin Teichmann]

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

[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

[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

[Chris Angelico]

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

[Chris Angelico]

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

[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

[Martin Teichmann]

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

[Martin Teichmann]

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

[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

[Martin Teichmann]

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

[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

[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

[Paul Bryan]

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

[Chris Angelico]

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

[Martin Teichmann]

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

[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

[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

[Paul Bryan]

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

[Chris Angelico]

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

[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

[Paul Bryan]

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

[Martin Teichmann]

Hi Joao,

I actually had the same fear as you. But as stated before, I managed to run 
most of the tests, and even compile and test numpy, with only some 30 tests 
failing. This means the entire tool chain, setuptools, pytest, cython and much 
more just worked. No, I did not need to touch one of them, even numpy itself 
runs fine except the failing tests.

The reason for that is that nearly all builtin code uses PyFloat_AsDouble, 
which is happily accepting a Fraction. I did not have to change that, it did 
that out of the box.

In the beginning I just did all that for fun just to see how it works, but 
after I had seen that it actually works, I decided I could at least propose it.

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/GI5IFTHTJHD7H3TMTQ7TLEEBZYNFGNMB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Joao S. O. Bueno]

On Fri, 14 May 2021 at 09:24, 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.
>

"...Although practicality beats purity."

This is a nice idea, but I think this ship has sailed.
Performance reasons apart, I think that most builtin (as in compiled from C
or other native code) calls that expect  a float simply won't work
with a Fraction object as it is today in Python.

Yes, not for the drawbacks, this could be nice - but it spells
an avalanche of trouble, a lot of which due to the fact that the Fraction
type
and all concepts in the Numeric Tower, had not sem much active use
in a lot of domains Python is used.

If you take all  examples on the static typing frontend, for example,
they all check for "float" when requiring non-integer numbers.
(Instead of, say "numbers.Real") - so almost all type-annotated code
would break with this change.



>
> 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/OCE5TKXEZ3F3UGSLVKPZMHMKA6CH5CQT/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Martin Teichmann]

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/