Open DavePearce opened 5 months ago
This is less of a problem when the first column of a permutation is positively signed. For example, something like this:
(module m1)
(defcolumns A B)
(defpermutation (X Y) ((+ A) (- B)))
Then for a trace like this:
{ "m1": { "A": [1,1,2,3], "B": [40,56,65,90] } }
This is accepted correctly because a spillage value of 0
for A
ensures we can accept a padded trace like this:
{ "m1": { "A": [0,0,1,1,2,3], "B": [0,0,40,56,65,90] } }
However, we can still construct a problematic trace such as:
{ "m1": { "A": [0,0,0,0], "B": [40,56,65,90] } }
Here, again, we are given an incorrect spillage value for B
.
The logical option here is to have an append padding strategy, but I'm unsure whether or not this is permissible.
Some updates on this point specifically. Yes, we can choose to append at the end or the beginning (let's call this the padding sign of a column). However, I did not make this work for permutation sorts. Specifically, at a minimum because of this:
The easiest solution then is to enforce a requirement that we must have a leftmost positively signed column for a permutation sort and, furthermore, no trace prior to expansion can have 0
for that column.
Overall, my feeling is that it actually would just make sense to remove sorting direction altogether. That way, there is no confusion.
Minimal example to recreate:
With this example trace:
Then, running
corset compute --trace test.json --out test.out test.lisp
gives this:This does not look right to me. Specifically, the
padding_strategy
forY
will mean it is no longer a permutation ofX
. The logical option here is to have anappend
padding strategy, but I'm unsure whether or not this is permissible.@OlivierBBB FYI