John Meacham <john@repetae.net> wrote:

What would be cooler (IMHO) would be brining all of matlabs functionality into haskell via haskell libraries so one may use 'ghci' sort of as one uses matlab, but with the advantages haskell brings.

One could create Haskell libraries that are matlab-like, but most of the advantages of haskell (ie stong typing) are not realizable in Haskell. To express even the most basic of matrix datatypes and operations requires dependent types. Now, most of the dependent types needed are (linear) integer dependencies, so some of the tricks recently shown on this mailing list could be used, but the end result would be hardly palatable, and certainly not competitive with Matlab on usability grounds. Shapely types (a la FISh) are quite promising in this direction, as are systems (like Epigram) taking dependent types head-on. It is too bad that Aldor (www.aldor.org) was too far ahead of its time with its first-class and dependent type system :-( Scarily, it is essentially deemed a 'failure' in Computer Algebra circles, as its type system, powerful as it is, is still too weak to conveniently express the mathematics of calculus. And calculus/analysis is what most people use Matlab, Maple and Mathematica for. [I was with Maplesoft Inc (makers of the CAS Maple) for 10 years, Senior Architect and Product Development Director for 2000-2002 before I got lured by academia. I say this mostly as a way to allow others to judge the weight they should place on my above stated opinions.] Jacques

Jerzy Karczmarczuk:

Jacques Carette wrote:

...

John Meacham <john@repetae.net> wrote:

...

What would be cooler (IMHO) would be brining all of matlabs functionality into haskell via haskell libraries so one may use 'ghci' sort of as one uses matlab, but with the advantages haskell brings.

One could create Haskell libraries that are matlab-like, but most of the advantages of haskell (ie stong typing) are not realizable in Haskell. To express even the most basic of matrix datatypes and operations requires dependent types.

I did not understand what is not realizable where...

I wonder what for do you need those dependent types. Matlab is quite orthodox, its main flexibility comes from the dynamical typing, resolution of the dimensions at the run-time, etc. The Numerical Python gives a good share of Matlab functionalities. Now, overloading arith operations for some bulk data (lists, lists of lists, arrays, etc.) casting them to some "matrix" general types, should not be impossible without dependent types. Hm. I will not bet my head, but, please, *provide an example* of such situation.

I think Jacques possibly means the ability to do static checking of matrix and vector extents, to make sure that you don't try to perform operations like matrix-vector multiply on operands whose extents do not match. If you want to have this ability on your language, then you will have to restrict the way you are allowed to construct array bounds so the equations that arise can be solved. Possibly a dependent type system can be helpful for this. Björn Lisper

I recognize that I'm far out of my depth here--both in Haskell and in mathematics--but I'll ask anyway. In what ways are dependent types (http://haskell.org/hawiki/FunDeps, http://www.cse.ogi.edu/~mpj/pubs/fundeps.html) insufficient to address these issues? On Friday, August 27, 2004, at 10:04AM, Jacques Carette <carette@mcmaster.ca> wrote:

...

I think Jacques possibly means the ability to do static checking of matrix and vector extents, to make sure that you don't try to perform operations like matrix-vector multiply on operands whose extents do not match. If you want to have this ability on your language, then you will have to restrict the way you are allowed to construct array bounds so the equations that arise can be solved. Possibly a dependent type system can be helpful for this.

This is indeed what I meant.

If one is going to move from a dynamically typed language (like Matlab, Maple, Mathematica, etc) to something statically typed, then the expectation is that this is going to truly help. And, for many applications, it does [this is partly why I have an MSc student coding a reverse engineering application in Haskell].

Since the claim of static typing is that things cannot go wrong at run-time, one start to think (incorrectly, but optimistically) that this means that 'nonsense' cannot happen at run-time. And multiplying matricies with non-matching sizes is nonsense, so it is rather disappointing that, without tricks, this is not caught at compilation time.

Matrix length are one of many commonly occuring dependent types in mathematics. Variable names for polynomials, expansion point and 'scale' for generalized series expansions, coefficient ring for normalization and factorization of polynomials, and so on up the food chain. The dependencies get quite interesting when one is dealing with modelling mixed PDEs and recurrence equations as ideals in rings of Ore polynomials!

Jacques

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

Michael Manti mmanti@mac.com

I said:

One could create Haskell libraries that are matlab-like, but most of the advantages of haskell (ie stong typing) are not realizable in Haskell. To express even the most basic of matrix datatypes and operations requires dependent types.

Jerzy Karcmarczuk replied:

I did not understand what is not realizable where...

Note that I did not say "not realizable" [this would be false], I only claimed that most of the advantages of Haskell would be "lost". It has been shown how to embed a dynamically typed language into a statically typed one. An interesting embedding of Matlab-like functionality in Haskell would really need to feel more like Haskell than Matlab! This is not to say that embedding Matlab functionality into Haskell, even at the cost of having that subset be dynamically typed, would not be quite useful. Quite the contrary.

I have the impression that the true calculus/math analysis percentage in Matlab programs is negligible. Look at the composition of Matlab toolboxes.

[This information is straight from Cleve Moler]. The main uses of Matlab are in industry, not academia. And there, they use toolboxes, few use 'raw' Matlab. The most propular toolbox is Simulink. And the mathematics of Simulink is partly about matricies, but mostly it is about differential equations. The interface just hides them from the user quite successfully.

With symbolic packages, such as Maple or Mathematica it is a bit different, but statistically what counts is pure algebra + a good deal of visualization facilities. Actually, with the development of the Automatic differentiation techniques, one needs much less of symbolic processing nowadays...

I do not understand this 'statistically what counts is pure algebra + visualization' statement. That visualization is extremely important I fully agree with. That the nitty-gritty of these systems is all implemented using pure algebra, again agreed. But my experience is that what most users want is to solve differential equations (or computing quadratures, but that is clearly the same thing). Of course, what they really want is to not see those DEs at all, but see control systems, circuits, chemical flows, etc. All of which boil down to DEs. Jacques