 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povray org> wrote:
: Perl doesn't have what you'd call "iterators" per se. To iterate over an
: associative array in Perl, you do:
: for $index ( keys( %assoc_array ) ) {
: do_stuff_with( $assoc_array{$index} )
: }
I think this is slower than using iterators.
Referencing to an object with an iterator is a constant-time operation
and incrementing the iterator is an amortized constant-time operation.
Thus, going through the whole array is an O(n)-time operation.
Indexing one element with a key is an O(log n)-time operation (at least
with the STL map), so going through all elements by indexing each one of
them would be a O(n*log n)-time operation.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 29 Feb 2000 07:38:29 -0500, Nieminen Juha wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: Perl doesn't have what you'd call "iterators" per se. To iterate over an
>: associative array in Perl, you do:
>
>: for $index ( keys( %assoc_array ) ) {
>: do_stuff_with( $assoc_array{$index} )
>: }
>
> I think this is slower than using iterators.
Yes, it is. Unfortunately, it's the only way in Perl. TMTOWTDI, indeed.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 29 Feb 2000 07:38:29 -0500, Nieminen Juha wrote:
> Referencing to an object with an iterator is a constant-time operation
>and incrementing the iterator is an amortized constant-time operation.
Actually, I have an associative array (of sorts) that I've written here
that has an O(1) increment, not amortized. It's a threaded 2-3 tree.
Indexing is still, of course, O(log n), as are insertion and deletion.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov wrote:
>
> With time I've compiled a list of features I would be happy to see in
> POV-Ray. I think it wouldn't hurt if I posted it here.
Here is my little wish list - tee hee !
1.) displacement mapping
2.) export capabilities pov2???
3.) programmable shaders ala renderman
4.) the ability to internaly tesselate POV-Ray primatives
5.) subdivision surfaces
6.) extended capabilities for the warp turbulence feature
7.) nurbs
and...
and...
and...
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
: Actually, I have an associative array (of sorts) that I've written here
: that has an O(1) increment, not amortized. It's a threaded 2-3 tree.
: Indexing is still, of course, O(log n), as are insertion and deletion.
How can the increment of the iterator be O(1) non-amortized with a tree?
Unless you have next-pointers in each node making the container also a
linked list... (well that _is_ a solution but it takes a little bit more
memory).
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
: TMTOWTDI, indeed.
Sorry?
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 29 Feb 2000 05:06:01 -0800, Ken wrote:
>
>
>Peter Popov wrote:
>>
>> With time I've compiled a list of features I would be happy to see in
>> POV-Ray. I think it wouldn't hurt if I posted it here.
>
>Here is my little wish list - tee hee !
>
>1.) displacement mapping
>
>2.) export capabilities pov2???
>
>3.) programmable shaders ala renderman
>
>4.) the ability to internaly tesselate POV-Ray primatives
>
>5.) subdivision surfaces
>
>6.) extended capabilities for the warp turbulence feature
>
>7.) nurbs
Most of these are perfectly reasonable things to wish for. (1) and (2) are of
course rather dependent on (4), and of course that ability would be limited to
the primitives that can be tesselated.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 29 Feb 2000 08:15:51 -0500, Nieminen Juha wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: Actually, I have an associative array (of sorts) that I've written here
>: that has an O(1) increment, not amortized. It's a threaded 2-3 tree.
>: Indexing is still, of course, O(log n), as are insertion and deletion.
>
> How can the increment of the iterator be O(1) non-amortized with a tree?
>Unless you have next-pointers in each node making the container also a
>linked list... (well that _is_ a solution but it takes a little bit more
>memory).
That's the "threaded" part. It's actually a doubly-linked list. Memory is
cheaper than processor time in this application.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 29 Feb 2000 08:16:15 -0500, Nieminen Juha wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: TMTOWTDI, indeed.
>
> Sorry?
The Perl motto: There's More Than One Way To Do It. Not true in this case.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wouldn't displacement mapping require LOTS of triangles? And I mean _LOTS_.
Just think that you want to apply a 640x480 displacement map to each side
of a cube. If I have understood correctly, you will need at least 2 triangles
per map pixel (like in a heightfield), which would make a total of at least
640x480x2x8 = 4915200 triangles.
Since this kind of triangle mesh can not (AFAIK) be optimized like a
height field can be, it would take rather lot of memory.
Perhaps I'm just exaggerating.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
