 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What you want is simple: Support for defining variables inside functions.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What you want is simple: Support for defining variables inside functions.
All we miss then yet is only iteration/recursion inside of these functions, and
they're turing-complete ...
(I know, the language itself is already, but function themselfes are not, are they ?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jan Walzer <jan### [at] lzer net> wrote:
> All we miss then yet is only iteration/recursion inside of these functions, and
they're turing-complete ...
Imagine the mandelbrot pattern defined as a function... Or any other
fractal whatsoever.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
But it would be quite a high risk, to get a stack overflow ...
As I understood, functions are more deeper embedded in POVRay, than macros ...
so there probably would be a need for extra checkings, to make functions, not to block
the whole system ...
Imagine a function that looks up, because of a infinite-loop, that gets computet first
time at 50% of an Image ... (this image
rendered at 2pps) ...
how will you tell, that it's the function, dooing an infinite loop, and not "only the
image with a bit of
media/refraction/any-other-slow-feature" ?
I think it would be _very_ powerful, but it would lead to even more headaches than we
have already ...
I think you all know what I mean ... <looking into p.b-t> ....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jan Walzer <jan### [at] lzernet> wrote:
> But it would be quite a high risk, to get a stack overflow ...
It would just give a "max recursion depth limit reached" error. Nothing
fancy.
Of course this limit should be something usable, eg. at least hundreds or
better some thousands.
Naturally if some type of iterative loop is implemented, then recursion
will not be needed.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Naturally if some type of iterative loop is implemented, then recursion
> will not be needed.
And you can't tell if these loops will terminate, if it's turing complete ...
so one could lock up the render, without knowing it ....
probably one have to include something like a "maxiteration" for loops (if they were
available) .. so to cancel an infinite loop
after, maybe, 10000 times going over a specified "label" .... (just an idea) ...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c939dc5$1@news.povray.org>, jan### [at] lzernet says...
> And you can't tell if these loops will terminate, if it's turing complete ...
> so one could lock up the render, without knowing it ....
Whats the problem? A sufficienty complicated object (preferrably with a
glas material and filled with scattering media...) can do practically the
same.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yeah ... but it WILL terminate ...
and even if recursion-depth will be 2^32 .... it WILL terminate ...
you can't tell this for every function if the "machine" is turing-complete
... or better the other way around:
If a function terminates, then: fine...
but if it is running, there's no algorithmic way, to determine if this function will
ever terminate or not ...
Your only chance is to wait and see ...
of course, there are trivial ones, but for every function you find, that is possible
to tell, there are infinite other functions,
where you can't tell ...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jan Walzer <jan### [at] lzernet> wrote:
> And you can't tell if these loops will terminate, if it's turing complete ...
> so one could lock up the render, without knowing it ....
So can a #while. So what?
That's not the problem here.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote:
> Jan Walzer <jan### [at] lzernet> wrote:
> > And you can't tell if these loops will terminate, if it's turing complete ...
> > so one could lock up the render, without knowing it ....
>
> So can a #while. So what?
> That's not the problem here.
but it happens at parse-stage ... there's no image rendered yet, and you can debug it
by using the debug-stream ...
functions can get evaluated at rendertime ...
you can't debug them by writing some intermediate-values to some stream ...
you see my prob ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
