Max Horn

Results 501 issues of Max Horn

In order to run ring conformance tests, one has to provide a suitable `test_elem` method. I think we should provide more generic ones for those, e.g. for polynomial and series...

Right now `test/Rings-conformance-tests.jl:169` has this: ```julia @testset "Unsafe ring operators" begin for i in 1:reps a = test_elem(R)::T b = test_elem(R)::T c = test_elem(R)::T A = deepcopy(a) B = deepcopy(b)...

Consider this: ``` julia> R = @free_associative_algebra(GF(2), [:x, :y, :u, :v, :t, :s]) Free associative algebra on 6 indeterminates x, y, u, v, ..., s over finite field F_2 ```...

It would be nice if there was a way to reach the "inner" function for a method declared with `@attr`. So e.g. if we have ```julia @attr Any function bla(x::Int)...

- **Remove redundant gcdinv methods** - **Add isapprox methods for ZZRingElem & QQFieldElem** - **Enhance fpPolyRingElem constructor to accept more Integer types** - **Fix missing return values in two unsafe...

Add a bunch of `one!` and `neg!` methods. Also used `zero!`, `one!`, `neg!` in a few more spots. And placed these function in a uniform way into the code based...

(...) We could (... add ...) a separate struct `fq_nmod_t` (and `fmpz_t` etc. etc.) which faithfully replicate the FLINT structs, nothing more and nothing less. Then e.g. `fqPolyRepFieldElem` could start...

With some minor modifications it should be possible to turn `prod_diagonal(A::ZZMatrix)` into the new generic method, replacing the current generic method.

And then extend them to accept `ZZRingElemOrPtr` and `QQFieldElemOrPtr`. And change the implementation However we should tweak them to use `_num_ptr` and `_den_ptr` instead of a `ccall`. Perhaps we can...