Prev: biew-6.1.0 has been released
Next: Java native binding to Agner Fog's random number library
From: Daniel Pitts on 14 Dec 2009 15:09
Vaclav Haisman wrote:
> If you consider different coordinate systems like cylindrical or spherical
> then angle is vector, IMHO.
Almost, a vector is a direction and magnitude. Angle is just direction.

There is no requirement that my vectors/points be implemented in terms
of rectangular coordinates, it just makes the operations easier.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Daniel Pitts on 14 Dec 2009 15:17
Pascal J. Bourguignon wrote:
> Daniel Pitts <newsgroup.spamfilter(a)virtualinfinity.net> writes:
>
>> This is almost an English question, rather than a programming
>> question, because I'm searching for the suitable name of a class.
>>
>> I'm creating some value types for a simulation that I'm working on.
>>
>> In the past, I've used a vector as a representation of a point, but
>> I've realized that they have subtle differences in properties. A
>> vector represents a delta, or a change, where a Point represents a
>> fixed location.
>>
>> From this realization, I've determined:
>>
>> 1. A vector can be multiplied or divided by a scalar; A point can not.
>> 2. A vector has a unit value; A points does not.
>> 3. Two vectors can be added or subtracted. Two points can be only
>> subtracted (which results in a vector)
>> 4. A vector can be added to and subtracted from a point, resulting
>> in a point.
>>
>> Among other things.
>>
>> So, for my implementation, vectors are implemented in terms of a
>> rectangular coordinate and points are implemented in terms of a
>> vector. The vector value of a point is the delta from the origin.
>>
>> Now, I have also figured out that there is the same difference between
>> an "Angle" and a "____", but I don't know what to call "____" (and I'm
>> not sure which one is the vector analogue vs the point analogue).
>>
>> I'm thinking that maybe angles are the fixed (point analague)
>> value.
>> The vector analogue, eg the delta, might be called "rotation",
>> but I'm not sure.
>> An angle would be implemented in terms of a
>> "rotation" from some determined origin (east for example), and
>> rotation will be defined as a scalar value (probably using radian
>> units).
>>
>> Does this all make sense, or am I too sleep deprived :-)
>>
>> So, what should my class names be? I'm thinking of calling them
>> Vector, Point, Rotation, Angle, but Rotation seems to not quit fit.
>> FixedAngle vs RelativeAngle is a bit too wordy, and there is probably
>> a more concise and exact concept that I'm missing.
>
>
> I would have had direction <-> point and angle <-> vector, but one
> problem is that we don't in general give directions (or angles) from
> an absolute origin, but from a relative one, so it is more difficult
> to characterize an angular equivalent to a point.
In the common radian scale, usually an absolute angle is relative to east.

> (What makes a point
> particular with respect to a vector, is that it is usually given
> relative to an origin). Also, this is the reason why "angle" might be
> somewhat ambiguous, and you're right that "rotation" would be clearer
> in this context. Another term that could be used for an absolute
> direction is "quadrant", but it is rather coarse.
>
> But in a program, you get to choose and define your terminology, so I
> would use "Direction" (from the origin).
>
> Vector <-> Rotation
> ^ ^
> | |
> v v
> Point <-> Direction
So:
Point implemented as Vector+implicit origin.
Direction implemented as Rotation+implicit origin.

That seems like a good fit. Maybe I'll look in a thesaurus for
direction/rotation :-)

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: BGB / cr88192 on 14 Dec 2009 18:01

"Daniel Pitts" <newsgroup.spamfilter(a)virtualinfinity.net> wrote in message
news:yeuVm.50745$cX4.33730(a)newsfe10.iad...
> This is almost an English question, rather than a programming question,
> because I'm searching for the suitable name of a class.
>
> I'm creating some value types for a simulation that I'm working on.
>
> In the past, I've used a vector as a representation of a point, but I've
> realized that they have subtle differences in properties. A vector
> represents a delta, or a change, where a Point represents a fixed
> location.
>

beyond this, personally I don't really see the point of distinguishing them.
I once asked a teacher this, as he was making the distinction, and he went
on and never really gave a solid answer. "it is because it is I guess"...

a point is a location, as contrasted from a vector relative to the
origin?...

I don't know, as far as the math or behavior goes there is not a whole lot
of difference.


> From this realization, I've determined:
>
> 1. A vector can be multiplied or divided by a scalar; A point can not.
> 2. A vector has a unit value; A points does not.
> 3. Two vectors can be added or subtracted. Two points can be only
> subtracted (which results in a vector)
> 4. A vector can be added to and subtracted from a point, resulting in a
> point.
>
> Among other things.
>

there are lots of operations which apply...
there are, infact, more operations than one may care to think about (unlike,
say, real numbers, vectors would seem to be a lot more "open ended" in these
regards).

your example list doesn't even include dot and cross product, FWIW, ...


> So, for my implementation, vectors are implemented in terms of a
> rectangular coordinate and points are implemented in terms of a vector.
> The vector value of a point is the delta from the origin.
>

personally I see vectors as being in a rectangular coordinate system as more
a property of the coordinate space than of the vectors, since the
operations/... remain themselves mostly unchanged even though the "space" is
different (although I guess one could argue that a cross product in a
right-hand space is different from a left-hand space, depending on ones'
interpretations and implementation).

the problem though with the cross-product, is that its behavior in a
left-hand space would be indeterminate apart from defining (either
implicitly or explicitly) a plane along which the space is mirrored (I would
have to verify, but it seems intuitively that there would be multiple
possible left-hand cross-products WRT a given right-hand cross product
depending on the spatial projection).



> Now, I have also figured out that there is the same difference between an
> "Angle" and a "____", but I don't know what to call "____" (and I'm not
> sure which one is the vector analogue vs the point analogue).
>

this is only true if the angle is assumed to be an absolute rotation.

more so, you don't state if you are talking here about 2D or 3D, where
rotation in 3D is a different beast from 2D (and in turn, 4D is a different
beast from 3D, challenging what one may think of "rotation"...).

one can instead think that an angle is essentially like a very limited delta
rotation, rather than an absolute rotation (though, an angle can fill this
role in 2D).

granted, in 3D, people often end up using euler angles (ZXZ and ZXY being
common, or informally, as "yaw, pitch, roll"), although, personally, I have
found that I rather dislike euler angles much beyond the "simple" case, and
instead prefer nearly any other option.

one idea I had made use of recently was to embed an axis-angle into the form
of 3 angles (sort of like euler angles), but which allows allows a 1:1
conversion between this and unit quaternions. more so, in the simple case,
it can identity map to a yaw angle.

the idea:
Quat <-> Axis-Angle, and Axis-Angle <-> 3Rot, where 3Rot encodes the axis in
the pitch and roll fields, and the angle in yaw (pitch=roll=0 then
corresponds to the Z axis, allowing for ordinary rotation in this case).

the main reason to do something like this was to "retrofit" quaternion-based
rotations onto a mass of code designed for the use of euler angles (in
particular, the Quake2 engine, where a flag indicates which system is in
use, but I had by mistake called this flag ZXZ, later realizing that this
system was not, in fact, ZXZ...).


> I'm thinking that maybe angles are the fixed (point analague) value. The
> vector analogue, eg the delta, might be called "rotation", but I'm not
> sure. An angle would be implemented in terms of a "rotation" from some
> determined origin (east for example), and rotation will be defined as a
> scalar value (probably using radian units).
>
> Does this all make sense, or am I too sleep deprived :-)
>

this seems counter-intuitive...

but, normally angles are not relative to some particular direction, but
along some particular axis (such as Z). they can also be regarded as a
relation between 2 coordinate systems along said axis, where usually an
angle of '0' would mean a 1:1 mapping between these systems.

which way is "east" or "forwards" is then a secondary issue, although,
normally the orientation of: X=right, Y=forwards, Z=up is common.

this is also apparently a difference between Quake1 and Quake2, where in
Quake1 (and in the non-renderer code in Quake2), this is followed, but
within the renderer Y=right and -X=forwards...

nevermind that Q2 can't keep it consistent which way angles go (leading to
frequent angle flipping in the renderer), or even whether clockwise or
counter-clockwise is the front-facing vertex order (so, the character models
use CCW vertex ordering and the BSP models use CW ordering, ...).


all this stuff made it a pain to add on new features (mostly for my own
learning experience), such as real-time stencil lighting and shadows (as-in
Doom3), which required lots of hacking and fiddling (and still looks not
very good as the Quake2 maps are designed for radiosity, and hence are not
well lit and have low-saturation textures, whereas the Quake1 maps look much
better, but tend to be bright and over-saturated with Quake2's
lightmapping...).

similar goes for rigid body physics, which turned out disappointingly
not-very-good...


> So, what should my class names be? I'm thinking of calling them Vector,
> Point, Rotation, Angle, but Rotation seems to not quit fit. FixedAngle vs
> RelativeAngle is a bit too wordy, and there is probably a more concise and
> exact concept that I'm missing.
>

dunno really...


I have never actually really done any of this via classes.
I have older code, which mostly used float pointers and functions.

some of my newer code uses a vector system based on top of compiler SIMD
intrinsics, which uses an API designed partly based on GLSL.


vec3 u, v, w;

u=vec3(1, 0, 0);
v=vec3(0, 1, 0);
w=v3cross(u, v);


> Thanks,
> Daniel.
> --
> Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>


From: Ben Bacarisse on 14 Dec 2009 18:43
Daniel Pitts <newsgroup.spamfilter(a)virtualinfinity.net> writes:

> Ben Bacarisse wrote:
>> Daniel Pitts <newsgroup.spamfilter(a)virtualinfinity.net> writes:
>>
>>> This is almost an English question, rather than a programming
>>> question, because I'm searching for the suitable name of a class.
>>>
>>> I'm creating some value types for a simulation that I'm working on.
>>>
>>> In the past, I've used a vector as a representation of a point, but
>>> I've realized that they have subtle differences in properties. A
>>> vector represents a delta, or a change, where a Point represents a
>>> fixed location.
>>>
>>> From this realization, I've determined:
>>>
>>> 1. A vector can be multiplied or divided by a scalar; A point can not.
>>> 2. A vector has a unit value; A points does not.
>>> 3. Two vectors can be added or subtracted. Two points can be only
>>> subtracted (which results in a vector)
>>> 4. A vector can be added to and subtracted from a point, resulting
>>> in a point.
>>
>> Why can't these be done to points? Take the first. Give P a sequence
>> of points, P' = x * P (multiply the points in P by a scalar x) has a
>> well-defined geometric meaning.
> Scaling a point has a meaning based on the origin, but the origin is
> itself an arbitrary point, so the geometric meaning of scaling a point
> is dependent on the origin. Yes, the origin is most commonly (0,0),
> but that doesn't mean it must be. Vectors, since they have a
> direction and magnitude, but no location, can be scaled regardless of
> origin choice.

Scaling a point has a meaning. You don't want to permit it. That's
fine if you think there is an advantage, but telling me what the
meaning is (which of course I know!) does not persuade me that you are
right to prohibit it. (0, 0) often /is/ a special point, so the fact
that it is treated as such in some operations is not obviously a bad
idea. You may be writing an application in which the (0, 0) has no
(or little) significance, but your classes have a meaning beyond your
particular application.

Will you distinguish between co-ordinates and distances? I.e. will
your points be a pair of two objects that are not of the same type as
the objects in a vector? Because of my point (that a co-ordinate is
just a distance form 0) you don't have to do this, but if not, what is
it about vectors that means they get special treatment.

>> I suppose my point (sorry) is why would you want to complicate matters
>> by making this distinction? Does it pay off for the programmer?
>>
>> <snip>
>
> It does pay off. Even if the operations were exactly the same, the
> semantics of a point are very specific. A point is slightly less
> primitive than a vector, and avoiding primitive obsession leads to
> cleaner code.

I don't know what this is. Is it known principle of design? Anyway,
I am not sure that it applies because I am not arguing for any one
type being primitive. I am simply applying a sort of programming
Occam's razor -- the fewer the types there are to understand the
simpler the program.

<snip>
--
Ben.
From: bartc on 14 Dec 2009 19:11

"Daniel Pitts" <newsgroup.spamfilter(a)virtualinfinity.net> wrote in message
news:yeuVm.50745$cX4.33730(a)newsfe10.iad...

> In the past, I've used a vector as a representation of a point, but I've
> realized that they have subtle differences in properties. A vector
> represents a delta, or a change, where a Point represents a fixed
> location.
>

> So, what should my class names be? I'm thinking of calling them Vector,
> Point, Rotation, Angle, but Rotation seems to not quit fit. FixedAngle vs
> RelativeAngle is a bit too wordy, and there is probably a more concise and
> exact concept that I'm missing.

There's a danger of getting tied up in knots here.

What do you do with your floating point scalar type? Do you have different
classes for distance, length, angle, area, volume, mass, time, velocity,
acceleration,....?

It sounds at first sensible to create dedicated types for each (and then for
each combination...), but perhaps a better suggestion is to keep the types
straightforward and put any such information into the variable names. At
least until your project is fully working.

--
Bartc

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: biew-6.1.0 has been released
Next: Java native binding to Agner Fog's random number library