Re: [Caml-list] string_of_float less accurate than sprintf "%f" ?

Re: [Caml-list] string_of_float less accurate than sprintf "%f" ?

[David Chase]

Ignore the previous mail, Eudora, sent it for me when
I stumbled across ctrl-E, and I changed my mind about
sending it anyway.

David Chase

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] string_of_float less accurate than sprintf "%f" ?

[David McClain]

David Chase writes:

"It's also not entirely clear what rounding you are supposed
to get when you ask for less-precise printing.  The possibilities
include:
....
"

These rounding modes are controlled by bits in a control register.
Separating them from the format string allows one to test the stability of
the entire (or portions) of the math code. I have never seen anyone attempt
to plant this specification inside of a format string. If it matters for
printout, then surely it also matters elsewhere in the code.

- DM

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] string_of_float less accurate than sprintf "%f" ?

[David Chase]

[-- Attachment #1: Type: text/plain, Size: 3540 bytes --]

At 10:53 AM 5/4/2002 +0200, Xavier Leroy wrote:
>I'm not taking sides here, just noticing that Java takes the computer
>engineering viewpoint and C (and Caml, by inheritance of
>implementation :-) takes the physicist's viewpoint...

I think it is more likely that C "just happened".  Among
other things, White and Steele had not yet written their
paper on converting machine numbers to strings at the time
C was created.

The computer engineering viewpoint (in this case) is the correct
one for GENERAL use, because it guarantees that no matter
how many times you parse and unparse a floating point number,
you keep the same value.  This seems like a good thing to me.
It may be a value that is an approximation to an inaccurately
measured quantity, but after the initial input-to-FP translation,
the wiggling stops.  This does have one problem, in that the
number of digits printed may vary quite a bit (e.g., between
1.25 and 1.333333333333333) depending upon whether a number
has an exact binary representation.

Because of this problem, and because the number of actually
meaningful digits may vary, it makes plenty of sense to have
ways to print that do allow finer control.  I am not sure that
either C or Java is worth blindly following here.  Java's
decimal format code is a bit baroque in its corner cases
(depending upon how you encode the # and 0 and . and , in its
input, you can describe normal notation, scientific notation,
and engineering-scientific notation.  Unfortunately, the
input notation allows you to say many things that are
nonsensical, and it is not immediately evident what is
desired by looking at a format string).

It's also not entirely clear what rounding you are supposed
to get when you ask for less-precise printing.  The possibilities
include:

1.   round-toward-zero
2.   round-toward-positive-infinity
3.   round-toward-negative-infinity
4.   round-toward-infinity
5.   round-to-nearest-even-if-tie (1.5 --> 2, 2.5 --> 2)
6.   round-to-nearest-rti-if-tie  (1.5 --> 2, 2.5 --> 3, -1.5 --> -2)

1-3,5 correspond to modes often found supported by hardware.
5     is the default answer from numerical people; I think it
      loses the smallest amount of information without introducing
      a bias.
6     is what I think most people expect to see.

What often gets implemented (e.g., by Sun in their implementation
of java.text.DecimalFormat) is actually a combination of two of
these -- first the number is formatted out to "full" (adequately
precise) form (this assumes some sort of rounding), and then that
is reduced in size using some more rounding.  Double-rounding is
bad -- in the worst case, you might arrive at 1.45 rounding (once)
to 1.5 rounding (twice) to 2.0, which is clearly wrong.  The
magnitude of the error is generally much smaller in actual
formatting (1.4999999999995 rounding to 1.5, e.g.) but it is still
an error, and it is avoidable at low or no cost.  Gdtoa from netlib
will do this for you -- I have used it myself, for an implementation
of java.text.DecimalFormat -- and it provides control over the
rounding of the output as well.  (I've attached a test program that
illustrates this, crudely.  It requires gdtoa, obviously.)

But (on the other hand) I really haven't a good idea how
someone might go about elegantly specifying desired rounding
in formatting.  It does matter -- people working with money
(at least in the US) have very definite opinions about how
half of anything is supposed to round (it rounds away from zero,
towards the nearest infinity).

David Chase

[-- Attachment #2: tfp.c --]
[-- Type: text/plain, Size: 1657 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include "gdtoa.h"

FPI fpi_near = {
  53, 1-1023-53+1, 2046-1023-53+1, 1, 0
};

FPI fpi_zero = {
  53, 1-1023-53+1, 2046-1023-53+1, 0, 0
};

FPI fpi_up = {
  53, 1-1023-53+1, 2046-1023-53+1, 2, 0
};

FPI fpi_down = {
  53, 1-1023-53+1, 2046-1023-53+1, 3, 0
};

typedef __int64 s64;

char * mygdtoa( double d, int mode, int ndigits, FPI * amper_fpi) {
  s64 l = * (s64*)&d;
  int i0 = (int) (l >> 32);
  int i1 = (int) l;
  int m0 = i0 & 0xfffff;
  int e0 = (i0 >> 20) & 0x7ff; 
  int isNeg = i0 < 0;
  int mantissa[2];
  int decpt;
  int kind = STRTOG_Normal;
  char * result;
  char * rve;
  int length;

  if (e0 == 0x7ff) {
    if ((m0 | i1) != 0) {
      return "NaN";
    } else {
      return isNeg ? "-Infinity" : "Infinity";
    }
  }
  if ((m0 | i1 | e0) == 0) {
    return isNeg ? "-0.0" : "0.0";
  }

  if (e0 != 0) m0 |= 0x100000;
  else e0 = 1;

  e0 -= 0x3ff + 52;

  mantissa[0] = i1;
  mantissa[1] = m0;

  
  result = gdtoa(amper_fpi, e0, mantissa, &kind, mode, ndigits, &decpt, &rve);

  length = rve - result;
  return result;
}

test1(double x, int n) {
  printf("near %d %s\n", n, mygdtoa(x,2,n, &fpi_near)); 
  printf("zero %d %s\n", n, mygdtoa(x,2,n, &fpi_zero)); 
  printf("up   %d %s\n", n, mygdtoa(x,2,n, &fpi_up)); 
  printf("down %d %s\n", n, mygdtoa(x,2,n, &fpi_down)); 
  
}

void test (double x) {
  test1(x,1); 
  test1(x,5); 
  test1(x,6); 
  test1(x,7); 
  test1(x,8); 

  test1(-x,5); 
  test1(-x,6); 
  test1(-x,7); 
  test1(-x,8); 

  printf("\n");
}

int main(int argc, char ** argv) {
  test (0.40999995);
  test (0.40444449);
  test (1.5);
  test (2.5);
}

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: [Caml-list] string_of_float less accurate than sprintf "%f" ?

[John Max Skaller]

David Chase wrote:

>
>If someone decides to do this, please contact me, I have
>a list of fixes necessary for correct compilation of fdlibm
>under Microsoft's incorrect C compilers.  Some ninny thought
>that the distributive law held true for machine FP, and they
>don't constant propagate "funny values" (NaN, -0) properly.
>
Best not label their compilers "incorrect" -- unless you can
quote the paragraph of the ISO C Standard that they violate :-)


-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] string_of_float less accurate than sprintf "%f" ?

[John Max Skaller]

Francois Thomasset wrote:

>>Beck01, Wolfgang wrote:
>>
>>There's another problem too:
>>
>># string_of_float 42.0;;
>>- : string = "42"
>>
>>The result isn't an ocaml float literal.
>>
>Is it not?
># float_of_string (string_of_float 42.0);;
>- : float = 42
>So if you know that there is a float in the string, it is a float isn't it?
>
It isn't a floating point literal, in ocaml, C, or any other language.
Floating point literals always have either a decimal indicator
or an exponent. It should return "42.0", in my opinion:
"42" is an integer.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] string_of_float less accurate than sprintf "%f" ?

[David McClain]

Xavier Leroy writes:

> There might be a more philosophical issue behind this.  For a
> numerical analyst, or physicist, or experimental scientist in general,
....

I am such a scientist, and in fact the numeric representation I seek
generally depends heavily on the experimental precision available. So I
ended up writing a flexible printf routine in OCaml to support printing only
as many decimal places as afforded by the standard deviation of my
measurements. It was easy to do, but it did require the use of magic...

Here is the general formatting routine...

let fmt_val_sigma title value sigma =
  let rec iter sf x =
    if x >= 1.0 then
      if sf > 4 then
 printf "%g (%g)\n" value sigma
      else
 printf (U.as_format
    (sprintf "%%%d.%df (%%%d.%df)\n"
       (sf + 3) sf (sf + 2) sf))
   value sigma
    else
      iter (sf + 1) (x *. 10.0)
  in
    printf "%20s = " title;
    if sigma = 0.0 then printf "%g\n" value
    else
      iter 0 sigma

Here is a sample of its use...

     fmt_val_sigma "psf_scale"  sys.parms.psf_scale sigma_scale;

where the value of interest is psf_scale, and its standard deviation is
sigma_scale. The rouitne above examines the standard deviation and
determines the appropriate print format, typically in the form  "title 1.03
(5)"  where the value is 1.03 and the standard deviation is 0.05, or (5) in
the last place...

And here is the "magic" in module Utility.ml and Utility.mli (the
U.as_format in the above code)

Utility.mli:
(* convert a dynamic string to a printf format *)
val as_format : string -> ('a, out_channel, unit) format

Utility.ml:
(* as_format allows to build a string that can later be used *)
(* as a printf format string *)
let as_format (str : string) =
  (Obj.magic str : ('a,out_channel,unit) format)

Cheers,

- David McClain, Sr. Scientist, Raytheon Missile Systems Co., Tucson, AZ

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] string_of_float less accurate than sprintf "%f" ?

[Xavier Leroy]

> while doing some time measurements with Unix.gettimeofday() I
> discovered a problem with string_of_float:
> 
> # string_of_float 123456789.123456789;;
> - : string = "123456789.123"
> 
> OK, just it may by just an inaccuracy of the float type. However,
> sprintf returns a different result:
> 
> # sprintf "%f" 123456789.123456789;;
> - : string = "123456789.1234567"

This is not an inaccuracy of the underlying float value, which is
indeed double-precision, but a consequence of the definition of
string_of_float, which is essentially sprintf "%.12g".  So, you get a
different rounding than sprintf "%f".  Here, %f is more precise, but
not always (try with 1e-12 for instance).

> My application needs to be fast (that's why I am using OCaml :-) and
> sprintf is of course slower than string_of_float.

Not by much.  I recommend that you use sprintf with the floating-point
format appropriate for your application, e.g. "%.3f" for printing
times with a millisecond precision.  

Now, you might wonder why string_of_float doesn't "do the right thing"
and prints its float argument with as many digits as necessary to ensure
e.g. float_of_string(string_of_float f) = f.  The main reason is
pragmatic: OCaml's float-to-string conversions are built on top of the
sprintf() function from the C runtime library, and the latter doesn't
provide a "print a float with enough digits to represent it exactly"
format.  David Chase mentioned some third-party source that does this
(thanks for the pointer); I wish the C library would provide something
like this.

There might be a more philosophical issue behind this.  For a
numerical analyst, or physicist, or experimental scientist in general,
floating-point numbers are just approximate measurements of
experimental measures, or results of computations on these approximate
measurements.  Hence, there is no such thing as "the" string
representation of a floating-point value: not all digits are meaningful,
and how many significant digits to print depends on the physical
problem being modeled and solved.  With this viewpoint,
string_of_float doesn't make any sense, and you should always use
sprintf with the float format appropriate for your problem.

Then, there is the computer engineering viewpoint on floating-point
numbers, which are collections of (say) 64 bits with well-defined (if
a bit convoluted) operations on them such as addition, multiplication,
etc, as specified in IEEE 754.  From this viewpoint, it makes sense to
have conversions to and from strings that are exact, i.e. without
information loss.  (It is feasible, but much harder than it sounds;
there was two full papers at PLDI 94 (?) on this problem.)

I'm not taking sides here, just noticing that Java takes the computer
engineering viewpoint and C (and Caml, by inheritance of
implementation :-) takes the physicist's viewpoint...

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] string_of_float less accurate than sprintf "%f" ?

[David Chase]

At 04:41 PM 5/3/2002 +0200, Oliver Bandel wrote:
>But a problem can occur too, when the type is not known
>from within the program: When writing the string-representation
>of a float to a file and read it back from the file,
>then the non-float representation of the float yields
>in parsing-/type-problems.
>So that is a problem within the program and it's data
>(I/O)... So this seems to be actually a problem.
>
>If (string_of_float 42.0) yields "42.0" (instead of "42"),
>this maybe is not the right value, because it maybe is only
>correct as "42.0000000000000"?

>Well.... philosophical question?

The "right" answer is to steal from Java, assuming that the
floating point data types are relativ

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] string_of_float less accurate than sprintf "%f" ?

[Oliver Bandel]

On Thu, 2 May 2002, John Max Skaller wrote:

> Beck01, Wolfgang wrote:
> 
> >Hello,
> >
> >while doing some time measurements with Unix.gettimeofday() I
> >discovered a problem with string_of_float:
> >
> ># string_of_float 123456789.123456789;;
> >- : string = "123456789.123"
> >
> There's another problem too:
> 
> # string_of_float 42.0;;
> - : string = "42"
> 
> The result isn't an ocaml float literal.

Well... but the type is not necessarily an int though.

The type is a float, even if the representation looks like
an int.
The only problem here is that it's confusing for human readers.
But is it necessary that a type can have only one possible
representation?

A problem only occurs with type inference... you can not
say that 42 is a float-value: the type inference always
says, that 42 is an int:
# 42;;
will not yield a float.

This is confusing. I had problems with it too.


But when you look at the following example, you see, that
the type will be used correct and is not derived from it's
representation:


##################################################
oliver@first:/home/oliver > ocaml
        Objective Caml version 3.04

# type mytype = Nothing | Value of float;;
type mytype = Nothing | Value of float
# let x = Nothing;;
val x : mytype = Nothing
# let y = Value 42;;
This expression has type int but is here used with type float
# let y = Value (float_of_string "42");;
val y : mytype = Value 42
# let z = Value (float_of_string (string_of_float 24.0));;
val z : mytype = Value 24
# let zz = Value  (float_of_string (string_of_float 33));;
This expression has type int but is here used with type float
# 
##################################################


Value is of type float and Ocaml works correctly with it.
So this is not really a problem.
It seems to be only a problem, when type inference is
used - so it's a problem in human-machine-interfacing.

But a problem can occur too, when the type is not known
from within the program: When writing the string-representation
of a float to a file and read it back from the file,
then the non-float representation of the float yields
in parsing-/type-problems.
So that is a problem within the program and it's data
(I/O)... So this seems to be actually a problem.


If (string_of_float 42.0) yields "42.0" (instead of "42"),
this maybe is not the right value, because it maybe is only
correct as "42.0000000000000"?


Well.... philosophical question?


Ciao,
   Oliver

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] string_of_float less accurate than sprintf "%f" ?

[jeanmarc.eber]

En réponse à John Max Skaller <skaller@ozemail.com.au>:

> There's another problem too:
> 
> # string_of_float 42.0;;
> - : string = "42"
> 
> The result isn't an ocaml float literal.

This has been corrected in the working version a few weeks ago
I think. (Pervasives.ml 1.47).

Jean-Marc Eber
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] string_of_float less accurate than sprintf "%f" ?

[David Chase]

At 10:44 PM 5/2/2002 +1000, John Max Skaller wrote:
>Beck01, Wolfgang wrote:
>
>>while doing some time measurements with Unix.gettimeofday() I
>>discovered a problem with string_of_float:
>>
>># string_of_float 123456789.123456789;;
>>- : string = "123456789.123"

>There's another problem too:
>
># string_of_float 42.0;;
>- : string = "42"
>
>The result isn't an ocaml float literal.

I'm new to Caml, but I did manage to slog through the sources
enough to determine that Caml does it "wrong", at least as
measured against what is possible and freely available.

A version of the Java rules would be appropriate
here -- as many digits as necessary to disambiguate from
any other machine double/float, or at least one fractional
digit, whichever is shorter.  David Gay wrote some code to
do this (gdtoa) that is available at netlib, and (having
glued this code to a Java VM) I can provide some guidance
in using it, if you would like.  You can also use gdtoa to
get other sorts of formatting -- n digits past the point,
that sort of thing.

Similarly, the transcendental functions available in fdlibm
(Freely Distributable libm) are almost as fast as hardware
(on those machines where there is hardware), but avoid the
stupid input limits (e.g., |x| < 2**64) and also use a large
enough value of PI to always deliver a result that is within
1 ulp, usually within 1/2 ulp (I have studied this problem
more than I care to).  The results will be fast, portable
across all platforms, and as correct as you are likely to
get, certainly as good as you are likely to get for free.

Note: where available, hardware sqrt and log are usually
usable, though I have not checked carefully in those
portions of domain where their derivative is > 1.

If someone decides to do this, please contact me, I have
a list of fixes necessary for correct compilation of fdlibm
under Microsoft's incorrect C compilers.  Some ninny thought
that the distributive law held true for machine FP, and they
don't constant propagate "funny values" (NaN, -0) properly.

yours,

David Chase

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] string_of_float less accurate than sprintf "%f" ?

[Francois Thomasset]

> Beck01, Wolfgang wrote:
> 
> There's another problem too:
> 
> # string_of_float 42.0;;
> - : string = "42"
> 
> The result isn't an ocaml float literal.
> 
Is it not?
# float_of_string (string_of_float 42.0);;
- : float = 42
So if you know that there is a float in the string, it is a float isn't it?

-- 
					François Thomasset.
					INRIA (A3)

Francois.Thomasset@inria.fr		Tél.: +33 (1) 39-63-54-75
					Fax: +33 (1) 39-63-59-95
INRIA, Rocquencourt, BP 105, 78153 Le Chesnay Cedex, France


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] string_of_float less accurate than sprintf "%f" ?

[John Max Skaller]

Beck01, Wolfgang wrote:

>Hello,
>
>while doing some time measurements with Unix.gettimeofday() I
>discovered a problem with string_of_float:
>
># string_of_float 123456789.123456789;;
>- : string = "123456789.123"
>
There's another problem too:

# string_of_float 42.0;;
- : string = "42"

The result isn't an ocaml float literal.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] string_of_float less accurate than sprintf "%f" ?

[Beck01, Wolfgang]

Hello,

while doing some time measurements with Unix.gettimeofday() I
discovered a problem with string_of_float:

# string_of_float 123456789.123456789;;
- : string = "123456789.123"

OK, just it may by just an inaccuracy of the float type. However,
sprintf returns a different result:

# sprintf "%f" 123456789.123456789;;
- : string = "123456789.1234567"

I am using ocaml 3.02 under FreeBSD 4.5. However, the 'Changes' file
did not mention string_of_float in more recent ocaml versions.

My application needs to be fast (that's why I am using OCaml :-) and
sprintf is of course slower than string_of_float.

Did I miss a 'double' type in the manual?

--
Wolfgang Beck
T-Systems Nova GmbH 
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners