From: Jacques-Henri Jourdan <jacques-henri.jourdan@normalesup.org>
To: Tung Vu Xuan <toilatung90@gmail.com>,
"Soegtrop, Michael" <michael.soegtrop@intel.com>
Cc: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] Approximations when converting from string to float
Date: Tue, 25 Oct 2016 19:04:39 +0200 [thread overview]
Message-ID: <f1116b3f-471b-ef33-96fe-271f81123fd2@normalesup.org> (raw)
In-Reply-To: <CAFxmOcQwFS-_46nEv6btOYdK82Pj=LtP3BNTvR4zxkTkjJE0SQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4120 bytes --]
Ok.
But really, you should use ZArith, which is much more modern, faster and
well-maintained than Big_int.
On 10/25/2016 06:58 PM, Tung Vu Xuan wrote:
> Hi,
>
> Thanks for suggestions. Since I am using a library for interval
> arithmetic [1], your idea becomes easier for me.
>
> let intv_of_big_int bi =
> let n = Big_int.num_bits_big_int bi in
> if n <= 53 then
> let bi_float = Big_int.float_of_big_int bi in
> {low=bi_float;high=bi_float}
> else begin
> let n = n - 53 in
> (* Extract top 53 bits of x *)
> let top = Big_int.shift_right_big_int bi n in
>
> let top_float = Big_int.float_of_big_int top in
> (* interval [2, 2] *)
> let two_I = {low=2.;high=2.} in
> (* interval: [2, 2]**n *)
> let two_I_to_n = pow_I_i two_I n in
>
> (* compute upper bound of mantissa, represented as an intv *)
> (* interval arithmetic is needed because rounding error might
> occur *)
> let mantissa_upper_bound_intv = {low=top_float;high=top_float}
> +$ one_I in
>
> (* intv of mantissa *)
> let mantissa_intv = {low=top_float;
> high=mantissa_upper_bound_intv.high} in
> (* compute final interval *)
> mantissa_intv *$ two_I_to_n
> end
>
> [1] Alliot, J.M., Gotteland, J.B., Vanaret, C., Durand, N., Gianazza,
> D.: Implementing an interval computation library for OCaml on
> x86/amd64 architectures. In: ICFP. ACM (2012)
>
> Thanks again,
> Tung.
>
> On Tue, Oct 25, 2016 at 5:28 PM, Soegtrop, Michael
> <michael.soegtrop@intel.com <mailto:michael.soegtrop@intel.com>> wrote:
>
> Dear Jacques-Henri,
>
> if the number is cut off after n digits, the upper and lower
> bounds I suggested are the (truncated
> integer)*10^(#cut-off-digits) and (truncated
> integer+1)*10^(#cut-off-digits). The true number is obviously
> between these two. Since the integer has higher precision than the
> mantissa in the case of cut off, this is only a fraction of a
> mantissa bit. The errors you get by multiplying with the powers of
> 10 is likely larger in most cases.
>
> In the case you mentioned, 2^70=1180591620717411303424 and 32 bit
> one would truncate after
>
> 1180591620 * 10^12
>
> Maxima gives
>
> is(1180591620 * 10^12 <= 2^70);
>
> true
>
> is(1180591621 * 10^12 >= 2^70);
>
> true
>
> As I said, this method doesn’t give the tightest bounds possible,
> but it gives you true upper and lower bounds without multi
> precision arithmetic. It gives 0 intervals e.g. for integers which
> fit in the mantissa, but not for large exact powers of 2.
>
> > Moreover, it is not possible to implement interval arithmetic
> with OCaml, since you cannot change the rounding mode without a
> bit of C...
>
> It should be possible to make the powers of 10 tables such that
> this works even with round to nearest, but it would likely be
> easier to make a C library for this.
>
> Of cause it is a good question if I/O is the right place to save
> performance and waste precision. On the other hand you lose only 2
> or 3 bits and you know what the precision is. I would think most
> applications are such that the required precision is not exactly
> an IEEE precision, so that these 2 or 3 bits are ok. I used this
> method once in an embedded platform, where multi precision
> arithmetic was not an option, and this was a good compromise.
>
> Best regards,
>
> Michael
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>
>
>
>
> --
> Tung Vu Xuan,
> Japan Advanced Institute of Science and Technology,
> Mobile: (+81) 080 4259 9135 - (+84) 01689934381
> Hometown: Bac Ninh
> Email: toilatung90@gmail.com <mailto:toilatung90@gmail.com>
[-- Attachment #2: Type: text/html, Size: 11834 bytes --]
next prev parent reply other threads:[~2016-10-25 17:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-24 14:01 Tung Vu Xuan
2016-10-25 10:21 ` Jacques-Henri Jourdan
2016-10-25 11:20 ` Soegtrop, Michael
2016-10-25 11:24 ` Soegtrop, Michael
2016-10-25 14:19 ` Jacques-Henri Jourdan
2016-10-25 15:28 ` Soegtrop, Michael
2016-10-25 16:58 ` Tung Vu Xuan
2016-10-25 17:04 ` Jacques-Henri Jourdan [this message]
2016-10-25 18:07 ` Xavier Leroy
2016-10-26 9:38 ` Tung Vu Xuan
2016-10-26 8:08 ` Soegtrop, Michael
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=f1116b3f-471b-ef33-96fe-271f81123fd2@normalesup.org \
--to=jacques-henri.jourdan@normalesup.org \
--cc=caml-list@inria.fr \
--cc=michael.soegtrop@intel.com \
--cc=toilatung90@gmail.com \
/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