[Haskell-cafe] Proposal for restructuring Number classes

[Dylan Thurston]

On Mon, Apr 10, 2006 at 12:13:55PM +0200, Andrew U. Frank wrote:
> there has been discussions on and off indicating problems with the structure
> of the number classes in the prelude. i have found a discussion paper by
> mechveliani but i have not found a concrete proposal on the haskell' list of
> tickets. i hope i can advance the process by making a concrete proposal for
> which i attach Haskell code and a pdf giving the rational can be found at
> ftp://ftp.geoinfo.tuwien.ac.at/frank/numbersPrelude_v1.pdf
> 
> if i have not found other contributions, i am sorry and hope to hear about
> them. 
> 
> i try a conservative structure, which is more conservative than the
> structure we have used here for several years (or mechveliani's proposal).
> It suggests classes for units (Zeros, Ones) and CommGroup (for +, -),
> OrdGroup (for abs and difference), CommRing (for *, sqr), EuclideanRing (for
> gdc, lcm, quot, rem, div...) and Field (for /). I think the proposed
> structure could be a foundation for mathematically strict approaches (like
> mechveliani's) but still be acceptable to 'ordinary users'.

I agree with Henning Thielemann about putting 'zero' in 'CommGroup'
and 'one' in 'CommRing'.  What is your thinking here?  I would also
argue for putting 'fromInteger' in 'CommRing', as discussed in the
NumPrelude proposal.  'EuclideanRing' is a misnomer; a Euclidean Ring
is a particular type of ring where GCD, etc. can be defined (see
http://planetmath.org/encyclopedia/EuclideanRing.html), but there are
other such rings, namely any Principal Ideal Domain or PID.
'IntegralDomain' is also a misnomer; I don't know what you're getting
at there, but there is a well-established mathematical term 'integral
domain' that means something different.

o On enforcing properties: there's not currently any way to enforce
properties (e.g., monad laws are not enforced); however, I believe
that expected properties should be documented.

o ^ and ^^ (which can actually be combined, see our proposal) are in
fact quite useful, and can be implemented considerably more
efficiently than a general exponentiation.  If you want a complete
proposal, you do need to go further.

o You do impose some additional burden by changing the name of the
'Num' class, and it is worth noting that.

o Mechvelliani's implementation could not be built on top of your
base, because he needs to have a sample argument to 'zero' to
determine, e.g., the right zero for modular arithmetic.  Henning
mentioned this in his response.  To implement modular arithmetic with
these signatures, as far as I know, you need to either separate Zero
constructors or do something like the Kiselyov-Shan paper.  (See,
e.g., Frederick Eaton's linear algebra library recently posted to the
Haskell list.)

Peace,
	Dylan Thurston


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org//pipermail/haskell-cafe/attachments/20060417/02b963f8/attachment.bin