Unsafe ops for fq_default #1906
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1906 +/- ##
==========================================
+ Coverage 87.25% 87.27% +0.01%
==========================================
Files 97 97
Lines 35651 35640 -11
==========================================
- Hits 31109 31105 -4
+ Misses 4542 4535 -7 ☔ View full report in Codecov by Sentry. |
| +(x::FqFieldElem, y::$jT) = x + parent(x)(y) | ||
| +(x::$jT, y::FqFieldElem) = y + x | ||
|
|
||
| -(x::FqFieldElem, y::$jT) = x - parent(x)(y) | ||
| -(x::$jT, y::FqFieldElem) = parent(y)(x) - y |
There was a problem hiding this comment.
shouldn't these delegate to add! or sub! as well?
Edit: I just noticed that there are no corresponding flint functions for these, but we have fallbacks in place in AA.
Edit: but this would be an endless loop...
maybe just add a comment here that these wait for a change in FLINT?
There was a problem hiding this comment.
We could implement add! and sub! already now without an endless loop by inserting the coercions there. But there are already tons of changes and I have to draw the line somewhere. So here I just took the code that was there, the only change is that it is now in an for ... @begin eval construct.
Someone can make these additional changes in a future iteration. There are a gazillion other things one could do in this file alone (e.g. adding set! methods to simplify the constructors). For now I'd like to move on
Co-authored-by: Lars Göttgens <[email protected]>
No description provided.