Re: Configuration on IceLake

2021-09-06 Thread Torbjörn Granlund
Arturo Fernandez  writes:

  I wasn't expecting Nehalem so my guess is that it doesn't recognize
  IceLake and is assigning some default value.

We let all unknown "model" numbers mean nehalem.  This is so that both
unknown low-end cores and unknown high-end cores will at least work.

There have been plans to refine this by checking various features (such
as AVX) and from the result match the closest known microarch.  E.g. if
a "model" number appears which has all the features of, say, skylake,
assume skylake.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs


Configuration on IceLake

2021-09-06 Thread Arturo Fernandez

Hello,
Trying to configure GMP v6.2.1 in an IceLake system (running CentOS8) is 
returning:

Version: GNU MP 6.2.1
Host type: nehalem-pc-linux-gnu
ABI: 64
Install prefix: /usr
Compiler: gcc
Static libraries: yes
Shared libraries: yes
I wasn't expecting Nehalem so my guess is that it doesn't recognize IceLake 
and is assigning some default value.

Thanks.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs


Re: Rounding error

2021-09-06 Thread Frank Heckenbach
Marco Bodrato wrote:

> Il 2021-08-25 05:54 Frank Heckenbach ha scritto:
> > mpf_get_str seems to round incorrectly sometimes.
> > In this test program, the digits around 809 are "...244594553...",
> > so it should round to "...244595", but it outputs "...244594".
> 
> Here, your report says that you expected a "rounded" result,
> but you get a truncated one.
> 
> Il 2021-08-27 07:36 Frank Heckenbach ha scritto:
> > Actually, what I wanted is truncation, not rounding. But AFAICS
> 
> Here, you say that you actually want truncation.

Yes, I actually want truncation.

Since GMP does not support string conversion with truncation
(correct?), I tried to emulate truncation by subtracting 0.5e-P,
then rounding, which should give the same result as truncation
(e.g. 2.3 -> 1.8, rounded to 2; 2.8 -> 2.3, rounded to 2).

When I did this, I found that in some cases, rounding was wrong, and
after asking here, I learned that apparently GMP is not expected to
always round correctly.

Yes, it's true that the wrong rounding happens to be truncation,
but that doesn't help me, since it only occurs sometimes, so I never
know if what I get is rounded or truncated.

My solution (hopefully) is therefore to multiply by 1eP, convert to
mpz_t and insert the decimal point manually.

AFAICS, the conversion to mpz_t always truncates (correct?), so this
should work (albeit slightly slower, but I don't mind).

If I ever need correct rounding with GMP (I don't ATM), I think
I could add 0.5e-P, then (like above) multiply by 1eP, convert to
mpz_t and insert the decimal point manually.

> > there is no string conversion function with truncation (correct?),
> 
>  From the manual I read a general claim about functions using mpf:
> "Final results are always truncated to the destination variable's 
> precision."
> See https://gmplib.org/manual-6.2.1/Floating_002dpoint-Functions .
> 
> Do you have an example of the function not working as documented?

AIUI, this refers to mpf_t computations (i.e. where the destination
is a mpf_t), not conversion to string, so something else. (String
conversions are usually rounded, but not always.)

Viele Grüße,
Frank
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs