On 3/24/07, Vivian McPhail wrote:

...

I agree with Sven, but...

What I want to push is a 'mathematically sound' numeric prelude. A

mgsloan wrote: proper

...

numerical prelude should have bona fide mathematical obects like groups, rings, and fields underlying common numerical classes. It would be edifying to the student who discovered that the particular data type he is using is an inhabitant of a known class and can thus take advantage of known properties, presupplied as class methods. Reasoning and communication about programs, data types, and functions would be enhanced.

One problem with that is that the instances are often times not mathematically sound - Int and Double certainly aren't.

Int is algebraically sound as a factor ring Z/nZ with n=2**k, k the number of bits (which could be implementation defined). Unfortunately the order inherited from Integer is not compatible with the algebra... Cheers Ben

Hi, (new here) 2007/3/25, Jacques Carette :

Some classes would become even more important: monoid, groupoid, semi-group, loop (semi-group with identity), etc. But all of those are, to the average programmer (and many a mathematician), just as scary as Monad.

Of course, when you get that general, you start having the problem that many types can be made into these structures in more than one way. Even the current Monoid class has that problem, even though it has some ties to a particular application (the Writer monad and stuff similar to it -- as reflected in the 'mappend' and 'mconcat' names). You can have newtype wrappers, but that's at least somewhat annoying :-) I'd like to see these classes in the standard library, but I'm not sure at this point whether they are useful enough to have in the prelude, as long as they're not at least losely to a specific application (Field -> numbers; Monoid -> collecting results; Monad -> imperative computations). - Benja

ok, tongue out of cheek again, someone would need to investigate the particular shape in which such abstract concepts would be most useful (which may or may not be the same shape best known in maths, see Monad, Monoid, Applicative, Arrow,..), and how those shapes are best expressed within the programming language abilities. and then, of course, someone would need to write code and tutorials. Agreed. This is why I mentioned semi-groups when someone talked about classical structures like rings and fields. To pick just one example, Kleene Algebras seem more applicable to CS than say fields. Similarly,

My main worry is that this can be a horrible time sink without a clear path to success and, worse, known obstacles in the way. For example: we know that all Monads are Functors, but that is not expressed in the type classes, because it would be too much a pain to do so. That pain is heavily multiplied in a 'proper' subdivision of mathematical types. Until that is fixed, I know I do not consider it worthwhile to spend a lot of time working on this because the end result might be correct, but completely unrealistic. Another obvious item is that the lessons from DoCon have not all been reflected into advances in Haskell, not even Haskell'. If I was in a pessimistic mood, I would mention the lessons from AUTOMATH (you know, stuff from 1968 to the mid 70s). Claus Reinke wrote: there are more rngs and rigs than rings. More applications for non-archimedian fields (power series) than archimedean ones (reals). And so on.

perhaps i was mistaken in thinking that there is a group of math-interested haskellers out there discussing, developing, and documenting the area? or perhaps that group needs introductory tutorials presenting its work? My guess is that there are a number of people "waiting in the wings", waiting for a critical mass of features to show up before really diving in. See http://www.cas.mcmaster.ca/plmms07/ for my reasons for being both interested and wary).

Probably the simplest test case is the difficulties that people are (still) encountering doing matrix/vector algebra in Haskell. One either quickly encounters efficiency issues (although PArr might help), or typing issues (though many tricks are known, but not necessarily simple). Blitz++ and the STL contributed heavily to C++ being taken seriously by people in the scientific computation community. Haskell has even more _potential_, but it is definitely unrealised potential. Jacques

Jacques Carette wrote:

...

...

perhaps i was mistaken in thinking that there is a group of math-interested haskellers out there discussing, developing, and documenting the area? or perhaps that group needs introductory tutorials presenting its work? My guess is that there are a number of people "waiting in the wings", waiting for a critical mass of features to show up before really diving in. See http://www.cas.mcmaster.ca/plmms07/ for my reasons for being both interested and wary).

Probably the simplest test case is the difficulties that people are (still) encountering doing matrix/vector algebra in Haskell. One either quickly encounters efficiency issues (although PArr might help), or typing issues (though many tricks are known, but not necessarily simple). Blitz++ and the STL contributed heavily to C++ being taken seriously by people in the scientific computation community. Haskell has even more _potential_, but it is definitely unrealised potential.

I am one of those mathematicians "waiting in the wings." Haskell looked very appealing at first, and the type system seems perfect, especially for things like multilinear algebra where currying and duality is fundamental. I too was put off by the Num issues though--strange mixture of sophisticated category theory and lack of a sensible hierarchy of algebraic objects.

However, I've decided I'm more interested in helping to fix it than wait; so count me in on an effort to make Haskell more mathematical. For me that probably starts with the semigroup/group/ring setup, and good arbitrary-precision as well as approximate linear algebra support.

I've been watching this thread for quite a while now, and it seems to me that there is quite a bit of interest in at least working on a new Prelude. I've also noticed a 'The Other Prelude' page on the wiki [http://haskell.org/haskellwiki/The_Other_Prelude] and they seem to have a start on this. So it seems that we should actually start this, because people will contribute. Can somebody with good Cabal skills and maybe access to darcs.haskell.org start a new library for people to start patching? Bryan Burgers

Wouldn't this be a good discussion for the Haskell Prime List? Reilly Hayes +1 415 388 3903 (office) +1 415 846 1827 (mobile) rfh@ridgecrestfinancial.com On Apr 2, 2007, at 3:24 PM, Andrzej Jaworski wrote:

...

I too was put off by the Num issues though--strange mixture of sophisticated category theory and lack of a sensible hierarchy of algebraic objects.

Perhaps we should replace CT with lattice theoretic thinking (e.g. functor = monotonic function) before cleaning up the type-related mess? See: http://citeseer.ist.psu.edu/269479.html

...

so count me in on an effort to make Haskell more mathematical. For me that probably starts with the semigroup/group/ring setup, and good arbitrary-precision as well as approximate linear algebra support.

I agree: semigoups like lattices are everywhere. Then there could be a uniform treatment of linear algebra, polynomial equations, operator algebra, etc. So, perhaps haste is not a good advice here?

-Andrzej

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

NumericPrelude does seem like a good starting point for discussion and addition. Is it still being actively developed, and what are the goals there? On 4/3/07, Henning Thielemann wrote:

On Mon, 2 Apr 2007, jasonm wrote:

...

Jacques Carette wrote:

...

...

perhaps i was mistaken in thinking that there is a group of math-interested haskellers out there discussing, developing, and documenting the area? or perhaps that group needs introductory tutorials presenting its work? My guess is that there are a number of people "waiting in the wings", waiting for a critical mass of features to show up before really diving in. See http://www.cas.mcmaster.ca/plmms07/ for my reasons for being both interested and wary).

Probably the simplest test case is the difficulties that people are (still) encountering doing matrix/vector algebra in Haskell. One either quickly encounters efficiency issues (although PArr might help), or typing issues (though many tricks are known, but not necessarily simple). Blitz++ and the STL contributed heavily to C++ being taken seriously by people in the scientific computation community. Haskell has even more _potential_, but it is definitely unrealised potential.

I am one of those mathematicians "waiting in the wings." Haskell looked very appealing at first, and the type system seems perfect, especially for things like multilinear algebra where currying and duality is fundamental. I too was put off by the Num issues though--strange mixture of sophisticated category theory and lack of a sensible hierarchy of algebraic objects.

However, I've decided I'm more interested in helping to fix it than wait; so count me in on an effort to make Haskell more mathematical. For me that probably starts with the semigroup/group/ring setup, and good arbitrary-precision as well as approximate linear algebra support.

NumericPrelude popped up in this thread earlier. Is this the starting point you are after? http://darcs.haskell.org/numericprelude/