From: John S. <sk...@oz...> - 2003-06-17 02:54:23
|
I finally managed to get hold of the archive. If you want to make me a developer I can contribute to the documentation. Comments. DynArray.make size null: makes an array of length zero, with size element slots initialised by null. Can't you initialise the empty slots with Obj.magic(0)? I don't want to put an element here. I may not have a convenient default, and even if I do it is going to kill performance compared to an integer, since there will be a bogus pointer for the collector to chase down. Also, I haven't checked the collector header, but isn't there a count field that can be used for the count without compromising the allocator's knowledge of the length of a block? [The size may be needed for disposal and/or movement on compaction] If there is, the store can be totally uninitialised, which is even more efficient. -- John Max Skaller, mailto:sk...@oz... snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 |
From: Brian H. <bri...@ql...> - 2003-06-17 15:09:36
|
On Tue, 17 Jun 2003, John Skaller wrote: > I finally managed to get hold of the archive. > If you want to make me a developer I can contribute to the documentation. > > Comments. DynArray.make size null: makes an array of length zero, > with size element slots initialised by null. > > Can't you initialise the empty slots with Obj.magic(0)? No. What if it's an array of floats, which is unboxed? > I don't want to put an element here. I may not have a > convenient default, and even if I do it is going > to kill performance compared to an integer, since > there will be a bogus pointer for the collector to > chase down. If you don't have a convient default, use a 'a option Dynarray.t. That gives you a convient default- None. I didn't want to always use options in the array, because in many cases you don't need them, cases where there are sane, or at least usable default values (0, nan, "", false, etc). Note: in the current API there is no way to get access to an element with a null value. So you don't ever have to worry about distinguishing null values from sensible values. So it's still safe if the null value would otherwise have meaning. > > Also, I haven't checked the collector header, > but isn't there a count field that can be > used for the count without compromising the > allocator's knowledge of the length of a block? > [The size may be needed for disposal and/or movement > on compaction] If there is, the store can be > totally uninitialised, which is even more efficient. I haven't checked, but the idea of using uninitialized memory with a garbage collector makes me nervous. Brian |
From: John M. S. <sk...@oz...> - 2003-06-19 12:32:03
|
Brian Hurt wrote: > On Tue, 17 Jun 2003, John Skaller wrote: >>Can't you initialise the empty slots with Obj.magic(0)? >> > No. What if it's an array of floats, which is unboxed? Ah. > If you don't have a convient default, use a 'a option Dynarray.t. No way. That's a hack to support a faulty implementation. I want a 'a Dynarray.t, the *filled* slots always have that type. I don't see why I should change the type to suit an implementation that can't handle the idea of a variable length array properly. C++ vector does this correctly. > Note: in the current API there is no way to get access to an element with > a null value. So you don't ever have to worry about distinguishing null > values from sensible values. So it's still safe if the null value would > otherwise have meaning. I have examples where I CANNOT construct a dummy value. The fact that the value is not accessible with an array access cannot remove a requirement an object may have to connect to other objects. In particular, consider a type in which a representation of an open file handle is stored. Now you force me to create a dummy file in the file system just to create an array. It could be there is NO good solution in Ocaml. In that case, use a C solution. I want this data structure to work exactly right, and I need it precisely *because* I can't define it myself. -- John Max Skaller, mailto:sk...@oz... snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 |
From: Brian H. <bri...@ql...> - 2003-06-19 15:20:16
|
On Thu, 19 Jun 2003, John Max Skaller wrote: > Brian Hurt wrote: > > > On Tue, 17 Jun 2003, John Skaller wrote: > > >>Can't you initialise the empty slots with Obj.magic(0)? > >> > > No. What if it's an array of floats, which is unboxed? > > > Ah. > > > > If you don't have a convient default, use a 'a option Dynarray.t. > > > No way. That's a hack to support a faulty implementation. > I want a 'a Dynarray.t, the *filled* slots always have that type. > I don't see why I should change the type to suit an implementation > that can't handle the idea of a variable length array properly. As I can't use Obj.magic() if it's an array of floats, the only other option I have is to make *everything* a 'a option Dynarray.t implicitly- make the internal array a 'a option array instead of just a 'a array. Which means if it's a dynarray of ints, the ints are not unboxed. Futhermore, if I understand things correctly, the ints aren't unboxed in the option variable either- meaning that I've now added two dereferences and two extra words for every integer in the array- when I can instead just use an integer array in the current implementation. > > C++ vector does this correctly. At the cost of emitting a whole new wad og object code for every single type you put into a vector. Vector<int> requires the compiler to produce a whole vector class to deal with ints, seperate from Vector<short>, Vector<char>, Vector<void *>, etc. > > > Note: in the current API there is no way to get access to an element with > > a null value. So you don't ever have to worry about distinguishing null > > values from sensible values. So it's still safe if the null value would > > otherwise have meaning. > > > I have examples where I CANNOT construct a dummy value. > The fact that the value is not accessible with > an array access cannot remove a requirement > an object may have to connect to other objects. In this case, you're going to be using a 'a option Dynarray.t one way or another. The question is wether you can ever get rid of the option part. > It could be there is NO good solution in Ocaml. > In that case, use a C solution. I want this > data structure to work exactly right, and I need > it precisely *because* I can't define it myself. Feel free to submit code. Brian |
From: John M. S. <sk...@oz...> - 2003-06-20 03:41:29
|
Brian Hurt wrote: >>C++ vector does this correctly. >> > > At the cost of emitting a whole new wad og object code for every single > type you put into a vector. Vector<int> requires the compiler to produce > a whole vector class to deal with ints, seperate from Vector<short>, > Vector<char>, Vector<void *>, etc. Your comparison is unfair and untrue. If you make the equivalent vector to ocaml, you'd make a vector of pointers. It is in fact easy and common practice to specialise vector on pointers to use the code for a vector<void*> plus casts wrapped in the template. Most compilers will optimise this to the calls to the void* specialisation if the wrappers are inline. So no code bloat. On the contrary, C++ has a built-in mechanism for handling specialisations and Ocaml does not, so in this area it is way ahead of Ocaml: put another way: if you have unboxed types and pointers, you can always use boxed types. The reverse is not true. Ocaml is in fact based on a faulty type system, which fails to recognize that copying values cannot be handled polymorphically: it cheats by using boxing. There are a few areas where this fault is evident, for example recursive types: the usual definition is in fact quite wrong: the unfold of a recursive type is a distinct type. Its only isomorphic to the original if the types are replaced by pointers. The principal problem in C++ here is the lack of a garbage collector. The code bloat from the specialisations is the price for high performance: ocaml is doing that too with unboxed arrays of floats etc .. but it will never compete with C++ in this area: the ocaml team has to 'hack' the underlying implementation to gain performance. The C++ end user can do it easily and more reliably. In fact.. its the default :-) > In this case, you're going to be using a 'a option Dynarray.t one way or > another. The question is wether you can ever get rid of the option part. Nah, just box the floats. Should be easy. Make the underlying array type int. Use 0 as the null value. Use casts to convert incoming and outgoing values. Easy. Floats stay boxed though. I don't care. -- John Max Skaller, mailto:sk...@oz... snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 |
From: Nicolas C. <war...@fr...> - 2003-06-20 04:48:46
|
[...] > Nah, just box the floats. > Should be easy. Make the underlying array > type int. Use 0 as the null value. > Use casts to convert incoming and outgoing > values. Easy. Floats stay boxed though. > I don't care. I agree with that one, it would be interesting to improve DynArray this way. you need also to copy elements one_by_one instead of doing Array.sub in DynArray.to_array. Nicolas Cannasse |
From: Brian H. <bri...@ql...> - 2003-06-20 15:48:01
|
On Fri, 20 Jun 2003, John Max Skaller wrote: > Brian Hurt wrote: > > > >>C++ vector does this correctly. > >> > > > > At the cost of emitting a whole new wad og object code for every single > > type you put into a vector. Vector<int> requires the compiler to produce > > a whole vector class to deal with ints, seperate from Vector<short>, > > Vector<char>, Vector<void *>, etc. > > > Your comparison is unfair and untrue. > > If you make the equivalent vector to ocaml, > you'd make a vector of pointers. It is both fair and true. Notice that the examples I gave, all except void* were unboxed. I don't know how many C++ compilers can figure out that a Vector<foo*> and a Vector<bar*> can use the same object code. I can easily envision tricky code where they couldn't. But I haven't looked recently, so they may (in the cases where they can). > The principal problem in C++ here is the lack of > a garbage collector. If this is the only reason you're using Ocaml and not C++, take a look at: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ Or you might take a gander at this language: http://java.sun.com/ I hear they're adding both templates and operator overloading in the next version. > > In this case, you're going to be using a 'a option Dynarray.t one way or > > another. The question is wether you can ever get rid of the option part. > > > Nah, just box the floats. > Should be easy. Make the underlying array > type int. Use 0 as the null value. > Use casts to convert incoming and outgoing > values. Easy. Floats stay boxed though. > I don't care. > > Don't have casts in Ocaml. I don't know of a way to force unboxing of floats in an array without coding in C. If I could do that, Obj.magic() would work. So we're talking about rewritting the whole thing in C. Could be done. Don't use ints for the array type, use the Value type. But one of the reasons I'm contributing to ExtLib is that I want to do some programming in *Ocaml*. But I'm willing to take it under advisement, and put it on my to do list. Just don't hold your breath. And are you willing to gaurentee that no one will ever care that float Dynarray.t's are boxed? "But float arrays are unboxed! This makes all my data structures 50% larger than they need to be! Bloat! Horror! Dynarrays should work just like arrays, but dynamic!" Brian, who is snarly because he's having to wade through some atrocious C++, and isn't in the mood to listen to people sing hosanahs to the language. |
From: John M. S. <sk...@oz...> - 2003-06-20 19:27:50
|
Brian Hurt wrote: > On Fri, 20 Jun 2003, John Max Skaller wrote: > > It is both fair and true. Notice that the examples I gave, all except > void* were unboxed. I don't know how many C++ compilers can figure out > that a Vector<foo*> and a Vector<bar*> can use the same object code. You didn't understand. They ALL can. Because it doesn't require any work by the compiler at all. It is the CLIENT that does it: template<class T> class vector<T*> { T* get(i) { static_cast<vector<void*> >(*this).get(i); } ... } All the compiler has to do is inline the get method call, which consists exclusively of type casting, and then dispatching to the common routine used by vectors of T* for all T. >>The principal problem in C++ here is the lack of >>a garbage collector. >> > > If this is the only reason you're using Ocaml and not C++, take a look at: > http://www.hpl.hp.com/personal/Hans_Boehm/gc/ > > Or you might take a gander at this language: > http://java.sun.com/ > I hear they're adding both templates and operator overloading in the next > version. Don't be silly. I said "the principle problem in C++ *here*" refering to the context of discussion. I meant: a vector of pointers in C++ isn't a substitute for a vector of T, because of memory management issues. You can do the very same trick for handles as raw pointers in C++, but that still won't handle recursive data structures .. > Don't have casts in Ocaml. you have Obj.magic, which is a cast. > I don't know of a way to force unboxing of > floats in an array without coding in C. There is no need to do that. The proposal is to make an array of ints. And cast input values, all of which are boxed, to int. And cast values being fetched into single values, all of which are boxed. If I could do that, Obj.magic() > would work. So we're talking about rewritting the whole thing in C. > Could be done. Don't use ints for the array type, use the Value type. Ok. > But one of the reasons I'm contributing to ExtLib is that I want to do > some programming in *Ocaml*. But I'm willing to take it under advisement, > and put it on my to do list. Just don't hold your breath. I agree, it would be nice to do everything in Ocaml. But this is a fundamental data type it seems we cannot do in Ocaml. The null value is not acceptable at all. Just suppose that you wanted to use a Dynarray.t to implement some part of another polymorphic container .. then you would have to pass the null value to IT too. So the null value 'permeates' any data structure you use it in. For example a list which automagically converts to an array to improve performance. So if it is necessary to do a C implementation, then do one, because it will make Ocaml programming so much easier. I need a dynamic array. I'm using lists far too often. I can implement it in Ocaml easily as an array ref, but I'd have to copy the array on *every* append operation. > And are you willing to gaurentee that no one will ever care that float > Dynarray.t's are boxed? "But float arrays are unboxed! This makes all my > data structures 50% larger than they need to be! Bloat! Horror! > Dynarrays should work just like arrays, but dynamic!" I can't guarrantee that, I'm just saying that if I have to choose, the null value's got to go. I won't use Dynarray otherwise, its already annoying to have to fill an array with a dummy value when I then immediately fill it with some other data: I can get around that with function, but it is often very inconvenient to have to wrap procedural code up. An important advantage of Dynarray is that it doesn't do gratuitous initialisations: neither wasting time nor requiring a dummy value. > Brian, who is snarly because he's having to wade through some atrocious > C++, and isn't in the mood to listen to people sing hosanahs to the > language. You have my sympathy. I have recently been blasting the committee about the mess. But I'm on it, I'm entitled :-) I'm not claiming C++ is a good language, especially compared to Ocaml. I'm just commenting that in this area, it is much better at handling unboxed data types, and therefore often can generated more efficient code. You are right that means *more* code, and also that in general, it instantiates needless duplicates of the same code... for example, the vector<void*> will often do for vector<int> on a Unix machine. -- John Max Skaller, mailto:sk...@oz... snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 |
From: Brian H. <bri...@ql...> - 2003-06-20 20:38:11
|
First off, an apology. I was grumpy this morning about things completely irrelevent to the list- and thus responded a lot more hotly than was called for. Sorry. And thank you for being rational enough not to flame in return. Unless I'm missing something (which is possible), there are three possible implementations of Dynarray that I can see working: 1) Have the internal array be a 'a option array, and not a 'a array as it is currently. This means we are going through at least one, maybe 2 references for every element, need it or not. If I understand things correctly, in this case a dynarray of booleans takes up 3 words per entry, and retrieving on takes two or three dereferences. 2) Use the null value kludge. I agree that this is far from optimal- but it allows me to avoid options were not needed, and still write in Ocaml. 3) Write in C, leaving floats unboxed. Actually, thinking about it, we could do this in C even keeping floats unboxed- if we don't allocate the array until the first element is added (and we know what type it is). I'm not opposed to option 3. Heck, I'd even support an implemention along those lines. I'm just unlikely to write it anytime soon. On Sat, 21 Jun 2003, John Max Skaller wrote: > There is no need to do that. The proposal is > to make an array of ints. And cast input values, > all of which are boxed, to int. And cast > values being fetched into single values, > all of which are boxed. > This won't work- it'll cause the GC to screw up. Since they're int's (the low bits are set), the GC won't follow any references. If the last reference to an object is in a Dynarray.t, the GC will think there aren't *any* references to the object at all, and collect the object. Then, when the reference is fished out of the int it was stored in and returned, all sorts of chaos will happen. Is there any sort of documentation kicking around about Obj? > > But one of the reasons I'm contributing to ExtLib is that I want to do > > some programming in *Ocaml*. But I'm willing to take it under advisement, > > and put it on my to do list. Just don't hold your breath. > > > I agree, it would be nice to do everything in Ocaml. > > But this is a fundamental data type it seems we cannot do > in Ocaml. > Actually, we can do it. Just have the inner array be a 'a option array instead of just a 'a array. > The null value is not acceptable at all. Just suppose > that you wanted to use a Dynarray.t to implement > some part of another polymorphic container .. > then you would have to pass the null value to IT too. > So the null value 'permeates' any data structure > you use it in. For example a list which automagically > converts to an array to improve performance. Yep. > > So if it is necessary to do a C implementation, > then do one, because it will make Ocaml > programming so much easier. > > I need a dynamic array. I'm using lists far too often. > I can implement it in Ocaml easily as an array ref, > but I'd have to copy the array on *every* append > operation. So take the time to write one. Write it once, write it correct, and submit the code. WRT to unboxed floats, I myself wouldn't be horrified. The only data structure in which floats are unboxed (to my knowledge) is arrays. If the data size is that important, use arrays. Actually, as on average about 1/2 of the dynarray is allocated by unused, I could make the argument that keeping floats in dynarrays unboxed actually uses less memory. > You have my sympathy. I have recently been blasting the > committee about the mess. But I'm on it, I'm entitled :-) I've been trying to keep the amount of C++ discussions on the Ocaml lists to an absolute minimum. As they are off topic. Brian |
From: Eric C. C. <ec...@cm...> - 2003-06-20 22:02:26
|
On Fri, Jun 20, 2003 at 03:58:38PM -0500, Brian Hurt wrote: > Unless I'm missing something (which is possible), there are three possible > implementations of Dynarray that I can see working: > > 1) Have the internal array be a 'a option array, and not a 'a array as it > is currently. [...] > 2) Use the null value kludge. [...] > 3) Write in C, leaving floats unboxed. [...] I'm probably missing some essential context, but what is wrong with the simple approach of using a mutable 'a array that gets replaced with a bigger one when you try to set an element beyond its current length? Something like the following: type 'a t = { mutable data : 'a array; mutable length : int } let make n v = { data = Array.make n v; length = n } let empty () = { data = [||]; length = 0 } let length a = a.length let get a i = if i < a.length then a.data.(i) else raise (Invalid_argument "Dynarray.get") let set a i v = if i >= a.length then begin if i >= Array.length a.data then begin let n = Array.length a.data in let newlen = max (i+1) (2*n) in let newdata = Array.make newlen v in Array.blit a.data 0 newdata 0 n; a.data <- newdata end; a.length <- i + 1 end; a.data.(i) <- v -- Eric C. Cooper e c c @ c m u . e d u |
From: Brian H. <bri...@ql...> - 2003-06-20 22:08:52
|
On Fri, 20 Jun 2003, Eric C. Cooper wrote: > On Fri, Jun 20, 2003 at 03:58:38PM -0500, Brian Hurt wrote: > > Unless I'm missing something (which is possible), there are three possible > > implementations of Dynarray that I can see working: > > > > 1) Have the internal array be a 'a option array, and not a 'a array as it > > is currently. [...] > > 2) Use the null value kludge. [...] > > 3) Write in C, leaving floats unboxed. [...] > > I'm probably missing some essential context, but what is wrong with > the simple approach of using a mutable 'a array that gets replaced > with a bigger one when you try to set an element beyond its current > length? Because then you are allocating a new array- and copying all the elements of the old array- every time you add a new element to the end of the array. So if you add n elements to an empty array, you end up allocating n arrays, and copying n*(n-1)/2 elements. At which point you might as well be using lists and @. Brian |
From: Eric C. C. <ec...@cm...> - 2003-06-20 23:45:06
|
On Fri, Jun 20, 2003 at 05:29:26PM -0500, Brian Hurt wrote: > On Fri, 20 Jun 2003, Eric C. Cooper wrote: > > I'm probably missing some essential context, but what is wrong with > > the simple approach of using a mutable 'a array that gets replaced > > with a bigger one when you try to set an element beyond its current > > length? > > Because then you are allocating a new array- and copying all the elements > of the old array- every time you add a new element to the end of the > array. So if you add n elements to an empty array, you end up allocating > n arrays, and copying n*(n-1)/2 elements. At which point you might as > well be using lists and @. If you double the array each time you need to grow it, you will create only O(log n) arrays, and copy only O(n log n) elements. Do any of the other approaches have better worst-case performance? -- Eric C. Cooper e c c @ c m u . e d u |
From: Alan P. <ap...@re...> - 2003-06-20 23:56:39
|
In article <200...@ec...>, Eric C. Cooper wrote: > On Fri, Jun 20, 2003 at 05:29:26PM -0500, Brian Hurt wrote: >> On Fri, 20 Jun 2003, Eric C. Cooper wrote: >> > I'm probably missing some essential context, but what is wrong with >> > the simple approach of using a mutable 'a array that gets replaced >> > with a bigger one when you try to set an element beyond its current >> > length? >> >> Because then you are allocating a new array- and copying all the elements >> of the old array- every time you add a new element to the end of the >> array. So if you add n elements to an empty array, you end up allocating >> n arrays, and copying n*(n-1)/2 elements. At which point you might as >> well be using lists and @. > > If you double the array each time you need to grow it, you will > create only O(log n) arrays, and copy only O(n log n) elements. Do > any of the other approaches have better worst-case performance? What is under discussion is what to put in the "empty" slots of the newly doubled array, ocaml having no "null" or "undef" value to stuff in them. |
From: Yamagata Y. <yor...@mb...> - 2003-06-21 08:48:37
|
From: Alan Post <ap...@re...> Subject: [Ocaml-lib-devel] Re: Array interface Date: Fri, 20 Jun 2003 23:56:25 +0000 (UTC) > What is under discussion is what to put in the "empty" slots of the > newly doubled array, ocaml having no "null" or "undef" value to stuff > in them. I do not understand the motive of Dynarray, so perhaps it is dumb to ask, but what is wrong with Markus's RES library? -- Yamagata Yoriyuki |
From: John M. S. <sk...@oz...> - 2003-06-21 23:52:08
|
Yamagata Yoriyuki wrote: > From: Alan Post <ap...@re...> > Subject: [Ocaml-lib-devel] Re: Array interface > Date: Fri, 20 Jun 2003 23:56:25 +0000 (UTC) > > >>What is under discussion is what to put in the "empty" slots of the >>newly doubled array, ocaml having no "null" or "undef" value to stuff >>in them. >> > > I do not understand the motive of Dynarray, Variable length array with automatic efficient resizing. It needs to allocate more store than the number of slots actually needed to minimise reallocation on extension of the array, and allow contraction without necessarily reallocating. So there are some slots of the underlying array that are unused. The problem is how to fool the garbage collector without a dummy object to put in the unused slots. The client may not be able to construct an object of the right type easily, and copying a real element may create references that prevent the collector removing an object -- unless the design carefully refills unused slots with the value of a used slot -- and destroys the array completely when no slots are used. Therefore, there is no really good design 'in ocaml': Dynarray is really a system primitive. Hmmm.. it was said a C implementation should use VALUE macro not integer 0. A small C interface will make that available as a universal NULL value? I guess this is a C null pointer: ie, an address the collector will leave alone, rather than an integer the collector will leave alone? -- John Max Skaller, mailto:sk...@oz... snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 |
From: Michal M. <mal...@pl...> - 2003-06-22 07:52:09
|
On Sun, Jun 22, 2003 at 09:51:40AM +1000, John Max Skaller wrote: > Hmmm.. it was said a C implementation should use VALUE > macro not integer 0. A small C interface will make > that available as a universal NULL value? It doesn't have to NULL pointer, any other pointer should do. Using: let null = ref 0.0 seems to work (with Obj.magic). Using Obj.magic 0 to assign float array causes SEGV. But this null needs to be global, so it won't get GCed itself. -- : Michal Moskal :: http://www.kernel.pl/~malekith : GCS {C,UL}++++$ a? !tv : When in doubt, use brute force. -- Ken Thompson : {E-,w}-- {b++,e}>+++ h |
From: John M. S. <sk...@oz...> - 2003-06-21 04:27:31
|
Eric C. Cooper wrote: > On Fri, Jun 20, 2003 at 03:58:38PM -0500, Brian Hurt wrote: > I'm probably missing some essential context, but what is wrong with > the simple approach of using a mutable 'a array that gets replaced > with a bigger one when you try to set an element beyond its current > length? Nothing other than performance. -- John Max Skaller, mailto:sk...@oz... snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 |
From: Michal M. <mal...@pl...> - 2003-06-20 22:31:24
|
On Fri, Jun 20, 2003 at 03:58:38PM -0500, Brian Hurt wrote: > > First off, an apology. I was grumpy this morning about things completely > irrelevent to the list- and thus responded a lot more hotly than was > called for. Sorry. And thank you for being rational enough not to flame > in return. > > Unless I'm missing something (which is possible), there are three possible > implementations of Dynarray that I can see working: > > 1) Have the internal array be a 'a option array, and not a 'a array as it > is currently. This means we are going through at least one, maybe 2 > references for every element, need it or not. If I understand things > correctly, in this case a dynarray of booleans takes up 3 words per entry, > and retrieving on takes two or three dereferences. I just did some mini-tests, and it seems that compiler uses one Some true and Some false value for all entries, i.e. one boolean takes one word in bool option array. However for ints it takes 3 words per array entry (if int's are all different, when setting all the array to Some 3, it took one word per entry). > 2) Use the null value kludge. I agree that this is far from optimal- but > it allows me to avoid options were not needed, and still write in Ocaml. Maybe use first value put into array as null value, and maybe provide way of setting null value as additional interface? This would have one drawback, that this first value might be complex object with references that would otherwise got GC-ed. > WRT to unboxed floats, I myself wouldn't be horrified. The only data > structure in which floats are unboxed (to my knowledge) is arrays. Records with only-floats fields also use unboxed floats. However my idea about unboxed floats in ocaml, is that floats are extensively used in benchmarks :-) -- : Michal Moskal :: http://www.kernel.pl/~malekith : GCS {C,UL}++++$ a? !tv : When in doubt, use brute force. -- Ken Thompson : {E-,w}-- {b++,e}>+++ h |
From: John M. S. <sk...@oz...> - 2003-06-21 04:25:18
|
Brian Hurt wrote: > First off, an apology. I was grumpy this morning about things completely > irrelevent to the list- and thus responded a lot more hotly than was > called for. Sorry. And thank you for being rational enough not to flame > in return. I wouldn't dare .. its usually ME that is the hot head: get in trouble for it all the time on the C++ committee reflector. > I'm not opposed to option 3. Heck, I'd even support an implemention > along those lines. I'm just unlikely to write it anytime soon. It should be done by the OCaml team. They'll get it right and ensure it stays synched with implementation changes. -- John Max Skaller, mailto:sk...@oz... snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 |