[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #63995] Octave c++ method .double_value on (in
From: |
anonymous |
Subject: |
[Octave-bug-tracker] [bug #63995] Octave c++ method .double_value on (intmax ("uint64")-1) |
Date: |
Tue, 4 Apr 2023 04:33:04 -0400 (EDT) |
Follow-up Comment #3, bug #63995 (project octave):
I did another quick test which complements the analysis:
1) Create a double with the value
std::numeric_limits<uint64_t>::max ()
The value is 18446744073709551616
2) Call a function which takes this double and returns the double
The value is 18446744073709551616
3) Cast the result to an uint64_t and print it which returns
1. (because 18446744073709551616 is 1 above the maximum value that can be
represented with a `uint64_t`)
So in essence it seems to be standard C++ behavior.
Note that interestingly enough, when I do step 1+2+3 within the SAME function,
one gets back 18446744073709551615.
double d_uint64_max = std::numeric_limits<uint64_t>::max ();
std::cout << std::setprecision (20) << "d_uint64_max: " << d_uint64_max <<
std::endl;
uint64_t tt = static_cast<uint64_t> (d_uint64_max);
std::cout << "d_uint64_max converted to tt (uint64_t): " << tt <<
std::endl;
d_uint64_max: 18446744073709551616
d_uint64_max converted to tt (uint64_t): 18446744073709551615
I guess that the compiler uses some quirks/optimizations which on purpose or
by accident assign the original std::numeric_limits<uint64_t>::max () to an
unit64_t, so one gets
18446744073709551615.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?63995>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/