I don't know if it is a bug or intended, but it caused me some loss of time
: the <1, 0, 0> + 0.5*t  yields <1, 0, 0, 0> and not <1, 0, 0, 0.5> as
expected (by me!). (This happens whatever the number at the place of 0.5)
Additions <1, 0, 0> + t, <1, 0, 0> + t*1, or 1*t + <1, 0, 0> yield <1, 0, 0,
1>!

#macro V4Show(S, V)
#debug concat(S, ": ", str(V.x,6,2), ", ", str(V.y,6,2), ", ",str(V.z,6,2),
", ",str(V.t,6,2), "\n")
#end

#declare vvv = <1, 0, 0> +1*t;
V4Show("vvv ",vvv)

Post a reply to this message

Wasn't it mm who wrote:
>I don't know if it is a bug or intended, but it caused me some loss of time
>: the <1, 0, 0> + 0.5*t  yields <1, 0, 0, 0> and not <1, 0, 0, 0.5> as
>expected (by me!). (This happens whatever the number at the place of 0.5)
>Additions <1, 0, 0> + t, <1, 0, 0> + t*1, or 1*t + <1, 0, 0> yield <1, 0, 0,
>1>!
>
>#macro V4Show(S, V)
>#debug concat(S, ": ", str(V.x,6,2), ", ", str(V.y,6,2), ", ",str(V.z,6,2),
>", ",str(V.t,6,2), "\n")
>#end
>
>#declare vvv = <1, 0, 0> +1*t;
>V4Show("vvv ",vvv)


The documentation states that "t" is defined as

 #declare t = <0, 0, 0, 1>;

But that's a long way from the place where we learned that the order of
the vector components is "rgbft". The fourth vector is "filter", not
"transmit".

V.t extracts the fifth component, not the fourth.


I reckon things would make more sense if "t" where defined (and
documented) to be <0,0,0,0,1> and "f" were defined to be <0,0,0,1,0>,
but the current code works exactly as documented, so it's not really a
bug.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

I think you misunderstand the problem. "t" is defined as <0, 0, 0, 1>, and
the ".t" operator extracts the fourth component of the vector. It has
nothing to do with filter or transmit.

To make it more clear, this script:
  #debug concat(str((<1, 0, 0> + t*1).t, 0, -1), "\n")
  #debug concat(str((<1, 0, 0> + 1*t).t, 0, -1), "\n")
outputs:
  1.000000
  0.000000
even though the two results should be identical.

Anders

--
light_source{6#local D#macro B(E)#macro A(D)#declare#declare C=mod(E
D);E=(E-C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(C<3)
}cylinder{0(C=<1 2>).2translate<D+C*A(2)A(4)#else}intersection{torus
{1 .2}box{-2y}rotate<1 0C>*90translate<D+1A(2)*2+1#end-2 13>pigment{
rgb x}finish{specular 1}#end#end#end=-8;1B(445000298)B(519053970)B(
483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}

Post a reply to this message

In article <3c4c286d$1@news.povray.org>,
 "Anders K." <and### [at] prostard2gcom> wrote:

> I think you misunderstand the problem. "t" is defined as <0, 0, 0, 1>, and
> the ".t" operator extracts the fourth component of the vector. It has
> nothing to do with filter or transmit.

Exactly, it is "t" as in "time", not "transmit". You can access filter 
and transmit with ".filter" and ".transmit".

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

In article <3c4c286d$1@news.povray.org>,
 "Anders K." <and### [at] prostard2gcom> wrote:

> To make it more clear, this script:
>   #debug concat(str((<1, 0, 0> + t*1).t, 0, -1), "\n")
>   #debug concat(str((<1, 0, 0> + 1*t).t, 0, -1), "\n")
> outputs:
>   1.000000
>   0.000000
> even though the two results should be identical.

The problem seems to be that "1" gets expanded to "< 1, 1, 1, 0, 0>", 
this works as expected:
#declare FourD1 = < 1, 1, 1, 1>;
#debug concat(str((<1, 0, 0> + t*FourD1).filter, 0, -1), "\n")
#debug concat(str((<1, 0, 0> + FourD1*t).filter, 0, -1), "\n")

So at least there's a workaround...

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

Wasn't it Anders K. who wrote:
>I think you misunderstand the problem. "t" is defined as <0, 0, 0, 1>, and
>the ".t" operator extracts the fourth component of the vector. It has
>nothing to do with filter or transmit.
>
>To make it more clear, this script:
>  #debug concat(str((<1, 0, 0> + t*1).t, 0, -1), "\n")
>  #debug concat(str((<1, 0, 0> + 1*t).t, 0, -1), "\n")
>outputs:
>  1.000000
>  0.000000
>even though the two results should be identical.

Oh, right. It's a precedence bug.

What we'd expect to happen is for the multiplication to happen first,
but it doesn't, the addition happens first; and for that to happen the 1
may need to be expanded to a 5d vector.

If we add brackets to the t*1 and 1*t we get the "right" answer 1.000000
in both cases

  #debug concat(str((<1, 0, 0> + (t*1)).t, 0, -1), "\n") // 1.000000
  #debug concat(str((<1, 0, 0> + (1*t)).t, 0, -1), "\n") // 1.000000

If we force the addition to happen first, then we get the wrong answer

  #debug concat(str(((<1, 0, 0> + t)*1).t, 0, -1), "\n") // 1.000000
  #debug concat(str(((<1, 0, 0> + 1)*t).t, 0, -1), "\n") // 0.000000

What's happening is that in the second case the "1" gets expanded to
<1,1,1,1,1>. This gets added to <1,0,0,0,0> to give <2,1,1,1,1>. 
<2,1,1,1,1> * <0,0,0,1,0> gives <0,0,0,0,1>.

  #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

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

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

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

In article <3c4d25ae$1@news.povray.org> , "mm" <mmo### [at] wanadoofr> wrote:

> but analysed as a tree.

Not really.  It is parsed recursively.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Wasn't it mm who wrote:

>I find the present state annoying not so much because 1*t and t*1 are
>distinct

1*t and t*1 do evaluate to the same thing, <0,0,0,1>.

It's A+1*t and A+t*1 that evaluate differently (where A is a 2d or 3d
vector).


Perhaps more worrying is that  A+1*z  is different from  A+z*1  (where A
is a 2d vector) even though 1*z = z*1 = <0,0,1>.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message