caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Tung Vu Xuan <toilatung90@gmail.com>
To: "Soegtrop, Michael" <michael.soegtrop@intel.com>
Cc: Jacques-Henri Jourdan <jacques-henri.jourdan@normalesup.org>,
	 "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] Approximations when converting from string to float
Date: Tue, 25 Oct 2016 18:58:19 +0200	[thread overview]
Message-ID: <CAFxmOcQwFS-_46nEv6btOYdK82Pj=LtP3BNTvR4zxkTkjJE0SQ@mail.gmail.com> (raw)
In-Reply-To: <0F7D3B1B3C4B894D824F5B822E3E5A172CFA06ED@IRSMSX102.ger.corp.intel.com>

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

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> 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
> 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

[-- Attachment #2: Type: text/html, Size: 9138 bytes --]

  reply	other threads:[~2016-10-25 16:58 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 [this message]
2016-10-25 17:04         ` Jacques-Henri Jourdan
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='CAFxmOcQwFS-_46nEv6btOYdK82Pj=LtP3BNTvR4zxkTkjJE0SQ@mail.gmail.com' \
    --to=toilatung90@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=jacques-henri.jourdan@normalesup.org \
    --cc=michael.soegtrop@intel.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;
as well as URLs for NNTP newsgroup(s).