Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

SET /A var\=...?

May
12,834
163
Should it work? I get odd results.

Code:
v:\> set n=85

v:\> set /a n\=2
2

v:\> echo %n
85
 
Interesting...under CMD;
Code:
c:\utils>set n=85

c:\utils>set /a "n/=2"
42
c:\utils>set /a "n/=2"
21
c:\utils>set /a "n/=2"
10
c:\utils>set /a "n/=2"
5
c:\utils>set /a "n/=2"
2
c:\utils>set /a "n/=2"
1

under TCC18;
Code:
c:\users\jlc\utils>set n=85

c:\users\jlc\utils>set /a "n/=2"
42.5

c:\users\jlc\utils>set /a "n/=2"
21.25

c:\users\jlc\utils>set /a "n/=2"
10.625

c:\users\jlc\utils>set /a "n/=2"
5.3125

c:\users\jlc\utils>set /a "n/=2"
2.65625

c:\users\jlc\utils>set /a "n/=2"
1.328125

Joe
 
That may be CMD, but I'm using TCC. TCC doesn't need the quotes. I don't think CMD handles anything but integers.

And I'm talking about '\' (integer division), not '/', In TCC, if n is 85, "set /a n\=2", if it works at all, should give 42.
 
Not supported in CMD, so not supported in TCC. (The SET /A syntax is solely for CMD compatibility, as there's otherwise no reason to use it.)
Well, "set /a n=n\2" is easy enough. But it should be noted that TCC's "SET /A" supports much that CMD doesn't.
Code:
v:\> set /a x=sin(PI/2)
1
v:\> set /a x=exp(1)
2.7182818285
v:\> set /a x=atan(1)
0.7853981634
v:\> set /a x=log10(100)
2
v:\> set /a x=2**3
8

It should also be noted that SET /A usually involves less typing and is often faster than using @EVAL.
Code:
v:\> set zz=0

v:\> timer do i=1 to 10000 (set /q /a zz+=3)
Timer 1 on: 21:35:31
Timer 1 off: 21:35:33  Elapsed: 0:00:01.48

v:\> echo %zz
30000

v:\> timer do i=1 to 10000 (set zz=%%@eval[zz+3])
Timer 1 on: 21:35:41
Timer 1 off: 21:35:43  Elapsed: 0:00:01.61

v:\> echo %zz
60000
 
You're timing the wrong thing. Your test is comparing the speed of a single environment update with that of a delete and a create.

Set /a updates in place; the other set has to delete the variable before adding it again. This is to allow changing the case of a variable name, which is required by some buggy apps like ClearCase.

Your argument about the difference in speed is unpersuasive. On my system it is about 7 microseconds. If you did this a hundred times a day, you'd have to run it a few centuries to make up the time you spent composing the message about @eval being slower.
 
I'm not really complaining (about "\=" or the speed) ... just making observations. I found it odd that SET /A lets you use almost everything @EVAL has to offer. A few exceptions are mentioned in the help, but not "\=". As for it not being supported, it does produce results, just not the intended ones, in fact, rether peculiar ones. You might think that, since "set /a n\=2" echoes "2", n is set to 2, but n remains unchanged.
 
Looks like a parsing error where SET /A is assigning a value to envvar "n\"

Code:
Groton> set /a n\=2
2
Groton> set n*
need_reccount=1
nn=2
noloadmsg=1
NUMBER_OF_PROCESSORS=4
numfound=62
nwords=2
n\=2

Groton>
 

Similar threads

Replies
4
Views
2K
Back
Top