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
I am filing this issue so that the comment posted in #2319 (comment) is properly remembered and addressed:
Is there a better implementation of clpz_t/2? Currently, reification is internally used in order to benefit from argument indexing and hence make the test deterministic if possible. Reification clearly has an overhead compared to "backtracking out" the cases, which also has an overhead in the form of redundant choice-points that may be left on the local stack.
Since the construct itself is sensible, it is a good candidate for implementation improvements. For example, could goal expansion be applied, similar to what (#=)/2 and other arithmetic comparisons already do? The pattern if_(.... clpz_t(....)), ..., ...) could be expanded to more efficient versions that take into account the concrete arithmetic term that occurs in the first argument of clpz_t/2, even if it occurs within a lambda expression as show in #2320.
I would greatly appreciate all insights and suggestions. Thank you a lot!
The text was updated successfully, but these errors were encountered:
I am filing this issue so that the comment posted in #2319 (comment) is properly remembered and addressed:
Is there a better implementation of
clpz_t/2
? Currently, reification is internally used in order to benefit from argument indexing and hence make the test deterministic if possible. Reification clearly has an overhead compared to "backtracking out" the cases, which also has an overhead in the form of redundant choice-points that may be left on the local stack.Since the construct itself is sensible, it is a good candidate for implementation improvements. For example, could goal expansion be applied, similar to what
(#=)/2
and other arithmetic comparisons already do? The patternif_(.... clpz_t(....)), ..., ...)
could be expanded to more efficient versions that take into account the concrete arithmetic term that occurs in the first argument ofclpz_t/2
, even if it occurs within a lambda expression as show in #2320.I would greatly appreciate all insights and suggestions. Thank you a lot!
The text was updated successfully, but these errors were encountered: