Hi. I don't know if I'm in the right group, but I was just wondering if
anyone sees the future possibility of adding for() to POV, or if this
can even be done. It certainly would be very cool.

For example, instead of writing

#declare value=0;
#while (value<whatever)
 blah, blah, blah...
 #declare value=value+something;
#end

We could write

#for (value=0;value<whatever;value=value+something)
blah, blah, blah...
#end

Or even

#for (value=0;value<whatever;value+=something)
{blah, blah, blah...}

And another thing that would be too nice to have, as in the above
example, would be ...oh, I forgot the name... but anyway, it would allow
things like this:

Instead of

#declare i=i+1;

we could have

#declare i++;

and instead of

#declare i=i*e;

we could have

#declare i*=e;

I don't know how this could be added but it would be most appreciated.

--
Anthony L. Bennett
http://welcome.to/TonyB

Who was the first President of the United States of America?

Post a reply to this message

>...oh, I forgot the name... but anyway, it would allow
>things like this:
>
>Instead of
>
>#declare i=i+1;
>
>we could have
>
>#declare i++;

The ++ is called the increment operator.
The -- is called the decrement operator.

I don't see a burning need for these since they just add or subtract
one from the variable.
There may be a use for *= and other compound operators, but still the
long version of what these accomplish gets the job done.

Regarding the for() loop, I usually just use this as an incrementing
loop anyhow which can be accomplished with the while loop by adding
an incrementer at the end. ie:

(I pulled this out of one of my objects)

#declare GX = 0;
#declare GR = 0;
#while (GX < 20)
union{
        cylinder {<0,.065,0>,
                  <0,0.03,0>,
                  0.01475
        }
        superellipsoid{ <.1,.1>
                scale<.0007,.0175,.017>
                rotate y*GR
                translate<0,.0475,0>
}
        texture{Chrome}
}
#declare GX = GX + 1;
#declare GR = GR + 18;
#end  




-- 
...coffee?...yes please! extra sugar,extra cream...Thank you.

Post a reply to this message

> The ++ is called the increment operator.
> The -- is called the decrement operator.
>
> I don't see a burning need for these since they just add or subtract
> one from the variable.

I see them as helpful in speeding up the parsing. Less text = less
parsing (no?)

> There may be a use for *= and other compound operators, but still the
> long version of what these accomplish gets the job done.

But it looks ugly.

> Regarding the for() loop, I usually just use this as an incrementing
> loop anyhow which can be accomplished with the while loop by adding
> an incrementer at the end. ie:

Your code was interesting, I've never done that. But still, the for would
look neater, and is easier to write, at least for me.

Post a reply to this message

I think there's no so much need for a #for statemen, but what I want to
see in a future version of povray is a do-while statement, like this:

#do
  (something that will be made at least 1 time)
  (make some calculations)
#while(condition)

  It's tedious to type:

(make some calculations)
#while(condition)
  (something that will be made at least 1 time)
  (make the same calculations here)
#end

  And of course some operators would be handy:

#declare Index+=1;
#declare PosX*=1.5;
#declare PosY/=2;
#declare PosZ-=10;

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

Of course the syntax cannot be

#do
  ...
#while(...)

since you may want to put a regular #while loop inside the do-while loop.
Perhaps something like:

#do
  ...
#dowhile(...)

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

TonyB wrote:
> 
> > The ++ is called the increment operator.
> > The -- is called the decrement operator.
> >
> > I don't see a burning need for these since they just add or subtract
> > one from the variable.
> 
> I see them as helpful in speeding up the parsing. Less text = less
> parsing (no?)

Not really, for instance the famous tree macro is short, and it take
ages to parse.
Parsing is not only reading the scene file, it's also creating the
memory representation of the scene.
If I were to agree with less text == less parsing, you have to remove
all
the comments, and all the blank lines (Wait, that's an idea, let's
remove
the carriage return/line feed : the one-line pov-scene !)

> 
> > There may be a use for *= and other compound operators, but still the
> > long version of what these accomplish gets the job done.
> 
> But it looks ugly.

Exactly what I thought on the first post: you are asking for cosmetic
changes.

<Extrem on>
 I would like the removal of sqrt(), instead you have to write 
   2^(1/2)   (or 2**0.5 ?)

 It's more like the formula in my math books. (fortran book ?)
<Extrem off>

> 
> > Regarding the for() loop, I usually just use this as an incrementing
> > loop anyhow which can be accomplished with the while loop by adding
> > an incrementer at the end. ie:
> 
> Your code was interesting, I've never done that. But still, the for would
> look neater, and is easier to write, at least for me.

It's just a cosmetic change.
Now, you can try to define a for() #macro for your personal usage.
something like:
#macro for(start,cond,inc,block)
start
#while(cond)
block
inc
#end
#end


Nota: I'm not sure this macro would ever work, or is even possible
Maybe it could be the real winner of the useless macro competition
(probably a higher complexity would help to gain some points...)

Post a reply to this message

Nieminen Mika wrote:
> 
>   Of course the syntax cannot be
> 
> #do
>   ...
> #while(...)
> 
> since you may want to put a regular #while loop inside the do-while loop.
> Perhaps something like:
> 
> #do
>   ...
> #dowhile(...)
> 

if you have something like

init
calcA
#while
calcB
calcA
#end

you can fold it like this:

init
#while 
#if (not first time) 
calcB
#end
calcA
#end

I do not see the need for #do/#dowhile

Post a reply to this message

>If I were to agree with less text == less parsing, you have to remove
>all
>the comments, and all the blank lines (Wait, that's an idea, let's
>remove
>the carriage return/line feed : the one-line pov-scene !)

Ken would be happy!
:-)

>Now, you can try to define a for() #macro for your personal usage.
>something like:
>#macro for(start,cond,inc,block)
>start
>#while(cond)
>block
>inc
>#end
>#end

This is interesting, I hadn't considered something like this. Of
course I think this just adds a step.

Phil

-- 
...coffee?...yes please! extra sugar,extra cream...Thank you.

Post a reply to this message

I could have sworn POV had a #do-while directive. Obviously
I haven't tried to use it. Hmm? I must be crossing up my code
a bit...
I've always been curious as to why the pov-team chose #declare
over #define. I mean it doesn't make a difference really, I just
thought since POV is written in C it would be more comfortable
even for them.

Phil
-- 
...coffee?...yes please! extra sugar,extra cream...Thank you.

Post a reply to this message

Nieminen Mika wrote:

> #declare Index+=1;
> #declare PosX*=1.5;
> #declare PosY/=2;
> #declare PosZ-=10;

Agreed, but I think ++ and -- are not necessary.
OTOH, I'd like to see the equality operator renamed from
= to == (I always get bitten by writing something like
#if(foo==bar)
and then having to correct it).

Another thing I'd like to see: The possibility of passing
the name of a macro as an argument to another macro.

This would allow one to e.g. create a triangle mesh for a
given function of two variables, where the name of the function
is given as the argument. Currently, the loop that makes
the mesh needs the name of the function hardcoded.

Ralf

Post a reply to this message