If there is an expression

        ((exp1)&(exp2))

POV-Ray will evaluate exp2 even if exp1 is already false and therefore the 
whole expression cannot become true anymore. Is there any good reason for 
that? I would really wish that it would not evaulate the rest of the 
expression as soon as it is evident that its value is not changed by it. 
This would make programming quite a bit easier.

Consider following example:

#declare a=array[n]

... (put values into array)

#while((i<n)&(a[i]=0))
        #declare i=i+1
#end

If the whole array is 0 then POV-Ray will output an error as i becomes n 
and it tries to access a[n]. I have not found a nice workaround for this 
problem so I ended up making the array one cell larger... but like that it 
is unused memory. I have also come to many other situations where it would 
be easier to program when the parsing of & and | would be different.

Maybe it is just me as I am used to this from other programming languages I 
use. Is anybody else finding this annoying? I know that changing this can 
cause incompatibilities with the current behaviour when people relied that 
always the whole expression is evaluated.

- Micha

Post a reply to this message

> Maybe it is just me as I am used to this from other programming languages I
> use. Is anybody else finding this annoying? I know that changing this can

It's a language thing. Some languages use short-circuit evaluation, and some
don't (e.g. certainly standard pascal, and probably some versions of basic at
the very least). So a pascal user might say the same thing as you if we changed
it to use short-circuit evals.

Apart from that above I'm not commenting on whether or not it will be changed,
I'm simply pointing out that it's not as illogical as you seem to think.

-- Chris

Post a reply to this message

In article <gk7### [at] michariser> , Micha Riser <mri### [at] gmxnet>  
wrote:

> #while((i<n)&(a[i]=0))
>         #declare i=i+1
> #end
>
> Maybe it is just me as I am used to this from other programming languages I
> use. Is anybody else finding this annoying?

The above code is illegal in C and C++, without question the most commonly
used programming language around today.  Many other well-designed languages
do not promise you that they do the minimum either (with a few very specific
exceptions, but that is not the point).  The example you provide is simply
extremely bad programming style and it is neither a bug nor a limitation on
part of POV-Ray that the above does not work.

    Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
:> #while((i<n)&(a[i]=0))
:>         #declare i=i+1
:> #end

: The above code is illegal in C and C++

  How so? I don't see anything wrong there (of course if we imagine that we
convert it to equivalent C code).

  The C standard *guarantees* that the expression at the right of && is not
evaluated if the expression at the left is false. (The & operator in POV-Ray
is equivalent to the && operator in C, and it should not be confused with
the & operator in C, which does a completely different thing.)
  The example doesn't either modify the same value in the same sentence or
anything similar. It looks completely ok to me.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Chris Cason wrote:

> 
> It's a language thing. Some languages use short-circuit evaluation, and
> some don't (e.g. certainly standard pascal, and probably some versions of
> basic at the very least). So a pascal user might say the same thing as you
> if we changed it to use short-circuit evals.

Yes, I know that it varies from language to language.. but AFAIK modern 
languages tend to short-circuit evaluation - at least Oberon uses it ;)

> 
> Apart from that above I'm not commenting on whether or not it will be
> changed, I'm simply pointing out that it's not as illogical as you seem to
> think.

I never claimed that short-circuit evaluation is more logical - I think at 
first sight the current implemenation is more logical. But all the same I 
believe that there would be an advantage of changing it.

- Micha

Post a reply to this message

Micha Riser <mri### [at] gmxnet> wrote:
: Yes, I know that it varies from language to language.. but AFAIK modern 
: languages tend to short-circuit evaluation - at least Oberon uses it ;)

  I wouldn't call C a "modern language". C was introduced in the 60's or
something like that... ;)

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Warp wrote:

> Thorsten Froehlich <tho### [at] trfde> wrote:
> :> #while((i<n)&(a[i]=0))
> :>         #declare i=i+1
> :> #end
> 
> : The above code is illegal in C and C++
> 
>   How so? I don't see anything wrong there (of course if we imagine that
>   we
> convert it to equivalent C code).

Doing that resulted in 

int a[1000];
int main() {

        int i;
        for(i=0;i<1000;i++) {a[i]=0;}
        i=0;    
        while( (i<1000)&&(a[i]==0) )
                {
                printf("%d\n",i);
                i++;
                }

}

works fine with gcc.

> 
>   The C standard *guarantees* that the expression at the right of && is
>   not
> evaluated if the expression at the left is false. (The & operator in
> POV-Ray is equivalent to the && operator in C, and it should not be
> confused with the & operator in C, which does a completely different
> thing.)
>   The example doesn't either modify the same value in the same sentence or
> anything similar. It looks completely ok to me.
> 

Thanks Warp, Thorsten's posting made me unsure about C.

Post a reply to this message

Warp wrote:

>   I wouldn't call C a "modern language". C was introduced in the 60's or
> something like that... ;)
> 
According to 'Free On-line Dictionary' C was designed ~1972.

I didn't say that old languages would not use it. I rather meant that 
"really old" ones like basic (~1960) and pascal (~1967) would not use 
short-circuit evaluation but its succesor (like e.g. Oberon in the case of 
Pascal) are using it.

- Micha

Post a reply to this message

Thorsten Froehlich wrote:

> exceptions, but that is not the point).  The example you provide is simply
> extremely bad programming style and it is neither a bug nor a limitation
> on part of POV-Ray that the above does not work.

If it is that bad programming style, how to do it the good way?? More 
specific:

Return the first non-zero position of an array of length n - or if it is 
all zero return n.

Can you do it without extra variable?

One solution working in pov is:

#declare goon=1;
#declare i=0;
#while ((i<n)&(goon=1))
        #if (a[i]=0)
                #declare i=i+1;
        #else
                #declare goon=0;
        #end
#end

So this can impossible be better style. Please enlighten me with your 
solution.

Post a reply to this message

In article <3bb34c82@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   How so? I don't see anything wrong there (of course if we imagine that we
> convert it to equivalent C code).
>
>   The C standard *guarantees* that the expression at the right of && is not
> evaluated if the expression at the left is false. (The & operator in POV-Ray
> is equivalent to the && operator in C, and it should not be confused with
> the & operator in C, which does a completely different thing.)

Ups, I saw the & and didn't actually look at the whole expression or even
remembered that & in POV is && in C (I rarely 'use' POV).  Of course for &&
and || left-to-right and only as much as is needed holds in C. Nevertheless,
only as an exception to the general rule (Section 5, Clause 4 & 5 ISO C++)
that the evaluation order is unspecified unless it is explicitly specified,
which it is for &&,||,?:,=.  Personally I find it easier to always assume
the order and how much is unspecified (except for assignments of course) -
it makes the code much more readable even after years of not having looked
at it.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message