Any one think they (logical operators &,|) shoud be short-circuit logic
operators (like &&, || in C/++) so that the following would be possible
#if( defined(somevar) & somevar)
    <some stuff>
#end
currently this is done like so
#ifdef(somevar)
    #if(somevar)
        <some stuff>
    #end
#end
--
Bye
Pabs

Post a reply to this message

In article <3A149BF8.C688E185@hotmail.com>, Pabs <pab### [at] hotmailcom> 
wrote:

> Any one think they (logical operators &,|) shoud be short-circuit logic
> operators (like &&, || in C/++) so that the following would be possible

POV already has & and | operators that behave as boolean logic 
operators. What exactly do you want? Bit-level operators?
A "defined()" function would be useful though...I don't think it can be 
done as a macro.

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

Chris Huff wrote:
> 
> In article <3A149BF8.C688E185@hotmail.com>, Pabs <pab### [at] hotmailcom>
> wrote:
> 
> > Any one think they (logical operators &,|) shoud be short-circuit logic
> > operators (like &&, || in C/++) so that the following would be possible
> 
> POV already has & and | operators that behave as boolean logic
> operators. What exactly do you want? Bit-level operators?
> A "defined()" function would be useful though...I don't think it can be
> done as a macro.
> 

No, he wants the behavior the C compiler has when evaluating:

 if ((divisor !=0)&&(amount/divisor ...

That is: if the divisor is 0, the division is not even performed
because the left part of the '&&' is false.

Sincerely, I'm against this idea for POV.
(it's ok in C).

Post a reply to this message

> No, he wants the behavior the C compiler has when evaluating:

>  if ((divisor !=0)&&(amount/divisor ...

> That is: if the divisor is 0, the division is not even performed
> because the left part of the '&&' is false.

> Sincerely, I'm against this idea for POV.
> (it's ok in C).


Oh, why?  Why should POV do extra work when the result is going to be false
already?  The reason it's done in C is to avoid that extra work.  Why would
this be a bad thing?  The only case I can think of is if there are side
effects to the second half of the equation (it calls a macro that creates an
object and returns a value), but that's so rarely necessary, plus needlessly
confusing (try figuring out code that has such side effects six months later
or which you didn't write) that it's not something that we really need.

Geoff

Post a reply to this message

Geoff Wedig wrote:
> 

> 
> > No, he wants the behavior the C compiler has when evaluating:
> 
> >  if ((divisor !=0)&&(amount/divisor ...
> 
> > That is: if the divisor is 0, the division is not even performed
> > because the left part of the '&&' is false.
> 
> > Sincerely, I'm against this idea for POV.
> > (it's ok in C).
> 
> Oh, why?  Why should POV do extra work when the result is going to be false
> already? The reason it's done in C is to avoid that extra work.  Why would
> this be a bad thing?  The only case I can think of is if there are side
> effects to the second half of the equation (it calls a macro that creates an
> object and returns a value), but that's so rarely necessary, plus needlessly
> confusing (try figuring out code that has such side effects six months later
> or which you didn't write) that it's not something that we really need.

You said it: it would open the door to needlessly confusing code.

The right way to write it is the current way:

#if (divisor <> 0.0)
#if (amount/divisor ...

There is no need to add confusion for the writer/reader of pov-script
with 'smart' browsing/evaluation of conditional expression.

Post a reply to this message

> Geoff Wedig wrote:
>> 
>> J?r?me Grimbert <jgr### [at] atos-groupcom> wrote:
>> 
>> > No, he wants the behavior the C compiler has when evaluating:
>> 
>> >  if ((divisor !=0)&&(amount/divisor ...
>> 
>> > That is: if the divisor is 0, the division is not even performed
>> > because the left part of the '&&' is false.
>> 
>> > Sincerely, I'm against this idea for POV.
>> > (it's ok in C).
>> 
>> Oh, why?  Why should POV do extra work when the result is going to be false
>> already? The reason it's done in C is to avoid that extra work.  Why would
>> this be a bad thing?  The only case I can think of is if there are side
>> effects to the second half of the equation (it calls a macro that creates an
>> object and returns a value), but that's so rarely necessary, plus needlessly
>> confusing (try figuring out code that has such side effects six months later
>> or which you didn't write) that it's not something that we really need.

> You said it: it would open the door to needlessly confusing code.

No, my *counterexample* (ie, the only reason you want anything else) is
needlessly confusing, because of side effects.  Having a pair of boolean
expressions that terminates if the first expression determines the whole
sequence is quite sensible.

I don't see why using two ifs is any clearer, it's just verbose, which is
its own kind of obtusification.

Geoff

Post a reply to this message

: You said it: it would open the door to needlessly confusing code.

  Why it would be confusing code?

  If I write: #if(a>0 & b>0)
does it matter whether the part "b>0" is evaluated or not as long as the
result is correct?

  Actually, doing it C-like can produce faster parsing:

  #if(a>0 & extremely_long_calculation(a)) ...

  If a<=0 then the extremely_long_calculation() macro is not called, saving
potentially a lot of time.
  Of course you can do it in the long way:

#if(a>0)
  #if(extremely_long_calculation(a))
    ...
  #end
#end

but why should you do it yourself when the povray parser can do it
automatically for you?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

  "The derivative of sin(2x) is cos(2x)"  - Matt Giwer

Post a reply to this message

On 17 Nov 2000 10:01:13 -0500, Warp wrote...
> : You said it: it would open the door to needlessly confusing code.
> 
>   Why it would be confusing code?

Because not everybody on these groups, or indeed everybody who uses POV, 
is experienced in, or capable of reading C style code.

I have enough trouble reading POV code as it is, and adding (more) 
abstract symbols to the scene description language would kill my ability 
to understand roughly what is happening in a scene file.

Sorry if I'm ranting, but I get a little fed up of seeing people trying 
to turn POV into a programming language, when, in my opinion, it isn't 
and shouldn't be.

Bye for now,
     Jamie.

Post a reply to this message

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

>   Actually, doing it C-like can produce faster parsing:
> 
>   #if(a>0 & extremely_long_calculation(a)) ...
> 
>   If a<=0 then the extremely_long_calculation() macro is not called, 
> saving potentially a lot of time.

If that extremely_long_calculation sets up some variables for later use, 
not evaluating it could lead to obscure bugs in scene files. Having side 
effects like this may be bad style, but having them be ignored sometimes 
would lead to problems that are very difficult to track down when they 
are done.

In other words, it is a minor optimization that can be done within the 
scene language and produces the possibility for bugs that are extremely 
difficult to track down(or code that is very vague because it relies on 
this optimization). Not worth adding in my opinion.

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

Warp wrote:


> : You said it: it would open the door to needlessly confusing code.
>
>   Why it would be confusing code?
>
>   If I write: #if(a>0 & b>0)
> does it matter whether the part "b>0" is evaluated or not as long as the
> result is correct?

Yes, and besides, this is much clearer to me than
  #if(a>0)
    #if(b>0)
It's especially more clear when limiting to a set:
  #if(a>0 & a<10)
because you don't need to read ahead or look at indentation to see that you're
limiting a to an interval (0,10) (or is that [0,10]?). Same goes for a
non-contigous set:
  #if((a>0 & a<10) | a>20 | a=15)
Imagine that coded as individual tests!

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message