William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/20/21 2:24 PM, Tor Olav Kristensen wrote:
> > Try this:
> >
> > #declare SomeVectors2D =
> >      array[5] {
> >          < 1,  5>,
> >          <-2, -2>,
> >          < 6,  3>,
> >          < 0,  2>,
> >          < 3, -1>
> >      }
> > ;
> > #declare vMean2D = Mean(SomeVectors2D);
>
> Ah, OK! I was thinking only in terms of sets of floats. Still arrays,
> but arrays of vectors.
>
> ---
> With the introduction of mixed arrays in v3.8, I guess, so long as we
> are willing to work in terms of the largest defined vector and take the
> unspecified components of shorter vectors as being zero, things will
> work out.
>
> There is an exposure if someone drops in a float in the wrong place. We
> get two different answers with a set up like the following where the
> Mean of the SomeVectorsA is OK if you take the float as being promoted
> to a 4 component vector, but that of SomeVectorsB is not because at the
> time of the addition the parser doesn't know the max vector size in the
> mixed array is four.
>
> #declare SomeVectorsA =
>      array mixed[5] {
>          < 1,  5>,
>          <-2, -2, 0, -1>,
>          < 6,  3>,
>          < 0,  2, 0, +2>,
>          0.123
>      }
> #declare SomeVectorsB =
>      array mixed[5] {
>          0.123
>          < 1,  5>,
>          <-2, -2, 0, -1>,
>          < 6,  3>,
>          < 0,  2, 0, +2>,
>      }
> ...
> Mean <1.0246,1.6246,0.0246,0.2246,0.0000> SomeVectorsA
> Mean <1.0246,1.6246,0.0000,0.2000,0.0000> SomeVectorsB
>
> Would it be enough to recommend against mixed array usage? Or might we
> test for mixed arrays in some way and stop, though, I have no idea how
> to do such a thing at the moment.
>
> Aside 1: If someone drops a non-numeric thing into a mixed array the
> parser appropriately generates an error.
>
> Aside 2: If someone uses color the length always goes to the full five
> color component vector. It's possible with colors to mix lengths of
> vector specification - even in the traditional non-mixed array case.
>
>      rgb 1,           // promoted to 1,1,1,0,0
>      color 1,         // warning. promoted to 1,1,1,1,1
>      rgb< 0,  2>,     // promoted to five components. Trailing 0s
>      rgb< 3, -1, 1>   // Same
>      rgb< 1, 2, 3, 4> // Warning and 4th component used. 5th 0.
>      rgbf<1, 2, 3, 4> // 4th used, no warning. 5th 0.
>
> Maybe behavior all just what it is - user beware?

When I see this I'm thinking that users that try to calculate the mean or
variance of an array containing mixed vectors deserves the messy result that
they may get.

My opinion is that POV-Rays automatic vector promotion is a design flaw. It
allows users to write code that is confusing and not so clear. And it creates
some hard to find errors.

Now I'm tempted to rewrite those macros so that they fail immediately if the
array contains anything else than floats. Perhaps it is best to not mention that
the mean() and variance() macros can be used with anything else than an array of
floats.

We can not, and should not, try to anticipate and warn/guard against all the
crazy things that users may do with macros. That would make them big, clumsy and
hard to read and understand.

If we keep the macros like they are now, then yes; we should have a user beware
warning.

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

Post a reply to this message