The discrepancy arises because we tested calc-2-8 but the documentation applies to 3-0 and later. The student whose tool revealed the discrepancy also found this:
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.
On Thu, 5 Mar 2015, Mooney, Tim M. wrote:
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.
- References:
- RE: acalcout subarray indices Mooney, Tim M.
- Navigate by Date:
- Prev:
RE: IOC shell message for waveform record Mark Rivers
- Next:
RE: asyn R4.26 Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: acalcout subarray indices Mooney, Tim M.
- Next:
waveProc maintainer? Michael Davidsaver
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
|