Re: [Open Babel] floating-point stuff

[Craig A. J. <cj...@em...>]

Beno=EEt Jacob wrote:
>> Speaking for myself, I never took a
>> class in numerical programming, so it's nice to get some informed
>> feedback!
>
> Neither did I. I might have a @math mail address, but I don't work in t=
he field of numerical computation. I just read documentation on how doubl=
es are internally represented...

Well, I have taken classes in numerical methods, and Beno=EEt's suggestio=
n is the correct way to do it.  My only caveat is that whatever's done sh=
ould be transparent to the casual user -- the default is more-or-less con=
sistent with OB's past behavior and will suit a wide variety of ordinary =
problems.  Programmers should only have to worry about what epsilon means=
 if they have unusually precise computations to make, in which case this =
should all make sense to them anyway.

> Hmm, after hours trying to make a clever answer to that, I'm still not =
too sure. I understand your concern : if length() is small but nonzero, d=
ividing by it can lead to an overflow or to wild imprecision. So there ar=
e basically two kinds of problems we can meet:
>
> 1) division by zero, overflow, or other floating-point violations
> 2) inaccurate computations
>
> Maybe, a solution would be to use exception handling, but I can't say m=
ore because I've never used that c++ feature. I've googled a bit about th=
is, and it seems that it's difficult to do well.

It's not difficult, it's nearly impossible.  I'd say, don't even consider=
 exceptions.  Exceptions are one of the most powerful and useful elements=
 of C++, but they are also wholly incompatible with C.  Many OB applicati=
ons, including scripting languages like Perl and Python (and, speaking pe=
rsonally, my own code which is a plug-in to Postgres), have to put a C "w=
rapper" around the OB code in order to integrate it with other C applicat=
ions.=20
The problem with exceptions is that if you fail to put a "catch" in for e=
very possible exception, then the exception propagates up to the C code, =
and of course the C language has no exception-handling mechanism, and gen=
erates a fatal error.  It is critical that a library like OB *never* gene=
rate anything that will cause an exception or call exit(1) in any way, si=
nce OB is often used in high-availability servers that are expected to ru=
n for months or years without errors.  C++ exceptions are just an acciden=
t waiting to happen in such applications.

With Java, the language forces you to declare all exceptions with a "thro=
ws" statement, and if you call a function that throws and exception, you'=
re required to either handle the exception or declare that you will throw=
 the same exception.  That way, the compiler forces the information propa=
gates up and an app developer knows what exceptions might be thrown.  Not=
 so for C++.  Some low-level function can throw some exception, and bring=
 an entire server crashing down.  The app developer has to grep the entir=
e source tree to know what exceptions to expect.

My two cents for today.

Craig