Chaps wrote:

> what is the use of goon?
> 
> I would just write:
> 
>  #declare i=0;
>  #while (i<n)
>          #if (a[i]=0) // this will not be evaluated if i = n
>                  #declare i=i+1;
>          #end
>  #end
> 

This does not work... if a[i]!=0 for some i<n then the while-loop will go 
on forever.

Post a reply to this message

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

> Can you do it without extra variable?

I can do it with i and n

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

Of course it depends on what exactly you want to do with the result to find
an optimal solution (in particular one that doesn't process the whole
array).  This macro should do what you want and it does not need more
variables:

#macro findzero(a, n)
 #local i = n;
 #while(i >= 0)
  #if(a[i] != 0)
   #declare n = i;
  #end
  #declare i = i - 1;
 #end
#end

#declare myarray = array[5]

#declare myarray[0] = 0;
#declare myarray[1] = 0;
#declare myarray[2] = 0;
#declare myarray[3] = 0;
#declare myarray[4] = 0;

#declare p = 4;
findzero(myarray, p)
#debug str(p,1,1)

#declare myarray[3] = 4;
#declare myarray[4] = 2;

#declare p = 4;
findzero(myarray, p)
#debug str(p,1,1)

#declare myarray[0] = 6;
#declare myarray[1] = 7;
#declare myarray[2] = 3;

#declare p = 4;
findzero(myarray, p)
#debug str(p,1,1)

#declare myarray[2] = 0;

#declare p = 4;
findzero(myarray, p)
#debug str(p,1,1)

Post a reply to this message

>  #local i = n;
>  #while(i >= 0)
>   #if(a[i] != 0)
>    #declare n = i;
>   #end
>   #declare i = i - 1;
>  #end

 He, he... That's what a "real" programmer calls "good style". .. :)
These are the kind of things I never come up myself (I don't consider my
self a "real" programmer at all). But in my simplicity, I will like it
more this way:

#local i=0;
#while (i<n)  
 #if (a[i]!=0)
  #break
 #end
 #local n=n+1
#end

  ...a pain it doesn't works, although I rarely need to use it with POV
scripts.

-- 
Jaime Vives Piqueres

La Persistencia de la Ignorancia
http://www.ignorancia.org/

Post a reply to this message

In article <3BB37763.77E42F48@ignorancia.org> , Jaime Vives Piqueres 
<jai### [at] ignoranciaorg>  wrote:

>  He, he... That's what a "real" programmer calls "good style". .. :)

I actually was referring to C/C++ as well as the assumption of short-circuit
evaluation in my original post.

> These are the kind of things I never come up myself (I don't consider my
> self a "real" programmer at all). But in my simplicity, I will like it
> more this way:
>
> #local i=0;
> #while (i<n)
>  #if (a[i]!=0)
>   #break
>  #end
>  #local n=n+1
> #end
>
>   ...a pain it doesn't works, although I rarely need to use it with POV
> scripts.

Indeed the lack of a "break" statement in POV-Ray #while-loops makes the
problem and code more difficult than in C.  So a bit more creative solutions
are needed.  In C I would never use the above code as it will always be too
slow and just iterate through the array for no good reason.  However, there
are might be more efficient ways to do in in POV-Ray as well (to cut down
parsing time).

By using the original search direction and a third variable it might well be
that there is a more efficient solution so parsing is faster if the above is
done on huge arrays with only a very few zeros.  Of course, knowing why the
first non-zero element needs to be found would really help - knowing the
whole problem is almost always a good idea as it allows to look not only for
more efficient, but possible completely different solutions to the actual
problem...


    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

In article <3bb37e54$1@news.povray.org> , "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> By using the original search direction and a third variable it might well be
> that there is a more efficient solution so parsing is faster if the above is
> done on huge arrays with only a very few zeros.

Actually, the code below should work (didn't bother to test it) and be much
faster in most cases.

#macro findzero(a, n)
 #local i = 0;
 #while(i <= n)
  #if(a[i] != 0)
   #declare n = i;
  #end
  #declare i = i + 1;
 #end
#end

    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

> #macro findzero(a, n)
>  #local i = 0;
>  #while(i <= n)
>   #if(a[i] != 0)
>    #declare n = i;       
>   #end
>   #declare i = i + 1;
>  #end
> #end

 Oh! Very fine. Like #break, but better...

-- 
Jaime Vives Piqueres

La Persistencia de la Ignorancia
http://www.ignorancia.org/

Post a reply to this message

Thorsten Froehlich wrote:

> In article <3bb37e54$1@news.povray.org> , "Thorsten Froehlich"
> <tho### [at] trfde> wrote:
> 
>> By using the original search direction and a third variable it might well
>> be that there is a more efficient solution so parsing is faster if the
>> above is done on huge arrays with only a very few zeros.
> 
> Actually, the code below should work (didn't bother to test it) and be
> much faster in most cases.
> 
> #macro findzero(a, n)
>  #local i = 0;
>  #while(i <= n)
>   #if(a[i] != 0)
>    #declare n = i;
>   #end
>   #declare i = i + 1;
>  #end
> #end

Nice idea to traverse the array from the end.. but as you already noticed 
it is less efficient. But you two variables all the same.. with my example 
'n' has been a constant and the result was returned in the only changed 
variable 'i'. And I still think that the variant with usage of 
short-circuit evaluation is nicer... it is shorter, more efficient, and if 
somebody looks at it he/she instantly sees what it does.

Where I got to this problem was some problem of sorting a special array 
with many same values and a special pre-order. It was only thought as an 
example why I prefered short-circ eval.

That still leaves the question open if other people are unhappy as well 
with the current evaulation type.

- Micha

Post a reply to this message

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

> That still leaves the question open if other people are unhappy as well
> with the current evaulation type.

Well, you are the first person I know who complained about it.  And AFAIK
the logic operations have been in POV-Ray since 3.0, which came out about
five years ago...


    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

On Thu, 27 Sep 2001 17:23:20 -0400, Thorsten Froehlich wrote:
>In article <m34### [at] michariser> , Micha Riser <mri### [at] gmxnet>  
>wrote:
>
>> That still leaves the question open if other people are unhappy as well
>> with the current evaulation type.
>
>Well, you are the first person I know who complained about it.  And AFAIK
>the logic operations have been in POV-Ray since 3.0, which came out about
>five years ago...

I think it's a moot point, as I'm not sure the expression parser could be
rewritten to do the short-circuit behavior without a bit of pain.

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

Post a reply to this message

In article <slr### [at] fwicom> , ron### [at] povrayorg (Ron
Parker) wrote:

> I think it's a moot point, as I'm not sure the expression parser could be
> rewritten to do the short-circuit behavior without a bit of pain.

The function parser could in 3.5, but it is pointless right now as its
"logic" operators are really min and max functions.   As for the expression
parser, I don't think it would be easy.  Perhaps just parsing and counting
opening and closing parenthesis would work (but be a bit ugly), but I don't
think it even should be changed...

    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