RE: acalcout subarray indices

["Mooney, Tim M." <mooney@aps.anl.gov>]

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 (mooney@aps.anl.gov) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab


________________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of jon@u.washington.edu [jon@u.washington.edu]
Sent: Wednesday, March 04, 2015 7:01 PM
To: tech-talk@aps.anl.gov
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.