[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