In povray.general we recently discussed implementing some limited type 
checking. Attached is an include files showing testing for two new 
keywords in the povr branch called id_type() and id_types_match().

Note. Though the id values often change from release to release I found 
an id_type() works in a switch statement making the id_type() worthwhile 
too, I thought.

//---
#include "id_types.inc"

Mcr_ID_type(ID_type_float)
Mcr_ID_type(ID_type_string)
Mcr_ID_type("Hello")

Mcr_ID_type_test()

#error "\nTesting. Stop early\n"
//---

An excerpt of the output follows showing the current povr values for 
certain types. Notably the parser treats some things we might think of 
as separate as the same internal ID.
---
float       = 27.0
string      = 527.0
vector2D    = 584.0
vector3D    = 71.0
vector4D    = 592.0
vector5D    = 95.0
dictionary  = 209.0
array       = 121.0
array_mixed = 121.0
sphere      = 390.0
box         = 390.0
object      = 390.0
merge       = 390.0
union       = 390.0
color       = 95.0
finish      = 247.0
normal      = 381.0
pigment     = 420.0
texture     = 542.0
---

Bill P.

Post a reply to this message

Attachments:
Download 'id_types.inc.txt' (5 KB)

in news:60abd77d$1@news.povray.org William F Pokorny wrote:

> id_type() and id_types_match()

Very useful. Thanks,

Ingo

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> In povray.general we recently discussed implementing some limited type
> checking. Attached is an include files showing testing for two new
> keywords in the povr branch called id_type() and id_types_match().
>
> Note. Though the id values often change from release to release I found
> an id_type() works in a switch statement making the id_type() worthwhile
> too, I thought.

Nice !

Can it also be used with different functions types, splines, matrices,
transforms, materials, file descriptors, light sources, cameras, color maps, and
other maps ?

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

Post a reply to this message

On 5/24/21 2:17 PM, Tor Olav Kristensen wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> In povray.general we recently discussed implementing some limited type
>> checking. Attached is an include files showing testing for two new
>> keywords in the povr branch called id_type() and id_types_match().
>>
>> Note. Though the id values often change from release to release I found
>> an id_type() works in a switch statement making the id_type() worthwhile
>> too, I thought.
> 
...
> Can it also be used with different functions types, splines, matrices,
> transforms, materials, file descriptors, light sources, cameras, color maps, and
> other maps ?
> 

Played with these more tonight and I'm now leaning toward dropping 
id_types_match(). As with most things the more I played the more the 
hidden gotchas popped out, and the more complex the code got.

Answers to your category/type questions are mostly yes. Functions come 
in two types depending on whether they return doubles or vectors. Light 
sources I've not tested as yet, but I think those have always been 
considered objects and so will likely get lumped with spheres et al(1).

In some oddness, there is a MACRO_ID_TOKEN, but it's impossible to 
evaluate macro names because once they exist the parser attempts to run 
them. I don't see a way to work around it - excepting maybe via some 
very messy methods.

Bill P.

(1) - It's only code, as an old friend used to say to my enhancement 
requests. :-) Likely some way to tell the object is really a light and 
we could then set some bogus, large value maybe - or negative values. 
There are, I know, some object type 'flags' that get set when objects 
are created. We'll see.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:

this looks v promising.  am  a little confused by the sample output posted,
expected, for example, the four vector types to have (somewhat) related ids.

> ...
> In some oddness, there is a MACRO_ID_TOKEN, but it's impossible to
> evaluate macro names because once they exist the parser attempts to run
> them. I don't see a way to work around it - excepting maybe via some
> very messy methods.

testing via 'defined(macroname)'?  (not tried it with macroname as string, but
maybe Parse_String could help then).


regards, jr.

Post a reply to this message

On 5/25/21 4:40 AM, jr wrote:
> this looks v promising.  am  a little confused by the sample output posted,
> expected, for example, the four vector types to have (somewhat) related ids.
> 

This is partly because internally the vector types are:

UV_ID_TOKEN, VECTOR_ID_TOKEN, VECTOR_4D_ID_TOKEN and COLOUR_ID_TOKEN.

The token enums are also sometimes also ordered into sections - 
internally called catagories. The VECTOR_ID_TOKEN is in a vector 
category grouping while the others are not for other reasons of parsing 
code I guess. The COLOUR_ID_TOKEN is exempt from the color category too(1).

I think it's because there is, for example, color/colour keywords and so 
to color IDs. I don't think there is a 'vector' keyword, so vector ids 
can be lumped with other generic vector stuff like vcross.

I'm not completely sure of all of it, there isn't a uv keyword, but 
maybe because we have uv_vectors? I don't know.

>> ...
>> In some oddness, there is a MACRO_ID_TOKEN, but it's impossible to
>> evaluate macro names because once they exist the parser attempts to run
>> them. I don't see a way to work around it - excepting maybe via some
>> very messy methods.
...
> testing via 'defined(macroname)'?  (not tried it with macroname as string, but
> maybe Parse_String could help then).

I found a solution using the new to v3.8 global dictionary. You have to 
code macros with the 'global.' prefix...

Supposing I have a macro wrapping id_type():

#macro Mcr_id_type(_id)
     id_type(_id)
#end

so I can create IDs on the fly as in:

#debug concat("float id = ",str(Mcr_id_type(1.2*(1/3)),4,1),"\n")

I can then grab the Mcr_id_type macro's id type number with:

#debug concat("macro = ",str(id_type(global.Mcr_id_type),4,1),"\n")

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> I found a solution using the new to v3.8 global dictionary. You have to
> code macros with the 'global.' prefix...
>
> Supposing I have a macro wrapping id_type():
>
> #macro Mcr_id_type(_id)
>      id_type(_id)
> #end
>
> so I can create IDs on the fly as in:
>
> #debug concat("float id = ",str(Mcr_id_type(1.2*(1/3)),4,1),"\n")
>
> I can then grab the Mcr_id_type macro's id type number with:
>
> #debug concat("macro = ",str(id_type(global.Mcr_id_type),4,1),"\n")

neat.  (lucky there's a non-"messy" way :-))  question: does 'id_type()' rely on
any 'povr' branch only features, or could it be implemented as-easily in POV-Ray
too?  (and if yes, when??  :-))


regards, jr.

Post a reply to this message

On 5/25/21 8:40 AM, jr wrote:
> could it be implemented as-easily in POV-Ray
> too?

You, and that concept of easy... ;-) As implemented it's a stand alone 
bit of code.

Aside: I did manage to use some of the object flags to break out 
light_sources, csg (merge,union,difference,intersection), light unions 
and light groups from the object id category. The id sub-catagories Left 
in as probably more useful than not, but there is the nagging thought it 
might somewhere be the wrong thing to do.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/25/21 8:40 AM, jr wrote:
> > could it be implemented as-easily in POV-Ray
> > too?
>
> You, and that concept of easy... ;-)

my ignorance wrt POV-Ray source stands me in good stead..  :-)


> As implemented it's a stand alone bit of code.

that is good.  (afaict)  so it could be issued as a patch to the 3.8.0-alpha?


> Aside: I did manage to use some of the object flags to break out
> light_sources, csg (merge,union,difference,intersection), light unions
> and light groups from the object id category. The id sub-catagories Left
> in as probably more useful than not, but there is the nagging thought it
> might somewhere be the wrong thing to do.

forgot to thank you for the vector id background info.  read in conjunction with
the above, I'm thinking a two function approach perhaps, 'id_type' much as is,
supported by a similar function which returns an 'array mixed' with the various
"properties"/categories broken out?


regards, jr.

Post a reply to this message

On 5/27/21 2:08 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 5/25/21 8:40 AM, jr wrote:
>>> could it be implemented as-easily in POV-Ray
>>> too?
>>
>> You, and that concept of easy... ;-)
> 
> my ignorance wrt POV-Ray source stands me in good stead..  :-)

:-) Me alongside. Nobody understands the whole of the code base.

> 
> 
>> As implemented it's a stand alone bit of code.
> 
> that is good.  (afaict)  so it could be issued as a patch to the 3.8.0-alpha?
> 

Could be. Yes.

> 
>> Aside: I did manage to use some of the object flags to break out
>> light_sources, csg (merge,union,difference,intersection), light unions
>> and light groups from the object id category. The id sub-catagories Left
>> in as probably more useful than not, but there is the nagging thought it
>> might somewhere be the wrong thing to do.
> 
> forgot to thank you for the vector id background info.  read in conjunction with
> the above, I'm thinking a two function approach perhaps, 'id_type' much as is,
> supported by a similar function which returns an 'array mixed' with the various
> "properties"/categories broken out?
> 

What I've not done for arrays vs mixed arrays as yet is look for a 
method 'like' that employed to break out a few of the object types like 
light sources(1). The object flags popped into my head on Tor Olav's 
question.

Even without getting different type ids for arrays vs mixed arrays today 
from id_type, you can walk a mixed array asking about the types for each 
element and in that way via SDL looping (or your foreach work) build up 
what types in total are seen for any given the mixed array.

(1) - Strictly, the information isn't needed for code safety sake. We 
can today (v3.8) employ the back door type checking I mentioned 
'somewhere' to be sure types coming in via mixed arrays are consistent - 
when then need to be. I used the technique while adopting Tor Olav's 
array statics macro suggestions. Let me see, as two examples, I used the 
trick with his Mean and Minimum macros which now look like:

#macro Mean(Values)

     #local N = dimension_size(Values, 1);
     #local Sum = array[1] // Fixed array types cannot change.
     #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

#macro Minimum(Values)

     #local N = dimension_size(Values, 1);
     #local Min = array[2] {1,1} // Fixed array types cannot change.
     #local Min[0] = Values[0];  // Better err msg - min() floats only.
     #for (I, 1, N - 1)
         #local Min[1] = Values[I]; // Better err msg.
         #local Min[0] = min(Min[0], Min[1]);
     #end // for

     Min[0]

#end // macro Minimu

Bill P.

Post a reply to this message