Tcl Source Code

Currently srand() takes an integer (long) argument.
It would be nice if it was extended to also handling
wides that were too big for a long aswell. 

Rationale:

expr {srand( [clock clicks] )}

is probably not an uncomon idiom (well i use it :-) 
This is fine in 8.4 where [clock clicks] is a long,
but under 8.5 gives the initially confusing error:

can't use floating-point value as argument to srand

Although rand()'s "randSeed" is a long, in the case
where it is given a big wide, couldn't Tcl just, for
example, truncate it down to a long?

File Added - 176830: 1480509-85.patch

Logged In: YES 
user_id=80530


and the patch for 8.5a4.

Both patches committed.

File Added - 176828: 1480509.patch

Logged In: YES 
user_id=80530


Here's a patch for 8.4.14

data_type - 110894

Logged In: YES 
user_id=80530


Looks like that change caused this
bug.

Logged In: YES 
user_id=80530


Mystery solved:

2005-04-05  Don Porter  <[email protected]>

        * generic/tclExecute.c (ExprSrandFunc): Replaced
incursions into the
        * generic/tclUtil.c (TclGetIntForIndex): intreps of
numeric types
        with simpler calls of Tcl_GetIntFromObj and
Tcl_GetLongFromObj,
        now that those routines are better behaved wrt
shimmering.
        [Patch 1177219]

Logged In: YES 
user_id=80530


Mystery solved:

2005-04-05  Don Porter  <[email protected]>

        * generic/tclExecute.c (ExprSrandFunc): Replaced
incursions into the
        * generic/tclUtil.c (TclGetIntForIndex): intreps of
numeric types
        with simpler calls of Tcl_GetIntFromObj and
Tcl_GetLongFromObj,
        now that those routines are better behaved wrt
shimmering.
        [Patch 1177219]

Logged In: YES 
user_id=1386588

fyi - my previous 8.4 result was from an
ActiveState installed tclsh...

Just tried with a self built version:

% info pa
8.4.11
% expr srand(4294967296)
can't use floating-point value as argument to srand

And with an older self built (debug):

% info pa
8.4.6
% expr srand(4294967296)
0.242578298898

Logged In: YES 
user_id=80530


Note that on 32-bit platforms,
"long" and "int" are identical,
so the distinction I made doesn't
show up there.

I'm troubled that my 8.4 results
are different from yours:

% info patch
8.4.13
% expr srand(4294967295)
0.757421701102
% expr srand(4294967296)
can't use floating-point value as argument to srand

Logged In: YES 
user_id=80530


Um, sorry, I take that correction
back.  ExprSrandFunc does indeed
pull a "long" from the argument,
and then truncates to "int".

And this means there's no
simple way to test an argument
for acceptability at the script
level.

Logged In: YES 
user_id=1386588

I'm happy with Donal's answer - my call to srand() was
unnecesary. I'm happy to close this report now.

>Currently srand() takes an "int"
>argument, not a "long" argument.
>That is, only values that pass
>[string is integer -strict] are
>accepted.

...i was skeptical when i read this (!) but, you're right:

% info pa
8.5a3
% string is integer -strict  4294967296
0
% string is integer -strict  4294967295
1
% expr srand(4294967295)
0.7574217011022483
% expr srand(4294967296)
can't use floating-point value as argument to srand


although, this isn't the behaviour of 8.4:

% info pa
8.4.8
% string is integer -strict  4294967295
1
% string is integer -strict  4294967296
0
% expr srand(4294967295)
0.757421701102
% expr srand(4294967296)
0.242578298898

Logged In: YES 
user_id=80530


Um, just a minor correction.

Currently srand() takes an "int"
argument, not a "long" argument.
That is, only values that pass
[string is integer -strict] are
accepted.

Logged In: YES 
user_id=79902

Actually, Tcl automatically seeds the PRNG with a value
based on [clock clicks] anyway, even without being asked.
The real use for srand() is for getting a *reproducable*
sequence of pseudorandom numbers...