POV-Ray : Newsgroups : povray.general : Github repository with useful macros Server Time
21 May 2025 05:15:21 EDT (-0400)
  Github repository with useful macros (Message 24 to 33 of 43)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
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

From: Bald Eagle
Subject: Re: Github repository with useful macros
Date: 22 May 2021 20:05:00
Message: <web.60a99b83985098ff1f9dae3025979125@news.povray.org>
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

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

That's crazy.

There are MORE joys of floating point math?  ;)


with qtpovray on Linux Mint, I get
1e15 + 1 = ScalarValue = 1000000000000001.000
1e15+1.1 = ScalarValue = 1000000000000001.125
1e16 + 1 = ScalarValue = 10000000000000000.000
1e16 +1.1 = 2D2D VECTOR = <10000000000000002.000, 0.000>
1e16 + 10 = 2D2D VECTOR = <10000000000000010.000, 0.000>
1e17 = 2D VECTOR = <100000000000000000.000, 0.000>

> So these solutions are not numerical robust.

Nope.   But for smaller numbers and general usage they're better than what we
had.

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

Alternatively, we could use a trap() or OnError () function that allows
sequential rejection of blocks of code that would try to operate on the wrong
type until the code encountered a test that didn't throw an error.


Post a reply to this message

From: jr
Subject: Re: Github repository with useful macros
Date: 22 May 2021 20:35:00
Message: <web.60a9a222985098ff79819d986cde94f1@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/22/21 12:13 PM, jr wrote:
>> ...  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 documentation is pretty .. explicit on optional macro args and "reliable"
testing requiring 'local.' (dictionary) -- highlighted box.


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

I was surprised to see there's a way to "smuggle" an undeclared identifier into
a macro, but yeah, "caveat emptor", as BE might say.  :-)


regards, jr.


Post a reply to this message

From: William F Pokorny
Subject: Re: Github repository with useful macros
Date: 23 May 2021 09:04:50
Message: <60aa52f2$1@news.povray.org>
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.
> 
> Alternatively, we could use a trap() or OnError () function that allows
> sequential rejection of blocks of code that would try to operate on the wrong
> type until the code encountered a test that didn't throw an error.
> 

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.

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?

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.


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.