POV-Ray : Newsgroups : povray.general : Github repository with useful macros Server Time
20 May 2025 23:52:28 EDT (-0400)
  Github repository with useful macros (Message 34 to 43 of 43)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Bald Eagle
Subject: Re: Github repository with useful macros
Date: 23 May 2021 10:35:00
Message: <web.60aa6759985098ff1f9dae3025979125@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

> I didn't want to think about this having already
> quite a mess in my head, but my head has.

<Mr Smithers>   Exxxxxxxcellent...  </Mr Smithers>

Welcome to my daily reality.

> I think something like idtypesmatch() might be relatively simple(1).
> You'd set an id to a reference thing. Then compare other IDs against
> that reference by internal type. The function would return 0 or 1.
> Useful enough?

Yes.

And then it would be easy enough to write a macro that gets called and tests
what that thing is, to address your later concerns.
If I can do #read (OpenFile, Thing) and then find out what Thing is before I
further process it, then that's perfect.


Post a reply to this message

From: jr
Subject: Re: Github repository with useful macros
Date: 23 May 2021 10:45:00
Message: <web.60aa6948985098ff79819d986cde94f1@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/22/21 8:02 PM, Bald Eagle wrote:
> >> 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.
> > ...
> Somewhere in this thread jr had a feeling istype() wouldn't be too
> difficult to implement. I didn't want to think about this having already
> quite a mess in my head, but my head has.

back when I used to be real good at giving people headaches.  ;-)


> I think something like idtypesmatch() might be relatively simple(1).
> You'd set an id to a reference thing. Then compare other IDs against
> that reference by internal type. The function would return 0 or 1.
> Useful enough?

sounds good, having a design that returns a bool is v elegant.  and should work
well, eg, when writing a macro for "public consumption" since I could provide
what (argument type) I look for and compare it to the parameter supplied.

(there's lots I'm not clear on, say, 'array [2][2][2]' would compare equal to
any size 3D array of same float/vect/whatever, and such, but like the
design/idea)


> Once into something like istype(), we at a minimum need to make all the
> types of interest accessible by name in the SDL. Internally there are
> type classes - 'someKindaVector' and so on which would likely be useful
> to have defined too. The implementation complexity rapidly increases, if
> you want to set up or store types for later work in a parser aware way,
> define types priori, ...
>
> Bill P.
>
> (1) - Less controlled variations could store values of types via say
> typevalueof() in float capable 'storage-types' for later float to float
> compares. Note. The type enums within the parser are not constant, but
> change as the parser keywords change. Meaning one would always have to
> run typevalueof() against reference 'things' to get the POV-Ray
> version's baseline type values against which to compare other things.

had not envisaged anything as sophisticated.  thought if 'istype()' returned an
integer value corresponding to type[*] of "foo", and the documentation has a
(lengthy) table with suggestive but not used symbolic names (derived from the
underlying enum) and their numeric values.  anyway, past.  :-)

[*] coded presumably to keep the actual number of "types" down.


regards, jr.


Post a reply to this message

From: Thomas de Groot
Subject: Re: Github repository with useful macros
Date: 23 May 2021 10:51:52
Message: <60aa6c08$1@news.povray.org>
Op 23-5-2021 om 16:31 schreef Bald Eagle:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> I didn't want to think about this having already
>> quite a mess in my head, but my head has.
> 
> <Mr Smithers>   Exxxxxxxcellent...  </Mr Smithers>
> 
> Welcome to my daily reality.
> 
Been there...

-- 
Thomas


Post a reply to this message

From: clipka
Subject: Re: Github repository with useful macros
Date: 26 May 2021 18:11:52
Message: <60aec7a8$1@news.povray.org>
Am 21.05.2021 um 23:31 schrieb Tor Olav Kristensen:

> I take it that you would like to be able write things like cos(v0) and then the
> cos function will be applied to all of the components of the vector. If so I
> second that. But only if that if is done with a built in functionality. I don't
> like the macro's we currently have in the include files for such things.

Yeah, no. I don't think that's going to happen. Not as a generic syntax. 
Not within the lifespan of this parser, anyway.


Post a reply to this message

From: clipka
Subject: Re: Github repository with useful macros
Date: 26 May 2021 18:53:27
Message: <60aed167$1@news.povray.org>
Am 22.05.2021 um 13:33 schrieb jr:

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

"Pfffffffaaaaaaaaaaaaahahahahaha! BWAAAAHAHAHAHAHAHA!"
(*manic laughter*)
-- Anonymous developer.


Keeping track of the type of things IN THE PARSER ITSELF is painful 
enough... add to that the trouble of coming up with a nice elegant 
syntax, questions such as whether this should work only on variables, or 
also literals or even complex expressions...

... oh, and then add to the mix that the parser doesn't go, "ah, let me 
evaluate and see what the result of this expression is", but rather "ah, 
I expect this particular type here; let me see how the following makes 
any sense under that presumption"...

... ah, and let's not forget arrays. Arrays and array elements are fun. 
Hooray for how the parser handles arrays, and their elements. Yaaaaaay...


Yeah. Multiple cans of worms.


Post a reply to this message

From: Bald Eagle
Subject: Re: Github repository with useful macros
Date: 26 May 2021 20:50:00
Message: <web.60aeeba5985098ff1f9dae3025979125@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:


> ... ah, and let's not forget arrays. Arrays and array elements are fun.
> Hooray for how the parser handles arrays, and their elements. Yaaaaaay...

He's BA-aaaaaaaaaaaaaaaaaaaaack!!!




OK, although I thought at first it might be a girl, I must admit that my next
guess was that it was the parser.  I sat here, sipping my gin & tonic, slowly
shaking my head in sadness...  "That poor boy.  It had to be the parser.   He
shouldn't have gone and fiddled with it like that.  It's too dangerous.
Everyone knows that.  Others have tried - and failed.  That damned parser ... it
finally broke him...."





"I mean that, for nearly 20 years developers have been searching through this
vast parser.  It's not something to be taken lightly.  No one knows its secrets.
 It's like nothing he's ever gone after before..."


Post a reply to this message

From: clipka
Subject: Re: Github repository with useful macros
Date: 26 May 2021 21:02:38
Message: <60aeefae$1@news.povray.org>
Am 27.05.2021 um 02:45 schrieb Bald Eagle:

> OK, although I thought at first it might be a girl, I must admit that my next
> guess was that it was the parser.  I sat here, sipping my gin & tonic, slowly
> shaking my head in sadness...  "That poor boy.  It had to be the parser.   He
> shouldn't have gone and fiddled with it like that.  It's too dangerous.
> Everyone knows that.  Others have tried - and failed.  That damned parser ... it
> finally broke him...."

Dang, how am I supposed to cry myself to sleep after reading THAT ;)


Post a reply to this message

From: jr
Subject: Re: Github repository with useful macros
Date: 27 May 2021 02:30:00
Message: <web.60af3bbd985098ff79819d986cde94f1@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> Am 22.05.2021 um 13:33 schrieb jr:
>
> > 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)
>
> "Pfffffffaaaaaaaaaaaaahahahahaha! BWAAAAHAHAHAHAHAHA!"
> (*manic laughter*)
> -- Anonymous developer.
>
> Keeping track of the type of things IN THE PARSER ITSELF is painful
> enough... add to that the trouble of coming up with a nice elegant
> syntax, questions such as whether this should work only on variables, or
> also literals or even complex expressions...
>
> ... oh, and then add to the mix that the parser doesn't go, "ah, let me
> evaluate and see what the result of this expression is", but rather "ah,
> I expect this particular type here; let me see how the following makes
> any sense under that presumption"...
> ...

and yet, WFP's current 'is_type()' is an excellent start on all that.  the thing
is that _any_ "introspection" support in SDL would be a step forward.


regards, jr.


Post a reply to this message

From: Bald Eagle
Subject: Re: Github repository with useful macros
Date: 17 May 2025 20:15:00
Message: <web.68292612985098ff1f9dae3025979125@news.povray.org>
I had occasion to revisit this, as I wanted to determine the "size" of a vector,
because having separate macros to compare vectors is ridiculous.

The way that POV-Ray promotes vectors and does scalar+vector addition seemed to
frustrate things.  But since the parser "knows" things about the values that
we're using, I was wondering if I could use some of that occult knowledge and
somehow distinguish between scalar and vector values.

trying to write efficient code led me to discover that you can write rgb 3

but if I: store 3 in an array and then try to write rgb Array[0]
or try rgbf, rgbt, or rgbft 3
I get: "Parse Error: Attempted to redfine float identifier as colour
identifier."

But we CAN write rgb 3, which gets promoted to <3, 3, 3, 0, 0>
Whereas actual vectors just get padded with zeros, unless it's a 5D vector.

So we can check if rgb v0 has x=y=z, and also check if
the transmit value of rgb v0 = v0 + <0, 0, 0, 0, 0>

Because if v0 is non-zero, then the former will be 0, and the latter will be v0.

Perhaps there is more that we can do in the same vein.

Developmental scene is attached.


"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

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

//#declare Vector = array mixed {pi, <1, 2>, <1, 2, 3>, <1, 2, 3, 4>, <1, 2, 3,
4, 5>}
//#declare Vector = array mixed {rgb pi, rgb <1, 2>, rgb <1, 2, 3>, rgb<1, 2, 3,
4>, rgb <1, 2, 3, 4, 5>}
#declare Vector = array mixed {
 rgb pi, rgb pi + 1, rgb pi + 2,
 rgb <1, 2>, rgb <1, 2>+1, rgb <1, 2>+2,
 rgb <1, 2, 3>, rgb <1, 2, 3>+1, rgb <1, 2, 3>+2,
 rgb<1, 2, 3, 4>, rgb<1, 2, 3, 4>+1, rgb<1, 2, 3, 4>+2,
 rgb <1, 2, 3, 4, 5>, rgb <1, 2, 3, 4, 5>+1, rgb <1, 2, 3, 4, 5>+2
}
//#declare Vector = array mixed {<0, 0>+1, <0, 0>+2, <0, 0, 0>+1, <0, 0, 0>+2,
<0, 0, 0, 0>+1, <0, 0, 0, 0>+2, <0, 0, 0, 0, 0>+1, <0, 0, 0, 0, 0>+2}

#declare VN = dimension_size (Vector, 1)-1;

#for (V, 0, VN)
 //#debug concat ("Vector = <", vstr(1+ceil((V+1)/2), Vector [V], ", ", 0, 0),
">           ")
 #debug concat ("Vector = <", vstr(5, Vector [V], ", ", 0, 0), ">           ")
 VectorDimTest(Vector [V])
 #debug "\n"
 #if (mod(V+1,3)=0)
  #debug "\n"
 #end
#end

#debug "\n"
#debug "\n"
#debug "\n"


Post a reply to this message


Attachments:
Download 'vectoroperations.pov.txt' (3 KB)

From: Bald Eagle
Subject: Re: Github repository with useful macros
Date: 19 May 2025 19:50:00
Message: <web.682bc388985098ff1f9dae3025979125@news.povray.org>
I do believe I have cracked the code!
I made a big spreadsheet to get a better overview of everything that was
happening with additions and automatic vector promotion.

It took me a while to get a good feel for what was possible, and what was just
going around in circles.
I was also concerned about all zero values being a special case.

Then I got some inspiration for leveraging the "asymmetry" afforded by the rgb
keyword.  Squaring v0 gives me all-positive values, so when I add 1 to the
result, I'm not losing the result I want when v0 is some form of -1.
Then I add the rgb conversion of that value, and that lets me differentiate
between scalars and all sizes of vectors.

I started making a huge list of test values, but I'm sure there's a better way
to automate the generation of 1D-5D values with all possible combinations of -,
0, +.

At the moment, I haven't run across any values that get improperly identified.
I separately list all vector components to show that accessing the individual
dot-notation components doesn't raise a "Bad operands for period operator"
error.

(I tried to use -GW or Warning_Console=Off, but the "Suspicious expression after
rgb" error doesn't get suppressed)

Check it out.
Hammer on it.
Try to break it.

- Bald "Nothing is Impossible!" Eagle


Post a reply to this message


Attachments:
Download 'vectoroperations.pov.txt' (4 KB)

<<< Previous 10 Messages Goto Initial 10 Messages

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