Strange && behaviour inside reducer

[hard rock]

I have the following code running inside a reducer:

        Circuit.log("---");
        Circuit.log("reducer action=", action);
        Circuit.log("reducer before state=", state);
        let notFinished = state.total.lessThan(requiredVotes);
        let mustCount = notFinished && action.isValid;
        Circuit.log("reducer notFinished=", notFinished, "isValid=", action.isValid, " mustCount=", mustCount);
        state.total = Circuit.if(mustCount, state.total.add(1), state.total);
        state.positive = Circuit.if(mustCount && action.positive, state.positive.add(1), state.positive);
        state.negative = Circuit.if(mustCount && action.negative, state.negative.add(1), state.negative);
        state.ignored = Circuit.if(mustCount && action.ignore, state.ignored.add(1), state.ignored);
        Circuit.log("reducer after state=", state);
        return state;

In the test case I am using requiredVotes = 3 and it should process 4 actions. The log is:

...
reducer action= { ignore: false, isValid: true, negative: false, positive: true }
reducer before state= { ignored: '0', negative: '0', positive: '2', total: '2' }
reducer notFinished= true isValid= true  mustCount= true
reducer after state= { ignored: '0', negative: '0', positive: '3', total: '3' }
---
reducer action= { ignore: false, isValid: true, negative: false, positive: true }
reducer before state= { ignored: '0', negative: '0', positive: '3', total: '3' }
reducer notFinished= false isValid= true  mustCount= true
reducer after state= { ignored: '0', negative: '0', positive: '4', total: '4' }
---

PROBLEM: the 4th time variable notFinished is false and isValid is true, and so mustCount should be false as it is evaluated using notFinished && isValid.

**But it is true !!! What is happening here ? **

Or I should do something like this const mustCount = notFinished.equals(Bool(true)).equals(action.isValid.equals(Bool(true))); ?

[sonic shard]

Can do Bool.And(notFinished, action.isValid) I think. Something like that. But yeah, I would assume the problem here is using && with circuits.

Circuit.if(mustCount && action.positive => Circuit.if(Bool.And(mustCount, action.positive)

[hard rock]

Mmm, ok. yes I suppose that is the problem. But I think I have seen some example using && . Anyway will do it the right way. Thanks again !

[sonic shard]

Which examples?

[hard rock]

Dont have them on my mind right now. Just think I saw some example where it was used when browsing code ,,, not important anyway.

For the docs https://docs.minaprotocol.com/zkapps/snarkyjs-reference/classes/Bool#and I assume will have to be notFinished.and(isValid)

[sonic shard]

There are both static and instance versions of the methods it looks like. I'm not sure if there is a performance difference 🤷‍♂️

[hard rock]

Trying it now ...

[sonic shard]

One of the most frustrating things about snarkyJS is how things perform differently in the proof than in javascript. Using && could be fine in some circumstances, or someone might have written code that passed a test with proofs off and published it as an example. In general, you have to be extremely cautious not to use variable-length arrays or branching logic since it's so natural in other contexts.

[hard rock]

It worked now:

---
reducer action= { ignore: false, isValid: true, negative: false, positive: true }
reducer before state= { ignored: '0', negative: '0', positive: '3', total: '3' }
reducer notFinished= false isValid= true  mustCount= false
reducer after state= { ignored: '0', negative: '0', positive: '3', total: '3' }

[sonic shard]

Nice work!

[hard rock]

Yes, really. It is really confusing sometimes. One has to remember that were are not really writing JS here, and is difficult to remember that all the time 🙂

[hard rock]

Well, yes I have seen a lot of examples with proofs off. I have set it on in all my test cases. Some weeks ago I spent many hours with something that worked ok on Local and not on Berkeley, and the issue was I was not using proofs on Local. NEVER AGAIN jaja

[sonic shard]

Well leaving proofs on slows things down sometimes. But it depends. It can speed things up in the long run if it saves you from making mistakes.

[hard rock]

Agree. Good to disable them for a quick test eventually. What time is there, working late ? Its past midnight here ...

[sonic shard]

One of my ideas for cohort 2, which I have no idea how to build but just think is a good idea, is some kind of visual interpretation of proofs. If you can visually define your proof, it will be easy to spot branching logic, or other dynamic behaviors.

Almost midnight here! I'm in east coast USA

[hard rock]

I am at UTC-3, Buenos Aires. So I think its 2 hours difference.

[hard rock]

It is quite a good idea, and it is just a "circuit" so graphical representation should be quite viable. I think that one would have to look at what Snarky produced to extract that info

[sonic shard]

So far, but basically the same time 😄

[sonic shard]

I thought so too, but some others reminded me how many constraints actually go into the proof. I guess the trick is to show enough information without being too noisy.

[hard rock]

I suppose that enabling different filtering levels may be possible, so you can hide some redundant constraints and get a cleaner picture

Anyway not an easy task 🙂