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

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/27/21 2:08 AM, jr wrote:
> > ...
> >> 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.

nice.


> ...
> > 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.

I put this badly.  meant that 'is_type()' probably "will do" for most use cases,
and so perhaps a complementary function (eg) 'is_type_details()' which returns
an array mixed, where the various flags are used to distinguish one ("390")
object from another.


> 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.

not sure I really understand.  if some macro expects an array mixed parameter,
say {3-vect, string, bool}, I do not know of a "safe" way to check all three.
for instance, whether I use 'strlen(string)' or similar, if it's not a string,
POV-Ray will "intervene".  (did I misread?)

(and the (snipped) macro examples too, while safe to use, would not allow me to
catch (as in handle with own error message) the eventual "odd" value, I think)


regards, jr.

Post a reply to this message

On 5/28/21 3:48 AM, jr wrote:
> hi,
> 
...
>> ...
>>> 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.
> 
> I put this badly.  meant that 'is_type()' probably "will do" for most use cases,
> and so perhaps a complementary function (eg) 'is_type_details()' which returns
> an array mixed, where the various flags are used to distinguish one ("390")
> object from another.
> 

Yes, is_type_details(), a possibility, but it would be work creeping 
well past "easy."

Aside: For the details which could be provided as strings of text as to 
type, my thought was this work would be pushed onto users - or some 
include file maintainer - in the form of a macro containing a big switch 
kicking out text or setting up an array with, say, response strings: 
"The is type passed to MagicMacro24 is a light_source."

> 
>> 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.
> 
> not sure I really understand.  if some macro expects an array mixed parameter,
> say {3-vect, string, bool}, I do not know of a "safe" way to check all three.
> for instance, whether I use 'strlen(string)' or similar, if it's not a string,
> POV-Ray will "intervene".  (did I misread?)
> 
> (and the (snipped) macro examples too, while safe to use, would not allow me to
> catch (as in handle with own error message) the eventual "odd" value, I think)
> 

You understood. What I coded up there is checking on the cheap; POV-Ray 
does it and the result is an internal parser error. What I had in mind 
for what I think you want to do - using id_type() - is something like 
the attached test case. Yes/No?

Bill P.

Post a reply to this message

Attachments:
Download 'utf-8' (3 KB)

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/28/21 3:48 AM, jr wrote:
> >> ...
> >> 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.
> >
> > I put this badly.  meant that 'is_type()' probably "will do" for most use cases,
> > and so perhaps a complementary function (eg) 'is_type_details()' which returns
> > an array mixed, where the various flags are used to distinguish one ("390")
> > object from another.
> >
>
> Yes, is_type_details(), a possibility, but it would be work creeping
> well past "easy."
>
> Aside: For the details which could be provided as strings of text as to
> type, my thought was this work would be pushed onto users - or some
> include file maintainer - in the form of a macro containing a big switch
> kicking out text or setting up an array with, say, response strings:
> "The is type passed to MagicMacro24 is a light_source."

I was about to suggest (almost) the opposite.  :-)

thinking that if one (you :-)) were to set up an enum, covering the basics
(float, bool, vector, macro, function, array, string, such[*]), then changing
(in the parser, between versions) ids could be "contained" in one mapping.  then
'is_type()', and later perhaps its companion func, would always provide
consistent "numbers".  and yes, some include file to turn the numbers back into
human speak would be v useful (will collaborate if thought helpful).

[*] off the top of my head.  in most ("95%") situations, I think, just knowing
it's "an array", say, without the "fall out" from using 'dimensions(foo)' when
it isn't, will suffice.


> ...
> > (and the (snipped) macro examples too, while safe to use, would not allow me to
> > catch (as in handle with own error message) the eventual "odd" value, I think)
>
> You understood. What I coded up there is checking on the cheap; POV-Ray
> does it and the result is an internal parser error. What I had in mind
> for what I think you want to do - using id_type() - is something like
> the attached test case. Yes/No?

thanks.  will look at code tonight/tomorrow.


regards, jr.

Post a reply to this message

On 5/28/21 8:23 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 5/28/21 3:48 AM, jr wrote:
>>>> ...
>>>> 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.
>>>
>>> I put this badly.  meant that 'is_type()' probably "will do" for most use cases,
>>> and so perhaps a complementary function (eg) 'is_type_details()' which returns
>>> an array mixed, where the various flags are used to distinguish one ("390")
>>> object from another.
>>>
>>
>> Yes, is_type_details(), a possibility, but it would be work creeping
>> well past "easy."
>>
>> Aside: For the details which could be provided as strings of text as to
>> type, my thought was this work would be pushed onto users - or some
>> include file maintainer - in the form of a macro containing a big switch
>> kicking out text or setting up an array with, say, response strings:
>> "The is type passed to MagicMacro24 is a light_source."
> 
> I was about to suggest (almost) the opposite.  :-)
> 
> thinking that if one (you :-)) were to set up an enum, covering the basics
> (float, bool, vector, macro, function, array, string, such[*]), then changing
> (in the parser, between versions) ids could be "contained" in one mapping.  then
> 'is_type()', and later perhaps its companion func, would always provide
> consistent "numbers".  and yes, some include file to turn the numbers back into
> human speak would be v useful (will collaborate if thought helpful).
> 

Suppose it could be done by running a script to build such a cross index 
as a check in hook or something.

There is today a basic enum to cross reference in the code that gets 
used when reporting messages and such. We're basically talking about 
some parallel ID enum to locked integer index I guess - which 
is_type_details() or similar could use... I'll think about it, but at 
the moment it all feels a bit clunky /ugly given the minor value to end 
users.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/28/21 8:23 AM, jr wrote:
> > ...
> > thinking that if one (you :-)) were to set up an enum, ...
> Suppose it could be done by running a script to build such a cross index
> as a check in hook or something.
>
> There is today a basic enum to cross reference in the code that gets
> used when reporting messages and such. ...

if that implies that the enumeration is sort of stable, perhaps it can be
"pressed into service"?

re the 'is_type()' code -- SDL user me says "Yes".  :-)  fwiw, I like this:

  #if (id_type(_mary[1]) != Mcr_id_type("Star dust falls"))

"idiom" a lot.

(also made me wonder what was playing on your radio while you wrote that code.
UFO's "Prince Kajuku"??  "Catch a falling star put it in your pocket..."
<https://www.youtube.com/watch?v=KSBIDIZ6ySc> :-))


regards, jr.

Post a reply to this message

On 5/29/21 2:53 AM, jr wrote:
> if that implies that the enumeration is sort of stable, perhaps it can be
> "pressed into service"?

It is in service with is_type(), but is itself not stable as keywords 
and keyword groupings change. Could an 'intended stable' form be created 
/ maintained - sure. Is it worth the trouble - ehhh...

> 
> re the 'is_type()' code -- SDL user me says "Yes".:-)   fwiw, I like this:
> 
>    #if (id_type(_mary[1]) != Mcr_id_type("Star dust falls"))
> 
> "idiom" a lot.
> 
> (also made me wonder what was playing on your radio while you wrote that code.
> UFO's "Prince Kajuku"??  "Catch a falling star put it in your pocket..."

References to 'radio' will lead the kids reading to think we're ancient. 
The youtube link was perhaps enough to fool em - that we're playing with 
POV-Ray won't help. ;-)

As for what's playing in my head... A storm, always about three beats 
from incoherence. When I listen to music while coding, it's 
meaningful-vocal-less. Thinking, reading, coding in a public place where 
the sounds are a vibration, where only an occasional word or two pops to 
the surface, is best.

Anyhow. Let me know when I've gone over the edge - another one. I'm 
still upright - I think.

Bill P.

Post a reply to this message

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

> References to 'radio' will lead the kids reading to think we're ancient.

Just call it "wireless".  A term so old, its new again.


> The youtube link was perhaps enough to fool em - that we're playing with
> POV-Ray won't help. ;-)

"More than just a pixel shader...."


> Anyhow. Let me know when I've gone over the edge - another one.

Don't call them "edges" - call them "new frontiers".

Post a reply to this message

On 5/29/21 8:03 AM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> References to 'radio' will lead the kids reading to think we're ancient.
> 
> Just call it "wireless".  A term so old, its new again.
> 
...

Ah! We just have to apply enough spin... :-)

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/29/21 2:53 AM, jr wrote:
> > if that implies that the enumeration is sort of stable, perhaps it can be
> > "pressed into service"?
>
> It is in service with is_type(), but is itself not stable as keywords
> and keyword groupings change. Could an 'intended stable' form be created
> / maintained - sure. Is it worth the trouble - ehhh...

so.  an include with one macro and version specific data, then?


> ...
> As for what's playing in my head... A storm, always about three beats
> from incoherence. When I listen to music while coding, it's
> meaningful-vocal-less. Thinking, reading, coding in a public place where
> the sounds are a vibration, where only an occasional word or two pops to
> the surface, is best.

:-)  recognise the preference (?) for instrumentals.  (cannot usually relax
enough in a public place to .. let my mind wander)


regards, jr.

Post a reply to this message

On 5/29/21 11:43 AM, jr wrote:
> so.  an include with one macro and version specific data, then?

Yeah, one could have a  macro - include which sets up an array of the 
values as they sit each version of code . Basically a bunch of calls to:

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

setting up an array (or dictionary) which you'd then reference in 
compares to id_type() instead of calls to Mcr_id_type().

Bill P.

Post a reply to this message