 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/29/19 3:07 AM, IGM wrote:
> This is my poor-man solution:
>
> // root(s) of function F = Y(X)-thr
> // Example:
> // #declare X = array [10] {0,10,20,30,40,50,60,70,80,90};
> // #declare C = array [10]
> {0.000,21.000,44.000,69.000,97.000,124.000,158.000,181.000,206.000,232.000};
> // root(X,C,35)
> // #debug concat("root: ", str(macro_value,5,3),"\n")
> #macro root(X,Y,thr)
>
> #include "math.inc"
> GetStats(Y);
>
> #local f_prism = prism {
> linear_spline
> -1, 1, dimension_size(Y,1)+3,
>
> #for (k,0,dimension_size(Y,1)-1)
> <X[k],Y[k]>,
> #end
> <X[dimension_size(Y,1)-1],StatisticsArray[2]-1>, // add lower point 1
> <X[0],StatisticsArray[2]-1>, // add lower point 2
> <X[0],Y[0]> // close prism
> // rotate x*-90 // For plot in x,z plane. In this case P0 = <0,thr,0>
> }
>
> #object {f_prism pigment {rgb <0,2,0>} } // no_image?
>
> #local P0 = <0,0,thr>; // Starting point
> #local V0 = <1,0,0>; // Incident vector
> // Trace to object
> #local N = <99,99,99>; // init
> #local P1 = trace(f_prism, P0, V0, N); // Loop here to find multiple roots
> // Plot traced ray:
> // #cylinder {P0, P1, 1 pigment {rgb <0,1,0>} no_shadow no_reflection}
>
> // For multiple roots create array!
> #declare macro_value = P1.x;
> #end
>
>
Looks workable, though a few things caught my eye.
1)
If thr is 0 the Starting point will be on the prism edge and I'm not
sure what the trace result might be in that case though expect one would
want 0.0 as the returned root.
2)
IIRC you have to look at the normal returned by the trace command to
really know whether it found a valid intersection. It's set on valid
intersections only I believe.
3) And a lesson for me!
Saw #object (which you shouldn't need for the trace) and #cylinder;
Thought, "Does that really work?" It does! You can also stick '#' on the
end on some lines or code #declare CylinderZ = #cylinder {} and nary a
peep or problem from the parser - new or old versions. The usual and
recommended syntax is object {} and cylinder {}.
A declare without the leading # works too but we get:
File 'tmp.pov' line 40: Parse Warning: Should have '#' before 'declare'.
File 'tmp.pov' line 40: Possible Parse Error: 'declare' should be changed to
'#declare'. Future versions may not support 'declare' and may require
'#declare'.
Given this warning, I'd think we should be getting one on #object {} and
the like too as the other side of the syntax change push - now that I
understand there is another side.
Suppose this behavior related to Christoph's recommendation to me back
in February to use default {} rather than #default {} though it's the
latter which is still in the documentation. The idea, as I understand
it, is to get to where the #<token> is used only with SDL language
control elements.
Twenty years playing with POV-Ray and still learning.
I'm also not the brightest light bulb. I code in bash and tcl which use
'#' style comments. I've long been aware
# camera { Camera00 }
doesn't comment the camera and isolated #s are ignored because sometimes
I comment with '#' by muscle memory. I'd personally like a parse error
for floating '#'s. It would save me time and I can see no reason to have
them though '# declare Widget12 = ...' works fine today (it's treated as
#declare).
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 1)
> If thr is 0 the Starting point will be on the prism edge and I'm not
> sure what the trace result might be in that case though expect one would
> want 0.0 as the returned root.
This was actually happening in my script, and the result was that the intercept
was at the other side of the prism, i.e. the last point! It deserve a dedicated
conditional check.
Thanks
igmar
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"IGM" <iar### [at] gmail com> wrote:
> This is my poor-man solution:
>
> // root(s) of function F = Y(X)-thr
>...
If your function is strictly monotone you can just define another linear spline
with the values switched at each index, like this:
#version 3.7;
#declare NoOfPoints = 10;
#declare X =
array [NoOfPoints] {
0,
10,
20,
30,
40,
50,
60,
70,
80,
90
}
;
#declare Y =
array [NoOfPoints] {
0.0,
21.0,
44.0,
69.0,
97.0,
124.0,
158.0,
181.0,
206.0,
232.0
}
;
#declare Spline =
spline {
linear_spline
#for (I, 0, NoOfPoints-1)
X[I], Y[I]*y
#end // for
}
#declare ReverseSpline =
spline {
linear_spline
#for (I, 0, NoOfPoints-1)
Y[I], X[I]*x
#end // for
}
#declare Thr = 35;
#declare Root = ReverseSpline(Thr).x;
#debug "\n\n"
#debug concat("Root: ", str(Root, 0, -1))
#debug "\n\n"
#error "To stop text output and prevent render window"
--
Tor Olav
http://subcube.com
https://github.com/t-o-k
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2019-09-29 à 03:07, IGM a écrit :
> This is my poor-man solution:
>
> // root(s) of function F = Y(X)-thr
> // Example:
> // #declare X = array [10] {0,10,20,30,40,50,60,70,80,90};
> // #declare C = array [10]
> {0.000,21.000,44.000,69.000,97.000,124.000,158.000,181.000,206.000,232.000};
> // root(X,C,35)
> // #debug concat("root: ", str(macro_value,5,3),"\n")
> #macro root(X,Y,thr)
>
> #include "math.inc"
> GetStats(Y);
>
> #local f_prism = prism {
> linear_spline
> -1, 1, dimension_size(Y,1)+3,
>
> #for (k,0,dimension_size(Y,1)-1)
> <X[k],Y[k]>,
> #end
> <X[dimension_size(Y,1)-1],StatisticsArray[2]-1>, // add lower point 1
> <X[0],StatisticsArray[2]-1>, // add lower point 2
> <X[0],Y[0]> // close prism
> // rotate x*-90 // For plot in x,z plane. In this case P0 = <0,thr,0>
> }
>
> #object {f_prism pigment {rgb <0,2,0>} } // no_image?
>
> #local P0 = <0,0,thr>; // Starting point
> #local V0 = <1,0,0>; // Incident vector
> // Trace to object
> #local N = <99,99,99>; // init
> #local P1 = trace(f_prism, P0, V0, N); // Loop here to find multiple roots
> // Plot traced ray:
> // #cylinder {P0, P1, 1 pigment {rgb <0,1,0>} no_shadow no_reflection}
>
> // For multiple roots create array!
> #declare macro_value = P1.x;
> #end
>
>
Why that «#» in front of «object» and that other one in front of
«cylinder» ?
The «#» is needed in front of directives, never in front of a primitive.
It should be :
object {f_prism pigment {rgb <0,2,0>} }
and
cylinder {P0, P1, 1 pigment {rgb <0,1,0>} no_shadow no_reflection}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2019-09-29 à 08:48, William F Pokorny a écrit :
>
> Looks workable, though a few things caught my eye.
>
> 1)
> If thr is 0 the Starting point will be on the prism edge and I'm not
> sure what the trace result might be in that case though expect one would
> want 0.0 as the returned root.
>
> 2)
> IIRC you have to look at the normal returned by the trace command to
> really know whether it found a valid intersection. It's set on valid
> intersections only I believe.
Trace return a nul vector if there is no intersection, as well as a
location of <0,0,0>.
>
> 3) And a lesson for me!
> Saw #object (which you shouldn't need for the trace) and #cylinder;
> Thought, "Does that really work?" It does! You can also stick '#' on the
> end on some lines or code #declare CylinderZ = #cylinder {} and nary a
> peep or problem from the parser - new or old versions. The usual and
> recommended syntax is object {} and cylinder {}.
>
> A declare without the leading # works too but we get:
>
> File 'tmp.pov' line 40: Parse Warning: Should have '#' before 'declare'.
> File 'tmp.pov' line 40: Possible Parse Error: 'declare' should be
> changed to
> '#declare'. Future versions may not support 'declare' and may require
> '#declare'.
Using declare instead of #declare can result in an error at parse time.
>
> Given this warning, I'd think we should be getting one on #object {} and
> the like too as the other side of the syntax change push - now that I
> understand there is another side.
#object should generate a warning.
Same for #Primitive_Name
>
> Suppose this behavior related to Christoph's recommendation to me back
> in February to use default {} rather than #default {} though it's the
> latter which is still in the documentation. The idea, as I understand
> it, is to get to where the #<token> is used only with SDL language
> control elements.
>
> Twenty years playing with POV-Ray and still learning.
>
> I'm also not the brightest light bulb. I code in bash and tcl which use
> '#' style comments. I've long been aware
>
> # camera { Camera00 }
>
> doesn't comment the camera and isolated #s are ignored because sometimes
> I comment with '#' by muscle memory. I'd personally like a parse error
> for floating '#'s. It would save me time and I can see no reason to have
> them though '# declare Widget12 = ...' works fine today (it's treated as
> #declare).
>
> Bill P.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/30/19 7:04 PM, Alain Martel wrote:
> Le 2019-09-29 à 08:48, William F Pokorny a écrit :
...
>> A declare without the leading # works too but we get:
>>
>> File 'tmp.pov' line 40: Parse Warning: Should have '#' before 'declare'.
>> File 'tmp.pov' line 40: Possible Parse Error: 'declare' should be
>> changed to
>> '#declare'. Future versions may not support 'declare' and may require
>> '#declare'.
>
> Using declare instead of #declare can result in an error at parse time.
>
If you have an example which results in an actual error at parse time,
I'd like to get it.
I have a collection of parser test cases and I spent time yesterday
capturing/creating parser test cases for these '#' variants. I didn't
come up with anything that generated an actual parse error - or render
problem - only the warnings above.
I did come up with a case with isolated #s ahead of a bare 'declare'
which did NOT generate the warnings above (I found a parser bug) though
the render result was still fine.
>>
>> Given this warning, I'd think we should be getting one on #object {}
>> and the like too as the other side of the syntax change push - now
>> that I understand there is another side.
>
> #object should generate a warning.
> Same for #Primitive_Name
>
Unsure if you were agreeing we should be getting such warnings, or
saying POV-Ray does generate such a warning. If the latter, I never saw
that while trying different things. If warnings for #Primitive_Name do
sometimes happen, I'd like an example test case for my collection.
Also had the thought last night, Does say '#accuracy 0.001' work..? It
does.
Aside: I've converted to vim/gvim for my editor. Still working to get
back up to speed, but, vim itself ships with syntax highlighting and
indenting for POV-Ray v3.7(1) and, interestingly, it specifically
supports the '#<zero or as many spaces as you want>local' type syntax
for the language control elements (and #default{} and not default{} if
wondering - matching our current documentation).
Bill P.
(1) - There are some issues with it as others have noted. I might have
go at my own v3.8 version adding error indications for bad # use along
with v3.8 plus experimental feature support.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Aside: I've converted to vim/gvim for my editor. ...
in case you don't already know: ":he tcl" ;-)
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain Martel <kua### [at] videotronca> wrote:
>
> Why that «#» in front of «object» and that other one in front of
> «cylinder» ?
>
> The «#» is needed in front of directives, never in front of a primitive.
My bad habit... I use # in front of primitives since I started playing with
povray, for uniformity. Now I know it's strongly discouraged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/1/19 1:45 PM, jr wrote:
> hi,
>
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> Aside: I've converted to vim/gvim for my editor. ...
>
> in case you don't already know: ":he tcl" ;-)
>
> regards, jr.
>
Yes! Not yet done anything with the capability, but certainly one of the
reasons I went to vim/gvim over other options. Relatively strong
coupling/behavioral similarities to the bash shell another.
Aside: I bought the book you recommended and found it useful. Thanks. In
fact I should probably read through it again.
More than two months and the old muscle habits are still tripping me up
all the time! The deeper I am in thought about something else, the less
conscious I am about the editor, the more I trip. It really bugs me
because it rips apart my concentration. The screen changes and I have no
idea what I did! "Oh, yeah..." I found too my touch typing skills had
drifted over the years due - whatever - I guess. Trying to reign in
those bad habits too.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/1/19 1:45 PM, jr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >> ...
> >> Aside: I've converted to vim/gvim for my editor. ...
> > in case you don't already know: ":he tcl" ;-)
> >
> Yes!
:-)
> Not yet done anything with the capability, but certainly one of the
> reasons I went to vim/gvim over other options. Relatively strong
> coupling/behavioral similarities to the bash shell another.
>
> Aside: I bought the book you recommended and found it useful. Thanks. In
> fact I should probably read through it again.
I go through .. phases where the book is next to the keyboard for days on end.
> More than two months and the old muscle habits are still tripping me up
> all the time! The deeper I am in thought about something else, the less
> conscious I am about the editor, the more I trip. It really bugs me
> because it rips apart my concentration. The screen changes and I have no
> idea what I did! "Oh, yeah..." I found too my touch typing skills had
> drifted over the years due - whatever - I guess. Trying to reign in
> those bad habits too.
the book's subtitle applies, it would seem. :-)
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
