I'm not that well versed in compilation, but I would expect that an
expression is parsed left to right, but analysed as a tree. If that would be
the case the sub-expression 1*t would be analysed first, on its own, and
typed as a 4D vector; then x + 1*t would be analysed and typed as a 4D
vector also. There is no need to parse or analyse the whole expression, just
to analyse it from leafs up in the tree.

I find the present state annoying not so much because 1*t and t*1 are
distinct (in math, there is no reason why the two would not be distinct
operations), but because the normal way to write math expressions is 1*t,
i.e., a real times a vector, not the other way round!

Michel Mouly


chr### [at] netplexaussieorg...
> In article <$sPY### [at] econymdemoncouk>,
>  Mike Williams <mik### [at] nospamplease> wrote:
>
> >   #declare Test = <2,1,1,1,1>*<0,0,0,1,0>;
> >   V5Show("Test ",Test) // Test:   0.00,   0.00,   0.00,   0.00,   1.00
>
> <2,1,1,1,1>*<0,0,0,1,0> should equal <0,0,0,1,0>, not <0,0,0,0,1>.
> Again, I don't think this is a precedence bug, but a bug with converting
> float values to vectors.
> (<1, 0, 0> + t*1).t
> expands to:
> (<1, 0, 0> + (< 0, 0, 0, 1, 0>*< 1, 1, 1, 1, 1>)).t
> which equals < 1, 0, 0, 1, 0>
> as it should, but
> (<1, 0, 0> + 1*t).t
> expands to:
> (<1, 0, 0> + < 1, 1, 1, 0, 0>*< 0, 0, 0, 1, 0>).t
> which equals < 1, 0, 0, 0, 0>.
> However, if you use:
> (<1, 0, 0, 0> + 1*t).t
> All is well.
>
> I'm guessing the code decides it's using a 3D vector when it parses the
> first vector, so it only expands the 1 to a 3D vector. When it then
> multiplies by a 4D vector, the fourth component is 0. Probably the only
> solution is to do 5D math all the time, I don't think it's possible to
> scan the expression to see the largest number of dimensions involved in
> the current parser.
>
> --
>  --
> Christopher James Huff <chr### [at] maccom>

Post a reply to this message