You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This turns out (as far as I can tell) to be a fairly serious bug. The issue is that columns with the same name, but defined in different perspectives always compile down to the same column. That is particularly a problem when they have different types (e.g. one has binary@prove for example) since the most restrictive type will be applied to all. Example to illustrate:
(defcolumns
A
(P :binary@prove)
(Q :binary@prove))
(defperspective p1 P ((B :binary@prove)))
(defperspective p2 Q ((B :byte)))
(defconstraint c2 (:perspective p2) (vanishes! (* A B)))
The question here is which column B refer to in the constraint c2? Here is the wizard-iop output:
Notice how there is only a single column B which includes a binarity constraint. This is not consistent at all with the intention of the original code. However, we can agree that the original code should never have compiled in the first place.
The text was updated successfully, but these errors were encountered:
This turns out (as far as I can tell) to be a fairly serious bug. The issue is that columns with the same name, but defined in different perspectives always compile down to the same column. That is particularly a problem when they have different types (e.g. one has
binary@prove
for example) since the most restrictive type will be applied to all. Example to illustrate:The question here is which column
B
refer to in the constraintc2
? Here is thewizard-iop
output:Notice how there is only a single column
B
which includes a binarity constraint. This is not consistent at all with the intention of the original code. However, we can agree that the original code should never have compiled in the first place.The text was updated successfully, but these errors were encountered: