Yes in that case an accumulator is needed. One method you could choose would be to pass a table through to accumulate while also allowing you to look back to previous rows:
q)update c2:1_@[;`c2]{y[`c2]:enlist $[(y[`c1][0]>last x[`c2]) or ((last x[`c])<last x[`c2]);y[`c1][0];last x`c2];x,y}/[enlist each {(1#0#x),x}update c2:0 from `c`c1#t] from t
c c1 c2
----------
30 10 10
40 20 20
25 5 20
20 25 25
4 5 5
4 4 4
4.5 3 4
4.5 3.5 4
Works for most scenarios. I have added one more row at the end where I get a different result than expected. The value for c2 in last row should be 4 instead of 3.
t:(c: 30 40 25 20 4 4 1; c1: 10 20 5 25 5 4 3)
c
c1
c2
c1>prev c2
OR
prev c < prev c2
?
c1
prev c2
30
10
10
10>0 (True)
OR
No need of evaluation
?
10
40
20
20
20>10(True)
OR
No need of evaluation
?
20
25
5
20
5>20(False)
OR
40<20(False)
?
20
20
25
25
25>20(True)
OR
No need of evaluation
?
25
4
5
5
5>25(False)
OR
20<25(True)
?
5
4
4
4
4>5(False)
OR
4<5(True)
?
4
1
3
4
3>4(False)
OR
4<4(False)
?
4
update c2:fills ?[(c1>prev c1) or c<prev c1;c1;0N] from t
c c1 c2
--------
30 10 10
40 20 20
25 5 20
20 25 25
4 5 5
4 4 4
1 3 3
Somehow not being able to use the previous calculated value of c2 directly is causing fallout for different combination of data. Last value of c2 will be 4 as per the logic but we get 3.5
From the Primary Accumulator list, select 0. From the First list, select Increment primary. From the Second list, select Use primary.Defines a custom accumulator operator. Accumulators are operators that maintain their state (e.g. totals, maximums, minimums, click test and related data) as documents .If you have access to Accumulator manager, you can access the Accumulator … To locate a record, you can sort each column alphabetically, …