String Representation of floating point values: *PROPOSAL*

[Barry McMullin]

Here's the story: I was probing a pair of double values
that ought to add up to 1.0; their displayed values
were:

  0.993307
  0.00669285

Guess what - they don't add up to one...

After a bit of scratching around I realised that what was
happening was that the displayed value was generated
with the good old "%f" type specifier (well - strictly,
%g, but that is equivalent to %f with these numbers);
in the absence of any explicit precision, this got
rendered as 6 significant digits - and, indeed, both
numbers above have just 6 significant digits.  And, the
"real" values inside the machine do indeed properly add
up to 1.0.

That was a bit counter-intuitive.  I feel it would be
better to display the "full" precision (which will
normally differ, of course, for float and double),
since presumably, if one is using double, one may be
interested in those extra digits.  But it's not fatal -
the internal values are still "right".

A more serious issue arises with floating point values
saved to disk using OutFile.  These also get limited to
6 sig digits.  Given that, quite typically, I'll reload
these values and expect to get (as near as possible)
"exactly" the same values, this is a real issue.

The "right" solution to both these issues would seem to
be that the programmer should be able to control or
specify exactly what conversion format they want to use
in each case (i.e. effectively be able to provide the
printf style format string they want used).

Unfortunately, providing this "right" solution is a
non-trivial exercise.  I would hope that the swarm team
would think about putting this on the "to-do" list
somewhere, but I can't see it as a high priority item.

So, in the meantime, I have a couple of PROPOSALS.
These are directed to the swarm team, as requests for
short term changes in the behaviour of Swarm, which
should be relatively quick and easy to implement. BUT:
they may significantly affect the way existing apps
behave, or are *perceived*, so I would appeal for anyone
opposed to these proposals to SHOUT NOW if they object
to these changes.


PROPOSALS:

The essential idea is that, *wherever* there is a
"default" conversion from floating point to string in
Swarm, which is currently done with "%g" (VarProbe) or
"%f" (OutFile), this default should be changed to a
format which preserves, as far as possible, *all*
precision and, for preference, is of fixed overall
width.  This effectively means changing to something
like "%+24.16e" for 64-bit IEEE (that's off the top of
my head - I'd have to look up the docs to get it just
right, but it should give you the general flavour I
have in mind).

This can be divided into two separate proposals:

1: Do this for probeDisplays.  The drawback is that,
where the numbers are typically "close" to 1.0, some
people might find the enforcement of scientific
notation (%e), and lots of digits, aesthetically
displeasing compared to the current displays.  On the
other hand, this is science, not art (;-)

2: Do this for OutFile.  I don't see *any* downside in
this case.



Again: the point is, if you do *not* want this, please
shout about it now - otherwise, I will be pressing the
developers to take it on board asap.


Cheers,

- Barry.


-- 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| Barry McMullin, ALife Group,               |    address@hidden |
| Santa Fe Institute, 1399 Hyde Park Road,   |  Voice: +1-505-984-8800 |
| Santa Fe, NM 87501, USA.                   |  FAX:   +1-505-982-0565 |
| http://www.eeng.dcu.ie/~mcmullin           |                         |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================