Prev: biew-6.1.0 has been released
Next: Java native binding to Agner Fog's random number library
From: James Harris on 14 Dec 2009 19:35
On 14 Dec, 20:17, Daniel Pitts
<newsgroup.spamfil...(a)virtualinfinity.net> wrote:
> Pascal J. Bourguignon wrote:
> > Daniel Pitts <newsgroup.spamfil...(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.

....

> >> 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).

....

> 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 :-)

For stuff like this I sometimes use the reverse dictionary feature of

http://www.onelook.com/

For sure it throws out many inappropriate suggestions but there can be
some gems mixed in with them. Depending on your need you may need to
derive or combine words if there is really no English word for what
you want.

James
From: Rouben Rostamian on 14 Dec 2009 21:32
On 2009-12-14, Ben Bacarisse <ben.usenet(a)bsb.me.uk> wrote:
>
> 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.

The OP is justified in distinguishing between points and
vectors. They are fundamentally different objects and it's
worthwhile to keep the distinction in mind.

The distinction becomes quite obvious if we change the
setting to a curved surface, or curved space (as in the
theory of relativity.) Consider, for instance, the surface
of the Earth. There is no ambiguity is saying that in my
location the wind is blowing in the easterly direction
at 40 kilometers per hour. The wind velocity is a vector.
If the wind blows twice as fast, then the wind velocity vector
will be doubled in size.

At the same time, my location is a "point" on the surface of
the Earth. What is the meaning of scaling my location by a
factor of two? If I am in Paris, does that take me to Rome?

The distinction between points and vectors becomes somewhat
blurred on flat surfaces but one should have in mind that
conceptually they are quite different objects.

--
Rouben Rostamian

From: Ben Bacarisse on 14 Dec 2009 22:19
Rouben Rostamian <rr(a)nohost.noname> writes:

> On 2009-12-14, Ben Bacarisse <ben.usenet(a)bsb.me.uk> wrote:
>>
>> 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.
>
> The OP is justified in distinguishing between points and
> vectors. They are fundamentally different objects and it's
> worthwhile to keep the distinction in mind.
>
> The distinction becomes quite obvious if we change the
> setting to a curved surface, or curved space (as in the
> theory of relativity.) Consider, for instance, the surface
> of the Earth. There is no ambiguity is saying that in my
> location the wind is blowing in the easterly direction
> at 40 kilometers per hour. The wind velocity is a vector.
> If the wind blows twice as fast, then the wind velocity vector
> will be doubled in size.
>
> At the same time, my location is a "point" on the surface of
> the Earth. What is the meaning of scaling my location by a
> factor of two? If I am in Paris, does that take me to Rome?
>
> The distinction between points and vectors becomes somewhat
> blurred on flat surfaces but one should have in mind that
> conceptually they are quite different objects.

Yes, they are different. I was not arguing that they were the same.
I am just unsure of the value of enforcing the distinction. You can't
(usually) add a time and mass and the distinction can be enforced by
the type system of some languages; but it seems to me an open question
as to whether this is really worth doing. Lots of software does not
bother despite it being plainly safer to do so. The burden of so many
distinct types might not pay off in some cases.

The OP's motivation seemed even less strong than this because they
seemed to be working in a geometry where it was at least possible to
represent a point as a vector from the (0, 0).

Would you preserve the distinction in one dimension? I.e. would you
distinguish between a co-ordinate and a distance?

--
Ben.
From: Daniel Pitts on 14 Dec 2009 21:35
bartc wrote:
>
> "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?
That is a primitive type. It is either parameterized (using templates),
or I will dictate that it is one specific type (double or float,
depending on what my whim is)

> Do you have
> different classes for distance, length, angle, area, volume, mass, time,
> velocity, acceleration,....?
distance is length, and yes, length will have a class. area/volume/mass
won't be needed in my simulation. Time will have a class. velocity and
acceleration will both have classes.
>
> 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.
Ah, right, because compilers can catch misuse based on variable names.
Oh wait, they can't.

If it is a noun in your domain, it most likely should be a class in your
model.



--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Daniel Pitts on 14 Dec 2009 21:52
BGB / cr88192 wrote:
> "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"...
The reason is semantics. Why distinguish a complex number from a 2d
vector? You can certainly create a single class which will handle both
cases (there is even some overlap). But you don't want your API clients
passing in a vector when you expected a complex number.
>
> a point is a location, as contrasted from a vector relative to the
> origin?...
A point *has* a location. A vector has a magnitude and direction.
Although both points and vectors are representable in the same
coordinate spaces, the semantics of those representations are very
different.
>
> I don't know, as far as the math or behavior goes there is not a whole lot
> of difference.
Not in the math, but in the meaning.

>
>> 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, ...
If I'd wanted to make an exclusive list, it wouldn't have included
"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.
>>
>
> personally I see vectors as being in a rectangular coordinate system as more
> a property of the coordinate space than of the vectors,
True, but the vectors have to be implemented some how, and choosing
rectangular coordinates simplify a lot of the common operations
(addition, dot product, etc...)
> 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).
Technically, you end up with an object which is not a vector, I forget
the name of it, but it is basically a double-sided vector. a union of
both left and right handed. Much like square root radicals, its
convention from which we choose ignore one of the results.
>
> 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).
Kind of diverged there from the topic :-) Anyway, I'm dealing with 2d
space, so cross-product is not a concern.
>
>
>
>> 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"...).
Ah, I did forget to mention I was working in a 2d space.
>
> 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...).
Off topic again are ya? ;-)
>
>
>> 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.
In 2d spaces, absolute angles are relative (by convention) to the
positive x axis. Although, this is something which I will be
abstracting away, so the convention need not apply. A user can start
with axial unit vector, and then rotate clockwise or counter-clockwise
by whatever amount.
> 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...
You really like going off on tangents, don't you :-) I actually don't
mind, its always interesting to me to hear more about these kinds of
things, even if they aren't relevant to the discussion at hand
>
>
>> 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);
That's not very different from using classes, just the syntax changes
slightly.


--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
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