]> >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