In article <O1+4OE0dCXqQafXKqfXLL1aqGEUo@4ax.com> , Peter Popov 
<pet### [at] usanet>  wrote:

>>Therefore, I would probably just add integer types (maybe char, but most
>>likely not).  And I'm pretty sure I'd totally avoid any unsigned types.
>
> These should suffice, really. And at first I didn't realize the
> problems a person with no programming background might run into when
> working with unsigned types. You're right, leave'em out.

When using only integer types, I think the whole thing can be hidden from
the user and POV-Ray automatically determines the type (floating-point or
integer). This allows for hiding the type from the user, and in loop, etc
even new users would get the benefit without ever having to deal with
variable types.

For a #declare (of a so far undefined variable) just check if the value is
an integer and then store it as such.  I.e. "#declare MyFoo = 1" is an
integer, but neither would be "#declare MyFoo = 1.0" or "#declare MyFoo =
1.8542".  Now, whenever a floating-point result is to be assigned to this
integer, promote "MyFoo" to floating-point (for backward compatibility!).

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.

During evaluation this should still be possible with (nearly?) no runtime
penalty.


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany

Post a reply to this message

Margus Ramst wrote in message <38B711FF.1E959678@peak.edu.ee>...
>Some wishes arising from my current projects:
>
>Dynamic arrays. In POV, arrays are the best way to acces large datasets,
but the
>size of the array has to be declared before any data is inserted. The thing
is,
>you often don't know how much data will be generated. And manually resising
a
>100,000 element array is inefficient, to say the least.


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.

Mark

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote:
: I have not either. Perhaps you have missed my main point, and it is
: textures. Imagine you have this:

: intersection
: { union
:   { sphere { -x, 1 pigment { Red } }
:     sphere { x, 1 pigment { Blue } }
:   }
:   box { <-3,0,-2>, <3,2,2> }
: }

  But that's not possible. Suppose that the radiuses of the spheres are
a bit larger (so that the spheres overlap). What's the color of the
overlapping part?
  On the other hand, even in your example: How can povray know which one
is the right sphere to get the color from? It only has knowledge of the
intersection of the ray with the box. It would have to somehow decide which
sphere is the right one. I don't know how povray works in this matter, but
it might be difficult to see which sphere is the right one. It's more difficult
if the spheres overlap or one sphere is completely inside the other.
  And besides, bounding is not intended for that kind of functionality.
Boundind is intended only for speeding up the rendering.

-- 
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

In article <38b877a0@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> 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] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

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

Ron Parker <ron### [at] povrayorg> 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

Nieminen Juha <war### [at] sarakerttunencstutfi> writes:

> Ron Parker <ron### [at] povrayorg> 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

On 28 Feb 2000 03:02:18 -0500, Nieminen Juha wrote:
>Ron Parker <ron### [at] povrayorg> 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

In article <qqmd7phhh09.fsf_-_@schlatt.fmi.uni-konstanz.de> , Thomas 
Willhalm <tho### [at] willhalmde>  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

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