 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/21/21 4:09 PM, Tor Olav Kristensen wrote:
> I also wonder if "hiding" functions inside an array or a dictionary is a good
> and robust way to avoid function related name clashes. But I guess we will still
> have to struggle with name clashes related to the function parameters.
>
RE: name clashes on function parameters.
---
Note. In v3.8 with optional macro parameters, parameter names can
collide. This an additional reason I'm chasing the no (a-z,0-9,_)
identifiers checking in the povr branch.
//---
#version 3.8;
#local Filename = "File99"
#macro Mcr00(_string, optional Filename)
//#ifndef(local.Filename)
#ifndef(Filename)
#local Filename = "File00";
#end
#debug concat("00 File name: ",Filename," String: ",_string,"\n")
#end
#macro Mcr01(_string, optional _filename)
//#ifndef(local._filename)
#ifndef(_filename)
#local Filename = "File01";
#else
#local Filename = _filename;
#end
#debug concat("01 File name: ",Filename," String: ",_string,"\n")
#end
Mcr00("abc",Filename)
Mcr01("abc",Filename)
Mcr00("xyz",Wildname) // oops
Mcr01("xyz",Wildname)
#error "Stop early"
//---
RE: Dictionary of functions.
---
Suspect useful. When functions are dynamic, macro call to macro call, as
is the case passing the transform - and not used inside the macro
multiple times in a loop say - I think your recent approach likely the
best way to go.
Where the function internal to the macro 'could' be compiled and kept
for future use I've been wondering if we should not in v3.8 onward be
testing for function definition in the global dictionary space;
compiling only if not already compiled and thereafter using the global
identifier pointing to compiled code? Something like:
#version 3.8;
#macro Mcr02(_string,_a,_b,_c)
#ifndef(global.Fn00_Macro2)
#declare Fn00_Macro2 = function { x+y+z }
#debug "Compiled Fn00_Macro2\n"
#end
#debug concat("02 ",_string," ",str(Fn00_Macro2(_a,_b,_c),6,4),"\n")
#end
Mcr02("Call 0",1,2,3)
Mcr02("Call 1",4,5,6)
Mcr02("Call 2",7,8,9)
#error "Stop early"
>
>> I'll have to spend more time thinking about it and the actual inner
>> workings. I suspect you've gotten to something near like what happens
>> with prod and sum internally with the vm.
> Sorry, but I don't understand what you mean here. I've never studied the
> internals of that vm.
>
Suppose it's that I'm not completely sure I do either! :-)
In looking at a performance question from Bald Eagle where he had used
prod - as I recall -it seemed like the sum * prod functions were doing
parser expression work and compilation on each call in the 'loop.' I
take your code to be doing something similar. As in, no call to already
compiled vm code from a function ID. Beyond that, there are details I
don't fully understand.
>
...
>
> Btw.:
> Have you considered using sum() in the FnctNxNx9ArrayEntryToDBL() macro in
> arraycoupleddf3s.inc ?
I'd not.
Aside 1: The sum and prod functions are suspect performance wise. (see
related comments just prior)
Aside 2: I'm considering dropping the FnctNxNx9ArrayEntryToDBL() from
the core arraycoupleddf3s.inc file as the povr branch has more capable
inbuilt functions for nearly identical functionality. Perhaps it'll be
code retained as a non-core macro / include. We'll see.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmail com> wrote:
> Hi Ricky
>
> It took me a while to figure out what is going on there.
> You are exploiting the automatic vector promoting "feature".
Well, that's what I was implying, and it seemed like you "knew" about that
already.
> > > I don't think that it is possible to investigate the number of components in a
vector without it being promoted a
utomatically ...
I know that clipka gave me an example that stuck, of which I use variants all
the time:
http://news.povray.org/povray.documentation.inbuilt/message/%3Cweb.59398df47cb8f4dcc437ac910%40news.povray.org%3E/#%3Cw
eb.59398df47cb8f4dcc437ac910%40news.povray.org%3E
> Here's my take on it:
>
>
> #macro VectorDimTest(v0)
>
> #local vZ3D = <0, 0, 0>;
> #local vZ4D = <0, 0, 0, 0>;
> #local vZ5D = <0, 0, 0, 0, 0>;
> #local v1 = v0 + 1;
> #local v2 = v0 + 2;
> #local D2 = ((vZ3D + v1).z = (vZ3D + v2).z);
> #local D3 = ((vZ4D + v1).t = (vZ4D + v2).t);
> #local D4 = ((vZ5D + v1).transmit = (vZ5D + v2).transmit);
>
> #if (D2)
> #debug "2D"
> #else
> #if (D3)
> #debug "3D"
> #else
> #if (D4)
> #debug "4D"
> #else
> #debug "5D or scalar"
> #end // if
> #end // if
> #end // if
>
> #end // VectorDimTest
Both of your macros are pretty nice :)
It's early and I'm still on First Coffee, but I'm fuzzily thinking that maybe
there's a way to disambiguate a 5D vector and a scalar by adding and/or
multiplying with vectors containing different signs and testing the result?
My brain is also giving me the impression that binary math and things like (I
said _like_) bitmasks and xor might offer inspiration for a solution.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> > "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> > > I don't think that it is possible to investigate the number of components in a
> > > vector without it being promoted automatically or having POV-Ray halt on an
> > > error.
> >
> > It is possible to do certain tests. For example, ...
> ...
> That's clever sorcery !
>
> Here's my take on it:
> ...
> #debug "5D or scalar"
> ...
thinking that what your + CR's (ingenious) posts demonstrate is just how much an
'istype()' like function is needed in SDL. (I've a feeling it would not be too
difficult to implement, a developer's perspective would be good)
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Note. In v3.8 with optional macro parameters, parameter names can
> collide. This an additional reason I'm chasing the no (a-z,0-9,_)
> identifiers checking in the povr branch.
>
> //---
> #version 3.8;
>
> #local Filename = "File99"
>
> #macro Mcr00(_string, optional Filename)
> //#ifndef(local.Filename)
> #ifndef(Filename)
> #local Filename = "File00";
> #end
> #debug concat("00 File name: ",Filename," String: ",_string,"\n")
> #end
>
> #macro Mcr01(_string, optional _filename)
> //#ifndef(local._filename)
> #ifndef(_filename)
> #local Filename = "File01";
> #else
> #local Filename = _filename;
> #end
> #debug concat("01 File name: ",Filename," String: ",_string,"\n")
> #end
>
> Mcr00("abc",Filename)
> Mcr01("abc",Filename)
>
> Mcr00("xyz",Wildname) // oops
> Mcr01("xyz",Wildname)
>
> #error "Stop early"
> //---
may be I'm too dense, but what goes wrong at 'oops'? since 'Mcr00' only looks
for 'Filename', which exists, it'll use that. and 'Wildname' isn't defined, so
'Mcr01' also appear (to me) to do the correct thing. did I misread yr point?
I changed the code to use 'local' as I would, and see nothing .. unexpected in
the output.
regards, jr.
jr@swift:1:20210522$ c### [at] t5pov
#version 3.8;
global_settings {assumed_gamma 1}
box {0,1}
#local Filename = "File99"
#macro Mcr00(_string, optional _filename)
#ifndef(local._filename)
#local _filename = "File00";
#end
#debug concat("00 File name: ",_filename," String: ",_string,"\n")
#end
#macro Mcr01(_string, optional _filename)
#ifndef(local._filename)
#local _filename = "File01";
#end
#debug concat("01 File name: ",_filename," String: ",_string,"\n")
#end
Mcr00("abc",Filename)
Mcr01("abc",Filename)
Mcr00("lmn",)
Mcr01("lmn",)
Mcr00("xyz",bad_name)
Mcr01("xyz",bad_name)
#error "Stop early"
jr@swift:2:20210522$ povparse t5.pov
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10064268.unofficial
...
==== [Parsing...] ==========================================================
00 File name: File99 String: abc
01 File name: File99 String: abc
00 File name: File00 String: lmn
01 File name: File01 String: lmn
00 File name: File00 String: xyz
01 File name: File01 String: xyz
File 't5.pov' line 31: Parse Error: Parse halted by #error directive: Stop early
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> I'm fuzzily thinking that maybe
> there's a way to disambiguate a 5D vector and a scalar by adding and/or
> multiplying with vectors containing different signs and testing the result?
>
> My brain is also giving me the impression that binary math and things like (I
> said _like_) bitmasks and xor might offer inspiration for a solution.
I got most of the way there by finally realizing that a scalar added to a 5D
vector adds the scalar to ALL of the vector components, whereas with a vector
added to a 5D vector, automatic vector expansion pads the smaller vector with
zeros, and then the corresponding components are added to each other.
The really tricky part I've mostly ironed out is differentiating scalar 0 and
the all-zero-vectors.
I had some real trouble getting it work for the 5D zero vector, but I made a
hack that seems to work. (See Vdiscrim calculation and D1 logic)
Maybe to be robust, there needs to be a walk up to 5D and then back down
again...
It's a little messy and complex, because I wrote it by feel and flashes of
inspiration rather than pure rigor, but it seems to work for most cases I've
plugged in.
Now, you know what to do: Take it and Break it.
Post a reply to this message
Attachments:
Download 'vector_size.pov.txt' (4 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> > I'm fuzzily thinking that maybe
> > there's a way to disambiguate a 5D vector and a scalar by adding and/or
> > multiplying with vectors containing different signs and testing the result?
> >
> > My brain is also giving me the impression that binary math and things like (I
> > said _like_) bitmasks and xor might offer inspiration for a solution.
>
> I got most of the way there by finally realizing that a scalar added to a 5D
> vector adds the scalar to ALL of the vector components, whereas with a vector
> added to a 5D vector, automatic vector expansion pads the smaller vector with
> zeros, and then the corresponding components are added to each other.
>
> The really tricky part I've mostly ironed out is differentiating scalar 0 and
> the all-zero-vectors.
>
> I had some real trouble getting it work for the 5D zero vector, but I made a
> hack that seems to work. (See Vdiscrim calculation and D1 logic)
> Maybe to be robust, there needs to be a walk up to 5D and then back down
> again...
>
>
> It's a little messy and complex, because I wrote it by feel and flashes of
> inspiration rather than pure rigor, but it seems to work for most cases I've
> plugged in.
>
> Now, you know what to do: Take it and Break it.
I followed your multiplication suggestion - and ended up with this, which after
some initial tests seems to work:
#macro VectorDim(v0)
#local vZ3D = <0, 0, 0>;
#local vZ4D = <0, 0, 0, 0>;
#local vZ5D = <0, 0, 0, 0, 0>;
#local v1 = v0 + 1;
#local v2 = v0 + 2;
#local v3 = (v0 + 1)*<1, 1>;
#local v4 = (v0*<1, 1>) + 1;
#local D2 = ((vZ3D + v1).z = (vZ3D + v2).z);
#local D3 = ((vZ4D + v1).t = (vZ4D + v2).t);
#local D4 = ((vZ5D + v1).transmit = (vZ5D + v2).transmit);
#local D5 = ((vZ3D + v3).z != (vZ3D + v4).z);
#if (D2)
#debug "2D"
#else
#if (D3)
#debug "3D"
#else
#if (D4)
#debug "4D"
#else
#if (D5)
#debug "5D"
#else
#debug "Scalar"
#end // if
#end // if
#end // if
#end // if
#end // VectorDim
#macro AltVectorDim(v0)
#local vZ3D = <0, 0, 0>;
#local vZ4D = <0, 0, 0, 0>;
#local vZ5D = <0, 0, 0, 0, 0>;
#local v1 = v0 + 1;
#local v2 = v0 + 2;
#local D2 = ((vZ3D + v1).z = (vZ3D + v2).z);
#local v3 = (v0 + 1)*<1, 1>;
#local v4 = (v0*<1, 1>) + 1;
#local D3 = ((vZ3D + v3).z != (vZ3D + v4).z);
#local D4 = ((vZ4D + v3).t != (vZ4D + v4).t);
#local D5 = ((vZ5D + v3).transmit != (vZ5D + v4).transmit);
#if (D5)
#debug "5D"
#else
#if (D4)
#debug "4D"
#else
#if (D3)
#debug "3D"
#else
#if (D2)
#debug "2D"
#else
#debug "Scalar"
#end // if
#end // if
#end // if
#end // if
#end // AltVectorDim
I'll have a look at the code you have made so far to see if we are on the same
track.
--
Tor Olav
http://subcube.com
https://github.com/t-o-k
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/22/21 12:13 PM, jr wrote:
> hi,
>
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
>
> may be I'm too dense, but what goes wrong at 'oops'? since 'Mcr00' only looks
> for 'Filename', which exists, it'll use that. and 'Wildname' isn't defined, so
> 'Mcr01' also appear (to me) to do the correct thing. did I misread yr point?
>
:-) Suppose, I think so. We want the #ifndef to only look at the tokens
passed on the macro call. The code can of course be correct, my point is
the option checking code can be wrong - thereby allowing definitions
into the macro by a path other than the call parameters/tokens.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/22/21 6:14 PM, Tor Olav Kristensen wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
...
>
> I'll have a look at the code you have made so far to see if we are on the same
> track.
>
...
FWIW. There is some type checking available via POV-Ray's fixed arrays.
For example, a method to keep all subsequent array types the same as the
first seen, when passed a mixed array, the Mean() macro would become:
#macro Mean(Values)
#local N = dimension_size(Values, 1);
// #local Sum = Values[0];
#local Sum = array[1]
#local Sum[0] = Values[0];
#for (I, 1, N - 1)
#local Sum[0] = Sum[0] + Values[I];
#end // for
(Sum[0]/N)
#end // macro Mean
On changes in type for the incoming mixed array 'Values' you'd get
messages like:
File 'dimsize.inc' line 52:
Parse Error:
Attempted to redefine float identifier as uv vector identifier.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > > I'm fuzzily thinking that maybe
> > > there's a way to disambiguate a 5D vector and a scalar by adding and/or
> > > multiplying with vectors containing different signs and testing the result?
> > >
> > > My brain is also giving me the impression that binary math and things like (I
> > > said _like_) bitmasks and xor might offer inspiration for a solution.
> >...
> >...
> > Now, you know what to do: Take it and Break it.
>
> I followed your multiplication suggestion - and ended up with this, which after
> some initial tests seems to work:
>...
Btw.: The Official Windows POV-Ray v3.7 says that 1e16 + 1 = 1e16.
Therefore I tested the macros I just posted with the scalar value 1e17, and they
both think that it is a 2D vector.
So these solutions are not numerical robust.
Perhaps we need an istype() function like jr suggested.
--
Tor Olav
http://subcube.com
https://github.com/t-o-k
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> Btw.: The Official Windows POV-Ray v3.7 says that 1e16 + 1 = 1e16.
>
> Therefore I tested the macros I just posted with the scalar value 1e17, and they
> both think that it is a 2D vector.
That's crazy.
There are MORE joys of floating point math? ;)
with qtpovray on Linux Mint, I get
1e15 + 1 = ScalarValue = 1000000000000001.000
1e15+1.1 = ScalarValue = 1000000000000001.125
1e16 + 1 = ScalarValue = 10000000000000000.000
1e16 +1.1 = 2D2D VECTOR = <10000000000000002.000, 0.000>
1e16 + 10 = 2D2D VECTOR = <10000000000000010.000, 0.000>
1e17 = 2D VECTOR = <100000000000000000.000, 0.000>
> So these solutions are not numerical robust.
Nope. But for smaller numbers and general usage they're better than what we
had.
> Perhaps we need an istype() function like jr suggested.
It would be great, especially since then we could type thing in CSV files as
they're being read in, and would need foreknowledge of the file structure.
Alternatively, we could use a trap() or OnError () function that allows
sequential rejection of blocks of code that would try to operate on the wrong
type until the code encountered a test that didn't throw an error.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
