Given the support for 64-bit numbers, there's no reason
that
pow(2,63) shouldn't do the right thing. Currently, it does
expr wide(pow(2,63))
9223372036854775807
which is off by one. Other 64-bit computations are also
odd:
expr wide(1 << 62)
1073741824
expr 1 << 62
1073741824
Logged In: YES
user_id=80530
Your demo script does not show anything
wrong with the pow() function.
pow(2,63) should return a double representation
of the value 2^63 = 9223372036854775808.
It does:
% format %.19g [expr {pow(2,63)}]
9223372036854775808
When you pass that value to wide(),
though, you ask for the wide integer
value of 2^63, which can't be done
because valid wide integers are those
in the range -2^63 to (2^63) - 1.
Use of 64-bit ints does not make overflow
issues go away, it just changes where
they happen.
On the other matter, try this:
% expr {wide(1) << 62}
4611686018427387904
Logged In: YES
user_id=115926
The documentation at
http://www.tcl.tk/man/tcl8.4/TclCmd/expr.htm does not
indicate that pow() converts the arguments to double or that
it returns a double.
In addition, << and >> only mention that they work with
'integers'. The documentation also says:
"On 32-bit systems, integer values MAX_INT (0x7FFFFFFF) and
MIN_INT (-0x80000000) will be represented as 32-bit values,
and integer values outside that range will be represented as
64-bit values (if that is possible at all.)"
Thus, from the description, one can reasonably assume that 1
<< 48, say, will produce a valid 64-bit number, not some
32-bit result.
Logged In: YES
user_id=80530
fair enough. Assigning to the
contributor of the latest 64-bit
improvements for his opinion
on what documentation
improvements might be a good idea.
If you can help with contributed
improvements, or by asking questions
about what the current docs do not
make clear, please do so.
Meanwhile, TIP 72 might provide
additional information about Tcl's
new 64-bit capabilities that you
find useful
http://purl.org/tcl/tip/72.html
Logged In: YES
user_id=79902
pow() is basically an embedding of pow() from the C math
library. That in turn is not an integer-returning function.
Hence neither is the Tcl version, and wrapping wide()
around it doesn't change anything; it just bandages on a
type-conversion afterwards.
Logged In: YES
user_id=79902
Tightened up the wording in expr.n as it was slightly loose
from the PoV of people coming from other than a C/C++
background.
I attach the patch I've applied (to both the HEAD and 8.4)
here. Henning, if you feel that the alterations it makes are
insufficient, could you please supply more detail about how
you feel things should be fixed? Thanks!
Patch for expr.n