Bad output in witness file

[guyu96]

Looks like the output from running the compiled circuit is contained in the witness file, where each element is encoded as a 4-tuple of uint64.

I created a simple CNN for MNIST, which outputs a 1d vector of length 10. One (out of 10) element of the circuit output is:

[7370974505352565529, 14361715451945731641, 17655054398070491924, 3143002292097891520]

When trying to convert this back to a field element with the following function:

from mclbn256 import Fr
def u64_arr_to_fr(arr):
    def encode(u64):
        return u64.to_bytes(8, byteorder='little')
    return Fr(encode(arr[0]) + encode(arr[1]) + encode(arr[2]) + encode(arr[3]))

arr = [7370974505352565529, 14361715451945731641, 17655054398070491924, 3143002292097891520]
u64_arr_to_fr(arr)

I get this error:

ValueError: MCl failed to return from Fr:getStr, ioMode=32

In addition, ignoring elements of the output vector that fail to convert, the result is still off compared to the original CNN. The max-valued index in the original CNN output gives the correct prediction, whereas the max-valued index in the circuit output does not. Maybe this is due to quantization error since I used the "resources" setting calibration strategy?

[alexander-camuto]

1. We also provide a function in ezkl python to do this conversion -- as the field elements are montegomery reduced when serialized

sample usage is as such

   message = [1.0, 2.0, 3.0, 4.0]
    message = [ezkl.float_to_vecu64(x, 7) for x in message]
    res = ezkl.poseidon_hash(message)
    assert ezkl.vecu64_to_felt(
        res[0]) == "0x0da7e5e5c8877242fa699f586baf770d731defd54f952d4adeb85047a0e32f45"

2. the conversions may be off with mclbn256 -- hence some of the accuracy issues but also would recommend calibrating for accuracy if you need the highest possible numerical fidelity.

[guyu96]

I see, thanks.

One question: what does ezkl.poseidon_hash have to do with field element serialization / deserialization?

And I did try it without hashing - the results make sense. Each integer step is split into 128 buckets.

>>> msg = [1.0, 2.0, 3.0, 4.0]
>>> serialized = [ezkl.float_to_vecu64(x, 7) for x in msg]
>>> serialized
[[8895048820941913435, 12590578388187041751, 10644156957292843428, 485414809211466155], [17790097641883826870, 6734412702664531886, 2841569840876135241, 970829618422932311], [8238402389116188689, 878247017142022022, 13485726798168978670, 1456244427634398466], [17133451210058102124, 13468825405329063773, 5683139681752270482, 1941659236845864622]]
>>> deserialized = [int(ezkl.vecu64_to_felt(x), 16) for x in serialized]
>>> deserialized
[128, 256, 384, 512]

But using ezkl.float_to_vecu64 still gives me wildly inaccurate results for MNIST. Any other steps I missed?

[alexander-camuto]

Ah sorry had just copy pasted one of our tests -- hash has nothing to do with it.

ezkl.float_to_vecu64 scales up the provided input using the passed in scale (in your case 7 -- so 1 -> 1 * 2^7 = 128). This is to reduce numerical accuracy loss when converting floating point numbers to field elements

If you want to round trip the serialization in full you can use ezkl.vecu64_to_float and pass in the used scale (in this case 7):

ezkl.vecu64_to_float(x, 7)

[guyu96]

Nice, this worked (for some inputs at least). Thanks!