Groups > comp.lang.c++ > #81702 > unrolled thread

How to get mantissa of long double?

Started by	wij <wyniijj@gmail.com>
First post	2021-10-01 08:37 -0700
Last post	2021-10-03 18:46 -0700
Articles	20 on this page of 103 — 17 participants

Back to article view | Back to comp.lang.c++

  How to get mantissa of long double? wij <wyniijj@gmail.com> - 2021-10-01 08:37 -0700
    Re: How to get mantissa of long double? RadicalRabbit@theburrow.co.uk - 2021-10-01 16:09 +0000
      Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-01 14:05 -0400
        Re: How to get mantissa of long double? wij <wyniijj@gmail.com> - 2021-10-01 17:23 -0700
          Re: How to get mantissa of long double? Manfred <noname@add.invalid> - 2021-10-02 18:58 +0200
            Re: How to get mantissa of long double? Manfred <noname@add.invalid> - 2021-10-02 19:21 +0200
    Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 19:18 +0200
      Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 19:20 +0200
        Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 19:25 +0200
          Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 19:53 +0200
            Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-03 08:09 +0200
              Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-03 11:15 +0100
                Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-03 12:19 +0200
                  Re: How to get mantissa of long double? red floyd <no.spam@its.invalid> - 2021-10-03 18:03 -0700
                  Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-04 09:52 +0200
                    Re: How to get mantissa of long double? Juha Nieminen <nospam@thanks.invalid> - 2021-10-04 09:59 +0000
                    Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-04 13:50 +0200
                      Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-04 20:04 +0200
                        Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 07:12 +0200
                          Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-05 09:47 +0200
                            Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 16:46 +0200
                              Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-05 19:04 +0200
                                Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 19:13 +0200
                            Re: How to get mantissa of long double? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-05 09:04 -0700
                              Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 19:14 +0200
                                Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-05 19:21 +0100
                                  Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 07:58 +0200
                                    Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-06 08:11 +0200
                                      Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 10:25 +0200
                                      Re: How to get mantissa of long double? scott@slp53.sl.home (Scott Lurndal) - 2021-10-06 14:25 +0000
                                        Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 16:53 +0200
                                    Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-06 12:12 +0100
                                      Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 14:48 +0200
                                        Re: How to get mantissa of long double? red floyd <no.spam.here@its.invalid> - 2021-10-06 09:44 -0700
                                          Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 18:52 +0200
                                            Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 19:02 +0200
                                          Re: How to get mantissa of long double? Juha Nieminen <nospam@thanks.invalid> - 2021-10-07 05:35 +0000
                                            Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-07 08:20 +0200
                                              Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-07 08:38 +0200
                                                Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-07 08:42 +0200
                                                  Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-07 10:23 +0200
                                                    Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-08 20:23 +0200
                                                      Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-09 10:23 +0200
                                                        Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-09 10:50 +0200
                                                          Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-09 09:02 +0000
                                                          Re: How to get mantissa of long double? scott@slp53.sl.home (Scott Lurndal) - 2021-10-09 14:57 +0000
                                                        Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-09 12:16 +0100
                                                          Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-09 15:10 +0200
                                                          Re: How to get mantissa of long double? red floyd <no.spam.here@its.invalid> - 2021-10-09 10:26 -0700
                                                        Re: How to get mantissa of long double? Vir Campestris <vir.campestris@invalid.invalid> - 2021-10-12 21:23 +0100
                                                          Re: How to get mantissa of long double? RadicalRabbit@theburrow.co.uk - 2021-10-13 10:30 +0000
                                            Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-07 08:38 +0200
                                              Re: How to get mantissa of long double? Juha Nieminen <nospam@thanks.invalid> - 2021-10-08 04:37 +0000
                                                Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-08 07:54 +0200
                                              Re: How to get mantissa of long double? red floyd <no.spam.here@its.invalid> - 2021-10-07 22:44 -0700
                                          Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-07 08:17 +0200
                                            Re: How to get mantissa of long double? Juha Nieminen <nospam@thanks.invalid> - 2021-10-08 04:39 +0000
                                              Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-08 09:25 +0200
                                                Re: How to get mantissa of long double? scott@slp53.sl.home (Scott Lurndal) - 2021-10-08 14:34 +0000
                                      Re: How to get mantissa of long double? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-06 13:57 -0700
                                Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-05 19:34 +0000
                              Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-05 19:33 +0000
                          Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-05 10:19 +0000
                    Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-04 14:06 +0100
                      Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-04 16:12 +0200
                        Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 16:15 +0000
                      Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 16:15 +0000
                        Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-05 09:48 +0200
                      Re: How to get mantissa of long double? Juha Nieminen <nospam@thanks.invalid> - 2021-10-05 05:19 +0000
                        Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-05 10:00 +0200
                        Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 16:47 +0200
                    Re: How to get mantissa of long double? scott@slp53.sl.home (Scott Lurndal) - 2021-10-04 14:37 +0000
                      Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-04 16:53 +0200
                      Re: How to get mantissa of long double? scott@slp53.sl.home (Scott Lurndal) - 2021-10-04 17:08 +0000
                        Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-04 20:22 +0100
      Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-01 19:09 +0100
        Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 20:16 +0200
    Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-01 18:53 +0000
      Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-01 20:19 -0400
        Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 02:16 +0000
          Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-02 01:28 -0400
          Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-02 01:56 -0400
            Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 10:59 +0000
              Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-02 14:57 -0400
              Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-02 15:37 -0400
                Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 00:47 +0000
                  Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-03 23:42 -0400
                    Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 04:35 +0000
    Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 12:09 +0200
    Re: How to get mantissa of long double? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-10-02 21:00 +0200
      Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-02 15:12 -0400
        Re: How to get mantissa of long double? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-10-02 21:23 +0200
          Re: How to get mantissa of long double? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-10-02 21:27 +0200
            Re: How to get mantissa of long double? Manfred <noname@add.invalid> - 2021-10-02 23:19 +0200
          Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-03 23:43 -0400
        Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 00:45 +0000
          Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-03 23:31 -0400
            Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 04:34 +0000
              Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-04 11:30 -0400
                Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 16:19 +0000
      Re: How to get mantissa of long double? wij <wyniijj@gmail.com> - 2021-10-03 00:35 -0700
    Re: How to get mantissa of long double? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-03 15:02 +0100
      Re: How to get mantissa of long double? wij <wyniijj@gmail.com> - 2021-10-03 18:46 -0700

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →

#81741

From	James Kuyper <jameskuyper@alumni.caltech.edu>
Date	2021-10-02 01:28 -0400
Message-ID	<sj8qmd$88h$1@dont-email.me>
In reply to	#81733

On 10/1/21 10:16 PM, Branimir Maksimovic wrote:
> On 2021-10-02, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 10/1/21 2:53 PM, Branimir Maksimovic wrote:
>> ...
>>> long double max = cumeric_limits<long double>::max();
>>> long mantissa = max; // impicit conversion
>> "A prvalue of a floating-point type can be converted to a prvalue of an
>> integer type. The conversion truncates; that is, the fractional part is
>> discarded. The behavior is undefined if the truncated value cannot be
>> represented in the destination type." (7.3.10p1).
>>
>> While it's not required to be the case, on most implementations
>> std::numeric_limits<long double>::max() is WAY too large to be
>> represented by a long, so the behavior of such code is undefined. The
>> minimum value of LDBL_MAX (set by the C standard, inherited by the C++
>> standard) is 1e37, which would require long to have at least 123 bits in
>> order for that conversion to have defined behavior.
>> And even when it has defined behavior, I can't imagine how you would
>> reach the conclusion that this conversion should be the value of the
>> mantissa.
> It is not undefined as long is larger then mantissa part.

No, the relevant issue isn't the size of the mantissa. As stated above
in my quote from the standard, it's whether "the truncated value cannot
be represented in the destination type". std::numeric_limits<long
double>::max() doesn't have a fractional part, so the truncated value is
the same as the actual value. On my system, for instance, that value is
1.18973e+4932.

> ok correct is long long :P

On my system, changing it to long long doesn't make any different - the
maximum value representable by long long is still 9223372036854775807,
the same as the maximum value for long; it's still far too small to
represent 1.18973e+4932, so the behavior of the conversion is undefined.
The actual behavior on my system appears to be saturating at LLONG_MAX
== 9223372036854775807. If I change the second line to

    long long mantissa = 0.75*max;

0.75*max is 8.92299e+4931, which should certainly not have the same
mantissa as max itself, but the value loaded into "mantissa" is still
9223372036854775807.

[toc] | [prev] | [next] | [standalone]

#81746

From	James Kuyper <jameskuyper@alumni.caltech.edu>
Date	2021-10-02 01:56 -0400
Message-ID	<sj8s9l$gg7$1@dont-email.me>
In reply to	#81733

I accidentally sent this message first to Branimir by e-mail, and he
responded in kind.

On 10/2/21 1:31 AM, Branimir Maksimovic wrote:
>
>> On 02.10.2021., at 07:27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>
>> On 10/1/21 10:16 PM, Branimir Maksimovic wrote:
...
>> ok correct is long long :P
>> On my system, changing it to long long doesn't make any different - the
>> maximum value representable by long long is still 9223372036854775807,
>> the same as the maximum value for long; it's still far too small to
>> represent 1.18973e+4932, so the behavior of the conversion is undefined.
>> The actual behavior on my system appears to be saturating at LLONG_MAX
>> == 9223372036854775807. If I change the second line to
>>
>>    long long mantissa = 0.75*max;
>>
>> 0.75*max is 8.92299e+4931, which should certainly not have the same
>> mantissa as max itself, but the value loaded into "mantissa" is still
>> 9223372036854775807.
> Problem is that neither long double nor long is defined how small
> or large can be…
> so it can fit or not…
The C++ standard cross-references the C standard for such purposes, and
the C standard imposes strict limits on how small those things can be:
LLONG_MAX is required to be at least 9223372036854775807, and LDBL_MAX
is supposed to be at least 1e37.
You are right, however, about there being no limits on how large they
can be. It is therefore permissible for an implementation to have
LLONG_MAX >= LDBL_MAX, but do you know of any such implementation?
In any event, the relevant issue is not the limits imposed on those
values by the standard, but the actual values of LLONG_MAX and LDBL_MAX
for the particular implementation you're using, and it's perfectly
feasible to determine those values from <climits>, <cfloat>, or
std::numeric_limits<>::max. What are those values on the implementation
you're using?
> but question is how to extract mantissa which was answer :P

No, that is not the answer. If max did have a value small enough to make
the conversion to long long have defined behavior, the result of that
conversion would be the truncated value itself (7.3.10p1), NOT the
mantissa of the truncated value. What makes you think otherwise?

[toc] | [prev] | [next] | [standalone]

#81784

From	Branimir Maksimovic <branimir.maksimovic@icloud.com>
Date	2021-10-02 10:59 +0000
Message-ID	<YXW5J.79377$VZ1.39277@fx08.iad>
In reply to	#81746

On 2021-10-02, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> I accidentally sent this message first to Branimir by e-mail, and he
>
> No, that is not the answer. If max did have a value small enough to make
> the conversion to long long have defined behavior, the result of that
> conversion would be the truncated value itself (7.3.10p1), NOT the
> mantissa of the truncated value. What makes you think otherwise?
Because mantissa is whole part of floating point number?

-- 

7-77-777
Evil Sinner!

[toc] | [prev] | [next] | [standalone]

#81790

From	James Kuyper <jameskuyper@alumni.caltech.edu>
Date	2021-10-02 14:57 -0400
Message-ID	<sjaa2v$5vq$1@dont-email.me>
In reply to	#81784

On 10/2/21 6:59 AM, Branimir Maksimovic wrote:
> On 2021-10-02, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> I accidentally sent this message first to Branimir by e-mail, and he
>>
>> No, that is not the answer. If max did have a value small enough to make
>> the conversion to long long have defined behavior, the result of that
>> conversion would be the truncated value itself (7.3.10p1), NOT the
>> mantissa of the truncated value. What makes you think otherwise?
> Because mantissa is whole part of floating point number?

Well, at least I'm clear now about what your confusion is. I'll give you
an answer in two parts:
1. The mantissa of a floating point number (also called the significand,
which is the term used in the C standard in text that is incorporated by
reference into the C++ standard) is something quite different from the
whole part of that number. See
<https://en.m.wikipedia.org/wiki/Significand> for details.

2. When a floating point number is greater than LLONG_MAX+1.0, the code
you provided has undefined behavior. That makes sense, since a long long
object cannot represent the whole part of such a number. The actual
behavior can vary from one implementation to another, but on my system,
it does NOT contain the mantissa, either.

Consider the following program:

#include <iostream>

int main(void)
{
    typedef long double FType;
    FType max= std::numeric_limits<FType>::max();
    FType large = 0xA.BCDEF0123456789p+16380L;
    FType middling = 0xABCDEF01.23456789p0L;
    long long maxll = max;
    long long largell = large;
    long long middlingll = middling;

    std::cout << std::fixed << "max: " << max << std::endl;
    std::cout << "large: " << large << std::endl;
    std::cout << "middling: " << middling << std::endl;

    std::cout << "maxll: " << maxll << std::endl;
    std::cout << "largell: " << largell << std::endl;
    std::cout << "middlingll: " << middlingll << std::endl;

    std::cout << std::hexfloat << std::showbase << std::showpoint <<
        std::hex << "max: " << max << std::endl;
    std::cout << "large: " << large << std::endl;
    std::cout << "middling: " << middling << std::endl;

    std::cout << "maxll: " << maxll << std::endl;
    std::cout << "largell: " << largell << std::endl;
    std::cout << "middlingll: " << middlingll << std::endl;
}

The output from that program on my system is:

max:
1189731495357231765021263853030970205169063322294624200440323733891737005522970722616410290336528882853545697807495577314427443153670288434198125573853743678673593200706973263201915918282961524365529510646791086614311790632169778838896134786560600399148753433211454911160088679845154866512852340149773037600009125479393966223151383622417838542743917838138717805889487540575168226347659235576974805113725649020884855222494791399377585026011773549180099796226026859508558883608159846900235645132346594476384939859276456284579661772930407806609229102715046085388087959327781622986827547830768080040150694942303411728957777100335714010559775242124057347007386251660110828379119623008469277200965153500208474470792443848545912886723000619085126472111951361467527633519562927597957250278002980795904193139603021470997035276467445530922022679656280991498232083329641241038509239184734786121921697210543484287048353408113042573002216421348917347174234800714880751002064390517234247656004721768096486107994943415703476320643558624207443504424380566136017608837478165389027809576975977286860071487028287955567141404632615832623602762896316173978484254486860609948270867968048078702511858930838546584223040908805996294594586201903766048446790926002225410530775901065760671347200125846406957030257138960983757998926954553052368560758683179223113639519468850880771872104705203957587480013143131444254943919940175753169339392366881856189129931729104252921236835159922322050998001677102784035360140829296398115122877768135706045789343535451696539561254048846447169786893211671087229088082778350518228857646062218739702851655083720992349483334435228984751232753726636066213902281264706234075352071724058665079518217303463782631353393706774901950197841690441824738063162828586857741432581165364040218402724913393320949219498422442730427019873044536620350262386957804682003601447291997123095530057206141866974852846856186514832715974481203121946751686379343096189615107330065552421485195201762858595091051839472502863871632494167613804996319791441870254302706758495192008837915169401581740046711477877201459644461175204059453504764721807975761111720846273639279600339670470037613374509553184150073796412605047923251661354841291884211340823015473304754067072818763503617332908005951896325207071673904547777129682265206225651439919376804400292380903112437912614776255964694221981375146967079446870358004392507659451618379811859392049544036114915310782251072691486979809240946772142727012404377187409216756613634938900451232351668146089322400697993176017805338191849981933008410985993938760292601390911414526003720284872132411955424282101831204216104467404621635336900583664606591156298764745525068145003932941404131495400677602951005962253022823003631473824681059648442441324864573137437595096416168048024129351876204668135636877532814675538798871771836512893947195335061885003267607354388673368002074387849657014576090349857571243045102038730494854256702479339322809110526041538528994849203991091946129912491633289917998094380337879522093131466946149705939664152375949285890960489916121944989986384837022486672249148924678410206183364627416969576307632480235587975245253737035433882960862753427740016333434055083537048507374544819754722228975281083020898682633020285259923084168054539687911418297629988964576482765287504562854924265165217750799516259669229114977788962356670956627138482018191348321687995863652637620978285070099337294396784639879024914514222742527006363942327998483976739987154418554201562244154926653014515504685489258620276085761837129763358761215382565129633538141663949516556000264159186554850057052611431952919918807954522394649627635630178580896692226406235382898535867595990647008385687123810329591926494846250768992258419305480763620215089022149220528069842018350840586938493815498909445461977893029113576516775406232278298314033473276603952231603422824717528181818844304880921321933550869873395861276073670866652375555675803171490108477320096424318780070008797346032906278943553743564448851907191616455141155761939399690767415156402826543664026760095087523945507341556135867933066031744720924446513532366647649735400851967040771103640538150073486891798364049570606189535005089840913826869535090066783324472578712196604415284924840041850932811908963634175739897166596000759487800619164094854338758520657116541072260996288150123144377944008749301944744330784388995701842710004808305012177123560622895076269042856800047718893158089358515593863176652948089031267747029662545110861548958395087796755464137944895960527975209874813839762578592105756284401759349324162148339565350189196811389091843795734703269406342890087805846940352453479398080674273236297887100867175802531561302356064878709259865288416350972529537091114317204887747405539054009425375424119317944175137064689643861517718849867010341532542385911089624710885385808688837777258648564145934262121086647588489260031762345960769508849149662444156604419552086811989770240.000000
large:
798441950131984170628030460666810333557348275190265576078984094186809314595841573532599033606882733242214503184515646114757854809285221996356228289554376635019344753920776702760669187940817514531317086140383510733112508649664623633139528050777110074618005617509580146833305060924324246754342390819803294975489244294690457181615916380846787220310100995994303945777913450178570581981686198498193907782547173273698279385392870067122516401380661309429194377571288675510592121362933128690216937551164723903033967732288194633304806974443077506079764506140348104093213176088240569763532433031309628120758051299847190906531282735560740981504351645262405988024022915769015155291537373039452757287714224413271925722965109196412960233450108997556205354431107378518341642987291604090752426939027264213019440145124490661477726747318914574881469961518134515108880857245240185572718139826633083153405462806445652888413410638188733734515336089461690188769941296000310237908472871534924022605781553137758150233789260358532907145882036161660126945661711839735421711825178177760957818009605928677177600206353608487447867000007661334384127783042012294562593528684725810884617737609254169149626757295679706675640253674305137724007576430362146351195481618750152400954313053997866464669799426096587456831642162987414724896100262164539763660362382092573961783134501772282908098290593289630152876770300417744973458556470142688766464671575130409003788303712422629946652772747989412570452719563049061781235816001067752251851519827096684941366242307880857459992859988995242358876699073496204946189012116094636726007751024562501070868616158003530658455857341162526439165492140517609950096619412732907944896057390196270057177242728156339638540867610924105857412556444579107776816889674631366413677833047161379884532164198993276772896425495083000505555449504361780772635099950677280195245017300352256591786535445649376601829488196382898175912034787015428923592784580276113369666903167358253633530441611097653596975461248061662339365488473119600829523500459203619456964603129018988931194328288813647101701632839512858929869478394804296698394260954809692417234406205371106893496236967789991565505735586236384677950809842953217931584749260769959701438782478571501334539385640439880396793372493213016627745357811930479029023541095769455142488296966879072936425173785823423491784831896194556031386766634408387982622337724480135007299914446877152530780342928097086987514633283924856437263144768383859171111988014305350935374816502702333251093923757732462792355307789905174719099488759733393438698689634230361403084258533397265120127568961174111327297320782260488730893216700453978837717137622769084406167566152759623181706028976375164646094475146647369281575972522853549552541720923007665948643646011282736873309526428963407898352464481165847664515121092198236329555997024089181776782273133008347683849048553390800664712980340475996260480072720565715887831207483955807832767939883392425546385536716077432630898214899484281107511073792175413829068138175373955787942264464985983774969783604562637885180871016551868231242254625289486930794202391413454134460390851822972288028367994924347840148793791361918282891665866879658491796934476927641493412928958649240130825652229115711491817767450106062789615541320400721098889852085898259254162735307793046490526388026316295280894798927076625172952033631816193510840287691268927294098058192308372212486275935018916579164964951401297805003291270040660302706760922674620757844937737189874735833048611876587062084398065184497992254250923170482005379707778025178444614040206924597320627466243597003790395509022310055565959173599974814957486832121747812898110468472757711344935141581619768179027277300745026178548690842027389022573413486719086424376549995531862953495262810743844967518912745788410885417320073667346399372144729172804316265474393461925206370016332837493346298714231599348699028709728862988664452830290361646545475793248617512310081372368799772054350231317371686452672996009981551057400080425522396446487229356262303917938229664789869208363238136397068893440807223464451417926302339445880535875195702287684615206433710292963594791392187167500246785808792158380039590563187800668321919054700778993223664127005039562879931963775644174414234242371897053417500956186032208506564827824530909432144378661326313617577661894233125412875713957392594237250272900479523399925200381753270457862573831453382693219682510773999798436059405397109340096099851440470543315842651194313580726690246948309173037070102422697928865543593593980166075781220064584748135949528803322043763798528128793152883647487108192854012453988821565817611465474933891481140768062268834838833326673555808237357184051468989117126978502141404852191804301542607646946130977410809967278476698460181222465259056386246982267558528987894457868410385101006422099287064483189598631389250604017773829174392421160930626885766469862665970968575978122938895191153280286720.000000
middling: 2882400001.137778
maxll: 9223372036854775807
largell: 9223372036854775807
middlingll: 2882400001
max: 0xf.fffffffffffffffp+16380
large: 0xa.bcdef0123456789p+16380
middling: 0xa.bcdef0123456789p+28
maxll: 0x7fffffffffffffff
largell: 0x7fffffffffffffff
middlingll: 0xabcdef01

I'll use hexadecimal notation in the following comments:

The whole part of "max" has the same value as "max" itself. The same is
true of "large". The whole part of middling is 0xABCDEF01. The
fractional part of middling is 0x0.23456789.

The mantissas are as follows:
max: 0xffffffffffffffff
large: 0xabcdef0123456789
middling: 0xabcdef0123456789

The values stored in "maxll" and "largell" do not match either the whole
part or the mantissa of the corresponding floating point number. Because
"middling" is the only one of the three long double values that is
smaller than LLONG_MAX, the value stored in middlingll is the whole part
of "middling", as it should be, but is quite different from the mantissa
of "middling".

[toc] | [prev] | [next] | [standalone]

#81795

From	James Kuyper <jameskuyper@alumni.caltech.edu>
Date	2021-10-02 15:37 -0400
Message-ID	<sjace5$nff$1@dont-email.me>
In reply to	#81784

On 10/2/21 2:59 PM, Branimir Maksimovic wrote:
>
>
>> On 02.10.2021., at 20:51, James Kuyper
>> <jameskuyper@alumni.caltech.edu
>> <mailto:jameskuyper@alumni.caltech.edu>> wrote:
>>
>> int main(void)
>> {
>>    typedef long double FType;
>>    FType max= std::numeric_limits<FType>::max();
>>    FType large = 0xA.BCDEF0123456789p+16380L;
>>    FType middling = 0xABCDEF01.23456789p0L;
>>    long long maxll = max;
>>    long long largell = large;
>>    long long middlingll = middling;
>>
>>    std::cout << std::fixed << "max: " << max << std::endl;
>>    std::cout << "large: " << large << std::endl;
>>    std::cout << "middling: " << middling << std::endl;
>>
>>    std::cout << "maxll: " << maxll << std::endl;
>>    std::cout << "largell: " << largell << std::endl;
>>    std::cout << "middlingll: " << middlingll << std::endl;
>>
>>    std::cout << std::hexfloat << std::showbase << std::showpoint <<
>>        std::hex << "max: " << max << std::endl;
>>    std::cout << "large: " << large << std::endl;
>>    std::cout << "middling: " << middling << std::endl;
>>
>>    std::cout << "maxll: " << maxll << std::endl;
>>    std::cout << "largell: " << largell << std::endl;
>>    std::cout << "middlingll: " << middlingll << std::endl;
>> }
> mantissa.cpp:7:18: warning: magnitude of floating-point constant too
> large for type 'long double'; maximum is 1.7976931348623157E+308
> [-Wliteral-range]
> Sorry your program is not correct..

The value of "large" was chosen to be almost as large as "max" on my
machine. It's apparently larger than LDBL_MAX on your system. A more
portable initializer would be

    FType large = 0x0.ABCDEF0123456789p0L * max;

Depending upon the value of LDBL_EPSILON on the target implementation,
that definition might result in the mantissa of "large" having fewer
significant digits than it has on mine, but that's not particularly
important.

> This is output on my system:
> bmaxa@Branimirs-Air projects % ./a.out
> max:
> 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000
> large: inf
> middling: 2882400001.137778
> maxll: 9223372036854775807
> largell: 9223372036854775807
> middlingll: 2882400001
> max: 0x1.fffffffffffffp+1023
> large: inf
> middling: 0x1.579bde02468adp+31
> maxll: 0x7fffffffffffffff
> largell: 0x7fffffffffffffff
> middlingll: 0xabcdef01
>
> Greetings, Branimir.

With that change, the value of "large" on my machine changes to
0xa.bcdef0123456788p+16380, with a corresponding (HUGE) change to the
less significant digits of the decimal output, and the mantissa is
therefore 0xabcdef0123456788.
You'll get much different values for "max" and "large" on your system,
since LDBL_MAX is much smaller, but the qualitative comments I made
about those values should still be accurate. There's no guarantees,
since the behavior is undefined, but I would expect that the values of
"maxll" and "largell" will be unchanged.

[toc] | [prev] | [next] | [standalone]

#81799

From	Branimir Maksimovic <branimir.maksimovic@icloud.com>
Date	2021-10-03 00:47 +0000
Message-ID	<Z476J.23134$4X4.11816@fx27.iad>
In reply to	#81795

On 2021-10-02, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 10/2/21 2:59 PM, Branimir Maksimovic wrote:
>>
>>
>>> On 02.10.2021., at 20:51, James Kuyper
>>> <jameskuyper@alumni.caltech.edu
>>> <mailto:jameskuyper@alumni.caltech.edu>> wrote:
>>>
>>> int main(void)
>>> {
>>>    typedef long double FType;
>>>    FType max= std::numeric_limits<FType>::max();
>>>    FType large = 0xA.BCDEF0123456789p+16380L;
>>>    FType middling = 0xABCDEF01.23456789p0L;
>>>    long long maxll = max;
>>>    long long largell = large;
>>>    long long middlingll = middling;
>>>
>>>    std::cout << std::fixed << "max: " << max << std::endl;
>>>    std::cout << "large: " << large << std::endl;
>>>    std::cout << "middling: " << middling << std::endl;
>>>
>>>    std::cout << "maxll: " << maxll << std::endl;
>>>    std::cout << "largell: " << largell << std::endl;
>>>    std::cout << "middlingll: " << middlingll << std::endl;
>>>
>>>    std::cout << std::hexfloat << std::showbase << std::showpoint <<
>>>        std::hex << "max: " << max << std::endl;
>>>    std::cout << "large: " << large << std::endl;
>>>    std::cout << "middling: " << middling << std::endl;
>>>
>>>    std::cout << "maxll: " << maxll << std::endl;
>>>    std::cout << "largell: " << largell << std::endl;
>>>    std::cout << "middlingll: " << middlingll << std::endl;
>>> }
>> mantissa.cpp:7:18: warning: magnitude of floating-point constant too
>> large for type 'long double'; maximum is 1.7976931348623157E+308
>> [-Wliteral-range]
>> Sorry your program is not correct..
>
> The value of "large" was chosen to be almost as large as "max" on my
> machine. It's apparently larger than LDBL_MAX on your system. A more
> portable initializer would be
>
>     FType large = 0x0.ABCDEF0123456789p0L * max;
>
> Depending upon the value of LDBL_EPSILON on the target implementation,
> that definition might result in the mantissa of "large" having fewer
> significant digits than it has on mine, but that's not particularly
> important.

Now outputs:
bmaxa@Branimirs-Air projects % ./a.out
max: 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000
large: 120645172288001372126619919515947355653853135095820093742269387851763173210613194516902557021349374744036403756647462602101944733127725809392434319981526284828181273773403605513307431121904981243948320057805774787281290926848565000291282225047507294705767371139696722108291516984908752371556782562287095382016.000000
middling: 2882400001.137778
maxll: 9223372036854775807
largell: 9223372036854775807
middlingll: 2882400001
max: 0x1.fffffffffffffp+1023
large: 0x1.579bde02468acp+1023
middling: 0x1.579bde02468adp+31
maxll: 0x7fffffffffffffff
largell: 0x7fffffffffffffff
middlingll: 0xabcdef01

>


-- 

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

[toc] | [prev] | [next] | [standalone]

#81817

From	James Kuyper <jameskuyper@alumni.caltech.edu>
Date	2021-10-03 23:42 -0400
Message-ID	<sjdt71$ia6$1@dont-email.me>
In reply to	#81799

On 10/2/21 8:47 PM, Branimir Maksimovic wrote:
> On 2021-10-02, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 10/2/21 2:59 PM, Branimir Maksimovic wrote:
>>>
>>>
>>>> On 02.10.2021., at 20:51, James Kuyper
>>>> <jameskuyper@alumni.caltech.edu
>>>> <mailto:jameskuyper@alumni.caltech.edu>> wrote:
>>>>
>>>> int main(void)
>>>> {
>>>>    typedef long double FType;
>>>>    FType max= std::numeric_limits<FType>::max();
>>>>    FType large = 0xA.BCDEF0123456789p+16380L;
>>>>    FType middling = 0xABCDEF01.23456789p0L;
>>>>    long long maxll = max;
>>>>    long long largell = large;
>>>>    long long middlingll = middling;
>>>>
>>>>    std::cout << std::fixed << "max: " << max << std::endl;
>>>>    std::cout << "large: " << large << std::endl;
>>>>    std::cout << "middling: " << middling << std::endl;
>>>>
>>>>    std::cout << "maxll: " << maxll << std::endl;
>>>>    std::cout << "largell: " << largell << std::endl;
>>>>    std::cout << "middlingll: " << middlingll << std::endl;
>>>>
>>>>    std::cout << std::hexfloat << std::showbase << std::showpoint <<
>>>>        std::hex << "max: " << max << std::endl;
>>>>    std::cout << "large: " << large << std::endl;
>>>>    std::cout << "middling: " << middling << std::endl;
>>>>
>>>>    std::cout << "maxll: " << maxll << std::endl;
>>>>    std::cout << "largell: " << largell << std::endl;
>>>>    std::cout << "middlingll: " << middlingll << std::endl;
>>>> }
>>> mantissa.cpp:7:18: warning: magnitude of floating-point constant too
>>> large for type 'long double'; maximum is 1.7976931348623157E+308
>>> [-Wliteral-range]
>>> Sorry your program is not correct..
>>
>> The value of "large" was chosen to be almost as large as "max" on my
>> machine. It's apparently larger than LDBL_MAX on your system. A more
>> portable initializer would be
>>
>>     FType large = 0x0.ABCDEF0123456789p0L * max;
>>
>> Depending upon the value of LDBL_EPSILON on the target implementation,
>> that definition might result in the mantissa of "large" having fewer
>> significant digits than it has on mine, but that's not particularly
>> important.
> 
> Now outputs:
> bmaxa@Branimirs-Air projects % ./a.out
> max: 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000
> large: 120645172288001372126619919515947355653853135095820093742269387851763173210613194516902557021349374744036403756647462602101944733127725809392434319981526284828181273773403605513307431121904981243948320057805774787281290926848565000291282225047507294705767371139696722108291516984908752371556782562287095382016.000000
> middling: 2882400001.137778
> maxll: 9223372036854775807
> largell: 9223372036854775807
> middlingll: 2882400001
> max: 0x1.fffffffffffffp+1023
> large: 0x1.579bde02468acp+1023
> middling: 0x1.579bde02468adp+31
> maxll: 0x7fffffffffffffff
> largell: 0x7fffffffffffffff
> middlingll: 0xabcdef01

Your system has a different value for LDBL_MAX than mine, which is
perfectly normal. With that difference in mind, all of those results are
consistent with what I said. None of the long long values are the same
as the mantissa of the corresponding float value, and only middlingll is
the same as the whole part of corresponding float value.

Do you now concede that your approach is not guaranteed to result in a
long long value containing the mantissa?

[toc] | [prev] | [next] | [standalone]

#81820

From	Branimir Maksimovic <branimir.maksimovic@icloud.com>
Date	2021-10-04 04:35 +0000
Message-ID	<hwv6J.155086$Kv2.60311@fx47.iad>
In reply to	#81817

On 2021-10-04, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
> Do you now concede that your approach is not guaranteed to result in a
> long long value containing the mantissa?
of course, you convinced me.

-- 

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

[toc] | [prev] | [next] | [standalone]

#81783

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-10-02 12:09 +0200
Message-ID	<sj9b43$9hm$1@dont-email.me>
In reply to	#81702

Am 01.10.2021 um 17:37 schrieb wij:
> // numeric_limits<long double>::digits=64.
> //
> typedef long double FType;
> FType x=numeric_limits<FType>::max();
> int iexp;
> int64_t mint;
> x=::frexpl(x,&iexp);
> x=::ldexpl(x,numeric_limits<FType>::digits);
> mint= static_cast<int64_t>(x);
> 
> Result (mint) is a negative number, something not right!!!
> 

Here, exactly 100 lines with a very convenient double to double
parts and double parts to double conversion:

#pragma once
#include <limits>
#include <cstdint>
#include <cassert>

struct dbl_parts
{
	static_assert(std::numeric_limits<double>::is_iec559, "must be standard 
fp");
	dbl_parts( double d );
	dbl_parts &operator =( double d );
	dbl_parts() = default;
	operator double();
	bool getSign();
	std::uint16_t getBiasedExponent();
	std::int16_t getExponent();
	std::uint64_t getMantissa();
	void setSign( bool sign );
	void setBiasedExponent( uint16_t exp );
	void setExponent( int16_t exp );
	void setMantissa( uint64_t mantissa );
private:
	union
	{
		double value;
		std::uint64_t binary;
	};
};

inline
dbl_parts::dbl_parts( double d ) :
	value( d )
{
}

inline
dbl_parts &dbl_parts::operator =( double d )
{
	value = d;
	return *this;
}

inline
dbl_parts::operator double()
{
	return value;
}

inline
bool dbl_parts::getSign()
{
	return (int64_t)binary < 0;
}

inline
std::uint16_t dbl_parts::getBiasedExponent()
{
	return (std::uint16_t)(binary >> 52) & 0x7FF;
}

inline
int16_t dbl_parts::getExponent()
{
	return (int16_t)getBiasedExponent() - 0x3FF;
}

inline
std::uint64_t dbl_parts::getMantissa()
{
	std::uint16_t bExp = getBiasedExponent();
	std::uint64_t hiBit = (uint64_t)(bExp && bExp != 0x7FF) << 52;
	return binary & 0xFFFFFFFFFFFFFu | hiBit;
}

inline
void dbl_parts::setSign( bool sign )
{
	binary = binary & 0x7FFFFFFFFFFFFFFFu | (std::uint64_t)sign << 63;
}

inline
void dbl_parts::setBiasedExponent( std::uint16_t exp )
{
	assert(exp <= 0x7FF);
	binary = binary & 0x800FFFFFFFFFFFFFu | (std::uint64_t)exp << 52;
}

inline
void dbl_parts::setExponent( std::int16_t exp )
{
	assert(exp >= -0x3FF && exp <= 400);
	setBiasedExponent( (uint16_t)(exp - 0x3FF) );
}

inline
void dbl_parts::setMantissa( std::uint64_t mantissa )
{
	assert((getBiasedExponent() == 0 || getBiasedExponent() == 0x7FF) && 
!(mantissa & -0x10000000000000));
	assert(getBiasedExponent() != 0 && getBiasedExponent() != 0x7FF || 
mantissa <= 0x1FFFFFFFFFFFFFu);
	binary = binary & 0xFFF0000000000000u | mantissa & 0xFFFFFFFFFFFFFu;
}

[toc] | [prev] | [next] | [standalone]

#81791

From	"Alf P. Steinbach" <alf.p.steinbach@gmail.com>
Date	2021-10-02 21:00 +0200
Message-ID	<sjaa8r$7hs$1@dont-email.me>
In reply to	#81702

On 1 Oct 2021 17:37, wij wrote:
> // numeric_limits<long double>::digits=64.
> //
> typedef long double FType;
> FType x=numeric_limits<FType>::max();
> int iexp;
> int64_t mint;
> x=::frexpl(x,&iexp);
> x=::ldexpl(x,numeric_limits<FType>::digits);
> mint= static_cast<int64_t>(x);
> 
> Result (mint) is a negative number, something not right!!!

Apparently you're trying to obtain the bits of the mantissa of a `long 
double` number, represented as an `int64_t` value.

A `long double` is in practice either IEEE 754 64-bit, or IEEE 754 
80-bit. In Windows that choice depends on the compiler. With Visual C++ 
(and hence probably also Intel) it's 64-bit, same as type `double`, 
while with MinGW g++ (and hence probably also clang) it 80-bit, 
originally the x86-family's math coprocessor's extended format. For 
80-bit IEEE 754 the mantissa part is 64 bits.

With 64-bits mantissa there is a high chance of setting the sign bit of 
an `int64_t` to 1, resulting in a negative value. I believe that that 
will only /not/ happen for a denormal value, but, I'm tired and might be 
wrong about that. Anyway, instead use  unsigned types for bit handling. 
For example, in this case, use `uint64_t`.

However, instead of the shenanigans with `frexpl` and `ldexpl` I'd just 
use `memcpy`.

Due to the silliness in gcc regarding the standard's "strict aliasing" 
rule, I'd not use a reinterpretation pointer cast.

- Alf

[toc] | [prev] | [next] | [standalone]

#81792

From	James Kuyper <jameskuyper@alumni.caltech.edu>
Date	2021-10-02 15:12 -0400
Message-ID	<sjaau5$bg8$1@dont-email.me>
In reply to	#81791

On 10/2/21 3:00 PM, Alf P. Steinbach wrote:
> On 1 Oct 2021 17:37, wij wrote:
>> // numeric_limits<long double>::digits=64.
>> //
>> typedef long double FType;
>> FType x=numeric_limits<FType>::max();
>> int iexp;
>> int64_t mint;
>> x=::frexpl(x,&iexp);
>> x=::ldexpl(x,numeric_limits<FType>::digits);
>> mint= static_cast<int64_t>(x);>>
>> Result (mint) is a negative number, something not right!!!
> 
> Apparently you're trying to obtain the bits of the mantissa of a `long 
> double` number, represented as an `int64_t` value.
> 
> A `long double` is in practice either IEEE 754 64-bit, or IEEE 754 
> 80-bit. In Windows that choice depends on the compiler. With Visual C++ 
> (and hence probably also Intel) it's 64-bit, same as type `double`, 
> while with MinGW g++ (and hence probably also clang) it 80-bit, 
> originally the x86-family's math coprocessor's extended format. For 
> 80-bit IEEE 754 the mantissa part is 64 bits.
> 
> With 64-bits mantissa there is a high chance of setting the sign bit of 
> an `int64_t` to 1, resulting in a negative value. I believe that that 
> will only /not/ happen for a denormal value, but, I'm tired and might be 
> wrong about that. Anyway, instead use  unsigned types for bit handling. 
> For example, in this case, use `uint64_t`.

It would be safer and more portable to use FType; there's no portable
guarantee that any integer type is large enough to hold the mantissa,
but FType is.

> However, instead of the shenanigans with `frexpl` and `ldexpl` I'd just 
> use `memcpy`.

The advantage of the code as written is that (if you change mint to have
FType) it will give the correct result even if your assumption about
IEEE 754 is false; that's not the case with memcpy().

[toc] | [prev] | [next] | [standalone]

#81793

From	"Alf P. Steinbach" <alf.p.steinbach@gmail.com>
Date	2021-10-02 21:23 +0200
Message-ID	<sjabjd$heb$1@dont-email.me>
In reply to	#81792

On 2 Oct 2021 21:12, James Kuyper wrote:
> On 10/2/21 3:00 PM, Alf P. Steinbach wrote:
>> On 1 Oct 2021 17:37, wij wrote:
>>> // numeric_limits<long double>::digits=64.
>>> //
>>> typedef long double FType;
>>> FType x=numeric_limits<FType>::max();
>>> int iexp;
>>> int64_t mint;
>>> x=::frexpl(x,&iexp);
>>> x=::ldexpl(x,numeric_limits<FType>::digits);
>>> mint= static_cast<int64_t>(x);>>
>>> Result (mint) is a negative number, something not right!!!
>>
>> Apparently you're trying to obtain the bits of the mantissa of a `long
>> double` number, represented as an `int64_t` value.
>>
>> A `long double` is in practice either IEEE 754 64-bit, or IEEE 754
>> 80-bit. In Windows that choice depends on the compiler. With Visual C++
>> (and hence probably also Intel) it's 64-bit, same as type `double`,
>> while with MinGW g++ (and hence probably also clang) it 80-bit,
>> originally the x86-family's math coprocessor's extended format. For
>> 80-bit IEEE 754 the mantissa part is 64 bits.
>>
>> With 64-bits mantissa there is a high chance of setting the sign bit of
>> an `int64_t` to 1, resulting in a negative value. I believe that that
>> will only /not/ happen for a denormal value, but, I'm tired and might be
>> wrong about that. Anyway, instead use  unsigned types for bit handling.
>> For example, in this case, use `uint64_t`.
> 
> It would be safer and more portable to use FType; there's no portable
> guarantee that any integer type is large enough to hold the mantissa,
> but FType is.

I believe you intended to write `uintptr_t`, not `FType`.

If so, agreed.

It's late in the day for me, sorry.


>> However, instead of the shenanigans with `frexpl` and `ldexpl` I'd just
>> use `memcpy`.
> 
> The advantage of the code as written is that (if you change mint to have
> FType) it will give the correct result even if your assumption about
> IEEE 754 is false; that's not the case with memcpy().

Uhm, I'd rather assert IEEE 754 representation 
(numeric_limits::is_iec559). Dealing with the bits of just about any 
representation seems to me a hopelessly daunting task. :-o


- Alf

[toc] | [prev] | [next] | [standalone]

#81794

From	"Alf P. Steinbach" <alf.p.steinbach@gmail.com>
Date	2021-10-02 21:27 +0200
Message-ID	<sjabqn$j14$1@dont-email.me>
In reply to	#81793

On 2 Oct 2021 21:23, Alf P. Steinbach wrote:
> On 2 Oct 2021 21:12, James Kuyper wrote:
>> On 10/2/21 3:00 PM, Alf P. Steinbach wrote:
>>> On 1 Oct 2021 17:37, wij wrote:
>>>> // numeric_limits<long double>::digits=64.
>>>> //
>>>> typedef long double FType;
>>>> FType x=numeric_limits<FType>::max();
>>>> int iexp;
>>>> int64_t mint;
>>>> x=::frexpl(x,&iexp);
>>>> x=::ldexpl(x,numeric_limits<FType>::digits);
>>>> mint= static_cast<int64_t>(x);>>
>>>> Result (mint) is a negative number, something not right!!!
>>>
>>> Apparently you're trying to obtain the bits of the mantissa of a `long
>>> double` number, represented as an `int64_t` value.
>>>
>>> A `long double` is in practice either IEEE 754 64-bit, or IEEE 754
>>> 80-bit. In Windows that choice depends on the compiler. With Visual C++
>>> (and hence probably also Intel) it's 64-bit, same as type `double`,
>>> while with MinGW g++ (and hence probably also clang) it 80-bit,
>>> originally the x86-family's math coprocessor's extended format. For
>>> 80-bit IEEE 754 the mantissa part is 64 bits.
>>>
>>> With 64-bits mantissa there is a high chance of setting the sign bit of
>>> an `int64_t` to 1, resulting in a negative value. I believe that that
>>> will only /not/ happen for a denormal value, but, I'm tired and might be
>>> wrong about that. Anyway, instead use  unsigned types for bit handling.
>>> For example, in this case, use `uint64_t`.
>>
>> It would be safer and more portable to use FType; there's no portable
>> guarantee that any integer type is large enough to hold the mantissa,
>> but FType is.
> 
> I believe you intended to write `uintptr_t`, not `FType`.
> 
> If so, agreed.
> 
> It's late in the day for me, sorry.

It's /very/ late.

There AFAIK is no suitable type name for the integer type with 
sufficient bits to represent the mantissa, or generally >N bits.

Unfortunately the standard library doesn't provide a mapping from number 
of bits as a value, to integer type with that many bits. It can be done, 
on the assumption that all types in `<stdint.h>` are present. And 
perhaps one can then define a name like `FType` in terms of that mapping.


>>> However, instead of the shenanigans with `frexpl` and `ldexpl` I'd just
>>> use `memcpy`.
>>
>> The advantage of the code as written is that (if you change mint to have
>> FType) it will give the correct result even if your assumption about
>> IEEE 754 is false; that's not the case with memcpy().
> 
> Uhm, I'd rather assert IEEE 754 representation 
> (numeric_limits::is_iec559). Dealing with the bits of just about any 
> representation seems to me a hopelessly daunting task. :-o
> 
> 
> - Alf
>

[toc] | [prev] | [next] | [standalone]

#81797

From	Manfred <noname@add.invalid>
Date	2021-10-02 23:19 +0200
Message-ID	<sjaidm$2mp$1@gioia.aioe.org>
In reply to	#81794

On 10/2/2021 9:27 PM, Alf P. Steinbach wrote:
> On 2 Oct 2021 21:23, Alf P. Steinbach wrote:
>> On 2 Oct 2021 21:12, James Kuyper wrote:
>>> On 10/2/21 3:00 PM, Alf P. Steinbach wrote:
>>>> On 1 Oct 2021 17:37, wij wrote:
>>>>> // numeric_limits<long double>::digits=64.
>>>>> //
>>>>> typedef long double FType;
>>>>> FType x=numeric_limits<FType>::max();
>>>>> int iexp;
>>>>> int64_t mint;
>>>>> x=::frexpl(x,&iexp);
>>>>> x=::ldexpl(x,numeric_limits<FType>::digits);
>>>>> mint= static_cast<int64_t>(x);>>
>>>>> Result (mint) is a negative number, something not right!!!
>>>>
>>>> Apparently you're trying to obtain the bits of the mantissa of a `long
>>>> double` number, represented as an `int64_t` value.
>>>>
>>>> A `long double` is in practice either IEEE 754 64-bit, or IEEE 754
>>>> 80-bit. In Windows that choice depends on the compiler. With Visual C++
>>>> (and hence probably also Intel) it's 64-bit, same as type `double`,
>>>> while with MinGW g++ (and hence probably also clang) it 80-bit,
>>>> originally the x86-family's math coprocessor's extended format. For
>>>> 80-bit IEEE 754 the mantissa part is 64 bits.
>>>>
>>>> With 64-bits mantissa there is a high chance of setting the sign bit of
>>>> an `int64_t` to 1, resulting in a negative value. I believe that that
>>>> will only /not/ happen for a denormal value, but, I'm tired and 
>>>> might be
>>>> wrong about that. Anyway, instead use  unsigned types for bit handling.
>>>> For example, in this case, use `uint64_t`.
>>>
>>> It would be safer and more portable to use FType; there's no portable
>>> guarantee that any integer type is large enough to hold the mantissa,
>>> but FType is.
>>
>> I believe you intended to write `uintptr_t`, not `FType`.
>>
>> If so, agreed.
>>
>> It's late in the day for me, sorry.
> 
> It's /very/ late.
> 
> There AFAIK is no suitable type name for the integer type with 
> sufficient bits to represent the mantissa, or generally >N bits.

He meant the FType that is in the original post. I.e. the same floating 
point type of the number to be analyzed.

> 
> Unfortunately the standard library doesn't provide a mapping from number 
> of bits as a value, to integer type with that many bits. It can be done, 
> on the assumption that all types in `<stdint.h>` are present. And 
> perhaps one can then define a name like `FType` in terms of that mapping.
> 
> 
>>>> However, instead of the shenanigans with `frexpl` and `ldexpl` I'd just
>>>> use `memcpy`.
>>>
>>> The advantage of the code as written is that (if you change mint to have
>>> FType) it will give the correct result even if your assumption about
>>> IEEE 754 is false; that's not the case with memcpy().
>>
>> Uhm, I'd rather assert IEEE 754 representation 
>> (numeric_limits::is_iec559). Dealing with the bits of just about any 
>> representation seems to me a hopelessly daunting task. :-o
>>
>>
>> - Alf
>>

[toc] | [prev] | [next] | [standalone]

#81818

From	James Kuyper <jameskuyper@alumni.caltech.edu>
Date	2021-10-03 23:43 -0400
Message-ID	<sjdt8h$ia6$2@dont-email.me>
In reply to	#81793

On 10/2/21 3:23 PM, Alf P. Steinbach wrote:
> On 2 Oct 2021 21:12, James Kuyper wrote:
...
>> It would be safer and more portable to use FType; there's no portable
>> guarantee that any integer type is large enough to hold the mantissa,
>> but FType is.
> 
> I believe you intended to write `uintptr_t`, not `FType`.

No, uintptr_t is not guaranteed to be able to hold the mantissa; nor is
any other integer type. FType is guaranteed to be able to hold it.

>>> However, instead of the shenanigans with `frexpl` and `ldexpl` I'd just
>>> use `memcpy`.
>>
>> The advantage of the code as written is that (if you change mint to have
>> FType) it will give the correct result even if your assumption about
>> IEEE 754 is false; that's not the case with memcpy().
> 
> Uhm, I'd rather assert IEEE 754 representation 
> (numeric_limits::is_iec559). Dealing with the bits of just about any 
> representation seems to me a hopelessly daunting task. :-o

Well, that's the purpose of frexpl() and ldexpl() - they save you from
having to worry about the bits.

[toc] | [prev] | [next] | [standalone]

#81798

From	Branimir Maksimovic <branimir.maksimovic@icloud.com>
Date	2021-10-03 00:45 +0000
Message-ID	<w276J.23133$4X4.13084@fx27.iad>
In reply to	#81792

On 2021-10-02, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 10/2/21 3:00 PM, Alf P. Steinbach wrote:
>> On 1 Oct 2021 17:37, wij wrote:
>>> // numeric_limits<long double>::digits=64.
>>> //
>>> typedef long double FType;
>>> FType x=numeric_limits<FType>::max();
>>> int iexp;
>>> int64_t mint;
>>> x=::frexpl(x,&iexp);
>>> x=::ldexpl(x,numeric_limits<FType>::digits);
>>> mint= static_cast<int64_t>(x);>>
>>> Result (mint) is a negative number, something not right!!!
>> 
>> Apparently you're trying to obtain the bits of the mantissa of a `long 
>> double` number, represented as an `int64_t` value.
>> 
>> A `long double` is in practice either IEEE 754 64-bit, or IEEE 754 
>> 80-bit. In Windows that choice depends on the compiler. With Visual C++ 
>> (and hence probably also Intel) it's 64-bit, same as type `double`, 
>> while with MinGW g++ (and hence probably also clang) it 80-bit, 
>> originally the x86-family's math coprocessor's extended format. For 
>> 80-bit IEEE 754 the mantissa part is 64 bits.
>> 
>> With 64-bits mantissa there is a high chance of setting the sign bit of 
>> an `int64_t` to 1, resulting in a negative value. I believe that that 
>> will only /not/ happen for a denormal value, but, I'm tired and might be 
>> wrong about that. Anyway, instead use  unsigned types for bit handling. 
>> For example, in this case, use `uint64_t`.
>
> It would be safer and more portable to use FType; there's no portable
> guarantee that any integer type is large enough to hold the mantissa,
> but FType is.

How so if FType is just typedef?


-- 

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

[toc] | [prev] | [next] | [standalone]

#81816

From	James Kuyper <jameskuyper@alumni.caltech.edu>
Date	2021-10-03 23:31 -0400
Message-ID	<sjdsjd$fgs$1@dont-email.me>
In reply to	#81798

On 10/2/21 8:45 PM, Branimir Maksimovic wrote:
> On 2021-10-02, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 10/2/21 3:00 PM, Alf P. Steinbach wrote:
>>> On 1 Oct 2021 17:37, wij wrote:
>>>> // numeric_limits<long double>::digits=64.
>>>> //
>>>> typedef long double FType;
>>>> FType x=numeric_limits<FType>::max();
>>>> int iexp;
>>>> int64_t mint;
>>>> x=::frexpl(x,&iexp);
>>>> x=::ldexpl(x,numeric_limits<FType>::digits);
>>>> mint= static_cast<int64_t>(x);>>
>>>> Result (mint) is a negative number, something not right!!!
>>>
>>> Apparently you're trying to obtain the bits of the mantissa of a `long 
>>> double` number, represented as an `int64_t` value.
>>>
>>> A `long double` is in practice either IEEE 754 64-bit, or IEEE 754 
>>> 80-bit. In Windows that choice depends on the compiler. With Visual C++ 
>>> (and hence probably also Intel) it's 64-bit, same as type `double`, 
>>> while with MinGW g++ (and hence probably also clang) it 80-bit, 
>>> originally the x86-family's math coprocessor's extended format. For 
>>> 80-bit IEEE 754 the mantissa part is 64 bits.
>>>
>>> With 64-bits mantissa there is a high chance of setting the sign bit of 
>>> an `int64_t` to 1, resulting in a negative value. I believe that that 
>>> will only /not/ happen for a denormal value, but, I'm tired and might be 
>>> wrong about that. Anyway, instead use  unsigned types for bit handling. 
>>> For example, in this case, use `uint64_t`.
>>
>> It would be safer and more portable to use FType; there's no portable
>> guarantee that any integer type is large enough to hold the mantissa,
>> but FType is.
> 
> How so if FType is just typedef?

A typedef is just a synonym for a type, it has exactly the same
characteristics as the type for which it is a synonym. What I said is
true because FType is a synonym for long double, the same type as x
itself. What I was asserting is that for any given floating point
object, the mantissa or significand stored in that object has a value
that is guaranteed to be representable in the same floating point type
as the object itself. There's no guarantee that any integer type is big
enough to represent it.

I've since thought this over, and checked carefully, and that's not
quite true - though it's true enough for most practical purposes. Let me
explain.

The C++ standard defines <cfloat>, and defines it's contents mostly by
cross-referencing the C standard's definition of <float.h>. Section
5.2.4.2.2 the C standard defines a parameterized model for floating
point representations, that is used as a basis for describing the
meaning of the macros defined in <float.h>, so that model is inherited
by C++.

I will need to refer to the following parameters of that model:
> b - base or radix of exponent representation (an integer > 1)
> e - exponent (an integer between a minimum e_min and a maximum e_max )
> p - precision (the number of base-b digits in the significand)

Note that b, e_min, e_max, and p are constants for any specific floating
point type.

In terms of that model, the value of the significand of a floating point
value x, interpreted as an integer, can be represented in the same
floating point type by a number with exactly the same significand, and e
= p.

The key issue is whether such a representation is allowed, and it turns
out that there can be floating point representations which fit the C
standard's model, for which e_max < p, preventing some signficands from
being representable in such a type.

The macro LDBL_MAX (corresponding to std::numeric_limits<long
double>::max()) is defined as expanding to the value of
(1 - b^(-p))*b^e_max, and is required to be at least 1e37. If, for
example, e_max == p-1 and b=2, then this means that for such a type, p
must be at least 124.

Every floating point format I'm familiar with has an e_max value much
larger than p, so I think, as a practical matter, that it's safe to
assume that signficands can be represented in the same floating point
type, but strictly speaking, it's not guaranteed.

[toc] | [prev] | [next] | [standalone]

#81819

From	Branimir Maksimovic <branimir.maksimovic@icloud.com>
Date	2021-10-04 04:34 +0000
Message-ID	<jvv6J.155085$Kv2.130132@fx47.iad>
In reply to	#81816

On 2021-10-04, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> Note that b, e_min, e_max, and p are constants for any specific floating
> point type.
>
> In terms of that model, the value of the significand of a floating point
> value x, interpreted as an integer, can be represented in the same
> floating point type by a number with exactly the same significand, and e
>= p.
>
> The key issue is whether such a representation is allowed, and it turns
> out that there can be floating point representations which fit the C
> standard's model, for which e_max < p, preventing some signficands from
> being representable in such a type.
>
> The macro LDBL_MAX (corresponding to std::numeric_limits<long
> double>::max()) is defined as expanding to the value of
> (1 - b^(-p))*b^e_max, and is required to be at least 1e37. If, for
> example, e_max == p-1 and b=2, then this means that for such a type, p
> must be at least 124.
>
> Every floating point format I'm familiar with has an e_max value much
> larger than p, so I think, as a practical matter, that it's safe to
> assume that signficands can be represented in the same floating point
> type, but strictly speaking, it's not guaranteed.
Great!!!
So intead of int we use float type and truncate?

-- 

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
ettps://github.com/rofl0r/chaos-pp

[toc] | [prev] | [next] | [standalone]

#81833

From	James Kuyper <jameskuyper@alumni.caltech.edu>
Date	2021-10-04 11:30 -0400
Message-ID	<sjf6n3$tca$1@dont-email.me>
In reply to	#81819

On 10/4/21 12:34 AM, Branimir Maksimovic wrote:
> On 2021-10-04, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
...
>> In terms of that model, the value of the significand of a floating point
>> value x, interpreted as an integer, can be represented in the same
>> floating point type by a number with exactly the same significand, and e
>> = p.
>>
>> The key issue is whether such a representation is allowed, and it turns
>> out that there can be floating point representations which fit the C
>> standard's model, for which e_max < p, preventing some signficands from
>> being representable in such a type.
>>
>> The macro LDBL_MAX (corresponding to std::numeric_limits<long
>> double>::max()) is defined as expanding to the value of
>> (1 - b^(-p))*b^e_max, and is required to be at least 1e37. If, for
>> example, e_max == p-1 and b=2, then this means that for such a type, p
>> must be at least 124.
>>
>> Every floating point format I'm familiar with has an e_max value much
>> larger than p, so I think, as a practical matter, that it's safe to
>> assume that signficands can be represented in the same floating point
>> type, but strictly speaking, it's not guaranteed.
> Great!!!
> So intead of int we use float type and truncate?

You're half right. If you want the mantissa (== significand), you should
not truncate - that might lose you the parts of the significand that
represent the fractional part of the number. The OP had it right at the
second to last step in his original code:

    x = std::ldexp(x, numeric_limits<FType>::digits);

At this point, x already contains the significand; there's no further
need to convert it to an integer type - in fact, in most contexts you'd
want it in floating point format for later steps in the processing.

[toc] | [prev] | [next] | [standalone]

#81837

From	Branimir Maksimovic <branimir.maksimovic@icloud.com>
Date	2021-10-04 16:19 +0000
Message-ID	<gQF6J.72293$ol1.62181@fx42.iad>
In reply to	#81833

On 2021-10-04, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
> You're half right. If you want the mantissa (== significand), you should
> not truncate - that might lose you the parts of the significand that
> represent the fractional part of the number. The OP had it right at the
> second to last step in his original code:
>
>     x = std::ldexp(x, numeric_limits<FType>::digits);
>
> At this point, x already contains the significand; there's no further
> need to convert it to an integer type - in fact, in most contexts you'd
> want it in floating point format for later steps in the processing.
Thanks for explanaition.

Greets, branimir

-- 

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

[toc] | [prev] | [next] | [standalone]

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →

csiph-web

How to get mantissa of long double?

Contents

#81741

#81746

#81784

#81790

#81795

#81799

#81817

#81820

#81783

#81791

#81792

#81793

#81794

#81797

#81818

#81798

#81816

#81819

#81833

#81837