expr - Evaluate an expression
expr arg ?arg arg ...?
expr(n) manpage (Tcl 8.4)
expr(n) manpage , mathfunc(n) manpage , mathop(n) manpage (all Tcl 8.5)
expr concatentates its arguments, evaluates this result as a Tcl [expr] implements a mini language that has a syntax separate from the Tcl syntax. It supports some of the same constructs as Tcl, such as variable substitution, command substitution, and braces. It adds additional syntax for mathematical operators and functions, and unlike Tcl, does not accept character strings that are not enclosed in double quotes or brackets. expr implements a little language that has a syntax separate from Tcl.
# Simple addition set a expr {1 + 2}
# Invoke expr function. set a expr {sqrt(4)}
#martin Lemburg: returns 1, because " 2 " will be converted to 2 set a expr {" 2 " == [string trim " 2 "}]
#returns 4, rather than -4 as some might expect set a expr {-2**2}
# returns 1 because 2==2 is evaluated first set a expr {5&2==2}
To ensure that expression evaluates to a floating point number, use function like ''double()'':
set a 1 set b 2 expr {double($a)/$b}
or, to get an integer:
expr {entier($a/$b)}
''int()'' would also have worked, but ''entier()'' is more general
In this example, '''expr''' [concat]enates each ''arg'' (adding separator
spaces between them), evaluates the result as a [Tcl] expression, and returns
the value. The operators permitted in Tcl expressions include most of the
operators permitted in [C] expressions and a few aditional ones, and they have
the same meaning and precedence as the corresponding C operators. Expressions
almost always yield numeric results (integer or floating-point values). For
example, the expression:
set val1 8.2
set val2 6
expr {$val1 + $val2}
expr {$val1} + ${val2}
evaluates to 14.2.This is an equivalent way of writing the previous [expr] command: In most cases, it's best to brace or otherwise expr {$val1+$val2} expr {$val1+$val2}
This allows expr to do the interpretation, rather than having Tcl interpret Any argument that can be interpreted in some way, e.g., variable or a command expansion, should be enclosed in brackets. This allows the [expr] command to do the interpretation, rather than having the caller interpret the arguments before handing them off to [expr]. See below for more details. expr expressions differ from C expressions in the way that operands are Tcl expressions differ from C expressions in the way that operands are specified. They also include some non-numeric operators for strings (comparison) and lists (membership).
expr's parsing of decimals may be hampered by locale - you might get an
expr concatenates its arguments into an expression. Consider the following expr resolves variables in the context of its caller, interpolating their value before evaluating the expression. Consider the following
expr 5 > {} ;# -> missing operand at _@_
set color2 green
expr {$color1} eq {$color2} ;# 1
Concatenated, the arguments form the script, `green eq green`, in which the two
But if the arguments are not bracketed, there is an error in the expression syntax:
Another example illustrating the same point:#wrong expr $color1 eq $color2
invalid bareword "green" in expression "green eq green"; should be "$green" or "{green}" or "green(...)" or ...
This is because in [[expr]] syntax, strings should be quoted or bracketed
set a "abc" expr $a in $b # invalid bareword "abc" # in expression "abc in 123 abcd xyz lmnop"; # should be "$abc" or "{abc}" or "abc(...)" or ...
expr {$a in $b} ;#-> 0 expr {$a in $b} # 0 expr {$a ni $b} ;#-> 1 expr {$a ni $b} # 1
% expr $a == "foo" ? true : false
% expr {$a eq "foo" ? true : false}
% expr {$a == "foo" ? true : false}When exactly one unconcatenated value is passed to expr, the argument can be In addition, [expr] is usually much more performant when its non-literal arguments are braced, since this allows byte-compilation. Fast:
AMG: The security problems of unbraced expressions are very similar to AMG: The security problems of unbraced expr expressions are very similar to SQL injection attacks. Notice how sqlite's Tcl binding does its own this problem as well because the default is to apply multiple passes of interpretation.
See also double substitution.
input:
#DON'T EXECUTE THIS SCRIPT!!!
set x {[exec format C:\\]}
set j {[puts Sucker!]}
#C:\ get formatted in the next command
set k [expr $x / $j.]On the other hand,
set k [expr { $x / double($j) }]gives a much more reasonable result:
argument to math function didn't have numeric value
while executing
"expr { $x / double($y) }"
invoked from within
"set k [expr { $x / double($y) }]
"
(file "foo.tcl" line 3)
Unless you know exactly what you are doing, unbraced expressions are not recommended. Nevertheles...
With unbraced expressions, . (\x2e) can be appended to a variable to get expr With unbraced expressions, a "." can be appended to a variable to get [expr] to interpret the value as a float, but the double() function is a better alternative:
set x 1; set j 2
# works (but don't do this)
expr $x/$j.
#an accepted way to do it
expr {double($x)/$j}
# error: syntax error in expression "$x/$j." (expr parser)
expr {$x/$j.}It's faster, too:
set script1 {
set x 1
set j 2
set k [expr $x / $j.]
}
set script2 {
set x 1
set j 2
set k [expr { $x / double($j) }]
}
foreach v {script1 script2} {
foreach v { script1 script2 } {
}
#script1: 38 microseconds per iteration
#script2: 9 microseconds per iteration
#[pyk] 2012-11-28: what a difference a few years makes (an "old" 3.06Ghz Intel Core 2 Duo):
#[pyk] 2012-11-28: wow, what a difference a few years makes (an "old" 3.06Ghz Intel Core 2 Duo):
#script2: 0.7374299 microseconds per iterationRS: This was just to demonstrate the differences between the regular Tcl parser and expr's parser, not recommended practice. Another example is
set op +
set op "+"
9
expr {4 $op 5}
syntax error in expression "4 $op 5"See the for page on a case where that helped. See the for page on a case where that helped.
Note that many operators have command-equivalents in the namespace ::tcl::mathop from Tcl 8.5 onwards.
[The term mathop is a misnomer, since some of the operators included in this namespace are string, rather than math, oriented...]
The expr operators, in order of precedence (tightest-binding to least-tight binding), are:
| - + ~ ! | Unary operators; specifically a negation operation, a non-negation operation (I see little point in this one), a bit-wise NOT operation (every bit in the input value gets replaced by its inverse) and a logical NOT operation (non-zero maps to zero, and zero maps to one.) |
| * / % | Multiplication, division and integer remainder (see fmod() below.) |
| + - | Addition and subtraction. |
| << >> | Left and right shift. Equivalent to multiplying or dividing by a suitable power of two, and then reducing the result to the range representable in an integer on the host platform. |
| < > <= >= | Ordering relations (less than, greater than, less than or equal, greater than or equal.) Note that these operations work on strings as well as numbers, but you are probably better off testing the result of string compare instead as that is more predictable in the case of a string that looks like a number. |
| == != | Equality and inequality. Note that these operations work on strings as well as numbers, but you are probably better off testing the result of string equal instead as that is more predictable in the case of a string that looks like a number. For example, string equal considers "6" and "06" to be different strings, but expr's == considers them to be equivalent numbers. |
| eq ne | (2004-07-08 added): From Tcl 8.4 on. The same as before, but arguments only strings. Will find "6" and "06" (as well as 1 and 1.0) to be different. |
| ** | exponential. From Tcl 8.5 on |
| in ni | Item (argument 1) in/not in list (argument 2). From Tcl 8.5 on |
| & | Bit-wise AND. A bit is set in the result when the corresponding bit is set in both the arguments. |
| ^ | Bit-wise exclusive OR. A bit is set in the result when the corresponding bit is set in precisely one of the arguments. |
| | | Bit-wise OR. A bit is set in the result when the corresponding bit is set in either of the arguments. |
| && | Logical AND. The result is a one (true) when both of the arguments are non-zero (true), and zero (false) otherwise. Note that this operation is a short-circuiting operation, and will only evaluate its second argument when the first argument is non-zero. This includes the expansion of Tcl commands in square brackets, but this delay in evaluation only occurs if the whole expression is enclosed in curly braces. |
| || | Logical OR. The result is a zero (false) when both of the arguments are zero (false), and one (true) otherwise. Note that this operation is a short-circuiting operation, and will only evaluate its second argument when the first argument is zero. This includes the expansion of Tcl commands in square brackets, but this delay in evaluation only occurs if the whole expression is enclosed in curly braces. |
| x?y:z | If-then-else, as in C (where x,y,z are expressions). If the value x is non-zero (true) then the expression y is evaluated to produce the result, and otherwise the expression z is evaluated to produce the result. Note that this operation is a short-circuiting operation, and will not evaluate expression y if x is zero (false) and will not evaluate expression z if x is non-zero (true). This includes the expansion of Tcl commands in square brackets, but this delay in evaluation only occurs if the whole expression is enclosed in curly braces. It is usually clearer and easier to maintain (and no slower - the generated bytecode is identical) to use the Tcl if command instead of this. |
See the mathfunc man page, listed above, for the Tcl 8.5 man page information on expr builtin functions.
BUILTIN FUNCTIONS
On 1992-12-28 JO published the voting results 37 : 8 in favor of embedded functions() vs. separate [commands] - [L1 ]
RS 2003-04-24: Here's a tiny wrapper for friends of infix assignment: expr conditions (like those used in if or while) take 0 to mean false and all other numbers to mean true. In addition, the following string constants can be used:
* true, on, yes * false, off, no man Tcl_GetBoolean: "Any of these values may be abbreviated, and upper-case spellings are also acceptable." Beware that if you need code to run in Tcl releases as old as 8.3, you have to quote these if you use them directly as constants, as [Donald Porter] noted: ''[[expr]] tries to interpret "bare" strings as function names, such as cos($x). You must quote the string "true". Then it behaves as you expect in 8.3.3.'' Refer to the Operands section of the [http://www.tcl.tk/man/tcl8.4/TclCmd/expr.htm#M5%|%expr man page%|%] for the syntax rules. ---- [RS]: Would it make sense to extend the expr parser? I also see the funny behavior:
set y 2*3; puts expr {$y} ;# ==> 2*3 (so y is not checked), but: set y 2*3; puts expr {$y+0} ;# ==> can't use non-numeric string as operand of "+"
Maybe before raising that error, expr's arguments could be reparsed, so it comes out like with the unbraced
set y 2*3; puts expr $y+0 ;# ==> 6
2003-04-24 - ..and here's a tiny wrapper for friends of infix assignment:
proc let {var = args} {
% proc let {var = args} {uplevel 1 set $var \[expr $args\]} ;#RS
1
% let j = $i + 1
2
% let k = {$i + $j}
3[AM] The problem with variables whose values are actually expressions is that for caching the parsed expression will then be lost. [AMG]: This reopens the door to all the security, performance, and correctness problems solved by bracing one's expressions. ---- During March of 2005, a developer mentions surprise at the fact that [Wookie]: I had some trouble recently using `expr` to calculate time
expr int(36.37*100)
returns an unexpected value. After the traditional observation concerning
inability to represent some floating points exactly, [Bruce Stephens]
also makes a couple more observations:
"Yet another way of thinking about it is that "expr int($a)" is almost
always wrong. It's been poor style for a long time, and the various
Tcl checking programs have warned about it. So really (almost) nobody
should be writing "expr int($a)".
"Just as nobody would write:
if $i<10 { ...
nobody ought to be writing "expr int($a)". You almost always should
write
if {$a<10} { ...
and "expr {int($a)}".
[RS] Hmm...
% expr 36.37*100
3637.0 ;#-- good enough...
% expr {36.37*100}
3637.0 ;#-- the same
% expr {int(36.37*100)}
3636 ;#-- Hmm
% expr int(36.37*100)
3636 ;#-- the same
% info pa
8.4.9
[LV] My response on [comp.lang.tcl] was that I thought it was a shame
that expr (or perhaps it is Tcl) didn't use the same mechanism for
both calculations of 36.37 * 100 ; that way, the results would at least
be consistent. Even if they were consistently '''wrong''', one would
be able to at least to live within the ''law of least surprise''.
As it is, until one experiments, one won't know which way that Tcl
is going to ''round'' results.
[EPSJ] This may be a side effect of the IEEE floating point standard. This is
done in hardware to guarantee the convergence in the case of a series of math
algorithms. The rule is that the mantissa of a floating point number must be
rounded to the nearest even number. As 36.37 cannot be represented exactly in
float point it ends up being a small fraction below the intended number. On the
other side 36.38 moves on the other direction. Look the following result:
() 60 % expr int(36.380*100)
3638
() 61 % expr int(36.370*100)
3636
x86 floating point hardware allows this to be configurable to nearest even,
nearest odd, and a few more options. But usually nearest even is the default.
The result may seem inconsistent, but it is intentional.
[RS] My point was that braced or not, [expr] returns the same (string rep of)
double as well as int() result, so I don't see this as an argument why one has
to brace (though I know there are...)
----
'''(Outdated) Expr [Gotchas]'''
Addition
% expr (1<<31)-1
2147483647
% expr 2147483647 + 2147483647
-2
Multiplication
% expr sqrt((1<<31)-1)
46340.9500011
expr 46341*46341
-2147479015
These are results of Tcl 8.4 and older versions using a 32-bit representation for integers. Check out http://tip.tcl.tk/237 , an implemented [TIP] describing arbitrary-precision Integers for Tcl. This is available in Tcl 8.5.
----
[LES] on July 23 2005:
% expr pow(5,6)
15625.0
% expr 5**6
15625
Two syntaxes, two slightly different results. Is that intentional? [RS] Yes - while pow() always goes for double logarithms, '**' tries to do integer exponentiation where possible.
----
[RS] 2006-06-19 A word of warning: [expr] may normalize strings that look like octals to decimal, even if no arithmetic operation was performed on them:
%set bond james
% expr {$bond eq ""? "-": "$bond"}
james
% set bond 0070
% expr {$bond eq ""? "-": "$bond"}
56
But no complaints if the string cannot be parsed as octal:
% set bond 008
% expr {$bond eq ""? "-": "$bond"}
008
In such cases it's better and more robust to use [if]:
if {$bond eq ""} {set bond -}
[HE] 2006-06-20 Strange behavior! The manpage of expr says:
eq ne
Boolean string equal and string not equal.
Each operator produces a zero/one result.
The operand types are interpreted only as strings.
There is no mention about this behavior. (I remember weakly this two operators are added exactly to avoid this problem)
More interesting: The manpage of if says:
The if command evaluates expr1 as an expression (in the same way that expr evaluates its argument).
Is there something wrong?
[JMN] 2006-10-19
Not really.. This normalization isn't occurring in the 'eq' operation - it happens when expr returns the result.
This may make it clearer:
%expr {$bond eq ""? "-": "hello $bond"}
hello 0070
%expr {$bond}
56
%expr {$bond eq 56}
0
%expr {$bond == 56}
1
[LV] Note the previous discussions on this page regarding the precautions one should keep in mind when using eq on tcl variables which contain numeric values. I am not certain I can think of a case where one would use eq when comparing numeric values...
----
[davou] what is the precision of expr's functions, and how can it be expanded upon?
[Lars H]: That's generally determined by the [C] library functions that implement them, i.e., it depends on where (and against what) Tcl is compiled. For "real" numbers that means '''double'''s, which are floating-point numbers of typically about 17 decimal digits precision (but how many of these are correct varies between functions and platforms). For integers Tcl has traditionally used '''long'''s, which in most cases means 32-bit two's complement integers ($tcl_platform(wordSize) tells you the actual number of bytes), but as of Tcl 8.5 it supports (almost) arbitrarily large integers ([googol magnitude] is no problem anymore, whereas googolplex magnitude wouldn't fit in the computer memory anyway). As for extending what the core provides, [tcllib] provides math::bignum and [math::bigfloat].
----
At least as of Tcl 8.5, [NaN] and [Inf] are potential values returning from expr.
Also in Tcl 8.5, [in] and [ni] are new string operators.
----
[LV] [Roy Terry] writes this example in a thread about whether strings need to be quoted in Tcl, over on [comp.lang.tcl]:
% if {joe eq mike} {puts wow}
syntax error in expression "joe eq mike": variable references require preceding $
% if {"joe" eq "mike"} {puts "wow"}
% if {{joe} eq {mike}} {puts {wow}}
%
This is an example of a context where a Tcl ''bareword'' string needs to quoted in some manner.
There are other cases in Tcl where this quoting need not happen.
% puts wow
wow
% set a abc
abc
%
If you prefer consistency, then always quote the strings.
----
[Wookie] I had some trouble recently using expr to calculate time offsets. I had 2 time stamps in the form hh:mm
So I had 4 variables h1, m1, h2, m2 and one of my `expr` functions was
So I had 4 variables h1, m1, h2, m2 and one of my expr functions wasset result expr {$m1 + $m2} set result expr ($m1 + $m2)
As many of you may be thinking, you fool! what about 08 and 09, which will get As many of you may be thinking, you fool! what about 08 and 09, which will get treated as invalid octal. So after some grumbling I thought okay so I have to trimleft them. Bit verbose but who cares:
set m1 [string trimleft $m1 0] set m2 [string trimleft $m2 0] set result [expr ($m1 + $m2)]
Now what could possibly go wrong with that... well obviously 00 becomes the Now what could possibly go wrong with that... well obviously 00 becomes "", which causes unexpected closed parameter in the expr. So now I have to check for "". So...
set m1 [string trimleft $m1 0]
if {$m1=={}} {set m1 0}
if {$m1==""} { set m1 0 }
set m2 [string trimleft $m2 0]
if {$m2=={}} {set m2 0}
if {$m2==""} { set m2 0 }
set result [expr {$m1 + $m2}]
set result [expr ($m1 + $m2)]
... and then repeat it for the hours. It all seemed very clumsy. So I came up
... and then repeat it for the hours. It all seemed very clumsy. So I came up with this, which may solve many of the conversion issues in this section.scan "$h1:$m1 $h2:$m2" "%d:%d %d:%d" h1 m1 h2 m2 set result expr {$m1 + $m2} set result expr ($m1 + $m2)
All the conversions to int have been done and leading 0's have been stripped All the conversions to int have been done and leading 0's have been stripped and returns 0 if the value is all 0s. This works for float and probably double (though I've not tried). Can anyone see any problems with this approach? glennj: No, scan is definitely the way to parse numbers out of dates glennj No, scan is definitely the way to parse numbers out of dates and times. However, for date arithmetic, nothing beats clock.
# adding a delta to a time set h1 12; set m1 45 set h2 3; set m2 30 clock format [clock add [clock scan "$h1:$m1" -format "%H:%M"] $h2 hours $m2 minutes] -format %T ;# ==> 16:15:00