Re: [Caml-list] Bigarray map & set/get (long)

[Chris Hecker <checker@d6.com>]

>Agreed, but in this case (as I mentioned in my earlier post) you'd get
>better performance by just using regular float arrays rather than 
>bigarrays.(*)
>Thus, I recommend using bigarrays only when interfacing with C or
>Fortran numerical code.

Sure, but what a pain if you want to do both (say, do some math on an array 
of floats in caml and then pass them to a graphics api as vertices).  Or, 
you start with an algorithm in caml and then slowly need to move parts of 
it to C/asm.  It would clearly be better if there was a single uniform way 
to do things that was "optimal" (or close) for both situations.  It seems 
that the bigarray stuff is not far off from this, as I said.  There seems 
to be some nice low hanging fruit that could make a big difference in the 
native compiler with bigarrays.

Anyway, I'll look into it again and do some experiments at some point and 
see what I come up with.  I'd much rather have the caml team working on 
harder more higher level stuff that I'd have no prayer of being able to 
do[*], anyway.

Chris

[*] My current list of needed/wanted language features:

1. operator overloading/generics for making math less ugly and painful
2. module recursion
3. views for pattern matching abstract data types

I added views to my want-list relatively recently (6 months ago?) as I 
started trying to do more interesting stuff.  I can't believe the conflict 
between wanting to pattern match like you're supposed to in ml and wanting 
to abstract data types like you're supposed to in ml doesn't get more 
attention in the functional programming community.  It seems like a glaring 
problem, but maybe I'm missing something.


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners