From http://www.aps.anl.gov/bcda/synApps/calc/calcReleaseNotes.html, in the upgrade
to version 3-0:
WARNING! NON-BACKWARD-COMPATIBLE CHANGE:
Fixed the array calc {} (subrange in place) operator to treat array indices as documented
- exactly as the [] (subrange) operator treats them. Previously, for example, aa{0,n} was
not the same as aa[0,n], but instead performed aa{0,n-1}.
My test IOC is running version 3-2, and your code is on 2-8, hence the difference!
So, the interpreter is correct according to the docs and the current version, but wrong
with respect to the code you guys are running.
Hi Jon,
What is the value of R.B?
When I use that expression, I don't get that result, unless R.B==-1.
There is a test whose results seem clearer to me:
R.CALC=IX
caget -#6 R.AVAL -> R.AVAL 6 0 1 2 3 4 5
CALC = IX{2,4}
caget -#6 R.AVAL -> R.AVAL 6 0 0 2 3 4 0
Tim Mooney ([email protected]) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab
________________________________________
From: [email protected] [[email protected]] on behalf of [email protected] [[email protected]]
Sent: Wednesday, March 04, 2015 7:01 PM
To: [email protected]
Subject: acalcout subarray indices
This documentation on the acalcout record:
http://www.aps.anl.gov/bcda/synApps/calc/R2-6/aCalcoutRecord.html
says that subarray indices are inclusive, so that {2,4} selects
elments with indices 2,3,4 (where 0 is the first index):
AA{2,4} where AA = (1,2,3,4,5,6) Result is (0,0,3,4,5,0).
But this test seems to show that indices are exclusive, that is,
the upper index is excluded from the subarray:
record(acalcout, R) {
field(NELM, "2")
# no INPA or INPB - write directly to R.A and R.B
field(CALC, "ARR(0)+ARR(A){0,1}+ARR(B){1,2}")
}
epics> dbgf R.AVAL
DBR_DOUBLE[2]: 0 0
epics> dbpf R.A 1
DBR_DOUBLE: 1
epics> dbgf R.AVAL
DBR_DOUBLE[2]: 1 0
According to the documentation, it seems {0,1} should select the two
elements with indices 0 and 1, but here only the first bit in AVAL
gets set. Similar tests with larger arrays, subarrays longer than one
element, values other than 1, and positions other than the first, show
similar results: the upper index is not included in the subarray.
Can anyone explain this?
Jon Jacky
PS - This discrepancy was found by a graduate student here at UW, who
wrote an analyzer that checks an EPICS database against assertions about
its intended behavior.
