octave-bug-tracker
[Top][All Lists]
Advanced

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]