"Warp" <war### [at] tagpovrayorg> schrieb im Newsbeitrag news:3c93f560@news.povray.org...
> Jan Walzer <jan### [at] lzernet> wrote:
> > but it happens at parse-stage ... there's no image rendered yet, and you can debug
it by using the debug-stream ...
>
>   You can do the same thing with functions.
No ... I can't

> > functions can get evaluated at rendertime ...
> > you can't debug them by writing some intermediate-values to some stream ...
>
>   Yes, you can.
Can I ? ... How ?
> > you see my prob ?
>
>   No.

You mean, I should better read the doc ? There is a way ?

Post a reply to this message

In article <3c94681e@news.povray.org>, "Jan Walzer" <jan### [at] lzernet> 
wrote:

> You mean, I should better read the doc ? There is a way ?

Are you just trying to be annoying?
Your argument: if flow control structures are added, it would be 
possible to end up with endlessly iterating structures with no way to 
output debug values.
There is currently no way to do it, but there currently aren't flow 
control structures either. There is no reason a debug command couldn't 
be added to functions, making your argument invalid.

I really don't think it is a problem anyway...you can make infinite 
loops now, or do other things that take extremely long times to render.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Jan Walzer <jan### [at] lzernet> wrote:
>>   Yes, you can.
> Can I ? ... How ?

#debug concat(str(MyFunction(1,2,3),0,-1), "\n")

  It doesn't matter if 'MyFunction' is a macro or a function. If it hangs,
it will hang at parse time.

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

Post a reply to this message

Peter Popov <pet### [at] vipbg> wrote:
>>If you set an arbitrary limit, it will either be too low and get in 
>>people's way (like the recursion limit for macros), or be too high and 
>>not be useful. Why bother?

> Only if you make it built-in. If you can change it in the scene or in
> the ini file, there will not be such a problem.

  So let's put a limit to the number of times a #while can execute. Right?

  I really don't see the problem here. If someone wants to make an infinite
loop, then let them make one. It's not your headache.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote:
> Jan Walzer <jan### [at] lzernet> wrote:
> >>   Yes, you can.
> > Can I ? ... How ?
>
> #debug concat(str(MyFunction(1,2,3),0,-1), "\n")
>
>   It doesn't matter if 'MyFunction' is a macro or a function. If it hangs,
> it will hang at parse time.

not for every case/function ...

What I meant, is that you can hardly compute/debug any values a function can
give while tracing (imagine, you have it as a imagemap)...

I think Christopher is right, when he means taht we shouldn't dispute about
issues, that are currently no problems at all ...

so propably I can say a EOT here ?

let me just say, that I think it would be great idea, to have recursive
funtions with definable variables, yes ... but leave this issue until 3.5 is
out ... OK ?

Post a reply to this message

On 17 Mar 2002 16:28:29 -0500, Warp <war### [at] tagpovrayorg> wrote:

>  I really don't see the problem here. If someone wants to make an infinite
>loop, then let them make one. It's not your headache.

Infinite loops have their uses. We're talking infinite recursion here,
and on less memory-protected systems a stack fault can cost more than
an interrupted render.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On Mon, 11 Mar 2002 03:17:07 -0500, "Slime" <noo### [at] hotmailcom> wrote:
>
> function{
>    f_noise3d(
>        x/(remember(1): sqrt(x^2+y^2+z^2)),
>        y/(recall:1),
>        z/(recall:1)
>    )
> }
>
> Where the 1 indicates that the remembered item labeled "1" should be
> recalled. The syntax I made up here is ugly, but is there any chance of this
> functionality appearing in the future?

It can appear tomorrow :-) if you just write:

 function{
    #local Function_With_One_Sqrt=function(x,y,z,sqrtxyz){
      f_noise3d(
          x/sqrtxyz,
          y/sqrtxyz,
          z/sqrtxyz
      )
    };
    Function_With_One_Sqrt(x,y,z,sqrt(x^2+y^2+z^2))
 }

The difference between your simple example and my case is very important.
While your subexpresssion is used three times in every function call, my
subexpression was used with apropriate condition in select(). I can't
precalculate it as subfunction with additional parameter becouse statisticaly
it is used only in 30% calls for example. Of course I can separate content of
select as sub function but it can slow down evaluation a lot when
subexpression is builded with hundreds of selects.

ABX

Post a reply to this message

On Sat, 16 Mar 2002 16:02:52 +0100, "Jan Walzer" <jan### [at] lzernet> wrote:
> All we miss then yet is only iteration/recursion inside of these functions, and
they're turing-complete ...

Personally I think that internally functions are ready for recursions :-)
I've got message "Possible infinite recursive function call." some time.
I've also got message like "Reached maximum number of
recursion in functions". In both cases messages were produced as a result of
bug as I reported in povray.beta-test but the fact they are builded in POV-Ray
lead me to conclusion that recursion is a part of design :-)

ABX

Post a reply to this message

On 16 Mar 2002 14:21:26 -0500, Warp <war### [at] tagpovrayorg> wrote:
> It would just give a "max recursion depth limit reached" error.

I've got such a message in 3.5 as I reported.

ABX
--
disc{z,-z 5#macro O()asc(substr("-+((1*(,1,/.-,*/(,&.323/'1"e,1))*.1-4#declare
e=e-1;#end#local e=26;pigment{#local g=function(_){ceil(_)-_}function#local//X
k=function{pattern{object{sphere_sweep{linear_spline 13#while(e>0)<O(),O()//AB
>.01#end}}}}{k(g(atan2(x,y)),g(ln((y+x)^2+1e-5)),0)}}finish{ambient 1}}//POV35

Post a reply to this message

> On Sat, 16 Mar 2002 16:02:52 +0100, "Jan Walzer" <jan### [at] lzernet> wrote:
>> All we miss then yet is only iteration/recursion inside of these functions, and
they're turing-complete ...
> 
> Personally I think that internally functions are ready for recursions :-)
> I've got message "Possible infinite recursive function call." some time.
> I've also got message like "Reached maximum number of
> recursion in functions". In both cases messages were produced as a result of
> bug as I reported in povray.beta-test but the fact they are builded in POV-Ray
> lead me to conclusion that recursion is a part of design :-)

Loops, too.  They're just not part of the syntax.  The 3.5 beta has some
debugging features built in, though, so you can actually use them.  For 
example, here's a simple iterative factorial function:

#declare Fact=function(x) {"fact.out","fact.func" };

#debug concat(str(Fact(0),3,3), "\n")
#debug concat(str(Fact(1),3,3), "\n")
#debug concat(str(Fact(2),3,3), "\n")
#debug concat(str(Fact(3),3,3), "\n")
#debug concat(str(Fact(4),3,3), "\n")

and here are the contents of the file "fact.func":

grow    2
load    SP(0),r2
loadi   1,r0
cmpi    0,r2
ble     8
mul     r2,r0
subi    1, r2
jmp     3
rts

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message