Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
:>  And if integers are ever implemented in povray, there should be a very long
:>integer type (at least 64 bits) anyways :)

: In which case the space advantage of integers would vanish. 

  I said "there should be *A* very long integer type".
  I did NOT say "the integer type of povray should be very long".

  The first statement doesn't imply there could not be a shorter integer
as well.

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

David Fontaine <dav### [at] faricynet> wrote:
: And where's the stinkin' #for? :)

  I don't miss a #for in povray. It would be just a little shortcut, and
that's it.
  What I really miss is a #do...#while (or for practical resons better
yet #do...#until).
  You can achieve the same effect with a regular #while, but not without
repeating code.

-- 
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 <39b27663@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   I don't miss a #for in povray. It would be just a little shortcut, and
> that's it.

Well, it could make some things more readable...but I agree that it 
isn't very necessary.


>   What I really miss is a #do...#while (or for practical resons better
> yet #do...#until).
>   You can achieve the same effect with a regular #while, but not without
> repeating code.

Yes, I see why having these implemented natively would be better than 
"emulating" them with a #while loop...but I think I have only used one 
do...while loop in C. They aren't often used...but if #for loops are 
implemented, I think either #do...while() or #do...until() loops should 
be. Probably #do...#until, since using #while could confuse the parser.

-- 
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 3 Sep 2000 12:01:19 -0400, Warp wrote:
>Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
>:>  And if integers are ever implemented in povray, there should be a very long
>:>integer type (at least 64 bits) anyways :)
>
>: In which case the space advantage of integers would vanish. 
>
>  I said "there should be *A* very long integer type".
>  I did NOT say "the integer type of povray should be very long".
>
>  The first statement doesn't imply there could not be a shorter integer
>as well.

Sorry, I misread that. But I disagree. Types of different size are fine
for low-level languages like C (<flamebait>or Java</flamebait>), but I
don't think they are very useful for Povray. 

Basically, I think using double for everything (like it is now) is the
best solution: It has a reasonable range, accuracy and speed as an FP
number. It can be used as a perfectly accurate 54-bit integer number. 
There is only one type, so the user doesn't have to think about whether
automatic type conversion will do the right thing or whether he must
insert casts. 

Integers smaller than a double have an advantage (memory- and speedwise)
mainly if there are a lot of them. Maybe adding an element type (single
(32-bit float), int_32, int_16, int_8, int_1 (aka boolean)) to arrays
would make sense. Same might be true for some builtin types (e.g.,
meshes). Are height fields stored internally as mesh of
3d-double-precision vectors or as a 2D-array of integer numbers?

But I'm not too sure of that. Does anybody here have scenes with really
large arrays, where the parsing overhead is *not* the bottleneck?

For some applications a double FP isn't precise enough. int_64 and long
double (80 bit on Intel, up to 128 bit on some other architectures) have
good HW support, but also finite precision and range. An arbitrary
precision type would be nice, but I think it would be really bad on
performance, since it would probably have to be used everywhere to avoid
nasty surprises.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

On Sun, 03 Sep 2000 10:06:17 -0500, Chris Huff wrote:
>In article <slr### [at] tealhhjpat>, 
>hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:
>> Oh. I didn't notice that. Cool! I always thought that redeclaring a
>> variable at every assignment is somewhat inelegant.
>
>That shortcut still redeclares the variable, it is just a typing 
>shortcut,

Yes. But as far as "elegance" goes, I am more concerned about my POV
Scripts than what POV internally does with them.

    % a = a + 1

really looks much more like an ordinary assignment than

    #local a = a + 1


>but I agree that it is inelegant to redeclare a variable just 
>to assign to it. That is the exact reason I added a #set keyword in my 
>patch, so you can use a separate keyword for modifying variables.

Saw it just after my reply.  #set somewhat reminds me of BASIC or some
shells, but that's ok.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
: There is only one type, so the user doesn't have to think about whether
: automatic type conversion will do the right thing or whether he must
: insert casts. 

  Not exactly.
  Yes, the user defined numbers can only be doubles, but povray handles these
numbers as integers in some places. When you give povray a non-integer value
in one of these places, povray just converts it to an integer.
  This might have undesired results sometimes. For example, if you for one
reason or another give it a value of, eg. 1.5 povray will round it (I don't
know if it just rounds it to 1 or to the nearest integer value; if the latter,
the result is even worse since it may depend on the system whether it rounds
it to 1 or to 2). If you want to be absolutely sure that povray will get
the right value, you'll have to "cast" the value :)

: For some applications a double FP isn't precise enough. int_64 and long
: double (80 bit on Intel, up to 128 bit on some other architectures) have
: good HW support, but also finite precision and range.

  It's not possible to define a hardware-supported int_64 in ANSI C if the
default value of int is 32 bits long. In some 64-bit systems the long int
type is 64 bits, but not in any 32-bit system (at least not any I know).
  Some systems (such as linux and solaris) support the type long long, which
makes a 64-bit variable. However, this type is not part of the ANSI C.

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

On 3 Sep 2000 12:03:48 -0400, Warp wrote:
>David Fontaine <dav### [at] faricynet> wrote:
>: And where's the stinkin' #for? :)
>
>  I don't miss a #for in povray. It would be just a little shortcut, and
>that's it.
>  What I really miss is a #do...#while (or for practical resons better
>yet #do...#until).
>  You can achieve the same effect with a regular #while, but not without
>repeating code.

#declare FirstTime = 1;
#while ( FirstTime | (<condition>))
  <code>
  #declare FirstTime = 0;
#end


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

Post a reply to this message

Ron Parker wrote:

> >  You can achieve the same effect with a regular #while, but not without
> >repeating code.
>
> #declare FirstTime = 1;
> #while ( FirstTime | (<condition>))
>   <code>
>   #declare FirstTime = 0;
> #end

Either way you need an extra comparison...

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

David Fontaine <dav### [at] faricynet> wrote:
: Either way you need an extra comparison...

  The solution is much better than repeating code (I didn't think about that
solution), but it still looks like a kludge :)

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

On 4 Sep 2000 05:23:20 -0400, Warp wrote:
>Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
>: There is only one type, so the user doesn't have to think about whether
>: automatic type conversion will do the right thing or whether he must
>: insert casts. 
>
>  Not exactly.
>  Yes, the user defined numbers can only be doubles, but povray handles these
>numbers as integers in some places. When you give povray a non-integer value
>in one of these places, povray just converts it to an integer.

Yes. But that that behaviour is fixed and hopefully documented. The user
should be aware of the fact that the number will be rounded to an
integer, and he only needs to decide whether the default rounding
operation is the one he wants or whether he needs to round himself.

A plethora of numeric variable types, like C has (8 integers and 3 float
types) however, forces the user to decide on every variable what type it
should have. He has to think on every operation what happens when
operands are of different types, whether the result might overflow or
lose precision, etc. This may not be a problem for you and me, because
we are programmers (but accidents happen even to us, as you demonstrated
earlier in this thread), but I think the average povray user would be
overwhelmed by it. It also makes povray a lot more complicated
internally, and it gains very little. 

>: For some applications a double FP isn't precise enough. int_64 and long
>: double (80 bit on Intel, up to 128 bit on some other architectures) have
>: good HW support, but also finite precision and range.
>
>  It's not possible to define a hardware-supported int_64 in ANSI C if the
>default value of int is 32 bits long.

It is now (C99 added the "long long" type). Many compilers already
support it, although it will take several years before you can rely on
it.

However, this wasn't what I meant. 64 bit arithmetic can be implemented
on every architecture with just a few instructions for every operation.
Even if the compiler doesn't directly support them, 64 bit operations
can be easily and and reasonably efficiently implemented as functions
written in assembler or C.

Numbers with infinite precision on the other hand always need loops and
- even worse - you can't bound them. (1E1000+1)*(1E1000+1) gives a
result with a million digits and sqrt(2) one with an infinite number of
digits (so you would have to stop somewhere arbitrarily). Slow and
difficult to use, and only rarely useful.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message