![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <38b877a0@news.povray.org>, "Thorsten Froehlich"
<tho### [at] trf de> wrote:
> User control can still be available, i.e. introducing two functions
> to eliminate the common operations that should create floating-point
> results: For division offer a Pascal style "div" function (or even
> operator), and to still allow mixing integer and floating-point math
> without forcing promotion to floating-point for the result, an "int"
> function which can be placed around any section of a function, for
> example "#declare MyFoo = 1; #declare MyFoo = 8084 div 7 + MyFoo -
> (int(sin(45) * 10) * MyFoo;" would still give in an integer result.
Those functions already exist in POV. :-)
Section 4.1.3.6 Float Functions
...
div(A,B) Integer division. The integer part of (A/B) .
int(A) Integer part of A . Returns the truncated integer part of A .
Rounds towards zero.
Now all that has to be done is add code for deciding whether to use
integer or floating point...btw, I think the precision should be
specified instead of being left to the implementation of "int", it would
make the language more consistant across platforms and compilers. Or
maybe just have it decide depending on the size of the number-but I
think the overhead of that(some conditionals, comparisons, and type
conversions?) would outweigh any possible benefits.
--
Chris Huff
e-mail: chr### [at] yahoo com
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Fri, 25 Feb 2000 19:30:39 -0500, Chris Huff wrote:
Maybe a dynamic_array
>which behaves like a C++ STL vector.(If you are not familiar with this,
>it is an object type, a container class which is basically a dynamic
>one-dimensional array. It includes functions for appending, inserting,
>etc)
I want an array that acts like a C++ STL map, too.
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Ron Parker <ron### [at] povray org> wrote:
: I want an array that acts like a C++ STL map, too.
I think it's technically called "associative array".
And yes, povray versions of the STL vectors and maps would be very handy.
With maps there may be need for iterators.
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nieminen Juha <war### [at] sarakerttunen cs tut fi> writes:
> Ron Parker <ron### [at] povray org> wrote:
> : I want an array that acts like a C++ STL map, too.
>
> I think it's technically called "associative array".
>
> And yes, povray versions of the STL vectors and maps would be very handy.
> With maps there may be need for iterators.
It appears to me, that the time for the complete rewrite in C++
(i.e. POV-Ray 4.0) has come. Does somebody know, whether the
POV-Team has already started? (I'm looking forward to discuss
design and implementation issues.)
Thomas
--
http://thomas.willhalm.de/ (includes pgp key)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 28 Feb 2000 03:02:18 -0500, Nieminen Juha wrote:
>Ron Parker <ron### [at] povray org> wrote:
>: I want an array that acts like a C++ STL map, too.
>
> I think it's technically called "associative array".
Actually, I knew that, since I actually use them in Perl rather than
in C++. I was just trying for the parallelism with the original comment. :)
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} )
}
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <qqmd7phhh09.fsf_-_@schlatt.fmi.uni-konstanz.de> , Thomas
Willhalm <tho### [at] willhalm de> wrote:
> It appears to me, that the time for the complete rewrite in C++
> (i.e. POV-Ray 4.0) has come. Does somebody know, whether the
> POV-Team has already started? (I'm looking forward to discuss
> design and implementation issues.)
povray.announce.frequently-asked-questions: "POV-Ray plans for v3.1 and
beyond..."
Thorsten
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mark Wagner wrote:
>
> I've been working on "malloc", "realloc", and "free" macros. However, the
> current version of "realloc" is very slow, since it works by creating a new
> array and copying the old one into it.
>
Yes, I've done that too, out of necessity.
It's slow, plus you want to resize it as seldom as possible so you must waste
memory on unnecessarily large arrays.
Margus
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 29 Feb 2000 07:38:29 -0500, Nieminen Juha wrote:
>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.
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |