Small problem on update and print_ln

[winnnnnny]

When I test my code by printing the content in the variables, it seems that the value of the variable will be updated ahead of the update function.
Here is an example.

# a is originally 5
a = sint.get_input_from(0)
# b is originally 10
b = sint.get_input_from(1)
# a is now 5 correctly
print_ln('a: %s', a.reveal())
# just meaningless code
c = sint((sint(0) > (b - sint(3))))
# a is still 5 correctly
print_ln('a: %s', a.reveal())
# This code is necessary for triggering printing errors. If this code is deleted, the following print will be correct.
c.update((sint(0) > c))
# just meaningless code
var_0003 = Array(10,sint)
# a is now 81 ahead of the update
print_ln('a: %s', a.reveal())
# just meaningless code
var_0004 = Array(10,sint)
# a is now 81 ahead of the update
print_ln('a: %s', a.reveal())
a.update(sint(81))
# calculate the sum and show
sum = a + b
# If the sum is not shown, then the printing above will also be correct.
print_ln('sum: %s', sum.reveal())

The result is shown below.

./Scripts/mascot.sh test
Running /home/mp-spdz/Scripts/../mascot-party.x 0 test -pn 15382 -h localhost -N 2
Running /home/mp-spdz/Scripts/../mascot-party.x 1 test -pn 15382 -h localhost -N 2
Using security parameter 40
a: 5
a: 5
a: 81
a: 81
sum: 91
Significant amount of unused triples of SPDZ gfp. For more accurate benchmarks, consider reducing the batch size with --batch-size.
Note that some protocols have larger minimum batch sizes.
Significant amount of unused bits of SPDZ gfp. For more accurate benchmarks, consider reducing the batch size with --batch-size.
Note that some protocols have larger minimum batch sizes.
The following benchmarks are including preprocessing (offline phase).
Time = 2.32413 seconds 
Data sent = 59.5279 MB in ~889 rounds (party 0; use '-v' for more details)
Global data sent = 119.056 MB (all parties)
This program might benefit from some protocol options.
Consider adding the following at the beginning of 'test.mpc':
        program.use_edabit(True)

There is no problem with the other calculation, but just making some confusion when I test my code. If possible, may you make the print_ln always print the correct value?

[mkskeller]

Thank you for raising this. You should find that d6342d8 fixes it.

[winnnnnny]

Thank you for repairing this!

[winnnnnny]

Sorry for disturbing you again, @mkskeller.
There is still a small problem with update and print_ln. It is triggered when the variable is updated with the variable itself.
Here is an example.

a = sint(5)
b = sint(10)
c = sint(15)
# just meaningless code
a.update(a + b)
# c should still be 15, but it has been updated to 30 in advance
print_ln("c: %s", c.reveal())
# just meaningless code
b.update(b + a)
# c should still be 15, but it has been updated to 30 in advance
print_ln("c: %s", c.reveal())
# c is updated with the value related to itself, it not, then all the printing above will also be correct.
c.update(sint(15) + c)
# calculate the sum and show
sum = c + a
# If the sum is not shown, then all the printing above will also be correct.
print_ln("sum: %s", sum.reveal())

The result is shown below.

./Scripts/mascot.sh test 
Running /home/mp-spdz/Scripts/../mascot-party.x 0 test -pn 13570 -h localhost -N 2
Running /home/mp-spdz/Scripts/../mascot-party.x 1 test -pn 13570 -h localhost -N 2
Using security parameter 40
c: 30
c: 30
sum: 45
The following benchmarks are including preprocessing (offline phase).
Time = 0.00167082 seconds 
Data sent = 0.041528 MB in ~533 rounds (party 0; use '-v' for more details)
Global data sent = 0.083056 MB (all parties)

There is no problem with the other calculation, but may you make the print_ln print the value more correctly?

[mkskeller]

Thank you for raising this. You should find that version 0.3.6 fixes it.

[winnnnnny]

Thank you for your maintenance!