remove.haberg@matematik.su.se (Hans Aberg) writes:

> In article <3C321E28.22CE26C8@animats.com>, John Nagle
> <nagle@animats.com> wrote:
> >       vec2f   vec2d   mat2f   mat2d
> >       vec3f   vec3d   mat3f   mat3d
> >       vec4f   vec4d   mat4f   mat4d
> ...
> >    What namespace should those go in?
>
> "gui" (graphical user interface) perhaps, unless it is standarized.

No!

This has nothing to do with user interface. You can have graphics
without a GUI (indeed, typical DOS graphics libraries are/were
"GUI-free"), a GUI is just an UI using graphics (indeed, most things
you interact with in GUIs are not graphics-specific at all; windows,
menus and buttons already existed in text-only SAA interfaces). Of
course, GUI libraries generally include graphics libraries which are
suited to the GUI (i.e. allow you to draw in a given window,
etc.). But in principle, GUI and graphics interface are independent
from each other (a GUI usually gives you some graphics context, on
which all drawing is done; from the view of the graphics interface, it
doesn't matter that the graphics context describes a window or part of
a window of the GUI; it could as well describe the screen itself, a
graphics file, a printer page, ...)

[...]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

John Nagle <nagle@animats.com> wrote in message news:<3C352F4D.3F4301D6@animats.com>...
> The appropriate way to do that would be to derive a quaternion
> class from the vec4 class.
>
>    What's the mechanism for formally injecting this into the
> standards process?

The bureaucratic answer is something like "submit it via your national
body" (ANSI, BSI, Standards Canada, whatever).

You've already given a more practical answer in a prior post:

Submit it to www.boost.org first.

If it gets accepted by Boost, it will then progress on to the
committee with Boost's backing.  Quite a few members of the committee
are active on Boost, and they have committed to guide proposals along.
 Having something available on Boost also helps ensure that it will be
viewed by the committee as existing practice. Even committee members
are submitting their stuff to Boost first.

Of course as one of the Boost moderators, I'm biased:-)

--Beman Dawes

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3C321E28.22CE26C8@animats.com>,
John Nagle  <nagle@animats.com> wrote:
>    So, to make this clear, I'm proposing to standardize
>the following types:
>
> vec2f vec2d mat2f mat2d
> vec3f vec3d mat3f mat3d
> vec4f vec4d mat4f mat4d
>
>and the usual operations on such objects.
>
>    What namespace should those go in?

None, please.  This still has not addressed my objection (was it
lost?) that there is no way to differentiate a 4d Euclidean vector
from a Homogeneous 4-vector.  The latter is used heavily in graphics
with 4x4 matrices, but someone naively using the implementation would
no assume that vec4f was fundamentally different from vec3f, in more
than just the size if vec4f was a homogeneous vector.  A person using
the objects for 3d geometry might object if the 4-vector *wasn't*
homogeneous.

Solution?
--
Mark Ping
emarkp@soda.CSUA.Berkeley.EDU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

   The appropriate way to do that would be to derive a quaternion
class from the vec4 class.

   What's the mechanism for formally injecting this into the
standards process?

     John Nagle
     Animats


"E. Mark Ping" wrote:
>
> In article <3C321E28.22CE26C8@animats.com>,
> John Nagle  <nagle@animats.com> wrote:
> >    So, to make this clear, I'm proposing to standardize
> >the following types:
> >
> >       vec2f   vec2d   mat2f   mat2d
> >       vec3f   vec3d   mat3f   mat3d
> >       vec4f   vec4d   mat4f   mat4d
> >
> >and the usual operations on such objects.
> >
> >    What namespace should those go in?
>
> None, please.  This still has not addressed my objection (was it
> lost?) that there is no way to differentiate a 4d Euclidean vector
> from a Homogeneous 4-vector.  The latter is used heavily in graphics
> with 4x4 matrices, but someone naively using the implementation would
> no assume that vec4f was fundamentally different from vec3f, in more
> than just the size if vec4f was a homogeneous vector.  A person using
> the objects for 3d geometry might object if the 4-vector *wasn't*
> homogeneous.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3C321E28.22CE26C8@animats.com>, John Nagle
<nagle@animats.com> wrote:
>       vec2f   vec2d   mat2f   mat2d
>       vec3f   vec3d   mat3f   mat3d
>       vec4f   vec4d   mat4f   mat4d
...
>    What namespace should those go in?

"gui" (graphical user interface) perhaps, unless it is standarized.

In article <a12q9v$7af$1@agate.berkeley.edu>, emarkp@CSUA.Berkeley.EDU (E.
Mark Ping) wrote:

> This still has not addressed my objection (was it
>lost?) that there is no way to differentiate a 4d Euclidean vector
>from a Homogeneous 4-vector.

Are these the same thing as projective coordinates? If so, they should
have their own classes, as the operations are fundamentally different.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

John Nagle  <nagle@animats.com> wrote:
>   I'm proposing to standardize
>the following types:

>       vec2f   vec2d   mat2f   mat2d
>       vec3f   vec3d   mat3f   mat3d
>       vec4f   vec4d   mat4f   mat4d

If some of these should be used for time evolutions, then I think you
should treat them separately:
  vec3d  -- For 3D
  vec2dt -- For 2D & T (also dimension three)

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

   A Bezier curve library might be useful, but it's not a standards
issue.  Small vectors and matrices are widely used and are routinely
passed back and forth between various packages.  Most such packages
have their own representations, and interconversion is a constant
headache in graphics work.  Hence the justifification
for standardization.

   This is probably about as useful as standardizing "complex".
The same arguments apply: the desired data structures and operations
are well known, widely used, and agreed upon, but often implemented
imcompatibly.

     John Nagle
     Animats

Hans Aberg wrote:
>
> In article <3C27D1F4.3E80CB9F@animats.com>, John Nagle <nagle@animats.com>
> wrote:
> >   I'd like to suggest that a standard library for small vectors
> >and matrices (up to 4x4) be defined in the next round of the standard.
> >In graphics work, these structures come up all the time, and
> >every graphics program has some representation for them.
> >It's quite common to have three or four such libraries in a
> >program, since there's no standard on this.  Interconverting between
> >these representation is a constant headache.
>
> One interesting thing is that spline (Bezier) curves, plane curve segments
> parametrized by degree three polynomials, generalize to higher dimensions:

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3C2A5F9D.F2DA95F3@animats.com>, John Nagle <nagle@animats.com>
wrote:
>   A Bezier curve library might be useful, but it's not a standards
>issue.

It might, in fact it was discussed in one of the C++0x threads, because of
the standards issue of making C++ better for educational purposes, one
might add a graphics library of some sort: It is often a part of computer
courses to do some programming with graphical objects, and it is a pain to
find implementations having them.

On the other hand, it should be fairly easy for platforms PC and up which
uses a graphics, to implement a library that uses spline simplicies.

>  Small vectors and matrices are widely used and are routinely
>passed back and forth between various packages.  Most such packages
>have their own representations, and interconversion is a constant
>headache in graphics work.  Hence the justifification
>for standardization.

So while at it, one might as well study the issue of being able to
generate a basic graphics library as well. There would be some macro or
variable indicating whether the compiler supports it or not.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hans Aberg wrote:
<snip>
> So while at it, one might as well study the issue of being able to
> generate a basic graphics library as well. There would be some macro or
> variable indicating whether the compiler supports it or not.

In my (very) humble opinion this would be an extremely bad idea. The
idea of having the standard support some of the more commonly used data
types (matrices, vertices and so on) is not bad; it would be nice to
have a standard way of storing this common mathematical data. As long as
your implementation works with all the popular graphics APIs, you won't
have a problem. This is the first problem; these data structures will
only be used if they are compatible with the rest of a developer's
tools. Making C++ dependent on the interface of any third party software
seems like a bad idea.
Giving C++ innate rendering functionality would be disastrous. C++ is a
huge language; do you really think that the C++ community could maintain
(and possibly extend) C++ _and_ create a graphics library that is "good
enough"?
By "good enough" I mean that while it wouldn't have to be able to
compete with libraries like OpenGL, it would still need to be relatively
powerful if it is to be taken seriously.

-----------------------------------------------
 mail: curve at waveform.org, UIN: 64192061.
 list: curves-kiddies-request at ethernal.org.
-----------------------------------------------

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

John Nagle <nagle@animats.com> writes:

|>     A Bezier curve library might be useful, but it's not a standards
|>  issue.  Small vectors and matrices are widely used and are routinely
|>  passed back and forth between various packages.  Most such packages
|>  have their own representations, and interconversion is a constant
|>  headache in graphics work.  Hence the justifification for
|>  standardization.

|>     This is probably about as useful as standardizing "complex".  The
|>  same arguments apply: the desired data structures and operations are
|>  well known, widely used, and agreed upon, but often implemented
|>  imcompatibly.

I'm curious, but would a vector templatized on the size, and guaranteed
to not use dynamic memory, do the trick.  In my own pre-standard
library, I had a "template< class T, size_t n > Array" class, which for
all but the smallest arrays also guaranteed sizeof(Array<T,n>) ==
n*sizeof(T).  (With some sort of alignment magic, I could have
guaranteed it for all arrays, but the union I used to guarantee
alignment meant a minimum size of sizeof(double) on most machines, even
for Array<char,3>.)

This would seem to be more flexible, since if we standardize a vector of
size 3, then why not 4, and so on.  And except for the alignment
problem, it is fairly easy to implement for all types supporting copy
construction and assignment, i.e. the same requirements as for
std::vector.

--
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3C2B1C6D.5E25B35F@waveform.org>, Jacques <curve@waveform.org> wrote:
>> So while at it, one might as well study the issue of being able to
>> generate a basic graphics library as well. There would be some macro or
>> variable indicating whether the compiler supports it or not.
>
>In my (very) humble opinion this would be an extremely bad idea.
...
> As long as
>your implementation works with all the popular graphics APIs, you won't
>have a problem. This is the first problem; these data structures will
>only be used if they are compatible with the rest of a developer's
>tools. Making C++ dependent on the interface of any third party software
>seems like a bad idea.

One would need to extract a graphics library that is fairly easy to
implement if a typical graphics package is available on the platform. The
idea with putting into C++ is that it becomes fairly platform independent.

>Giving C++ innate rendering functionality would be disastrous. C++ is a
>huge language; do you really think that the C++ community could maintain
>(and possibly extend) C++ _and_ create a graphics library that is "good
>enough"?

Well, one has made say floating point arithmetic as a part of C/C++, but
that does not prevent one using that side by side with say a floating
point multiprecision library.

>By "good enough" I mean that while it wouldn't have to be able to
>compete with libraries like OpenGL, it would still need to be relatively
>powerful if it is to be taken seriously.

Well, the suggestion would be to include at least spline simplicies, and I
recall that all (language) typesetting (like in TeX, PostScript) can be
body using that. In addition, one would be able to such bodies in 3D and
time evolution.

That is always a start for keeping the student busy. :-)

I do not know whether one could make such a basic graphics library, but I
think that some experts might give it a look. When techniques evolve and
there emerges something that is de facto standard, the one can put it into
a library.

One other topic that comes to my mind is support for a windows console:
This is now a standard thing on most computers, and they work in a very
similar fashion. So C++ could give some support for that as well.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3C2B1C6D.5E25B35F@waveform.org>, Jacques says...
>
>Giving C++ innate rendering functionality would be disastrous. C++ is a
>huge language; do you really think that the C++ community could maintain
>(and possibly extend) C++ _and_ create a graphics library that is "good
>enough"?
>By "good enough" I mean that while it wouldn't have to be able to
>compete with libraries like OpenGL, it would still need to be relatively
>powerful if it is to be taken seriously.

I agree. However, basic graphics functionalities would allow textbook writers
and instructors to provide examples, and I think these are more appealing than
text-only examples. A similar point can be made for exercises.

Regards,

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

James Kanze wrote:
> John Nagle <nagle@animats.com> writes:
>     Small vectors and matrices are widely used and are routinely
> |>  passed back and forth between various packages.  Most such packages
> |>  have their own representations, and interconversion is a constant
> |>  headache in graphics work.  Hence the justifification for
> |>  standardization.

>
> I'm curious, but would a vector templatized on the size, and guaranteed
> to not use dynamic memory, do the trick.  In my own pre-standard
> library, I had a "template< class T, size_t n > Array" class, which for
> all but the smallest arrays also guaranteed sizeof(Array<T,n>) ==
> n*sizeof(T).  (With some sort of alignment magic, I could have
> guaranteed it for all arrays, but the union I used to guarantee
> alignment meant a minimum size of sizeof(double) on most machines, even
> for Array<char,3>.)
>
> This would seem to be more flexible, since if we standardize a vector of
> size 3, then why not 4, and so on.  And except for the alignment
> problem, it is fairly easy to implement for all types supporting copy
> construction and assignment, i.e. the same requirements as for
> std::vector.

    I have the feeling that generalizing this to length N would
complicate the implementation excessively.   Fixed-size vectors and
matrices of length 2, 3, and 4 are very widely used, and multiple,
incompatible implementations of the common operations on them already
exist.  So there's a clearly defined need for standardization.

    These operations need to go very fast for graphics work, so
they should be written in forms that will inline without
loops (assuming that's the fastest implementation).  It's
also common to have 2, 3, and 4 argument constructors for vectors
of length 2, 3, and 4.  N-argument functions are painful in
C++.

    N-dimensional arrays for mathematical work do need better
support in C++.  But that's a more general issue.  There,
you want more flexibility (submatrices, row rearrangement,
resizing, etc.).  So that's a more general library with
more dynamic storage.

    It would be desirable to have both, and have them know
enough about each other, so conversions work.

    Any specific comments about the "algebra3" library from
Graphics Gems?  (See

    http://www.animats.com/source/graphics/algebra3.h

which is basically the Graphics Gems code, cleaned up,
const-correct, and inline.)

    It's a problem that this
code is all "double".  How would people suggest
distinguishing single and double precision objects
with similar functionality?  The objects could
be generic, of course, but then we need a short
name for, say, "vec3<float>".   Suggestions?

     John Nagle
     Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

John Nagle <nagle@animats.com> writes:

|>  James Kanze wrote:
|>  > John Nagle <nagle@animats.com> writes:
|>  >     Small vectors and matrices are widely used and are routinely
|>  > |>  passed back and forth between various packages.  Most such
|>  > |>  packages have their own representations, and interconversion
|>  > |>  is a constant headache in graphics work.  Hence the
|>  > |>  justifification for standardization.

|>  > I'm curious, but would a vector templatized on the size, and
|>  > guaranteed to not use dynamic memory, do the trick.  In my own
|>  > pre-standard library, I had a "template< class T, size_t n >
|>  > Array" class, which for all but the smallest arrays also
|>  > guaranteed sizeof(Array<T,n>) == n*sizeof(T).  (With some sort of
|>  > alignment magic, I could have guaranteed it for all arrays, but
|>  > the union I used to guarantee alignment meant a minimum size of
|>  > sizeof(double) on most machines, even for Array<char,3>.)

|>  > This would seem to be more flexible, since if we standardize a
|>  > vector of size 3, then why not 4, and so on.  And except for the
|>  > alignment problem, it is fairly easy to implement for all types
|>  > supporting copy construction and assignment, i.e. the same
|>  > requirements as for std::vector.

|>      I have the feeling that generalizing this to length N would
|>  complicate the implementation excessively.

In what way.  The only potential problem I see is alignment; it is only
present if we require the separation of initialization and allocation
(so that a default constructor is not needed), and it is equally present
(and more of a problem to resolve) for small fixed size vectors.

|>   Fixed-size vectors and matrices of length 2, 3, and 4 are very
|>  widely used, and multiple, incompatible implementations of the
|>  common operations on them already exist.  So there's a clearly
|>  defined need for standardization.

|>      These operations need to go very fast for graphics work, so they
|>  should be written in forms that will inline without loops (assuming
|>  that's the fastest implementation).  It's also common to have 2, 3,
|>  and 4 argument constructors for vectors of length 2, 3, and 4.
|>  N-argument functions are painful in C++.

That sounds like a legitimate argument for specialization.  I would
argue against N-arguments, although there was a recent article on how to
implement them in CUJ.

Another possible solution is to adopt the C99 compound literals.
Ideally, there would be some way of converting the compound literal to a
pair of iterators, which would then be passed to the standard iterator,
iterator constructor, but I don't see how to do this easily.  And
functions like copy already suppose that the destination has the correct
length; in this case, we simply have to suppose that the source has the
correct length.

|>      N-dimensional arrays for mathematical work do need better
|>  support in C++.  But that's a more general issue.  There, you want
|>  more flexibility (submatrices, row rearrangement, resizing, etc.).
|>  So that's a more general library with more dynamic storage.

I agree that it is a different problem.  I'm not a specialist in this
domain, but from what I understand, what is really needed is some sort
of "view" classes, which present a view (projection, etc.) of the
underlying matrix.

--
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

John Nagle said on Sun, 30 Dec 2001 20:38:01 CST:
>    Any specific comments about the "algebra3" library from
>Graphics Gems?  (See
>
>    http://www.animats.com/source/graphics/algebra3.h
>
>which is basically the Graphics Gems code, cleaned up,
>const-correct, and inline.)
>
>    It's a problem that this
>code is all "double".  How would people suggest
>distinguishing single and double precision objects
>with similar functionality?  The objects could
>be generic, of course, but then we need a short
>name for, say, "vec3<float>".   Suggestions?

Yes, the code would probably need to be templatized.
vec3<T> seems right (which many may typedef to vec3f
and vec3d).

Another important aspect of small vector classes is
that they can commonly be opmtimized on current platforms
(PowerPC AltiVec and SSE(2) come to mind, with specific
compiler extensions).
Hasn't there already been some standardisation efforts
around vec4f classes and such in the graphic community ?


I had a quick look at algebra3.
Quick comments that come to mind:
 - I would prefer non-member functions to be used
   more often (maybe following Bjarne's recommendation
   that non-mutating ops should preferably be 'friends').
   Example: length(v), length2(v), unit(v), ...
 - I really prefer having explicit cross(a,b) and dot(a,b)
   operations instead overridden * and ^ (error prone).
 - I would personally drop the scalar division op
   ( prefering v *= 1/d )
 - How should the libs be split into headers ?
 - etc


Maybe submitting a library to www.boost.org would allow
a productive review process. Let me know if you would like
to do so. I am not active there, but I would be glad to
contribute. Let me know if I can help.

Regards,
Ivan  (strip _ for direct reply)

--
 Ivan Vecerina, Dr. med.  <>  http://www.post1.com/~ivec
 Soft Dev Manger, XiTact  <>  http://www.xitact.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

    That's helpful.  If you'd like to submit that library to
"boost.org", that would be good.

    It's a popular library in the graphics world.  It dates from
an era before templates really worked, which is why it's not
templated.  The original, in fact, wasn't even inlined.
Nor was it const-correct.  I've done that bit of modernization,
and agree that may be time for a templated version.

    I'd really like to avoid overburdening this library with
excessive generality.  The small, fixed-size matrix operations are
widely used in graphics code for which speed is a major competitive
issue.  Doing anything to slow them down is a mistake.

    One argument against a templated version is that there's
hardware support for small matrix operations on some machines.
SGI has had 4x4 matrix multipliers in the main CPU for years,
and AMD "3DNOW"-capable CPUs have support for small matrix
operations (although with non-IEEE special case semantics).

    If the types are standardized as "vec3f" and "vec3d", for
example, then whether or not the underlying implementation
is templated or written out is an implementation detail.
I'd suggest going that way.

    So, to make this clear, I'm proposing to standardize
the following types:

 vec2f vec2d mat2f mat2d
 vec3f vec3d mat3f mat3d
 vec4f vec4d mat4f mat4d

and the usual operations on such objects.

    What namespace should those go in?

    John Nagle
    Animats

Ivan Vecerina wrote:
>
> John Nagle said on Sun, 30 Dec 2001 20:38:01 CST:
> >    Any specific comments about the "algebra3" library from
> >Graphics Gems?  (See
> >
> >    http://www.animats.com/source/graphics/algebra3.h
> >
> >which is basically the Graphics Gems code, cleaned up,
> >const-correct, and inline.)
> >
> >    It's a problem that this
> >code is all "double".  How would people suggest
> >distinguishing single and double precision objects
> >with similar functionality?  The objects could
> >be generic, of course, but then we need a short
> >name for, say, "vec3<float>".   Suggestions?
>
> Yes, the code would probably need to be templatized.
> vec3<T> seems right (which many may typedef to vec3f
> and vec3d).
>
> Another important aspect of small vector classes is
> that they can commonly be opmtimized on current platforms
> (PowerPC AltiVec and SSE(2) come to mind, with specific
> compiler extensions).
> Hasn't there already been some standardisation efforts
> around vec4f classes and such in the graphic community ?
>
> I had a quick look at algebra3.
> Quick comments that come to mind:
>  - I would prefer non-member functions to be used
>    more often (maybe following Bjarne's recommendation
>    that non-mutating ops should preferably be 'friends').
>    Example: length(v), length2(v), unit(v), ...
>  - I really prefer having explicit cross(a,b) and dot(a,b)
>    operations instead overridden * and ^ (error prone).
>  - I would personally drop the scalar division op
>    ( prefering v *= 1/d )
>  - How should the libs be split into headers ?
>  - etc
>
> Maybe submitting a library to www.boost.org would allow
> a productive review process. Let me know if you would like
> to do so. I am not active there, but I would be glad to
> contribute. Let me know if I can help.
>
> Regards,
> Ivan  (strip _ for direct reply)
>
> --
>  Ivan Vecerina, Dr. med.  <>  http://www.post1.com/~ivec
>  Soft Dev Manger, XiTact  <>  http://www.xitact.com
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

John Nagle <nagle@animats.com> writes:

[...]

|     One argument against a templated version is that there's
| hardware support for small matrix operations on some machines.
| SGI has had 4x4 matrix multipliers in the main CPU for years,
| and AMD "3DNOW"-capable CPUs have support for small matrix
| operations (although with non-IEEE special case semantics).

But then, that doesn't forbid a primary templates, along with
specializations where applicable.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

   I'd like to suggest that a standard library for small vectors
and matrices (up to 4x4) be defined in the next round of the standard.
In graphics work, these structures come up all the time, and
every graphics program has some representation for them.
It's quite common to have three or four such libraries in a
program, since there's no standard on this.  Interconverting between
these representation is a constant headache.

   I'd like to suggest that the interface of the "algebra3" library
from Graphics Gems, be adopted.  See

    http://www.animats.com/source/graphics/algebra3.h

for an all-inline implementation.

    This is a widely used library that's been around
since 1993.  Like the other code in Graphics Gems, it
is available without any restrictions, so there's no
intellectual property problem.

     John Nagle
     Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3C27D1F4.3E80CB9F@animats.com>, John Nagle <nagle@animats.com>
wrote:
>   I'd like to suggest that a standard library for small vectors
>and matrices (up to 4x4) be defined in the next round of the standard.
>In graphics work, these structures come up all the time, and
>every graphics program has some representation for them.
>It's quite common to have three or four such libraries in a
>program, since there's no standard on this.  Interconverting between
>these representation is a constant headache.

One interesting thing is that spline (Bezier) curves, plane curve segments
parametrized by degree three polynomials, generalize to higher dimensions:

Define the n-simplex Delta^m to be the set Delta^m := { x in R^(m+1) | sum
x_i = 1, x_i >= 0 } (non-negative coordinates of sum 1), and define an
m-dimensional spline simplex in R^n (m <= n) to be a map Delta^m -> R^n
such that all the coordinate functions of this map are polynomials of
degree at most 3. Such simplicies can be naturally glued together if their
boundaries joined together.

Then it seems me that, just as the Bezier curves are important in graphics
in dimension n = 2, the case n = 3 might be useful for 3D modeling.
Further the case n = 3, 4 might also be important for the modeling of 2D
and 3D objects evolving in time.

So while at it, one should perhaps add some such library.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]