[ODE] On the meaning of ODE stability (was some quick notes on 0; 6) ...

[Terry L. Triplett]

On 6/22/06, Rodrigo Hernandez <kwizatz at aeongames.com> wrote:
>
>
> Well, there is one single reason I (and others) think ODE should not be


Who are these mysterious others?  Will they not reveal themselves?   :-)

part of a distribution, and that is the dual library aproach.
> which one should you distribute? double or single precision? both? if
> you decide for either, some will require the other, if you go for both,
> then we need to decide on how will we be distinguishing them, make build
> changes and so on, this isnt imposible, and maybe not hard, but not
> exactly easy.


Not much in life is easy if worthwhile.  Suck it up and make a decision.

At the present state of technology?  Both, I'd say.

Distinguished by name (e.g. ode-single-<version>.<foo> and
ode-double-<version>.<foo>, where foo is the designation for shared or
static libraries on appropriate platforms).  Both produceable by a single
build step (ie, building ODE by default gives you both).

Having a clear choice of which precision to link to (dynamic linking) or
include (static linking) for a C++ library at development time is better
than having things blow up in your face because the wrong precision was used
against the single ODE library that was available.

Which brings me to a point I wanted to present for a while.
> I think we should standarize the function names so that there is a
> single library with single and double precision calls, much
> like OpenGL "f" and "d" suffixes, just throwing the idea into the air
> here.


And what about quad precision and beyond?  (
http://en.wikipedia.org/wiki/Quad_precision).  As technology advances,
notions like precision based on the number of storage locations in memory
seem quaint.  Pretty soon there will need to be "q" and "whatever" suffixes
as well.

Ultimately, the answer is likely to be multiprecision, arbitrary precision
data types.  Until then we have to live with what the language and compiler
designers give us.

As for 1.0, I dont see it as just a label, I think once 1.0 is reached,
> the library would be a full feature library with a stable, standarized
> API, 1.1 being backward compatible with it and so on, this is just my
> opinion though.


I guess I'd have to see a targeted feature list to be able to interpret what
"full feature" would mean.  1.0 *is* just a label, even if it resonates with
our human perception of numbers.

No matter what the label (ODE-1.0, or
ODE-745.453.3452.I_AM_REALLY_STABLE_HONEST_TRUST_ME), it is the agreed upon
development objective(s), not the label, that defines stability and full
featuredness.

Targeting features rather than labels is a better path for this kind of
project, IMHO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://q12.org/pipermail/ode/attachments/20060622/fd0dd1c1/attachment.htm