[issue31707] Irrational fractions

2017-10-06 Thread Mark Dickinson

Mark Dickinson  added the comment:

I think this is way beyond the scope of the current fractions module. I'd 
suggest putting something on PyPI as a proof of concept.

Given the negative response from other core developers, I'm going to close here.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue31707] Irrational fractions

2017-10-06 Thread Henk-Jaap Wagenaar

Henk-Jaap Wagenaar  added the comment:

I would like to provide some colour to this discussion. In a former life I have 
coded these during my studies. Ben is talking about implementing the Field of 
Fractions of an Integral Domain. See 
https://en.wikipedia.org/wiki/Field_of_fractions

The way Fraction is implemented it has a unique representation for each 
fraction in Q and uses GCD. This requires us to strengthen the condition of 
Integral Domain to a Euclidean Domain where the Euclidean Function fulfills the 
role of %. I.e. Serhiy: it would only support exactly those rings that support 
gcd! See https://en.wikipedia.org/wiki/Euclidean_domain

One could implement a base class called (Euclidean)FractionField that 
generalizes to Euclidean domains. For future reference, there are a few 
practical niggles I want to record:
- how to deal with basic numeric types?
- Euclidean Domain needs to implement __abs__ to get a canonical denominator, 
unless gcd works out magically like it does in Z?

The added advantage beside being able to use the FractionField class as Ben 
suggests is that it splits up the mechanics of parsing/creating/casting to/from 
various basic numeric types from the mathematical operations in a fraction 
field making the code clearer.

I am happy to assist Ben with the patch if he wants any help.

--
nosy: +Henk-Jaap Wagenaar

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue31707] Irrational fractions

2017-10-06 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

Concur with Raymond.

Even multiplication doesn't work for irrational numerator and denominator, 
since gcd() is not applicable to them.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue31707] Irrational fractions

2017-10-05 Thread Raymond Hettinger

Raymond Hettinger  added the comment:

Put me down for -1.  This doesn't seem like standard library material. It 
doesn't seem to address a common need and it would add complexity to an already 
complicated module (nor does it seem to have a good fit with the numeric 
tower).  The proposal seems like something that should exist outside the 
standard library (especially since we don't already provide interoperable types 
like SquareRoot(3)).

--
priority: normal -> low
type: behavior -> enhancement
versions: +Python 3.7 -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue31707] Irrational fractions

2017-10-05 Thread Ben Burrill

Ben Burrill  added the comment:

The core operators, like multiplication and division, should work for any type 
that defines the right operators.  Hashing is tricky, and reducing the fraction 
is pretty much off the table.  This is why I suggested a superclass.  I'll try 
making a patch sometime soon.

I am aware of sympy and am not proposing that the standard library stray too 
far into symbolic mathematics.  Sympy's re-invention of the fraction makes 
sense given sympy's scope, but simpler libraries that offer other abstract math 
features (like one that just implemented a simple Polynomial type) would 
benefit from using fractions.Fraction.

This change would probably make it so that sympy symbols worked with 
fractions.Fraction, which although unnecessary, might be nice.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue31707] Irrational fractions

2017-10-05 Thread Raymond Hettinger

Raymond Hettinger  added the comment:

The fractions module isn't easily extended to support this proposal.  It was 
designed around a gcd() step and assumes integer numerators and denominators 
throughout.  Also, the Fraction class is registered with numbers.Rational() 
which implies some specific behaviors including inoperability with various 
other classes.

In additionl, the standard library also doesn't yet support unevaluated 
rationals like SquareRoot(3).  I suggest looking at the sympy module which may 
already have everything you need.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue31707] Irrational fractions

2017-10-05 Thread Ben Burrill

Change by Ben Burrill :


--
nosy: +mark.dickinson, rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue31707] Irrational fractions

2017-10-05 Thread Ben Burrill

New submission from Ben Burrill :

fractions.Fraction enforces its numerator and denominator to be rational.  This 
is a good idea for purely numeric fractions, but the abstractions that 
fractions.Fraction offers would also be useful for more abstract fractions.

Some places where this might be useful would be fractions of polynomial types 
or fractions with abstract irrational numeric types, like F(SquareRoot(3), 2).

This could be accomplished by having a more general Fraction superclass or by 
removing the requirement of rationality from fractions.Fraction.  It is not 
trivial to create a subclass of Fraction that does this because the operators 
are hardcoded to use Fraction and initiation is done in __new__.

--
components: Library (Lib)
messages: 303788
nosy: Ben Burrill
priority: normal
severity: normal
status: open
title: Irrational fractions
type: behavior
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com