Q: Array vs SArray
Leopold Toetsch
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
Amir Karger
>
> 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.
I know far too little to comment, but I'll comment anyway.
Is auto-extending the ONLY way in which PerlArray differs from Array?
I'm going to guess it isn't, in which case I would think Array should
be a child of list and a sibling of PerlArray (or a sibling of some
child of list that PerlArray is a child of).
-Amir
Leopold Toetsch
> Comments welcome,
> leo
leo
Dan Sugalski
> > 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
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> 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
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> 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.
Matt Fowles
> 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
Luke Palmer
> At 9:38 AM +0100 1/21/04, Leopold Toetsch wrote:
> >Dan Sugalski <d...@sidhe.org> 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
Lf
> *) 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
Leopold Toetsch
>>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
Leopold Toetsch
> 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
Leopold Toetsch
> *) 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
Dan Sugalski
>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.
Michael Scott
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
Dan Sugalski
>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.
Tim Bunce
> 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 type><qualifiers><contained type>
Tim.
Gordon Henriksen
> 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 type><qualifiers><contained 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
mali...@mac.com
Michael Scott
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
Gordon Henriksen
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
mali...@mac.com
Leopold Toetsch
> 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