Menu
▾
▴
tcl-core
|
From: Jos D. <jos...@gm...> - 2009-02-09 12:17:01
|
TIP #347: ADD 'STRING IS BIGNUM' TO THE 'STRING IS' SUBCOMMAND ================================================================ Version: $Revision: 1.2 $ Author: Jos Decoster <jos.decoster_at_gmail.com> State: Draft Type: Project Tcl-Version: 8.6 Vote: Pending Created: Monday, 09 February 2009 URL: http://purl.org/tcl/tip/347.html WebEdit: http://purl.org/tcl/tip/edit/347 Discussions-To: news:comp.lang.tcl Post-History: ------------------------------------------------------------------------- ABSTRACT ========== The *string* command supports tests for a number of Tcl's basic types, for example, integers, doubles, and booleans. This TIP proposes adding bignum integers, as was done for wide integers in [TIP #188]. RATIONALE =========== The *string* command includes tests for the common Tcl types: *string is boolean*, *string is double* and *string is integer*. Unaccountably, *string is bignum* is missing from the list, making it difficult for an input validation procedure to determine whether, in fact, a string contains a valid (bignum) integer. SPECIFICATION =============== This document proposes augmenting the *string is* command with a *string is bignum* that functions the same as *string is integer* in every respect except for the fact that it accepts any string containing a substring that is valid as a bignum integer (that is, acceptable to /Tcl_GetBignumFromObj/) possibly surrounded by whitespace. REFERENCE IMPLEMENTATION ========================== Patches that implement *string is bignum*, provide test cases for it, and update /doc/string.n/ to include it are available at SourceForge as Tcl Patch #2581150[<URL:https://sourceforge.net/support/tracker.php?aid=2581150>]. COPYRIGHT =========== This document has been placed in the public domain. ------------------------------------------------------------------------- TIP AutoGenerator - written by Donal K. Fellows |
|
From: Jos D. <jos...@gm...> - 2009-02-09 12:48:52
|
TIP #347: ADD 'STRING IS BIGNUM' TO THE 'STRING IS' SUBCOMMAND ================================================================ Version: $Revision: 1.3 $ Author: Jos Decoster <jos.decoster_at_gmail.com> State: Draft Type: Project Tcl-Version: 8.7 Vote: Pending Created: Monday, 09 February 2009 URL: http://www.tcl.tk/cgi-bin/tct/tip/347.html Discussions-To: news:comp.lang.tcl Post-History: ------------------------------------------------------------------------- ABSTRACT ========== The *string* command supports tests for a number of Tcl's basic types, for example, integers, doubles, and booleans. This TIP proposes adding bignum integers, as was done for wide integers in [TIP #188]. RATIONALE =========== The *string* command includes tests for the common Tcl types: *string is boolean*, *string is double* and *string is integer*. Unaccountably, *string is bignum* is missing from the list, making it difficult for an input validation procedure to determine whether, in fact, a string contains a valid (bignum) integer. SPECIFICATION =============== This document proposes augmenting the *string is* command with a *string is bignum* that functions the same as *string is integer* in every respect except for the fact that it accepts any string containing a substring that is valid as a bignum integer (that is, acceptable to /Tcl_GetBignumFromObj/) possibly surrounded by whitespace. REFERENCE IMPLEMENTATION ========================== Patches that implement *string is bignum*, provide test cases for it, and update /doc/string.n/ to include it are available at SourceForge as Tcl Patch #2581150[<URL:https://sourceforge.net/support/tracker.php?aid=2581150>]. COPYRIGHT =========== This document has been placed in the public domain. |
|
From: Donald G P. <dg...@ni...> - 2009-02-09 13:45:55
|
Jos Decoster wrote: > TIP #347: ADD 'STRING IS BIGNUM' TO THE 'STRING IS' SUBCOMMAND This proposal is part of what TIP 297 aims for. I would like to see the two TIPs merged into one and completed. FWIW, this would be the first exposure of the name "bignum" to the script level, and I don't find that a good thing. I would name the command [string is entier]. -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Donal K. F. <don...@ma...> - 2009-02-09 15:41:53
|
Donald G Porter wrote: > FWIW, this would be the first exposure of the name "bignum" to the > script level, and I don't find that a good thing. I would name the > command [string is entier]. For the record, the TIP has been updated in accordance with this (including its title). Donal. |
|
From: Lars H. <Lar...@re...> - 2009-02-11 11:23:28
|
Donal K. Fellows skrev:
> Donald G Porter wrote:
>> FWIW, this would be the first exposure of the name "bignum" to the
>> script level, and I don't find that a good thing. I would name the
>> command [string is entier].
>
> For the record, the TIP has been updated in accordance with this
> (including its title).
How very depressing! The unintelligible (unless, it seems, you're
versed in ALGOL) "entier" is getting further entrenched, and concerns
about C-level arithmetic are taken as canon for the script level interface.
The natural name for this functionality is [string is integer]. The
functionality now occupying that name should be revised (since,
according to TIP#297, it anyway doesn't quite do what the documentation
says) and given a name that more clearly hints at its range
restriction, e.g. [string is int] (which would have the advantage of
being accepted also in older Tcl versions).
In general, I suspect the usefulness of a command that checks a string
for being a valid integer *and* further applies a hardware-oriented
range restriction to it (current [string is integer] and [string is
wideinteger]) is rather limited, if there is an alternative command not
doing the range check. Yes, current [string is integer] can be used to
check whether e.g. [lindex] would choke on it, but how useful is it to go
if {![string is integer $index]} then {error "Not an int"}
set elem [lindex $list $index]
when the [lindex] command anyway throws an error in that case? Anyone
who bothers to check this kind of argument would probably apply a more
specific condition, e.g. that the $index must be in the range of the $list.
So: Let the proposed [string is bignum] be called [string is integer].
Yes, it is a potential incompatibility, but I think this change would
/fix/ far more programs than it breaks.
Lars Hellström
|
|
From: Donald A. <as...@tr...> - 2009-02-11 20:46:06
|
Lars Hellstr?m <Lar...@re...> writes: > Donal K. Fellows skrev: > > Donald G Porter wrote: > >> FWIW, this would be the first exposure of the name "bignum" to the > >> script level, and I don't find that a good thing. I would name the > >> command [string is entier]. > > > > For the record, the TIP has been updated in accordance with this > > (including its title). > > How very depressing! The unintelligible (unless, it seems, you're > versed in ALGOL) "entier" is getting further entrenched, and concerns > about C-level arithmetic are taken as canon for the script level interface. > > The natural name for this functionality is [string is integer]. Hear hear! I was about to pipe in about the meanings of "integer" and "entier", but they have already been covered. I like the idea of "int" for the original behavior. If seamless conversion and expr support can be relied on, then the original [string is integer] could be abandoned. When people are concened about the numerical range of their integers, they should check the numerical values. -- Donald Arseneau as...@tr... |
|
From: Donald G P. <dg...@ni...> - 2009-02-11 23:10:26
|
Donald Arseneau wrote: > If seamless conversion and expr support can be relied on, then > the original [string is integer] could be abandoned. When > people are concened about the numerical range of their integers, > they should check the numerical values. Check them with what? -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Andreas K. <and...@ac...> - 2009-02-11 23:17:59
|
Donald G Porter wrote:
> Donald Arseneau wrote:
>> If seamless conversion and expr support can be relied on, then
>> the original [string is integer] could be abandoned. When
>> people are concened about the numerical range of their integers,
>> they should check the numerical values.
>
> Check them with what?
The standard relational operators. I believe DonalA envisions code like
if {![string is integer $input] || ($input < $min) || ($input > $max)} {
handle out of range integr ...
}
Andreas
|
|
From: Donal K. F. <don...@ma...> - 2009-02-12 00:27:10
|
Andreas Kupries wrote: > I believe DonalA envisions code like I don't envisage anything here. I'm just acting as editor for Jos. Donal. |
|
From: Andreas K. <and...@ac...> - 2009-02-12 00:30:43
|
Donal K. Fellows wrote: > Andreas Kupries wrote: >> I believe DonalA envisions code like > > I don't envisage anything here. I'm just acting as editor for Jos. Apologies. I meant Donal<d>A, i.e. Donald Arsenau. Andreas. |
|
From: Donald A. <as...@tr...> - 2009-02-12 02:40:45
|
Donald G Porter <dg...@ni...> writes:
> Donald Arseneau wrote:
> > If seamless conversion and expr support can be relied on, then the original
> > [string is integer] could be abandoned. When
> > people are concened about the numerical range of their integers,
> > they should check the numerical values.
>
> Check them with what?
something like
if { [string is integer $x] && $x == ($x & 0xFFFFFFFF) } {
--
Donald Arseneau as...@tr...
|
|
From: <dg...@ni...> - 2009-02-12 03:42:37
|
Quoting "Donald Arseneau" <as...@tr...>:
> something like
> if { [string is integer $x] && $x == ($x & 0xFFFFFFFF) } {
But that's not what the current [string is integer] does.
It enforces a limited range that is platform dependent.
DGP
|
|
From: Twylite <tw...@cr...> - 2009-02-11 13:10:06
|
Lars Hellström wrote: > How very depressing! The unintelligible (unless, it seems, you're > versed in ALGOL) "entier" is getting further entrenched, and concerns > about C-level arithmetic are taken as canon for the script level interface. > Just voicing my agreement with Lars here -- entier is barely known or used in english or mathematics, and actually means "the integer part" (as in floor / trunc) rather than "an integer". [string is entier] is not only meaningless to most developers (who would understand "bignum" intuitively), but technically inaccurate. The best alternative proposal I have is [string is number]. But of course that should be true for non-integer real numbers. I don't think that changing the meaning of [string is integer] is the right approach. My 2c. Twylite |
|
From: Daniel A. S. <da...@ca...> - 2009-02-11 21:04:05
|
On Wed, Feb 11, 2009 at 19:55, Jeff Hobbs <je...@ac...> wrote: > As to [string is number] looking at the implementation, it turns out that [string is double] is actually [string is number] already, as it does not restrict to numbers that fit inside the C 'double' type... there is a TODO in that code, but given that that's been there since the original TIP#237 implementation and that this is now established behaviour in 8.5, we may be stuck with it: http://fisheye.categorifiedcoder.info/browse/Tcl/tcl/generic/tclCmdMZ.c?r=1.132#l1533 |
|
From: Jeff H. <je...@ac...> - 2009-02-11 18:55:58
|
On 11-Feb-09, at 3:49 AM, Twylite wrote: > Lars Hellström wrote: >> How very depressing! The unintelligible (unless, it seems, you're >> versed in ALGOL) "entier" is getting further entrenched, and concerns >> about C-level arithmetic are taken as canon for the script level >> interface. >> > Just voicing my agreement with Lars here -- entier is barely known or > used in english or mathematics, and actually means "the integer part" > (as in floor / trunc) rather than "an integer". [string is entier] is > not only meaningless to most developers (who would understand "bignum" > intuitively), but technically inaccurate. > > The best alternative proposal I have is [string is number]. But of > course that should be true for non-integer real numbers. I don't > think > that changing the meaning of [string is integer] is the right > approach. +1 on using bignum over entier. We don't need to make Tcl seem any more foreign for no good reason. As to [string is number], that may serve as a catch-all in addition, but the current string is are for classifying the limited string int types. Jeff |
|
From: Daniel A. S. <da...@us...> - 2009-02-11 20:33:15
|
On Wed, Feb 11, 2009 at 21:07, Daniel A. Steffen <da...@us...> wrote: > ([string is number] && ![string is double]) or rather ([string is number] && ![string is float]) with 'float' covering even those floating point numbers that are not doubles... |
|
From: Daniel A. S. <da...@us...> - 2009-02-11 22:56:18
|
On Wed, Feb 11, 2009 at 21:10, Daniel A. Steffen <da...@us...> wrote: > On Wed, Feb 11, 2009 at 21:07, Daniel A. Steffen > <da...@us...> wrote: >> ([string is number] && ![string is double]) > > or rather ([string is number] && ![string is float]) > with 'float' covering even those floating point numbers that are not doubles... ugh, sorry, what I meant to say is 'float' would cover the subset of R-Z that can be represented as floating point numbers... |
|
From: Daniel A. S. <da...@us...> - 2009-02-11 20:36:31
|
On Wed, Feb 11, 2009 at 19:55, Jeff Hobbs <je...@ac...> wrote: > As to [string is number], that may > serve as a catch-all in addition, but the current string is are for > classifying the limited string int types. note however that bignum is not a limited int type, given that it covers all integers (in the mathematical sense). it would seem that ([string is number] && ![string is double]) would be sufficient to cover the proposed usage of [string is entier] resp [string is bignum], sidestepping the whole naming issue (not a fan of entier either, but it's better than exposing bignum) Cheers, Daniel -- ** Daniel A. Steffen ** ** <mailto:da...@us...> ** |
|
From: Fredderic <mag...@gm...> - 2009-02-13 17:54:06
Attachments:
signature.asc
|
On Wed, 11 Feb 2009 21:07:37 +0100, "Daniel A. Steffen" <da...@us...> wrote: > On Wed, Feb 11, 2009 at 19:55, Jeff Hobbs <je...@ac...> > wrote: >> As to [string is number], that may >> serve as a catch-all in addition, but the current string is are for >> classifying the limited string int types. > it would seem that ([string is number] && ![string is double]) would > be sufficient to cover the proposed usage of [string is entier] resp > [string is bignum], sidestepping the whole naming issue (not a fan of > entier either, but it's better than exposing bignum) Would it make sense at all to throw the whole lot backwards a step, instead of having a bunch of [string is XXX]'s for various integer ranges. Something like one of these options; 1) how about adding -options to [string is integer] to constrain it to specific sizes of integer, with the default being any integer that TCL can handle (ie. the proposed [string is bignum]). This also would allow for a -?un?signed flag, and -8/16/32-bit (eg. "-bits 8/16/32"), etc., which could come in handy for testing whether a number will fit into a given [binary] field, for example. 2) add an easy way to obtain the number of bits needed to store a given number, or the number of bytes needed to store it. (The latter would likely be more useful anyhow.) Then just add an equally easy way to obtain the number of bits/bytes contained in various common integer types, and the test is only a comparison away. 3) a [string classes] command that will return a list of all the standard string classes which match a given value. Return the list sorted, suitable for use with [lsearch -sorted] or the "in" operator. Then, if the basic [string is] tests don't do it for you, [string classes] provides a bunch of properties that can be tested on. I can see this being painfully slow to use on a regular basis, however. My preference would be for option #1... A single [string is integer] class with optional constraints as to exactly what it will accept, but defaulting to the script-wise view of any integer TCL supports. Just a thought... -- Fredderic Debian/unstable (LC#384816) on i686 2.6.26-z2 2008 (up 4 days, 9:37) |
|
From: Donald G P. <dg...@ni...> - 2009-02-11 22:24:07
|
Daniel A. Steffen wrote: > On Wed, Feb 11, 2009 at 19:55, Jeff Hobbs <je...@ac...> wrote: >> As to [string is number] > > looking at the implementation, it turns out that [string is double] is > actually [string is number] already, as it does not restrict to > numbers that fit inside the C 'double' type... > > there is a TODO in that code, but given that that's been there since > the original TIP#237 implementation and that this is now established > behaviour in 8.5, we may be stuck with it: That TODO was never about changing the meaning of what [string is double] tests for, but about reconsidering the particular implementation in place at that point. The meaning of [string is double] got established as accepting integers when it was defined in terms of what strtod() accepted, and they accepted integers. -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Donald G P. <dg...@ni...> - 2009-02-11 22:32:22
|
Daniel A. Steffen wrote:
> On Wed, Feb 11, 2009 at 22:37, Daniel A. Steffen
> <da...@ca...> wrote:
>> sure, my point was that [string is double] accepts all bignums,
>> including those that cannot fit into a C double without loss of
>> precision, or even those bigger than DBL_MAX...
>
> leading to things like this:
>
> % set x [expr {10**400}]
> 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> % string is double $x
> 1
> % expr {double($x)}
> Inf
>
> from the manpage text, I would not have expected an overflowing double
> to be acceptable:
>
> double Any of the valid forms for a double in Tcl, with
> optional surrounding whitespace. In case of
> under/overflow in the value, 0 is returned and the
> varname will contain -1.
Looks like an overlooked doc update.
From TIP 249, "Incompatibillities":
Third, Tcl_GetDoubleFromObj will be both more and less permissive than
before. It will no longer accept constants with a leading zero and no
decimal point or 'E' that are invalid octal numbers. On the other hand,
it will accept constants that are too large to fit in a Tcl_WideInt;
somewhat surprisingly, string repeat 9 50 cannot today be interpreted as
a double. string is double will follow Tcl_GetDoubleFromObj in what it
considers acceptable. Any string that is accepted as either an integer
or a double by expr will be accepted in Tcl_GetDoubleFromObj, and only
those strings will be accepted.
--
| Don Porter Mathematical and Computational Sciences Division |
| don...@ni... Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
|
|
From: Daniel A. S. <da...@ca...> - 2009-02-11 23:20:59
|
On Wed, Feb 11, 2009 at 22:52, Donald G Porter <dg...@ni...> wrote: > Looks like an overlooked doc update. ok, I misunderstood the TODO to mean make the implementation agree with those docs... FWIW, I have nothing against that behaviour, I mainly meant to point out that we don't appear to need [string is number] since [string is double] is already true for all numbers... what we do need is an accurate, widely-understood but still unused name for either the set of integers (neither 'entier' nor 'bignum' fits IMO), or the set of non-integer floating point numbers (my 'float' above, not great either given the potential for confusion with 'double'...) |
|
From: Daniel A. S. <da...@ca...> - 2009-02-11 22:43:32
|
On Wed, Feb 11, 2009 at 22:32, Donald G Porter <dg...@ni...> wrote: > The meaning of [string is double] got > established as accepting integers when it was defined in terms of > what strtod() accepted, and they accepted integers. sure, my point was that [string is double] accepts all bignums, including those that cannot fit into a C double without loss of precision, or even those bigger than DBL_MAX... |
|
From: Daniel A. S. <da...@ca...> - 2009-02-11 22:52:20
|
On Wed, Feb 11, 2009 at 22:37, Daniel A. Steffen
<da...@ca...> wrote:
> sure, my point was that [string is double] accepts all bignums,
> including those that cannot fit into a C double without loss of
> precision, or even those bigger than DBL_MAX...
leading to things like this:
% set x [expr {10**400}]
10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% string is double $x
1
% expr {double($x)}
Inf
from the manpage text, I would not have expected an overflowing double
to be acceptable:
double Any of the valid forms for a double in Tcl, with
optional surrounding whitespace. In case of
under/overflow in the value, 0 is returned and the
varname will contain -1.
|
|
From: Jos D. <jos...@gm...> - 2009-02-12 17:10:37
|
Hi, I extended tip 347 to align the [string is <integer_range>] and [::tcl::mathfunc::<integer_range>] commands. http://www.tcl.tk/cgi-bin/tct/tip/347 Kind regards, Jos. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X