POV-Ray : Newsgroups : povray.general : POV Parsing Server Time
9 Aug 2024 17:17:50 EDT (-0400)
  POV Parsing (Message 41 to 50 of 52)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 2 Messages >>>
From: Peter J  Holzer
Subject: Re: POV Parsing
Date: 3 Sep 2000 10:00:39
Message: <slrn8r4l2a.g94.hjp-usenet@teal.h.hjp.at>
On Thu, 31 Aug 2000 23:20:44 -0500, Chris Huff wrote:
>In article <39AF1FCD.4B0CE825@faricy.net>, David Fontaine 
><dav### [at] faricynet> wrote:
>
>> And where's the stinkin' #for? :)
>
>Now, *this* I have no idea how to implement, though I would use a 
>C/Java-like syntax instead of the BASIC-like syntax.

Since a C for loop:

for (A; B; C) {
    D;
}

is just an abbreviation for

A;
while(B) {
    D;
    C;
}

(well, if you ignore continue, anyway)
and we already have a while loop in Povray, that shouldn't be too hard.

>The modulo operator would be just as easy...but the best operator
>to use for it would be %, and that is already used in MegaPOV as a
>shortcut for #local.

Oh. I didn't notice that. Cool! I always thought that redeclaring a
variable at every assignment is somewhat inelegant.

	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

From: Chris Huff
Subject: Re: POV Parsing
Date: 3 Sep 2000 11:04:38
Message: <chrishuff-5DABD7.10061703092000@news.povray.org>
In article <slr### [at] tealhhjpat>, 
hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:

> Since a C for loop:
...
> is just an abbreviation for
...
> (well, if you ignore continue, anyway)
> and we already have a while loop in Povray, that shouldn't be too hard.

It might not be easy to internally convert a for loop to a while loop, 
it may require a completely separate loop.


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

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

From: Warp
Subject: Re: POV Parsing
Date: 3 Sep 2000 12:01:19
Message: <39b275ce@news.povray.org>
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

From: Warp
Subject: Re: POV Parsing
Date: 3 Sep 2000 12:03:48
Message: <39b27663@news.povray.org>
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

From: Chris Huff
Subject: Re: POV Parsing
Date: 3 Sep 2000 17:25:54
Message: <chrishuff-A674EC.16273303092000@news.povray.org>
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

From: Peter J  Holzer
Subject: Re: POV Parsing
Date: 3 Sep 2000 18:01:37
Message: <slrn8r5cot.hvs.hjp-usenet@teal.h.hjp.at>
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

From: Peter J  Holzer
Subject: Re: POV Parsing
Date: 3 Sep 2000 18:01:41
Message: <slrn8r5d42.hvs.hjp-usenet@teal.h.hjp.at>
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

From: Warp
Subject: Re: POV Parsing
Date: 4 Sep 2000 05:23:20
Message: <39b36a08@news.povray.org>
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

From: Ron Parker
Subject: Re: POV Parsing
Date: 5 Sep 2000 12:09:25
Message: <slrn8ra7fg.14s.ron.parker@fwi.com>
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

From: David Fontaine
Subject: Re: POV Parsing
Date: 5 Sep 2000 23:43:50
Message: <39B5BC96.11133595@faricy.net>
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

<<< Previous 10 Messages Goto Latest 10 Messages Next 2 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.