"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
>
> > 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.
>
> I would agree that some features are more problematic than others, especially
> for newer users.   Is there a way to add, multiply, or test for [nonexistant]
> vector components with dot-notation in order to purposefully invoke the vector
> promotion and force everything to me the largest vector size (5?) from the
> start?

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 would have been nice to have some functionality like with Python's
try-except-else-finally statements.

But I assume that that would be a huge task to undertake in POV-Ray. So perhaps
we could implement something like #ifdef (v0.z) instead.


> [Just as a related aside, what would be useful is a way to perform typical
> mathematical functions like cosine on vectors and get a vector result.]

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.


To see how I've provided a similar functionality in my scikit-vectors Python
library:

- Look at the cells 'In [26]' and 'Out[26]' in this file:
https://github.com/t-o-k/scikit-vectors/blob/master/skvectors/doc/Using_a_Vector_Class.pdf

- and at the cells from 'In [48]' to 'Out[52]' in this file:
https://github.com/t-o-k/scikit-vectors/blob/master/skvectors/doc/Using_a_Fundamental_Vector_Class.pdf


>...
> Macros, functions, and the documentation are the (overly brief) textbooks of
> POV-Ray.  Scene files are the lecture and recitation notes.

Good analogy.


> In engineering, the rule of thumb for how tight a bolt should be is, "Torque it
> down until it snaps, then back it off a half a turn."  That's valuable knowledge
> to have which is easy to say and scribble on a blackboard, or show in a
> demonstration.  However, it's probably not going to make it into the textbook.

Funny :) I haven't heard that one before.


> > If we keep the macros like they are now, then yes; we should have a user beware
> > warning.
>
> This is always the most difficult and painful part of writing real-world code.

Yes, you are right about that.

I hate writing documentation. I suspect that one of the reasons for this is that
I'm struggling very much to be concise and precise with a rich, varied and good
language and at the same time use correct terms for the topic (or profession ?).

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

Post a reply to this message