 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
iden( string )
Turns a string into an identifier.
For example:
#declare iden("ThisFloat") = ThatFloat*2;
or
#declare ThisFloat = iden("ThatFloat")*2;
I find myself often need such a feature *very* much!
Please, anyone? :)
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated October 9)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
>
> iden( string )
>
> Turns a string into an identifier.
>
> For example:
>
> #declare iden("ThisFloat") = ThatFloat*2;
>
> or
>
> #declare ThisFloat = iden("ThatFloat")*2;
>
> I find myself often need such a feature *very* much!
>
> Please, anyone? :)
>
> Rune
I'm not sure if that's easy to implement, furthermore it's likely to
produce errors because the string can change during eveluation of the Pov
code.
BTW, i don't know any programming language that has such a function.
Christoph
--
Christoph Hormann <chr### [at] gmx de>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> I'm not sure if that's easy to implement, furthermore it's likely to
> produce errors because the string can change during eveluation of the Pov
> code.
>
> BTW, i don't know any programming language that has such a function.
I would imagine that the ability to change the string dynamically during the
parsing of the script is precisely the reason Rune would like a function
like this! And it's not unheard of - PHP, for instance, allows variable
variables, i.e. you can have one variable $a = "name", then use $$a just as
if it were $name.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The iden() feature would be perfect in situations where arrays aren't
flexible enough.
An array like this
FlexArray[X][Y]
could be made like this
iden( concat( "FlexArray", str(X,0,0), "x", str(Y,0,0) ) )
However, in arrays all the elements have to be of the same data type. Not so
with the iden solution.
Arrays are confined to the number of elements you initiate it with. Not so
with the iden solution.
With arrays you are limited to the dimensions you set. All rows and columns
must have the same number of elements. With the iden solution you can make
up a completely custom structure.
These are just some of the many possibilities with the iden() feature. Don't
hesitate, buy it today! Err, I mean, program it today! :)
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated October 9)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This looks like a potentially powerful feature...I don't know how easily
it could be done, but it shouldn't be impossible or very difficult.
It might allow the creation of a kind of "OOP" system written entirely
in POV-Script...though that would be a very slow and clumsy way to do it.
--
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 Sun, 26 Nov 2000 13:49:15 +0100, Rune wrote:
>iden( string )
>
>Turns a string into an identifier.
I think I'd rather see associative arrays a la perl.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
#macro iden(String)
#fopen TmpFile "tmptmp.tmp" write
#write(TmpFile, String)
#fclose TmpFile
#include "tmptmp.tmp"
#end
You can then use it exactly as you wanted:
#declare iden("ThisFloat") = ThatFloat*2;
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> #macro iden(String)
> #fopen TmpFile "tmptmp.tmp" write
> #write(TmpFile, String)
> #fclose TmpFile
> #include "tmptmp.tmp"
> #end
I had been thinking about using #write and #include some way or another to
solve my problem, but your solution is just perfect!
Thank you Warp, you have spared me for a lot a trouble. :)
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated October 9)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I had briefly considered writing to a file and then including it, but
didn't think it would work in all cases, because including a file or
calling a macro doesn't do a direct copy and paste...can you use it in
macro parameters?
That macro is a great way of getting it done now, but a built-in feature
wouldn't leave that temporary file hanging around...a minor
inconvenience, but annoying, especially if it conflicts with another
file, though that isn't likely...maybe something like "identinc.tmp"
would be better.
Anyway, another potential addition for the macros to be included with
POV 3.5, don't you think? It's going in my personal collection...
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
