Compound expression and order of evaluation
j...@maniscorse.co.uk
Can anybody confirm for that in the following code, that the regsub
expression is always evaulated first, so that I can be certain that
Extras will always be correctly set? I've looked on the Wiki and in
"Practical Programming" but I cannot find the answer.
Many thanks,
Jo.
set Extras "xx"
set LengthCheck 12
set BitMap "101010101010"
if {([regsub -all {[0-1]} $BitMap "" Extras] == $LengthCheck) &&
([string length $Extras] == 0)} {
.
.
.
Jeff Hobbs
> Can anybody confirm for that in the following code, that the regsub
> expression is always evaulated first, so that I can be certain that
> Extras will always be correctly set? I've looked on the Wiki and in
> "Practical Programming" but I cannot find the answer.
> if {([regsub -all {[0-1]} $BitMap "" Extras] == $LengthCheck) &&
> ([string length $Extras] == 0)} {
Yes, order of evaluation is left to right in Tcl expressions and does
proper short-circuiting.
Jeff
Roy Terry
news:1177958639.8...@y80g2000hsf.googlegroups.com...
Confirmed. Read the expr
man page.
> .
> .
> .
>
Robert Heller
Note: if the regsub *fails* it won't alter Extras...
>
> Jeff
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
suchenwi
Jeff Hobbs schrieb:
> Yes, order of evaluation is left to right in Tcl expressions and does
> proper short-circuiting.
With, iirc, the exception of the ** exponentiation operator new in 8.5
iirc, which is right-associative, so that in
$a**$b**$c
first $b**$c is computed, then $a raised to that power.
Arjen Markus
wrote:
Yes, that is the _only_ exception. (When it was introduced, it was
left-associative,
but that turned out to be rather confusing ;))
Regards,
Arjen
Mark Janssen
Correct me if I am wrong but associativity is unrelated to order of
evaluation. If you for instance use:
expr {[expr 1*1]**[expr 3*4]**[expr 1*1]}
, the order of evaluation of the terms will still be left to right
(even though ** is right associative). Which:
expr {[puts a ; expr 2]**[puts b; expr 2]**[puts c ; expr 2]}
shows.
Mark
suchenwi
Mark Janssen schrieb:
> Correct me if I am wrong but associativity is unrelated to order of
> evaluation. If you for instance use:
>
> expr {[expr 1*1]**[expr 3*4]**[expr 1*1]}
>
> , the order of evaluation of the terms will still be left to right
> (even though ** is right associative). Which:
>
> expr {[puts a ; expr 2]**[puts b; expr 2]**[puts c ; expr 2]}
>
> shows.
Right.. operator precedence takes ... precedence, as evident from
simple things like
2 + 3 * 4
Mark Janssen
Which is a different thing from associativity again. Precedence is
defined for different operators, associativity for multiple
applications of the same operator. e.g.
Associativity governs the result of:
1**2**3
1-2-3
precedence of
1+2**3
Any more mathematical concepts you would like to include :-)
Mark
Donal K. Fellows
> Which is a different thing from associativity again. Precedence is
> defined for different operators, associativity for multiple
> applications of the same operator. e.g.
> Associativity governs the result of:
> 1**2**3
> 1-2-3
> precedence of
> 1+2**3
In practical terms, the right-associativity of ** means that internally
Tcl has to build a stack of intermediate values before applying the
exponentiation operator to combine them. (With left-associative
operators, it is possible to handle terms without such complexity.)
Donal.
Donald Arseneau
> In practical terms, the right-associativity of ** means that internally
> Tcl has to build a stack of intermediate values before applying the
> exponentiation operator to combine them.
Oh no! You mean
2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2*...
will cause an overflow?!
;-)
--
Donald Arseneau as...@triumf.ca
suchenwi
Donald Arseneau schrieb:
> Oh no! You mean
> 2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2*...
> will cause an overflow?!
Even if left-associative, this will soon blow all limits...
Gerald W. Lester
Even with bignum support?
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Neil Madden
> suchenwi wrote:
>> Donald Arseneau schrieb:
>>> Oh no! You mean
>>> 2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2**2*...
>>>
>>> will cause an overflow?!
>>
>> Even if left-associative, this will soon blow all limits...
>>
>
> Even with bignum support?
Oh yes, even bignums have their limits:
% string length [expr {2**2**2**2**2}]
19729
% expr {2**2**2**2**2**2}
exponent too large
% info pa
8.5a6
-- Neil
Neil Madden
Urgh... shouldn't post this late. Obviously with left-associativity this
limit becomes quite a bit larger (it seems there is a particular limit
on the exponent, for sane reasons). A different test script:
set i 0
set n 2
while 1 {
set n [expr {$n**2}]
puts [format "%8d = %10d" [incr i] [string length $n]]
}
Currently, my MacBook is at:
18 = 78914
Iteration 19 is taking rather a long time... (and the fan has gone into
jet-engine mode).
-- Neil
Arjen Markus
>
> - Tekst uit oorspronkelijk bericht weergeven -
There is an easier way to estimate the size of (...
(((((2**2)**2)**2)**2)**2**2...):
log10(2**2) = 2*log10(2)
log10((2**2)**2) = 2*( log10(2**2)) = 2*2*log10(2)
...
So:
set n [expr {log10(2.0)}]
for { set i 1 } { $i < 100 } { incr i } {
set n [expr {2.0*$n}]
set d [expr {wide(ceil($n))}]
puts "(... $i ... (2**2)): ~ $d digits"
}
This, you can imagine, is a trifle faster :).
Regards,
Arjen
Donald Arseneau
> There is an easier way to estimate the size of (...
I'm glad my little joke provided so much ... errrmm.. amusement?
--
Donald Arseneau as...@triumf.ca
Arjen Markus
> Arjen Markus <arjen.mar...@wldelft.nl> writes:
> > There is an easier way to estimate the size of (...
>
> I'm glad my little joke provided so much ... errrmm.. amusement?
>
> --
:)
I didn't try to find a shortcut for the case of ** being right-
associative - mainly
because it soon becomes bizarre: how do you represent the number of
digits in
10**(10**10) (that is slightly smaller than
2**(2**(2**(2**(2**(2**(2**2))))), I think)?
Regards