[Haskell] 2-D Plots, graphical representation of massive data

Jerzy Karczmarczuk karczma at info.unicaen.fr
Fri Aug 27 04:44:05 EDT 2004


Jacques Carette wrote:

> John Meacham <john at 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.

>
> ...  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 have the impression that the true calculus/math analysis percentage in 
Matlab programs
is negligible. Look at the composition of Matlab toolboxes. 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...

Anyway, the scientific computing and its direct concrete applications 
(robotics, DSP,
experiment simulation, etc.) remains still an unexploited niche for 
Haskell, and I hope that
it will change one day.

I would like to ask the original poster, who asked first about the 
Matlab<->Haskell links
what are her/his *concrete* problems...

Jerzy Karczmarczuk





>
>


More information about the Haskell mailing list