 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
hi,
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmail com> wrote:
> "Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> > "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmail com> 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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
hi,
William F Pokorny <ano### [at] anonymous org> 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] t5 pov
#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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Bald Eagle" <cre### [at] netscape net> 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)
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Bald Eagle" <cre### [at] netscape net> wrote:
> "Bald Eagle" <cre### [at] netscape net> 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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 5/22/21 12:13 PM, jr wrote:
> hi,
>
> William F Pokorny <ano### [at] anonymous org> 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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 5/22/21 6:14 PM, Tor Olav Kristensen wrote:
> "Bald Eagle" <cre### [at] netscape net> 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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmail com> wrote:
> "Bald Eagle" <cre### [at] netscape net> wrote:
> > "Bald Eagle" <cre### [at] netscape net> 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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmail com> 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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
hi,
William F Pokorny <ano### [at] anonymous org> 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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|
 |