comparisons in tcl

[Lisa Pearlson]

Hi,

I see comparison operations performed like this:

if { $val ne 0 } ....

but I do them as this:

if { $val != 0 } ....

What's the difference? Why use "eq, ne, gt, lt" etc. instead of "==, !=, >,
<" ?

Lisa

[Jeff Godfrey]

"Lisa Pearlson" <n...@spam.plz> wrote in message
news:4380c62f$0$7400$e4fe...@dreader27.news.xs4all.nl...

Hi Lisa,

"eq" and "ne" were added recently (8.4?), specifically for use in
*string* comparisons...

Like --> if {$myVar ne "abc"} { ... }

"gt" and "lt" are not valid in standard Tcl (AFAIK), though they seem
to be provided by the "::math::bignum" library...

So, use ==, !=, >, <, etc for *numeric* comparisons, and eq/ne for
*string* comparisons...

Jeff

[miguel sofer]

to illustrate:
% set a 0x12
0x12
% expr $a
18
% set b 18
18
% expr {$a == $b}
1
% expr {$a eq $b}
0

(ie: $a and $b have the same numerical value, but they are not equal as
strings)

[Francois Vogel]

This is a very clear example, thanks.

There is also string compare, btw.

If I don't use hex, octal or whatever numbers in strings, what side effect
would I have if I use = instead of eq to compare character strings? I can't
think of any. For instance if I have a variable var containing a string read
in a file, or input by the user, or containing some setting of my script,
should I write:

if {$var == "whatIwant"} {...}
if {$var eq "whatIwant"} {...}
if {[string compare $var "whatIwant"] == 0} {...}

A bit lost... Any best practice rules?

Thanks,
Francois

[Ramon Ribó]

% expr 0 == 0.0
1
% expr 0 eq 0.0
0

Ramon Ribó

En Sun, 20 Nov 2005 23:04:04 +0100, Francois Vogel
<fsvogeln...@free.fr> escribió:

--
Compass Ing. y Sistemas Dr. Ramon Ribo
http://www.compassis.com ram...@compassis.com
c/ Tuset, 8 7-2 tel. +34 93 218 19 89
08006 Barcelona, Spain fax. +34 93 396 97 46

[Francois Vogel]

"Ramon Ribó" <ram...@compassis.com> a écrit dans le message de news:
op.s0j8jrh3wrbfww@akenatonv...

>
>
> % expr 0 == 0.0
> 1
> % expr 0 eq 0.0
> 0

Yes, I have understood the difference if the strings contain numbers.

but what if

>> If I don't use hex, octal or whatever numbers in strings

Is there a difference between the three comparison schemes I listed?

Francois

[Ramon Ribó]

Hello,

"eq" is more efficient than "==" if the arguments are known to be
strings, as you avoid shimmering. Also, you force the string "0.0" to
be different than the string "0", which is what you want, if you only
deal with strings.

Regards,

Ramon Ribó

En Sun, 20 Nov 2005 23:35:33 +0100, Francois Vogel
<fsvogeln...@free.fr> escribió:

> "Ramon Ribó" <ram...@compassis.com> a écrit dans le message de news:

--

[Bryan Oakley]

Francois Vogel wrote:
> This is a very clear example, thanks.
>
> There is also string compare, btw.
>
> If I don't use hex, octal or whatever numbers in strings, what side effect
> would I have if I use = instead of eq to compare character strings? I can't
> think of any.

Even if you don't have hex, octal or whatever numbers in strings, the
compiler can't tell if your intent is to compare two strings as numbers
or as strings.

Thus, if you have two strings and compare them using "==", you may get
false positives. Consider a simple app where you compare someone's
entered password against a stored password. If their password is stored
as "1.0", they could enter "1" in the password field (or 01, or 1.00,
etc) and the app would gleefully declare them as identical.

So, if you want to guarantee that two strings are identical or not,
don't use ==, because == can declare two strings being equal even if
they aren't byte-for-byte equal.

[Lisa Pearlson]

Your explanations have been very clear.. thank you.

Lisa

[Michael A. Cleverly]

On Sun, 20 Nov 2005, Bryan Oakley wrote:

> Thus, if you have two strings and compare them using "==", you may get false
> positives. Consider a simple app where you compare someone's entered password
> against a stored password. If their password is stored as "1.0", they could
> enter "1" in the password field (or 01, or 1.00, etc) and the app would
> gleefully declare them as identical.

Or if the user had the misfortune of selecting "nan" as their password
they'd never be able to authenticate:

% expr "nan" == "nan"
0
% expr "nan" eq "nan"
1

Michael

[Don Porter]

Francois Vogel wrote:
> A bit lost... Any best practice rules?

Best practice rules are to recognize that there is a difference
between numeric and string comparison, and use the operator that
means the comparison you intend.

If you want string comparison, use the "eq" operator.

--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|

[Francois Vogel]

> If you want string comparison, use the "eq" operator.

OK. And what about [string compare ...] == 0 ? Is it the exact same result
as eq or is there cases where the comparison result could differ?

Francois

[Gerald W. Lester]

It and [string equal ...] will return the same result as eq.

I'm not sure about the speed, one may be faster or slower than another do to
how things get byte compiled.

[Kaitzschu]

On Mon, 21 Nov 2005, Gerald W. Lester wrote:

> Francois Vogel wrote:
>>> If you want string comparison, use the "eq" operator.
>>
>> OK. And what about [string compare ...] == 0 ? Is it the exact same
>> result as eq or is there cases where the comparison result could
>> differ?
>
> It and [string equal ...] will return the same result as eq.

Just to stress that {expr eq} and [string equal] return the same result,
as [string compare] does way more complicated things.

Basically (as their codes are commented to stay in sync) {expr eq} and
[string equal] are the same command, with subtle difference, as [string
equal] has these not-so-often used options, as '-nocase' and '-length n'
(to do case-insensitive comparision and compare up to n first characters,
respectively).

> I'm not sure about the speed, one may be faster or slower than another
> do to how things get byte compiled.

No speed-issues here, nearly same code, nearly same timings. Without
those options, that is.

--
-Kaitzschu
s="TCL ";while true;do echo -en "\r$s";s=${s:1:${#s}}${s:0:1};sleep .1;done

[Jeff Hobbs]

string equal / expr eq is faster than string compare, notably
so for inequality, because string equality (being boolean) can
first check to see if the 2 strings are of equal length, if
not, then 0 is returned without looking at a single char.
Remember that string lengths are cached in Tcl_Objs.

--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos