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

[Rodrigo Hernandez]

Terry L. Triplett wrote:

> On 6/22/06, *Rodrigo Hernandez* <kwizatz at aeongames.com 
> <mailto: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?   :-)

You alone seem to be  the vocal minority who advocates for a system wide 
library, I remember John Watte supporting the
position that a System Wide library was a bad idea the second to last 
time we discused sonames, (forgive me John if I am mistaken).

>
>     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.
>
We need to have a consensus, its not just "suck it up and make a 
decision", specialy since I think a single library with precision sufixes is
better than a library for each precision.

>     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.
>
Jason answered this one.

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

True, I am not going to argue with you here, as this seems to be arguing 
just for the sake of arguing.