[Development] Move math3d from QtGui to QtCore

[Charley Bay]

<snip, possibly move "math3d" folder out-of-"QtGui">

charley spaketh:
>
<snip, need not-coupled-to-GUI domain-specific math3D stuff>

> > (We currently have our own 2D and 3D math libs, but if Qt had a non-GUI

> coupled lib, we could use it.)
>

Thiago respondeth:

> Can you tell me whether those classes would suffice to your needs?
>

Inside "math3d" I see some "qvector") stuff (2d, 3d, 4d), a
"qgenericmatrix", "qmatrix4x4", and some math-utility stuff (2d, 3d).

Short answer:  Yes, we could use this.  Some Qt stuff is "better" than our
home-grown stuff (like "fuzzy-compare" and other "quaternion" stuff -- we
didn't do that, we are mostly "Cartesian", but expect to need more
transform-stuff as we move to OpenGL, and we would prefer to not write
that).  Both Qt and ours should both be cross-platform, but Qt is proven
and ours is not, so that would be in-Qt's-favor.

We have a domain-specific need for "2DMatrix-inversion", which isn't yet
supported by Qt, but that's easy enough to add (just standard
matrix-math-inversion).  (There's a "special-case" where some 2D matrixes
cannot be inverted, and we had to handle that, so it would be nice if Qt's
implementation dealt with that too.  There's another special case where you
can "fiddle" with a cannot-be-inverted matrix to make it "invertible", and
it would be nice if Qt's implementation did that too.)  But, worst case, we
could use Qt's class and have an external algorithm do that inversion.
 (I'll also check at work to see if we can contribute that code, maybe, I
don't know.)

However, the "biggest-advantage" that I see for us to move to Qt's classes
would be for us to *avoid* the marshaling-to-a-different-data-structure
when interfacing with Qt's GUI or other modules (e.g., exposing Qt-classes
as bound-properties to QML), so that we don't keep copy-constructing
"QVector3D" from "MyVector3D".  There's not really anything "special" or
"clever" in our code, we just needed it throughout our model.  So, it would
be nice to have one-set-of-point-and-line-and-vector-and-matrix-types.

If it didn't really "fit-in" to the "QtCore" (I see your point), I'd
probably vote to put it into a "QtGeometry" (or "QtGeometry3D").  Even if
it's currently "small", I expect it would grow -- it would be nice to have
a package where we could "dump" new algorithms that are generally useful.

For example, (our domain again), we deal with *lots* of N-dimensional
parametric data.  There are *tons* of generic-algorithms that are useful to
identify populations, establish bounds on data sets, perform "smoothing",
compute population-and-data-set-statistics, perform transforms, establish
"contours", etc.  We have algorithms for all of these on 1D and 2D and some
3D, and are moving more into N-D.  Any of these algorithms could be
interesting/relevant to a number of applications, from mere
GUI-manipulation, to audio-data-sets, to "edge-detection", to
GIS/Spatial-data-analysis/Remote-Sensing, etc.  (Our domain uses them for
biology/cell-populations.)

For example, it would be nice IMHO for "QVector2D" to have even-basic-stuff
like "min", "max", and maybe "mode".  For our domain, we live-and-die on
"CV" and "Standard Deviation", so if those had to be "external" to QVector,
that's ok.  (We compute all stats through one-pass-through-the-matrix, and
it is incredibly fast.)  However, QVector2D already supports
addition-and-subtraction-and-scaling (we need those), so it's useful now.

(Hmm... QVector2D is based on "qreal", would be nice if we had an "integer"
option, as we often "increment(x,y)" when they represent "2D-histograms".
 Ours are all implemented as templates.  But, we could go-all-floating as
long as the performance was there.)

I'm not sure where Qt/QML is at-the-moment with "handwriting-recognition"
or "stylus-input" (e.g., "gestures-algorithms"), but those types of
gesture/stroke-analysis would also lend-well to 2D data-set-algorithms
(usually 3+D, as one must deal with stylus "pressure" and "velocity" in
addition to the 2D surface).

I don't mean to "explode" this topic.  However, my selfish goal would be:

(1) "GUI-Model-Reflection" -- Generic math/geometry data structures *not*
coupled-to-GUI, but which are the same physical types *used* by GUI.  Then,
the GUI would merely "reflect-the-model-directly" (e.g., no
marshaling-to-different data-structures.)  (We did this in the past in MFC,
amazingly fast, I can elaborate if people are interested.)

(2) "Out-Of-The-Box-Basics" -- Generic math/geometry algorithms to
manipulate/transform/compute-stats (just basic stuff would be great, some
of that is already present through "fuzzy-compare" and "rotateVector",
etc.).

...and it would be simple for users to extend with their own
domain-specific algorithms as-needed.  But, we could "share" algorithms
more, as IMHO most "domain-specific" algorithms are actually
generically-useful algorithms that are surprisingly applicable/relevant to
completely-unrelated domains.

For example, I've personally implemented some very-rich "typesetting"
libraries.  However, when it comes-down-to-the-details, the "heavy-lifting"
is actually something that looks a whole lot like QLayout in what it's
trying-to-achieve (e.g., most math algorithms are generically
useful/interesting).

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120704/ba3fc0c5/attachment.html>