POV-Ray : Newsgroups : povray.general : Github repository with useful macros Server Time
21 Apr 2024 06:58:11 EDT (-0400)
  Github repository with useful macros (Message 21 to 30 of 41)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Tor Olav Kristensen
Subject: Re: Github repository with useful macros
Date: 22 May 2021 05:40:00
Message: <web.60a8cfb8985098ff8e52cc8789db30a9@news.povray.org>
"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, this macro tests to see
> whether or not v_Padding has a .t component.  This macro is ad hoc, but perhaps
> a more general macro can be written.  I have not found a way to distinguish
> between a scalar and a macro, though.
>
> ----------[BEGIN CODE]---------
> // Convert input to a 4-D vector.  If the input is a 2-D or 3-D vector, then
> // use the .y component for .t.
> #macro Caption__Get_padding (v_Padding)
>   #local caption_Promoted = <0, 0, 0, 0> + v_Padding;
>
>  // See whether .t exists:
>   #local caption_Test1 = v_Padding + 1;
>   #local caption_Test2 = v_Padding + 2;
>
>   < caption_Promoted.x,
>     caption_Promoted.y,
>     caption_Promoted.z,
>    // Test whether .t exists:
>     ( (<0, 0, 0, 0> + caption_Test1).t = (<0, 0, 0, 0> + caption_Test2).t?
>       caption_Promoted.y: caption_Promoted.t
>     )
>     // N.B.  Although a scalar tests incorrectly as having a .t component, it
>     // doesn't matter, because the returned 4-D vector is the same either way.
>   >
> #end
> -----------[END CODE]----------

Hi Ricky

It took me a while to figure out what is going on there.
You are exploiting the automatic vector promoting "feature".
That's clever sorcery !

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


--
Tor Olav
http://subcube.com
https://github.com/t-o-k


Post a reply to this message

From: William F Pokorny
Subject: Re: Github repository with useful macros
Date: 22 May 2021 05:49:30
Message: <60a8d3aa$1@news.povray.org>
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

From: Bald Eagle
Subject: Re: Github repository with useful macros
Date: 22 May 2021 07:30:00
Message: <web.60a8ea5f985098ff1f9dae3025979125@news.povray.org>
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> 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

From: jr
Subject: Re: Github repository with useful macros
Date: 22 May 2021 07:35:00
Message: <web.60a8ebf0985098ff79819d986cde94f1@news.povray.org>
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

From: jr
Subject: Re: Github repository with useful macros
Date: 22 May 2021 12:15:00
Message: <web.60a92d96985098ff79819d986cde94f1@news.povray.org>
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

From: Bald Eagle
Subject: Re: Github repository with useful macros
Date: 22 May 2021 18:05:00
Message: <web.60a97f73985098ff1f9dae3025979125@news.povray.org>
"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)

From: Tor Olav Kristensen
Subject: Re: Github repository with useful macros
Date: 22 May 2021 18:15:00
Message: <web.60a98210985098ffdd9d48c789db30a9@news.povray.org>
"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

From: William F Pokorny
Subject: Re: Github repository with useful macros
Date: 22 May 2021 19:26:08
Message: <60a99310$1@news.povray.org>
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

From: William F Pokorny
Subject: Re: Github repository with useful macros
Date: 22 May 2021 19:26:26
Message: <60a99322$1@news.povray.org>
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

From: Tor Olav Kristensen
Subject: Re: Github repository with useful macros
Date: 22 May 2021 19:45:00
Message: <web.60a9970d985098ff8e52cc8789db30a9@news.povray.org>
"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

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.