From: Xavier Leroy <xavier.leroy@inria.fr>
To: Thorsten Ohl <ohl@hep.tu-darmstadt.de>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Printf: variable field width/precision
Date: Fri, 12 Oct 2001 16:23:47 +0200 [thread overview]
Message-ID: <20011012162347.D18676@pauillac.inria.fr> (raw)
In-Reply-To: <200110081609.f98G9T131189@heplix4.ikp.physik.tu-darmstadt.de>; from ohl@hep.tu-darmstadt.de on Mon, Oct 08, 2001 at 06:09:29PM +0200
> In the C library, printf(3) supports variable field widths and
> precisions with the `*' specifier.
> Unfortunately, neither the O'Caml library nor the compiler accept `*'.
> If the `*' form is available, the `*m$' form is hardly needed, but I
> couldn't find a way to hack around the missing `*' (handling every
> conceivable width/precision pair as a special case doesn't count ...).
>
> Is there are chance that variable field widths for the benefit of
> numerical programs will be supported in the future?
I've never needed the '*' specifier so far, but I agree this should be
supported at some point. As far as I can say, this requires a bit of
work, though.
> [It would be easy
> to hack the library, but since the compiler must perform its own magic
> for type safety, I couldn't distribute the code without asking users
> to patch the compiler.]
Well, you could always donate us the code, which would then end up in
the standard distribution, making life really easy for users :-)
> Or does anybody know a nice workaround?
You could write a wrapper around the low-level "format_float"
primitive, i.e.
external format_float: string -> float -> string = "format_float"
let format_float_variable width prec f =
format_float (Printf.sprintf "%%%d.%de" width prec) f
Not terribly nice, I agree.
Concerning your other request:
> The C library header file <float.h> contains (among others) the
> following useful macros:
> /* Number of decimal digits of precision in a double */
> #define DBL_DIG 15
> /* Difference between 1.0 and the minimum double greater than 1.0 */
> #define DBL_EPSILON 2.2204460492503131e-16
> /* Minimum normalised double */
> #define DBL_MIN 2.2250738585072014e-308
> /* Minimum int x such that 10**x is a normalised double */
> #define DBL_MIN_10_EXP (-307)
> /* Maximum double */
> #define DBL_MAX 1.7976931348623157e+308
> /* Maximum int x such that 10**x is a representable double */
> #define DBL_MAX_10_EXP 308
> It would be great if these values were accessible from O'Caml in a
> future version so that numerical code could be made to work on
> different machines.
This is very reasonable indeed. Thanks for the suggestion.
- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
next prev parent reply other threads:[~2001-10-12 14:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-08 16:09 Thorsten Ohl
2001-10-12 14:23 ` Xavier Leroy [this message]
2001-10-12 17:31 ` Alan Schmitt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011012162347.D18676@pauillac.inria.fr \
--to=xavier.leroy@inria.fr \
--cc=caml-list@inria.fr \
--cc=ohl@hep.tu-darmstadt.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox