In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> I think I'd rather see associative arrays a la perl.

Maybe Warp can implement that as a macro... :-)
Could you give more information on what the syntax would be like? Aren't 
associative arrays just structures that "associate" a string or hash 
with a variable?

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On Mon, 27 Nov 2000 16:45:50 -0500, Chris Huff wrote:
>In article <slr### [at] fwicom>, ron### [at] povrayorg 
>wrote:
>
>> I think I'd rather see associative arrays a la perl.
>
>Maybe Warp can implement that as a macro... :-)
>Could you give more information on what the syntax would be like? Aren't 
>associative arrays just structures that "associate" a string or hash 
>with a variable?

The Perl syntax, which is, well, Perl syntax, is  

$foo{"bar"}

which indicates "the scalar member of associative array foo having index
'bar'".

An associative array is a variable-sized data structure (a hash table, 
in Perl) which associates a key with an arbitrary scalar value.  Perl
uses them to do its equivalent of data structures, among other things.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> The Perl syntax...

I meant your idea of what it would look like in POV. Hopefully a little 
better than "$foo{"bar"}"...


> An associative array is a variable-sized data structure (a hash table, 
> in Perl) which associates a key with an arbitrary scalar value.  Perl
> uses them to do its equivalent of data structures, among other things.

I see...but a POV one would have to allow more than just scalars, but 
also vectors, objects...what should the keys be? Should(could?) both 
scalars and strings be allowed as keys? Or maybe keys should be used 
like identifiers...

#declare AssocArray =
assoc_array {
    Ident, Val;
    Ident2, Val2;
    Ident3, Val3;
    ...
};

Or maybe this, more consistent with other POV syntax...

#declare AssocArray =
assoc_array {
    {Ident, Val},
    {Ident2, Val2},
    {Ident3, Val3},
    ...
};

// Adds an item or modifies an existing item...
#declare AssocArray[NewIdent] = AssocArray[Ident2] + AssocArray[Ident1];

Or this, farther from array syntax(which may be a good thing, since it 
isn't the same thing) but makes more sense(to me):

#declare AssocArray.NewIdent = AssocArray.Ident2 + AssocArray.Ident1;

The identifier names would be local to the array, you would be able to 
use them in other places. It should be possible to have an associative 
array with a member with the same name as the array:
#declare Moof =
assoc_array {
    {Moof, 2.5}
};

#declare Moof.Moof = 6;

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On Mon, 27 Nov 2000 21:27:25 -0500, Chris Huff wrote:
>I see...but a POV one would have to allow more than just scalars, but 
>also vectors, objects...what should the keys be? Should(could?) both 

Well, in Perl, a reference to an array or another hash is itself a scalar,
so you can put almost anything in as the value.  If the value is itself
a hash (reference) you even get the effect of a multidimensional hash.

>scalars and strings be allowed as keys? Or maybe keys should be used 
>like identifiers...

As long as we're dreaming, might as well allow the key to be a string, vector,
color, or scalar.  Allowing scalars gives everyone those growable and/or 
sparse arrays they were looking for, too, at the expense of a bit of speed 
and efficiency.

>// Adds an item or modifies an existing item...
>#declare AssocArray[NewIdent] = AssocArray[Ident2] + AssocArray[Ident1];

I like how Perl uses curly braces for hashes so it's obvious what's going on.
We use curly braces for far too many things in POV already, but it'd be nice
if we could find some syntax that doesn't look like arrays.

>Or this, farther from array syntax(which may be a good thing, since it 
>isn't the same thing) but makes more sense(to me):
>
>#declare AssocArray.NewIdent = AssocArray.Ident2 + AssocArray.Ident1;

But not like this.  This looks too much like an object syntax, and I want it
to be clear that the primary purpose of an associative array is as a key/value
dictionary.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> We use curly braces for far too many things in POV already,
...snip...

That's funny, I didn't think they were used enough...


> But not like this.  This looks too much like an object syntax, and I 
> want it to be clear that the primary purpose of an associative array 
> is as a key/value dictionary.

Too much like object syntax? It seems closer to vectors to me, which 
makes it make even more sense...a vector has 3 elements with the keys 
being x, y, and z. Is your objection to the use of a single operator 
instead of brackets? How about:
AssocArray->NewIdent
or
AssocArray:NewIdent
or
NewIdent@AssocArray
or
AssocArray(NewIdent)

I think it would be better to use a more familiar syntax(the dot 
operator) than to use some rarely used character.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On Tue, 28 Nov 2000 06:24:44 -0500, Chris Huff wrote:
>makes it make even more sense...a vector has 3 elements with the keys 
>being x, y, and z. Is your objection to the use of a single operator 
>instead of brackets? How about:

Yes.  Without brackets of some kind, it would be harder to read and 
ambiguous to parse:

AssocArray->red 1 green .5 blue .2 filter .8 transmit 0
AssocArray->5*x+y


-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
:> I think I'd rather see associative arrays a la perl.

: Maybe Warp can implement that as a macro... :-)

  I don't think there's any efficient way of implementing that in the current
povray scripting language.
  The most efficient way (timewise) of implementing an associative array
is using a weighted binary tree. Implementing one in povray is probably a
pain (I can't say the word "impossible" since I have been surprised many
times with things that seemed impossible but they were implemented anyways;
I would, however, say that if it is possible, it's probably slow as h***).

  An extremely slow way of doing it would be just making a dynamic array
(or perhaps a growing string). Would work fine for some tens of items, but
it would be just way too slow for thousands of items. Not worth the
efforts, anyways.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> Yes.  Without brackets of some kind, it would be harder to read and 
> ambiguous to parse:

I was thinking that only valid identifiers would be useable as keys. 
Basically a group of variables called by name, something that could 
probably be done easily with a sort of name-mangling.
AssocArray:Val3 would be translated to _AssocArray__Val3_ or something 
similarly unlikely to be used by the user. No special data structures 
would need to be added, but it would be a little more limited.

If you can use any values as a key, but not identifiers, it is a bit 
different...how about the function-like notation? Or just go back to the 
[] array notation, which seems to work well enough in this case.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On Wed, 29 Nov 2000 06:59:16 -0500, Chris Huff wrote:
>I was thinking that only valid identifiers would be useable as keys. 
>Basically a group of variables called by name, something that could 
>probably be done easily with a sort of name-mangling.

Yes, but then it couldn't be used for the sort of iden() tricks this whole
thing started with, nor for the sparse or dynamic arrays others have asked
for.

>If you can use any values as a key, but not identifiers, it is a bit 
>different...how about the function-like notation? Or just go back to the 
>[] array notation, which seems to work well enough in this case.

I prefer the [] notation to the () notation, but I wish there were a third
alternative besides {}, because either [] or () is going to require the person
reading the code to find the declaration to know what's going on.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> Yes, but then it couldn't be used for the sort of iden() tricks this whole
> thing started with, nor for the sparse or dynamic arrays others have asked
> for.

Like I said: "it would be a little more limited". Probably not worth it.
However, it should do a pretty good imitation of sparse/dynamic arrays 
if used in combination with a iden() function/macro, and be fairly 
simple to implement.


> I prefer the [] notation to the () notation,

So do I, now that I have thought about it more.


> but I wish there were a third alternative besides {}, because either 
> [] or () is going to require the person reading the code to find the 
> declaration to know what's going on.

Will it? There isn't a lot of difference between a key and an index, at 
least not to most people...it will be pretty well understood that 
Array[Var] will retrieve element Var of array Array, whether Array is an 
associative array or an ordinary array and whether Var is a scalar, 
string, vector...
If someone uses Array["ParticleSpeed"], it is pretty obvious it is an 
associative array, if they use Array[5] there is an ambiguity, but it 
usually won't matter.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message