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

Aw, what we have now is fine!

I, too, get bit (heh) by things like this. At least you're not doing:

loop:
inc      ax,bitcount
cmp    cx,ax
jne      next_color
inc      cx,01d
jmp     loop

Well, it's been awhile. :)

GrimDude
vos### [at] arkansasnet

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:

There's always a need for these things. It will allow POVers to be more
creative, and at least, it will help people like me, who think in _for_ and
not in _while_.

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

I don't understand what you mean about this being easier.

>   And of course some operators would be handy:
>
> #declare Index+=1;
> #declare PosX*=1.5;
> #declare PosY/=2;
> #declare PosZ-=10;

I'm glad you agree. ++ and -- would also come in handy (i.e. less typing).

Post a reply to this message

Phil Clute <pcl### [at] tiacnet> wrote:
: I've always been curious as to why the pov-team chose #declare
: over #define.

  Because #declared identifiers in povray are not macros, while #defined
identifiers in C are macros.
  The #macros in 3.1 work like #defines in C, but naming them as #define
instead of #macro would have been very confusing.

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

J. Grimbert <jgr### [at] atos-groupcom> wrote:
: init
: #while 
: #if (not first time) 
: calcB
: #end
: calcA
: #end

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

  Still you have to do extra typing, and the code gets slower since there's
one "unnecessary" #if statement to be computed.

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

And of course the condition of the while-loop may be dependant of
the calculations.

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

On Thu, 06 May 1999 23:57:54 +0200, Ralf Muschall wrote:
>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).

Don't forget || and &&.

Post a reply to this message

Nieminen Mika wrote:
>Because #declared identifiers in povray are not macros, while #defined
>identifiers in C are macros.

I have to admit my experience with C programming is extremely
limited. I guess I am confused as to what a "macro" is then.
I assumed that constants were macros. What makes #define a 
macro and #declare not a macro? They seem to serve the same
purpose.

(There was actually a small discussion in povray.general entitled
"Macro tutorial" started by Andrew Cocker. I mentioned there that
#define and #declare are the same thing. If this is incorrect I
may have mislead Andrew and others.)

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

Post a reply to this message

This reminds me, there was a pure ASM rewite of POV 2.2 i think, crashed
everytime for me tho!!

Rick

GrimDude <vos### [at] arkansasnet> wrote in message
news:37321713.0@news.povray.org...
> Aw, what we have now is fine!
>
> I, too, get bit (heh) by things like this. At least you're not doing:
>
> loop:
> inc      ax,bitcount
> cmp    cx,ax
> jne      next_color
> inc      cx,01d
> jmp     loop
>
> Well, it's been awhile. :)
>
> GrimDude
> vos### [at] arkansasnet
>
>

Post a reply to this message

On Fri, 07 May 1999 13:46:56 -0400, Phil Clute <pcl### [at] tiacnet> wrote:
>I have to admit my experience with C programming is extremely
>limited. I guess I am confused as to what a "macro" is then.
>I assumed that constants were macros. What makes #define a 
>macro and #declare not a macro? They seem to serve the same
>purpose.

C's #define lets you do
  #define FOO(x,y,z) (x*32+y*z)

which you can then use like a function:

  printf( "%d", FOO(1,2,3) );

whereas #declare creates an actual instance of the specified
object and puts it in a "variable."  #declare is a lot like the
BASIC "Let" statement.

#macro is pretty much the same as #define, but with a little
different syntax.

Post a reply to this message

Aah I see! Thanks for your help.

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

Post a reply to this message

Phil Clute <pcl### [at] tiacnet> wrote:
: I have to admit my experience with C programming is extremely
: limited. I guess I am confused as to what a "macro" is then.
: I assumed that constants were macros. What makes #define a 
: macro and #declare not a macro? They seem to serve the same
: purpose.

  A macro identifier is completely replaced by its value. For example:

#define PrintStatus printf("This is the status\n")

  Now you can type something like:

void Function(void)
{ PrintStatus;
}

  When parsing, the compiler substitutes the macro, so it converts it to:

void Function(void)
{ printf("This is the status\n");
}

  Povray #declared identifiers do _not_ work this way. For example, you can't
make this:

#declare MyTexture=texture { pigment { rgb 1 } }

sphere { 0,1 MyTexture }

  Povray does _not_ substitute the identifier "MyTexture" with its value, ie.
the result is _not_ this:

sphere { 0,1 texture { pigment { rgb 1 } } }

  Instead, povray will issue an error:

error: No matching } in sphere, texture identifier found instead.

  However, #macros work in povray exactly like #defines in C. You can make
this:

#macro MyTexture() texture { pigment { rgb 1 } } #end

sphere { 0,1 MyTexture() }

and it will work.
  You can make this same thing in C:

#define MyTexture() texture(whatever)

and when you type "MyTexture()" it will be substituted with
"texture(whatever)" (of course the parenthesis are obsolete here). You can
also give arguments the the #defined macro, just like to the povray
#macro.

  A better naming for the commands would be, for example, #let instead
of #declare and #define instead of #macro (although #macro is ok). Of
course it's too late now.

-- 
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 Mika wrote:
>Instead, povray will issue an error:

>error: No matching } in sphere, texture identifier found instead.

Oh so that's why! I've tried to do exactly that, and that's the
error message I got.

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

Post a reply to this message

I was just looking through textures.inc and I found this:

#declare Shadow_Clouds =
texture {                          // The blue sky background for the
clouds 
    pigment { rgb <0.196078, 0.6, 0.8> }
    finish { ambient 0.7 diffuse 0 }
}
texture {                          // The upper part of the clouds
    pigment { FBM_Clouds }
    finish { ambient 1.0 diffuse 0 }
}
texture {                          // The darker underside of the clouds
    pigment { FBM_Clouds  translate -0.15*y }
    finish { ambient 0.6 diffuse 0 }
}


This gives the error message you said it would, so I wonder why it's in
there?

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

Post a reply to this message

You have to use texture identifiers this way:

sphere { 0,1 texture { MyTexture } }

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