Tcl Source Code

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

File Added - 54981: exprdoc.patch

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!

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=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=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


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