Lack of Tuple3d multiply

Thread view:

Martin - 26 Nov 2003 16:10 GMT

How come there is no component-by-component multiplication for the
abstract class Tuple3* and its descendants?

For scalars there is tuple.scale(scalar) and for the subclass Vector3*
there are the two forms of vector multiplication .dot() and .cross(),
but what if I want to multiply each component of a tuple, a, with
those of another tuple of the same dimensions, b, i.e.
a.x *= b.x;
a.y *= b.y;
a.z *= b.z;

Am I missing something, or shouldn't there be a.mul(b) to do this?

Reply to this Message

JK - 26 Nov 2003 16:18 GMT

Why would you do that?

Java3D deals with linear algebra for geometric 3d modelling. Is there a
geometric interpretation for your special product?

JK

> How come there is no component-by-component multiplication for the
> abstract class Tuple3* and its descendants?
[quoted text clipped - 8 lines]
>
> Am I missing something, or shouldn't there be a.mul(b) to do this?

Reply to this Message

Martin - 27 Nov 2003 11:04 GMT

I realise that there isn't a geometric interpretation for this
operation, i.e. A * B, where A and B are both vectors, doesn't make
any sense unless it is a dot or cross product. It is useful however
for other subclasses of Tuple3*, such as Color3f.

For instance I need to modulate (if that's the right word) a specific
colour by a particular 3-dimensional coefficient for a ray tracer that
I am writing.
e.g.
Color3f colour = new Color3f(0.8f, 0.8f, 0.8f);
Color3f specularCoefficient = new Color3f(0.1f, 0.2f, 0.3f);

// I'd like to just do this
color.mul(specularCoefficient);

// But have to do this instead
color.x *= specularCoefficient.x;
color.y *= specularCoefficient.y;
color.z *= specularCoefficient.z;

Martin.

> Why would you do that?
>
[quoted text clipped - 15 lines]
> >
> > Am I missing something, or shouldn't there be a.mul(b) to do this?

Reply to this Message

JK - 28 Nov 2003 10:13 GMT

Ah, you are right. I was to much focussed on geometry.

OTOH, it shouldn't be a problem to implement this yourself, either by
inheriting from Color3* or directly. x, y and z are indeed public
attributes, so you could use a static helper class to avoid annoying
casts and copies.

public class TupleTool {
public static void mul(Tuple3f a, Tuple3f b) {
a.x *= b.x;
...
}
}

Tuple3f a = new Tuple3f();
Tuple3f b = new Tuple3f();
TupleTool.mul(a,b);

or similar.

Regards
JK.

> I realise that there isn't a geometric interpretation for this
> operation, i.e. A * B, where A and B are both vectors, doesn't make
[quoted text clipped - 37 lines]
>>>
>>>Am I missing something, or shouldn't there be a.mul(b) to do this?

Reply to this Message

Martin - 02 Dec 2003 13:15 GMT

Ah, yes. The idea of using a static helper function is neat.

It also struck me as odd that none of the Tuple* functions returns the
result of its calculations (apart from angle(), dot() etc. which
return a scalar). Perhaps this is a way of avoiding the inevitable

(a.add(b.sub(c))).cross(e.sub(f.scaleAdd(2, g))

which is a pain to read and maintain. I know there have been
discussions regarding the readability of this method versus that
produced by operator overloading, e.g.

(a + (b-c)) * (e - (2*f + g))

but I would sometimes find it useful to do the calculation "in place"
rather than create a new object to temporarily hold the result.

Also, why does scaleAdd() assume I want to scale the first tuple
before adding the second (i.e. this = s*this + t1) rather than scaling
the second tuple and adding it to the first, i.e. this = this + s*t1

In order to do that I have to resort to the messy
t1.scaleAdd(s, t2, t1)

Just a thought.

> Ah, you are right. I was to much focussed on geometry.
>
[quoted text clipped - 18 lines]
> Regards
> JK.

Reply to this Message

JK - 03 Dec 2003 09:52 GMT

Comments inline:

> Ah, yes. The idea of using a static helper function is neat.
>
[quoted text clipped - 12 lines]
> but I would sometimes find it useful to do the calculation "in place"
> rather than create a new object to temporarily hold the result.

Well, in your example temporary vectors are also created, but
implicitly. Where else should the result of e.g. (b-c) be stored? I
think the idea in Java3D is memory efficiency. With Java3D you have full
control of how many objects are created. The garbage collector would
have lot of work deallocating all the temporary tuples, whose very small
size might also result in horrible fragmentation.

Another argument is, that Java3D is somehow derived from OpenInventor,
which is C++, i.e. does not have garbage collection at all.
Have you ever tried to do vector calculations in C++? Sure, it does
provide operator overloading, therefore you can implement vector
calculations using "+" etc. The problem is efficiency and the lack of a
garbage collector: To avoid memory leaks, the result of an "operator+"
for example must be a Vector and not a reference to one. That means,
after calculating the sum of the vectors the result must be copied to a
temporary automatic variable. Even in your small example there are 5
operations which would require a temporary variable and copying results.

As a last point, Java is object oriented. Let's look at a small example
with vectors x,y and z
x=y+z
Which method is required to do this? Thinking "object oriented", meaning
an object's state is only modified by calling its methods, results in a
method of x, which is the only variable that changes state (value). So
they put
x.add(y,z)
into the Java3D API.

> Also, why does scaleAdd() assume I want to scale the first tuple
> before adding the second (i.e. this = s*this + t1) rather than scaling
[quoted text clipped - 4 lines]
>
> Just a thought.

Yes, very strange indeed. The reason might be the historical SAXPY
operation in the Fortran BLAS (basic linear algebra subroutines)
library. SAXPY stands for "(single precision) a*x + b"

Regards
JK.

Reply to this Message

Lack of Tuple3d multiply

Free Magazines