This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author cryvate
Recipients Ben Burrill, cryvate, mark.dickinson, rhettinger, serhiy.storchaka
Date 2017-10-06.08:47:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1507279668.88.0.213398074469.issue31707@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2017-10-06 08:47:48cryvatesetrecipients: + cryvate, rhettinger, mark.dickinson, serhiy.storchaka, Ben Burrill
2017-10-06 08:47:48cryvatesetmessageid: <1507279668.88.0.213398074469.issue31707@psf.upfronthosting.co.za>
2017-10-06 08:47:48cryvatelinkissue31707 messages
2017-10-06 08:47:47cryvatecreate