Menu
▾
▴
#324 Integers aren't strings anymore
Throughout most of Tcl8, there has been a bug (or
malfeature of the tcl_precision variable) that two float
values can have identical string representations but
still behave differently when operated on. I hope that
TIP 132 will soon correct this.
Although floats have been slightly magical, one has
however always been able to rely on integers to not hide
any information from the string representation. Sadly,
that isn't true anymore. Behold:
% set l [expr 65536]
65536
% set w [expr {wide($l)}]
65536
% string equal $l $w
1
% expr {$l * 65536}
0
% expr {$w * 65536}
4294967296
In short, the bug is that [expr] lets its result depend
on details of the internal representation that are not
recorded in the string representation.
In a larger perspective, I think this is a symptom of a
failure to clearly decide what an integer should be in
Tcl, but sortinh that out requires a TIP. (IMHO the only
approach that has a chance of being consistent is to
allow arbitrarily long decimal strings as integers, as
now use efficient internal representations for integers
up to 32 or 64 bits, and rely on some callback similar
to [unknown] for all operations on larger numbers.)
Logged In: YES
user_id=80530
Note this is assigned to Donal Fellows,
who is only intermittently available
during the holiday season.
People interested in this report might
want to have a look at TIP 72, and
the compromises made to get 64-bit
integer support into Tcl while limiting
the incompatibilities introduced.
http://purl.org/tcl/tip/72.html
Logged In: YES
user_id=79902
Yuck.
The problem is balancing between the real need for 64-bit
values and the (unknown) quantity of code out there that
assumes that int values are 32-bits wide. If it hadn't been
for that (and the speed implications on 32-bit platforms),
I'd have preferred to make all integers 64-bits wide on all
platforms.
Trying to do something with magic representation shimmering
is unlikely to work well, since it is hard to make the
processor math ops give some kind of trap when they lose
information during the processing of ints. Getting a cheap
way to perform the type guards is the critical part, that
and defining a non-surprising way to deal with the situation
(which currently escapes me.)
If you want to try your hand at fixing math ops, their
semantics are defined entirely within tclExecute.c; the
math-related ops start at INST_EQ and are mostly
self-explanatory (if long.)
Logged In: YES
user_id=938835
The quickest way of fixing this bug is probably to keep the
behaviour of the bytecode instructions, but change the string
representation of wides so that this behaviour becomes
proper. Such a string representation could be as that
generated by the [format] specifier
wide(%d)
since this has the merit of surviving an unbraced [expr].
From this would then follow that anything matching the RE
wide\(-?(0|[1-9][0-9]*|0[0-7]*|0x[0-9a-f])\)
ought to be a valid integer. The main side-effect should be
that output of wides which is not [format]ed may look a
little strange, and that is probably acceptable.
Logged In: NO
Question.
Would making all Tcl integers 64 bit quantities
actually make a *noticeable* difference to speed
even on 32bit machines?
Logged In: YES
user_id=79902
In speed terms, I don't think it would make much odds. Any
string operations about will dominate for sure. :)
The problem is the semantic difference; nobody's sure how
much code exists out there that depends on 32-bit widths of
values.
Logged In: YES
user_id=79902
Doing anything about this "bug" requires a TIP and a great
deal of head-scratching. Transferring to the FRQ track...
Logged In: YES
user_id=99768
TIP #132 doesn't fix this, but TIP #237 should.
Logged In: YES
user_id=80530
This ought to be fixed now.
Comment here if not.
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).