Re: [RESEND] Q: Array vs SArray
On 25 Jan 2004, at 00:50, Gordon Henriksen wrote: [...] Is there something so terribly wrong with English? How about a general scheme of adjective* noun? So, respectively, MixedArray Array FixedArray StringArray FixedStringArray Array is what Perl familiars will usually want. Did I miss something? What is Array here? General scheme: Need something more specific? Type more. Not sure on Fixed, but I like it more than FLen. Other option is to flip it around and tag Resizable, but that violates my previous pricipal of most useful = most convenient. I don't think MixedArray will see much use, so FixedMixedArray doesn't worry me too much. :) I would definitely avoid the words mutable/immutable, as that will certainly be read by many (me :) to pertain to the values contained within the array. Yes, I'm already anti-me on that. It should have been Resizable. And though that's more precise than Fixed, I agree with your principle. So, to go back to Dan's original list, does that give us: (FixedMixedArray - fixed-size, mixed-type array) MixedArray - variable-sized, mixed-type array FixedPMCArray - fixed-size, PMC array PMCArray - variable-sized, PMC array FixedStringArray - fixed-size, string array StringArray - variable-sized, string array FixedNumberArray - fixed-size, number array StringArray - variable-sized, number array FixedIntegerArray - fixed-size, integer array IntegerArray - variable-sized, integer array with fixedarray - abstract fixed-size array array - abstract variable-sized array for the common functionality. Mike
Re: [RESEND] Q: Array vs SArray
On Sunday, January 25, 2004, at 06:10 , Michael Scott wrote: On 25 Jan 2004, at 00:50, Gordon Henriksen wrote: [...] Is there something so terribly wrong with English? How about a general scheme of adjective* noun? So, respectively, MixedArray Array FixedArray StringArray FixedStringArray Array is what Perl familiars will usually want. Did I miss something? What is Array here? General scheme: Need something more specific? Type more. Not sure on Fixed, but I like it more than FLen. Other option is to flip it around and tag Resizable, but that violates my previous pricipal of most useful = most convenient. I don't think MixedArray will see much use, so FixedMixedArray doesn't worry me too much. :) I would definitely avoid the words mutable/immutable, as that will certainly be read by many (me :) to pertain to the values contained within the array. Yes, I'm already anti-me on that. It should have been Resizable. And though that's more precise than Fixed, I agree with your principle. So, to go back to Dan's original list, does that give us: (FixedMixedArray - fixed-size, mixed-type array) MixedArray - variable-sized, mixed-type array FixedPMCArray - fixed-size, PMC array PMCArray - variable-sized, PMC array I'd abbreviate PMC as , since it's certain to be the most commonly-used. OTOH, PMC isn't a very long identifier to type. FixedStringArray - fixed-size, string array StringArray - variable-sized, string array FixedNumberArray - fixed-size, number array StringArray - variable-sized, number array FixedIntegerArray - fixed-size, integer array IntegerArray - variable-sized, integer array with fixedarray - abstract fixed-size array array - abstract variable-sized array Perhaps base*. Or perhaps not. Gordon Henriksen [EMAIL PROTECTED]
Re: [RESEND] Q: Array vs SArray
Michael Scott [EMAIL PROTECTED] wrote: So, to go back to Dan's original list, does that give us: (FixedMixedArray - fixed-size, mixed-type array) MixedArray - variable-sized, mixed-type array FixedPMCArray - fixed-size, PMC array PMCArray - variable-sized, PMC array FixedStringArray - fixed-size, string array StringArray - variable-sized, string array FixedNumberArray - fixed-size, number array StringArray - variable-sized, number array FixedIntegerArray - fixed-size, integer array IntegerArray - variable-sized, integer array with fixedarray - abstract fixed-size array array - abstract variable-sized array I'd vote for that scheme. Takers wanted. Mike leo
Re: [RESEND] Q: Array vs SArray
On Friday, January 23, 2004, at 11:05 , Tim Bunce wrote: Here's my preference: *) ArrayFLenMixed - fixed-size, mixed-type array *) ArrayVLenPMC- variable-sized PMC array *) ArrayFLenPMC- fixed-size PMC array *) ArrayVLenString - variable-sized string array *) ArrayFLenString - fixed-size string array (Of course VLen/FLen could be VSize/FSize if preferred, and Mixed seemed better than Any as I recall it's not truly any type.) The general scheme is container typequalifierscontained type Is there something so terribly wrong with English? How about a general scheme of adjective* noun? So, respectively, MixedArray Array FixedArray StringArray FixedStringArray Array is what Perl familiars will usually want. General scheme: Need something more specific? Type more. Not sure on Fixed, but I like it more than FLen. Other option is to flip it around and tag Resizable, but that violates my previous pricipal of most useful = most convenient. I don't think MixedArray will see much use, so FixedMixedArray doesn't worry me too much. :) I would definitely avoid the words mutable/immutable, as that will certainly be read by many (me :) to pertain to the values contained within the array. Gordon Henriksen [EMAIL PROTECTED]
Re: [RESEND] Q: Array vs SArray
Is there a reason why the names have to be so terse? Mutable is not a bad word for able-to-change. (Cribbed from Cocoa, though there the immutability is absolute). *) Array - fixed-size, mixed-type array *) MutablePArray - variable-sized PMC array *) PArray - Fixed-size PMC array *) MutableSArray - variable-sized string array *) SArray - fixed-size string array Mike On 22 Jan 2004, at 19:24, Dan Sugalski wrote: At 2:15 PM -0500 1/21/04, Matt Fowles wrote: All~ So, lets do the classes as: *) Array - fixed-size, mixed-type array *) vPArray - variable-sized PMC array *) PArray - Fixed-size PMC array *) vSArray - variable-sized string array *) SArray - fixed-size string array I suggest using Array to mean fixed size and Vector to mean variable size. I'd rather not. Vector, for me at least, has some specific connotations (from physics) that don't really match what we're talking about here. They're more vectors in the mathematical sense, but they won't behave like mathematical vectors so I don't think that's a good idea either. Array, while mundane (and a bit annoying with the prefix stuff tacked on) is at least accurate. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [RESEND] Q: Array vs SArray
At 2:19 PM +0100 1/23/04, Michael Scott wrote: Is there a reason why the names have to be so terse? No, I suppose not. Chalk it up to typing laziness, so the longer names are certainly a viable option. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [RESEND] Q: Array vs SArray
On Fri, Jan 23, 2004 at 02:19:37PM +0100, Michael Scott wrote: Is there a reason why the names have to be so terse? Mutable is not a bad word for able-to-change. (Cribbed from Cocoa, though there the immutability is absolute). *) Array - fixed-size, mixed-type array *) MutablePArray - variable-sized PMC array *) PArray - Fixed-size PMC array *) MutableSArray - variable-sized string array *) SArray - fixed-size string array By mutable you mean size but others might read it as the types or contents or some other aspect. Here's my preference: *) ArrayFLenMixed - fixed-size, mixed-type array *) ArrayVLenPMC- variable-sized PMC array *) ArrayFLenPMC- fixed-size PMC array *) ArrayVLenString - variable-sized string array *) ArrayFLenString - fixed-size string array (Of course VLen/FLen could be VSize/FSize if preferred, and Mixed seemed better than Any as I recall it's not truly any type.) The general scheme is container typequalifierscontained type Tim. Mike On 22 Jan 2004, at 19:24, Dan Sugalski wrote: At 2:15 PM -0500 1/21/04, Matt Fowles wrote: All~ So, lets do the classes as: *) Array - fixed-size, mixed-type array *) vPArray - variable-sized PMC array *) PArray - Fixed-size PMC array *) vSArray - variable-sized string array *) SArray - fixed-size string array I suggest using Array to mean fixed size and Vector to mean variable size. I'd rather not. Vector, for me at least, has some specific connotations (from physics) that don't really match what we're talking about here. They're more vectors in the mathematical sense, but they won't behave like mathematical vectors so I don't think that's a good idea either. Array, while mundane (and a bit annoying with the prefix stuff tacked on) is at least accurate. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [RESEND] Q: Array vs SArray
Dan Sugalski [EMAIL PROTECTED] wrote: *) Array - fixed-size, mixed-type array Personally I'd leave Array as it is, since it does one of the things that we need it to do. Array isn't really mixed-typed. It has methods to store or retrieve non-PMC types, but they are converted internally to PMCs. A true mixed-typed Array could use a typed union, i.e. the HashEntry type. This needs more space, but is type-safe and avoids PMC creation overhead. What do we need? leo
Re: [RESEND] Q: Array vs SArray
At 2:15 PM -0500 1/21/04, Matt Fowles wrote: All~ So, lets do the classes as: *) Array - fixed-size, mixed-type array *) vPArray - variable-sized PMC array *) PArray - Fixed-size PMC array *) vSArray - variable-sized string array *) SArray - fixed-size string array I suggest using Array to mean fixed size and Vector to mean variable size. I'd rather not. Vector, for me at least, has some specific connotations (from physics) that don't really match what we're talking about here. They're more vectors in the mathematical sense, but they won't behave like mathematical vectors so I don't think that's a good idea either. Array, while mundane (and a bit annoying with the prefix stuff tacked on) is at least accurate. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [RESEND] Q: Array vs SArray
Dan Sugalski [EMAIL PROTECTED] wrote: Okay, at this point we've a pile of different array classes Before we go any further we need to figure out what we want. 1) Unify setting/getting element count - the elements() vtable is unused (not accessible by opcode) - we use get_integer() - push for Array is unusabale currently - reserve array store size before filling can have performance benefits by avoiding reallocation So e.g. elements I0, P0 # @a.elements # scalar @a elements P0, I0 # @a.elements = I0 # $#a = I0-1 set I0, P0 # @a.internal_capacity set P0, I0 # @a.internal_capacity = I0 2) Array vs PerlArray - PerlArray does autoexpand and is derived from Array. - Array throws exceptions if you access elements beyond capacity - the underlying List does not do bounds checking So the class inheritance is wrong. 3) SArray - Should have been a simple typed array (At these times PerlHash store was typed too). Its obsolete now. 4) list.c - is too complicated for the current usage patterns A currently better implementation could be e.g. - one buffer array - a start index to accomodate shift/unshift - resize by 2 n until a certain limit, then by that limit - after pop/shift shrink buffer by limit if limit+threshold is free leo
Re: [RESEND] Q: Array vs SArray
At 9:38 AM +0100 1/21/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Okay, at this point we've a pile of different array classes Before we go any further we need to figure out what we want. 1) Unify setting/getting element count - the elements() vtable is unused (not accessible by opcode) - we use get_integer() - push for Array is unusabale currently - reserve array store size before filling can have performance benefits by avoiding reallocation Okay. So, let's do the following: *) Expose elements as an op. Two, actually, as we should have a get and set version. *) Expand elements to get_elements and set_elements 2) Array vs PerlArray 3) SArray If SArray is obsolete, let's kill it. I'd like to ultimately have a fixed-size PMC array, a variable size PMC array, fixed-size typed arrays, and variable-sized typed arrays. For the moment the fixed and variable sized PMC arrays are fine. Folks seem to want a mixed-type array as well, and while we'll pay performance for that I don't see any reason to not do it, though we can live with a fixed-size version for now. So, lets do the classes as: *) Array - fixed-size, mixed-type array *) vPArray - variable-sized PMC array *) PArray - Fixed-size PMC array *) vSArray - variable-sized string array *) SArray - fixed-size string array And so on, for N and I arrays. I'm not particularly attached to the names. (Actually I think they suck, but they are reasonably descriptive) Personally I'd leave Array as it is, since it does one of the things that we need it to do. PerlArray can be a full subclass of vPArray, since right now they're the same thing. That may change at some point later on. 4) list.c - is too complicated for the current usage patterns A currently better implementation could be e.g. - one buffer array - a start index to accomodate shift/unshift - resize by 2 n until a certain limit, then by that limit - after pop/shift shrink buffer by limit if limit+threshold is free If you want to hack in on this, go ahead, though it looks like something that we'll ultimately need--its the guts of a sparse mixed-type array, which is useful and we may well need at some point. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [RESEND] Q: Array vs SArray
All~ So, lets do the classes as: *) Array - fixed-size, mixed-type array *) vPArray - variable-sized PMC array *) PArray - Fixed-size PMC array *) vSArray - variable-sized string array *) SArray - fixed-size string array I suggest using Array to mean fixed size and Vector to mean variable size. Thus yielding *) Array - fixed-size, mixed-type array *) Vector - variable-size, mixed-type array *) PArray - Fixed-size PMC array *) PVector - variable-sized PMC array *) SArray - fixed-size string array *) SVector - variable-sized string array etc. One could also use List for variable sized, but I have C++ based biases for vector... Matt
Re: [RESEND] Q: Array vs SArray
Dan Sugalski writes: At 9:38 AM +0100 1/21/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Okay, at this point we've a pile of different array classes Before we go any further we need to figure out what we want. 1) Unify setting/getting element count - the elements() vtable is unused (not accessible by opcode) - we use get_integer() - push for Array is unusabale currently - reserve array store size before filling can have performance benefits by avoiding reallocation Okay. So, let's do the following: *) Expose elements as an op. Two, actually, as we should have a get and set version. I'd like it to be possible to return infinity here. If that means setting a PMC or returning a PMC, I think that's fine. As long as there are also Ireg variants. Luke
Re: [RESEND] Q: Array vs SArray
*) Array - fixed-size, mixed-type array *) vPArray - variable-sized PMC array *) PArray - Fixed-size PMC array *) vSArray - variable-sized string array *) SArray - fixed-size string array And so on, for N and I arrays. I'm not particularly attached to the names. (Actually I think they suck, but they are reasonably descriptive) i think they are not that bad... calling some vectors would mean having to remember which of the two synonyms is used for what - this can be hard. the 'modifiers' are on the front so its easier to parse them (as the regexp apocalypse explains) if i follow this correctly, variable-size means they autoeXpand, so maybe an x instead of v might also be understandable... (we would then have xp arrays ;) LF
Re: [RESEND] Q: Array vs SArray
Dan Sugalski [EMAIL PROTECTED] wrote: 4) list.c If you want to hack in on this, go ahead, though it looks like something that we'll ultimately need--its the guts of a sparse mixed-type array, which is useful and we may well need at some point. Actually that was the reason, I implemented it like that. But I'd like to have it a bit simplified, that is: - for small element counts use that simplified scheme - else use the current chunk based one with constant chunk size This could simplify the code by a fare amount. leo
Re: [RESEND] Q: Array vs SArray
Dan Sugalski [EMAIL PROTECTED] wrote: So, lets do the classes as: *) Array - fixed-size, mixed-type array *) vPArray - variable-sized PMC array *) PArray - Fixed-size PMC array *) vSArray - variable-sized string array *) SArray - fixed-size string array Actually I forgot one: We already have IntList, which is INTVAL only and doesn't bounds checking - vIArray in that naming convention. BTW SArray nicely meats current main usage as @argv :) And so on, for N and I arrays. I'm not particularly attached to the names. Nor am I. But the scheme sounds reasonable. leo
Re: [RESEND] Q: Array vs SArray
At 2:17 PM +0100 1/11/04, Leopold Toetsch wrote: One further note, while at Array/PerlArray: the class dependency is suboptimal. PerlArray isa Array isa list. The underlying list is auto-extending and does no bounds checking. Array does bounds-checking. PerlArray doesn't bounds check. So for better performace and simpler code, the dependency of PerlArray and Array should be swapped. Okay, at this point we've a pile of different array classes with fuzzy requirements and specified behaviours which sort of inherit from each other except when they don't. Before we go any further we need to figure out what we want. Then we need to see what we have. Then it's time to kill off the unneeded stuff and fix the rest. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[RESEND] Q: Array vs SArray
[ warnocked ] Leopold Toetsch [EMAIL PROTECTED] wrote: The set_integer_native() vtable method of arrays is implemented inconsistently. The old historical way in Array was to set an initial size. My implementation in SArray OTOH only reserves the needed store, but doesn't change the element count. new P0, .SArray set P0, 2 set I0, P0 # SArray.elements() print I0 new P1, .Array # or .PerlArray set P1, 2 set I1, P1 # Array.elements() print I1 print \n end 02 This is bad. But it gets worse: You can do push P0, x twice on the SArray, filling the first 2 elements. You can't do that on Array. It would set the element #2 which is beyond the preset element count - push is currently not usable for Array PMCs. (PerlArray works basically like Array but does auto-extend) I'd like to unify the behavior and get best from these two worlds: 1) can set an initial store size and (if really needed) 2) can set an initial element count, not-yet set values are NULL. One further note, while at Array/PerlArray: the class dependency is suboptimal. PerlArray isa Array isa list. The underlying list is auto-extending and does no bounds checking. Array does bounds-checking. PerlArray doesn't bounds check. So for better performace and simpler code, the dependency of PerlArray and Array should be swapped. Comments welcome, leo leo
