clipka <ano### [at] anonymousorg> wrote:

> Instead, I want to provide users with a dedicated syntax for cases where
> they know that the supplied function _already_ satisfies that form, so
> that the parser and render engine can exploit this property.

Right, sorry - I probably just confused the issue by speculating on a tenuous
similarity.


> You know,
> something like:
>
>     #declare MyFn1 = function(x,y,z) { ... }
>     #declare MyFn2 = function(x,y,z) { ... }
>     ...
>     #declare MyFnN = function(x,y,z) { ... }
>
>     #declare MyFn = function {
>         MyFn1(x,y,z bounded_by{box{ ... }}) +
>         MyFn2(x,y,z bounded_by{box{ ... }}) +
>         ...
>         MyFnN(x,y,z bounded_by{box{ ... }})
>     }
>
> except that this particular syntax would neither be reasonably easy to
> parse, nor do I consider it reasonably pretty.

Well, I was thinking that the way color maps and splines are defined, you could
just do something like

#declare MyFunctions = boundedf {
(x,y,z), pow(x,2) + pow(y,2) + pow(z,2), sphere { ...},
(x,y,z), -(pow(x,3) + pow(y,1) + pow(z,3)), box { ...},
(u,v,z), MyFn1, box { ...},
(u,v,t), MyFn2, box { ...},
(Theta, Phi), MyParametricFn, sphere { ...}
}

That way you don't need to have separate code blocks, retype "function" and
"bounded_by" and their associated braces every time, etc.

"boundedf" implies it's a function bounded by something already known.


It would be a nice feature to be able to use some mixture of (, [, and { to
define functions, as it always helps me differentiate between different parts of
large equations, and keep track of key terms - but that's "related to but
separate from" the present issue.

Post a reply to this message