Menu

#2379 improved docs for 64-bit computations

obsolete: 8.4.3
closed-fixed
3
2003-07-04
2003-06-21
No

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

Discussion

  • Don Porter

    Don Porter - 2003-06-22

    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

     
  • Don Porter

    Don Porter - 2003-06-22
    • labels: --> 47. Bytecode Compiler
    • assigned_to: nobody --> dgp
    • status: open --> closed-invalid
     
  • Henning Schulzrinne

    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.

     
  • Don Porter

    Don Porter - 2003-06-22
    • priority: 5 --> 3
    • assigned_to: dgp --> dkf
    • summary: pow(2,63) returns wrong result --> improved docs for 64-bit computations
    • status: closed-invalid --> open-remind
     
  • Don Porter

    Don Porter - 2003-06-22

    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

     
  • Donal K. Fellows

    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.

     
  • Donal K. Fellows

    • status: open-remind --> closed-fixed
     
  • Donal K. Fellows

    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!

     
  • Donal K. Fellows

    Patch for expr.n