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