SET /A var\=...?

[vefatica]

Should it work? I get odd results.

v:\> set n=85

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

v:\> echo %n
85

 

[Joe Caverly]

According to https://ss64.com/nt/set.html you have to do

set /a "n/=2"

Joe

 

[Joe Caverly]

Interesting...under CMD;

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;

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

 

[vefatica]

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.

 

[rconn]

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.)

 

[vefatica]

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.

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.

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

 

[rconn]

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.

 

[vefatica]

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.

 

[dcantor]

Looks like a parsing error where SET /A is assigning a value to envvar "n\"

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>

 

[rconn]

Looks like a parsing error where SET /A is assigning a value to envvar "n\"

Not a parsing error; it's exactly what CMD does. (Admittedly not useful either, but given the syntax is invalid it's not likely to produce useful output.)

 

[dcantor]

Yup.