https://travis-ci.org/Nemocas/Nemo.jl/builds/143837871
https://s3.amazonaws.com/archive.travis-ci.org/jobs/143837874/log.txt

What do we do about these changes in 0.5 which break Nemo? Try to fix them continuously? Or wait for 0.5 release and do them alltogether?

I have the feeling the following array construction did work in the past. Am I mistaken? I get the following error on julia 0.4.7 and 0.5.0.

julia> using Nemo; Qx, x = FlintQQ["x"]
(Univariate Polynomial Ring in x over Rational Field,x)

julia> [x, 0]
ERROR: MethodError: `convert` has no method matching convert(::Type{Nemo.fmpq_poly}, ::Int64)
This may have arisen from a call to the constructor Nemo.fmpq_poly(...),
since type constructors fall back to convert methods.
Closest candidates are:
  Nemo.fmpq_poly(::Int64)
  call{T}(::Type{T}, ::Any)
  convert{T}(::Type{T}, ::T)
  ...
 in setindex! at array.jl:326
 in cat_t at abstractarray.jl:866
 in vcat at abstractarray.jl:874
 in vect at abstractarray.jl:42

On FreeBSD 11.0 I see the following

HEAD is now at 768d1aaa5... Fix for fq_poly_divides.
DONE
Building flint ...
Configuring...x86_64-FreeBSD
Testing __builtin_popcountl...no
Testing __thread...no
Testing fenv...no
FLINT was successfully configured.
make[1]: Entering directory '/usr/home/dima/.julia/v0.6/Nemo/deps/flint2'
    CC   build/printf.lo
/bin/sh: gcc: command not found
make[1]: *** [Makefile:259: build/printf.lo] Error 127
make[1]: *** Waiting for unfinished jobs....
    CC   build/fprintf.lo
/bin/sh: gcc: command not found
make[1]: *** [Makefile:259: build/fprintf.lo] Error 127
make[1]: Leaving directory '/usr/home/dima/.julia/v0.6/Nemo/deps/flint2'
make: *** [Makefile:174: library] Error 2
ERROR: LoadError: failed process: Process(`make -j4`, ProcessExited(2)) [2]
Stacktrace:
 [1] pipeline_error(::Base.Process) at ./process.jl:682
 [2] run(::Cmd) at ./process.jl:651
 [3] #3 at /usr/home/dima/.julia/v0.6/Nemo/deps/build.jl:218 [inlined]
 [4] withenv(::##3#4, ::Pair{String,String}, ::Vararg{Pair{String,String},N} where N) at ./env.jl:157
 [5] include_from_node1 at ./loading.jl:569
 [6] include at ./sysimg.jl:14
 [7] process_options at ./client.jl:305
 [8] _start at ./client.jl:371
while loading /usr/home/dima/.julia/v0.6/Nemo/deps/build.jl, in expression starting on line 216

I did not try digging this up much: I guess it works on OSX as Xcode provides a fake gcc - a symlink to clang. Needless to say, building flint2 works without gcc command available - is it just a Julia quirk?

Here is some code to get things going:

import Base:rand
using Nemo

rand(R::FlintIntegerRing, r::UnitRange{Int}) = R(rand(r))

function rand{T <: RingElem}(M::MatSpace{T}, vs...)
   m = M()
   for i = 1:M.rows
      for j = 1:M.cols
         m[i, j] = rand(base_ring(M), vs...)
      end
   end
   return m
end

function rand{T <: RingElem}(R::PolyRing{T}, n::Int, vs...)
   x = gen(R)
   f = R()
   for i = 0:n
      f += rand(base_ring(R), vs...)*x^i
   end
   return f
end

function rand{T <: RingElem}(R::ResRing{T}, vs...)
   return R(rand(vs...))
end

function rand(R::ResRing{fmpz})
   m = convert(Int, R.modulus)
   return R(rand(0:m - 1))
end

It can be used as follows:

R, x = PolynomialRing(ZZ, "x")
M = MatrixSpace(R, 10, 10)

m1 = rand(M, 2, -5:5)

S = ResidueRing(ZZ, 3)
T, y = PolynomialRing(S, "y")
N = MatrixSpace(T, 10, 10)

m2 = rand(N, 2, 0:2)
m3 = rand(N, 2)

We need to add rand functions for all leaf types (ZZ, padic, fq, fq_nmod, arb, acb, nf_elem) and then for all generic types (FracField, PolyRing, MPolyRing, ResRing, AbsSeriesRing, ResSeriesRing).

I suggest we start with ranges of the form Int:Int for now, and leave ZZ:ZZ for a future incarnation (unfortunately Julia doesn't allow overloading of the relevant functions for types not belonging to Real, so we have to duplicate a lot of the range/colon code for Nemo.)

Each kind of generic ring in Nemo, e.g. polynomials, multivariate polynomials, etc., needs certain functions to exist in the base ring before it can be used, e.g. mul!, addeq!, zero!, add!, needs_parentheses, parent, hash, etc.

These should be documented somewhere for people implementing a new kind of ring.

These functions are needed for any ring that is designed to work with Polynomial.jl. But their interface is not documented anywhere. See issue #126

Since b9ab1ab Nemo is not working on 0.4 properly. Tests did not catch this regression, since we do not test print functions (we should change this).

Do we want to drop 0.4 support? @wbhart @fieker

The groups of Dirichlet characters could be implemented by wrapping http://arblib.org/dirichlet.html

May I ask to what extent Nemo's arithmetic is intended
to work as a replacement of Julia's arithmetic?

I'm trying to base my project on Nemo's arithmetic, but I
frequently come across cases where this is not possible
(at least not by direct substitution of basic types).

Consider for example:

using Nemo

R = [(-1)^n*Rational(1,n) for n in 1:9]
A = R |> abs
println(A)

R = [(-1)^n*fmpq(1,n) for n in 1:9]
A = R |> abs
println(A)

This gives a MethodError in the Nemo case.

• Replace windows with view for nmod_mat and fmpz_mat.
• Write a view function for all other matrix types.
• Scatter @inbounds across the matrix code (but first understand how it works).
• Save the GenMat in julia friendly order (almost done).
• Make A[1:n, 1:m] work for Nemo matrices.
• Disentangle GenMat and MatElem.
• Make matrices more collection like (allow A[i] to iterate through the rows).

Feel free to add more.

This is referred to as "type piracy" and strongly discouraged, as it changes the behavior of unrelated code depending on whether or not this package is imported. Specifically the methods on NTuple{N, UInt} at

Any objections to tagging 0.5.2?

on clang/FreeBSD (with gcc being a symbolic link to clang, OSX-style) it leads to

    CC   ../build/fmpz_lll/is_reduced_d_with_removal.lo
In file included from is_reduced_d_with_removal.c:14:
/usr/include/fenv.h:117:15: error: unknown type name 'inline'
__fenv_static inline int
              ^
/usr/include/fenv.h:117:22: error: expected identifier or '('
__fenv_static inline int
                     ^
...

Here is what Perl does for this issue.

I tried to install Nemo on OS X (head of Julia 0.4 branch), and received this error:

make[1]: Nothing to be done for `shared'.
mkdir -p /Users/eschnett/.julia/v0.4/Nemo/local/lib
mkdir -p /Users/eschnett/.julia/v0.4/Nemo/local/include
cp  fmpr.h  arf.h  mag.h  arb.h  arb_mat.h  arb_poly.h  arb_calc.h  acb.h  acb_mat.h  acb_poly.h  acb_calc.h  acb_hypgeom.h  acb_modular.h  acb_dirichlet.h  arb_hypgeom.h  bernoulli.h  hypgeom.h  fmpz_extras.h  bool_mat.h  partitions.h /Users/eschnett/.julia/v0.4/Nemo/local/include
tar: Error opening archive: Failed to open 'pari-2.7.4.tar.gz'
================================[ ERROR: Nemo ]=================================

LoadError: failed process: Process(`tar -xvf pari-2.7.4.tar.gz`, ProcessExited(1)) [1]
while loading /Users/eschnett/.julia/v0.4/Nemo/deps/build.jl, in expression starting on line 199

================================================================================

================================[ BUILD ERRORS ]================================

WARNING: Nemo had build errors.

 - packages with build errors remain installed in /Users/eschnett/.julia/v0.4
 - build the package(s) and all dependencies with `Pkg.build("Nemo")`
 - build a single package by running its `deps/build.jl` script

Since julia 0.5.0, we have the following behaviour

julia> M = [ fmpz() fmpz() fmpz(); fmpz() fmpz() fmpz()]
2×3 Array{Nemo.fmpz,2}:
 0  0  0
 0  0  0

julia> transpose(M)
WARNING: the no-op `transpose` fallback is deprecated, and no more specific `transpose` method for Nemo.fmpz exists. Consider `permutedims(x, [2, 1])` or w
riting a specific `transpose(x::Nemo.fmpz)` method if appropriate.
 in depwarn(::String, ::Symbol) at ./deprecated.jl:64
 in transpose(::Nemo.fmpz) at ./deprecated.jl:770
 in transpose_f!(::Base.#transpose, ::Array{Nemo.fmpz,2}, ::Array{Nemo.fmpz,2}) at ./arraymath.jl:369
 in transpose(::Array{Nemo.fmpz,2}) at ./arraymath.jl:407
 in eval(::Module, ::Any) at ./boot.jl:234
 in eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:64
 in macro expansion at ./REPL.jl:95 [inlined]
 in (::Base.REPL.##3#4{Base.REPL.REPLBackend})() at ./event.jl:68
while loading no file, in expression starting on line 0
3×2 Array{Nemo.fmpz,2}:
 0  0
 0  0
 0  0

The builtin transpose function will now "transpose" every entry in the array (think of matrices of matrices, but you want to treat it as one big matrix), and the generic transpose(x) = x will eventually be removed. Since we surely want to support transposing arrays of Nemo types, we have to do something. The example above would be fixed by defining

Base.transpose(x::fmpz) = deepcopy(x)

Because matrices are also subtypes of RingElem we cannot just do

Base.transpose{T <: RingElem}(x::T) = deepcopy(x)

This is really annoying. So far I have fixed the problems in the Nemo source using permutedims(M, [1,2]), but I think we all agree that compared to a simple transpose(M) or M' this is not a real solution.

I have found more, for example here:
https://github.com/Nemocas/Nemo.jl/blob/master/src/generic/CapRelSeries.jl#L758-L760

I managed to get Nemo running on my Windows 7. It all works except for converting fmpz to strings:

julia> using Nemo

Welcome to Nemo version 0.4.0

Nemo comes with absolutely no warranty whatsoever


julia> bin(fmpz(2))
"\"\0"

julia> bin(fmpz(4))
"?\x000"

julia> bin(fmpz(12))
"\"\x0000"

julia> fmpz(12)
??

julia> fmpz(32)
?☺

julia> fmpz(12)
??

On the other hand, it works on appveyor, so it must be a local problem. Any ideas?

While talking about consistency, maybe we can also decide on names.

1. The first issue would be underscores and is* functions. I think apart from some minor exceptions, in julia all the is* functions don't have an underscore after the is. In Nemo we have both. I propose that we also rename every is_* to is*.
2. In 0.6, julia has changed num to numerator and den to denominator. We should probably do the same (once we have switched to julia 0.6).

The timings I'm currently getting are 20-40s with a median of about 30s. But we report 0.6s.

I tried checking out Nemo 0.4 with Julia 0.4 and the timings are the same as they are with the most recent versions.

This seems to imply the timings are just wrong on the website. For the time being I can't think of any other reason for the timings to be so off. But I also can't get a timing of 0.6s or even close to it with a simple perturbation, e.g. with 10x10 matrix instead. So it's not obvious what actually went wrong.

The timings for the minpoly_finite_field benchmark are about right, so it's hard to imagine what could have been wrong with the original benchmark code. I would have expected the other benchmarks to be off too.

See https://groups.google.com/forum/#!topic/mpir-devel/T_NRX-gSpr8

• Clean up remove and valuation.
• Add documentation.

julia> R = ResidueRing(ZZ, 2)
Residue ring of Integer Ring modulo 2

julia> T, x = R["x"]
(Univariate Polynomial Ring in x over Residue ring of Integer Ring modulo 2,x)

julia> S, y = T["y"]
(Univariate Polynomial Ring in y over Univariate Polynomial Ring in x over Residue ring of Integer Ring modulo 2,y)

julia> zero(R)*y^0
Speicherzugriffsfehler (Speicherabzug geschrieben)

The error is a segfault, but I was too lazy to change languages.

I can reproduce it with the release and development version of julia.

It worked with an older version of Nemo, but I did not have time to do a bisect. It is probably due to the changed promotion system.

As discussed at the Hecke/Nemo/Flint workshop, there is a plan to add support for lattices of compatibly embedded finite fields to Nemo/Flint. This issue tracks progress on the subject.

There is an ongoing effort to add the basic algorithms to Flint, documented here: flintlib/flint#366.

On the Nemo side, @thofma has implemented an abstract map type, that should be a good object to represent the embeddings: https://github.com/Nemocas/Nemo.jl/tree/th/map

The branch flintlib/flint#351 of Flint contains algorithms (only naive ones, atm) for computing and evaluating embeddings. By wrapping those in a sensible interface, we shall

• implement maps between generic finite fields in Nemo;
• store the embedding information in a lattice, taking care of maintaining compatibility;
• wrap everything in a Fp-bar type.

Eventually, as support in Flint improves, we could think of using special families of irreducible polynomials for representing Fp-bar.

It might sound like a silly question, but what exactly is mul! supposed to do? (the same explanation for addeq! would be appreciated as well.)
By looking at code in different places I perceive that mul!(a, b, c) computes b*c, stores the result in a and then returns a, all with the aim of saving on memory allocation.
but then I am somewhat confused by examples of code like

b[i, k] = mul!(b[i, k], b[i, k], d)

Lets settle on simple c = mul!(c, c, d). When c is a more complicated object (e.g. when actual multiplication c*d takes part in "stages" (e.g. across several loops) providing the same c as a "storage"
may alter the result of the next stage, and result in an incorrect result.

This is exactly the case with backsolve! which gave me incorrect results until I allocated another tmp object and replaced all of mul!(c, c, d) by mul!(tmp, c, d)

Is this a bug, or have I implemented mul! incorrectly?

currently, a little unexpectedly:

• for n >= 2 it works (albeit not efficiently, we could compute order by cycle decomposition)
• for n = 1 it fails with MethodError: no method matching copy(::Nemo.perm)
• for n = 0 it fails with MethodError: no method matching one(::Nemo.perm)
• for n < 0 it fails with familiar (though unexpected) ERROR: DomainError: Cannot raise an integer x to a negative power -n.

Solutions:

1. define power_by_squaring(p::perm, n::Int) to which ^ defers.
2. define copy (similar to deepcopy_internal) and one; (user handles negative powers by inv(p)^n

This also brings the issue of one vs. eye for Groups;
Has anyone an idea how to handle e.g. Rings -> Groups forgetful functors, i.e. multiplicative one vs. additive zero?

3. Simple

function (^)(a::perm, n::Int)
   if n < 0
      return inv(a)^-n
   elseif n == 0
      return parent(a)()
   elseif n == 1
      return a
   else
      return Base.power_by_squaring(a, n % order(a))
   end
end

copy(p::perm) = deepcopy(p)

I am having problems to build Nemo in OSX, both using Julia 0.5.2 or 0.6.0-rc2.

The final output of Pkg.build("Nemo") is the following:

tmp-mul_1.s:144:no such instruction: `mulx 24(%rsi), %rbx,%rax'
make[2]: *** [mul_1.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_preinv_mod_1 -m64 -O2 -march=corei7 -mtune=corei7-avx -c preinv_mod_1.c  -fno-common -DPIC -o .libs/preinv_mod_1.o
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I did not get any further by doing julia build.jl in deps/. I think the problem is related to mpir-3.0.0.

Any ideas or suggestions?

Quite a few modules don't have a rand function. So far we only have rand for generic univariate polys, residue rings, integers, fraction fields, multivariate polys. We also need to document the random interface and use it in the generic matrix test code instead of the existing random functions, and also use it in the power series modules, especially for the more complex algorithms.

We might also consider implementing a version of rand that takes a lambda instead of a variadic argument list, as an alternative to the existing implementation that we have in Poly.jl, say.

We might also need a special version of rand for rationals that doesn't generate negative denominators.

When performing some matrix arithmetic I get the following warning:

WARNING: `x $ y` is deprecated.  use `xor(x, y)` or `x ⊻ y` instead.
Stacktrace:
 [1] depwarn(::String, ::Symbol) at ./deprecated.jl:70
 [2] $ at ./deprecated.jl:376 [inlined]
 [3] hash(::Nemo.GenMat{Nemo.fq_nmod}, ::UInt64) at /Users/siddmahen/.julia/v0.6/Nemo/src/generic/Matrix.jl:57

I believe the fix is easy; all occurrences of $ should be replaced appropriately.

If we change ZZ -> FlintZZ in the pearce and minpoly_gcd_domain benchmarks, it fails.

This occurs in Rings.jl where for some reason it doesn't recognise the runtime generated promote_rules. This seems like it could be a bug in Julia.

I keep getting this error trying to build Nemo.jl:

fatal: destination path 'antic' already exists and is not an empty directory.

I'm on Linux Mint 17.3, with Julia 0.4.6.

Recent travis build failed:

https://travis-ci.org/Nemocas/Nemo.jl/jobs/260163137

Algorithms for matrix spaces over non-commutative rings:

One solution would be to add another abstract type Group :> Ring :> CRing :> ... and write algorithms for Rings without assuming commutativity, while those (simpler/faster??) assuming commutativity should dispatch after CRings(Elems).

Currently rref only returns the matrix in reduced row echelon form. It would be useful if the pivot indices that were used were returned as well.

Reported by @erou

julia> using Nemo

julia> K, w = FiniteField(2, 2, "w")
(Finite field of degree 2 over F_2, w)

julia> R, T = K["T"]
(Univariate Polynomial Ring in T over Finite field of degree 2 over F_2,T)

julia> L = ResidueRing(R, T^2 + (w+1)*T + 1)
Residue ring of Univariate Polynomial Ring in T over Finite field of degree 2 over F_2 modulo T^2+(w+1)*T+(1)

julia> t = L(T)
T

julia> t^-1 == inv(t)
false

julia> t*t^-1
T

@wbhart @fieker

I would like to tag 0.5.1. Working around the deepcopy bug in Hecke is kind of annoying.

Any objections? If not, then once #90 is merged and travis is running I will do the tagging and the METADATA stuff.

julia> R, x = PolynomialRing(ZZ, "x")
(Univariate Polynomial Ring in x over Integer Ring,x)

julia>    S, y = PolynomialRing(R, "y")
(Univariate Polynomial Ring in y over Univariate Polynomial Ring in x over Integer Ring,y)

julia>    f = (x^2 + 1)*y^2 + 2x*y + 3x + 1
(x^2+1)*y^2+(2*x)*y+(3*x+1)

julia> g = (3x^3 + 2x^2)*y^3 + (3x +1)*y + 2x + 2
(3*x^3+2*x^2)*y^3+(3*x+1)*y+(2*x+2)

julia> gcd(f, g)
1

julia> gcd(f*y, g*y)
1

Doesn't look right to me.

I was trying to understand what our MatElem "interface" is and where the corresponding functions for GenMat are.

I think it would help a lot if we could separate functions for MatElem and GenMat filewise. But where would the MatElem functions go?

Second question. I think we write in the documentation that a custom matrix type has to overload the getindex function. Now in generic/Matrix.jl we have

function getindex{T <: RingElem}(a::MatElem{T}, r::Int, c::Int)
   return a.entries[r, c]
end

This looks like a very specific fallback, which I am not sure we want to have. We would now say in the documentation: A custom matrix type has to implement getindex OR it has to have a field named entries, which is of type Array{T, 2}, where the entries are stored as rows and columns (in this specific order).

I would suggest to restrict the signature to GenMat since this is actually the getindex implementation for GenMat.

You can use Conda.jl for installing binary dependencies. Released versions of GMP, MPFR, FLINT and ARB are already available as conda packages. This will help reduce the build time.

Currently we interpolate polynomials over an integral domain by first converting to Newton basis, doing an interpolation by the method of divided differences, then converting back to monomial basis. The problem is, if there is no polynomial over the integral domain which interpolates the initial values, the interpolation stage will do an inexact division. Currently we raise an exception if this happens. But what we haven't proved is that if there is a polynomial over the integral domain that interpolates the input values, then no fractions can occur at this point. This isn't trivial to prove (usually textbooks assume all the differences are units to make the proof work). However, it does seem to be true, both experimentally, and using a symbolic ring as input. What is missing is a mathematical proof that it always works without going to the fraction field internally. Beware that there is no obvious proof, and one must check carefully that any purported proof really checks that no inexact division could occur in the case of an exact interpolation, and that the same proof doesn't show that inexact divisions never happen, even when there is no polynomial interpolating the inputs!! The difficulty in the proof is that fractions could cancel out in the arithmetic in the inner loop of the interpolation. Working backwards naively from a valid interpolated polynomial isn't enough to show that this didn't happen.

fmpz_mat.convert...WARNING: When trying to convert a fmpz_mat to a Matrix{Int}, some elements were too large to fit the standard Int type: try to convert to a matrix of BigInt.

I just want to record some questions and tasks which emerged in the discussion of #4. Feel free to edit this.

Functionality which needs to be rolled out:

• Matrix constructors with 1-dimensional arrays for all matrix types (see fmpz_mat)
• zero!, one! for non-immutable types (see nmod_poly or fmpz_mat)
• Valuation for polynomials (over fields) (see nmod_poly)
• swap_rows and swap_rows! for generic matrices (see arb_mat)

Things we need to find conventions for and apply them consequently:

• is_hnf versus isprime
• Underscores in function names
• How to handle names of "internal" functions, i.e., how to hide them
• Consistent error messages (using error objects?)

Renaming:

• isnegative to has_minus_sign (or something like that).

Things which would be nice to have or improve:

• Valuation of polynomials with logarithmic complexity.

The following program fails both on Mac OS X using julia-0.4.6 and Linux using julia-0.5:

#!/usr/bin/env julia

using Nemo

CC = ComplexField(1024)

a = CC(1.0, 0.0)
b = CC(3/2, 0.0)
c = CC(7/2, 0.0)
z = CC(0.9^2, 0.0)

hyp2f1(a, b, c, z)

The error message on julia-0.4.6 is

$ ./bug.jl 

Welcome to Nemo version 0.5.0

Nemo comes with absolutely no warranty whatsoever


signal (11): Segmentation fault: 11
jl_free at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_julia/julia/work/julia-0.4.6/src/gc.c:2594
acb_hypgeom_pfq_series_sum_forward at /Users/hsg113/.julia/v0.4/Nemo/local/lib/libarb.dylib (unknown line)
acb_hypgeom_pfq_series_sum_bs at /Users/hsg113/.julia/v0.4/Nemo/local/lib/libarb.dylib (unknown line)
acb_hypgeom_pfq_series_direct at /Users/hsg113/.julia/v0.4/Nemo/local/lib/libarb.dylib (unknown line)
acb_hypgeom_2f1_series_direct at /Users/hsg113/.julia/v0.4/Nemo/local/lib/libarb.dylib (unknown line)
_acb_hypgeom_2f1_transform_limit at /Users/hsg113/.julia/v0.4/Nemo/local/lib/libarb.dylib (unknown line)
acb_hypgeom_2f1_transform_limit at /Users/hsg113/.julia/v0.4/Nemo/local/lib/libarb.dylib (unknown line)
acb_hypgeom_2f1_transform_limit at /Users/hsg113/.julia/v0.4/Nemo/local/lib/libarb.dylib (unknown line)
acb_hypgeom_2f1_transform at /Users/hsg113/.julia/v0.4/Nemo/local/lib/libarb.dylib (unknown line)
acb_hypgeom_2f1 at /Users/hsg113/.julia/v0.4/Nemo/local/lib/libarb.dylib (unknown line)
unknown function (ip: 0x3327520c1)
jl_apply_generic at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_julia/julia/work/julia-0.4.6/src/gf.c:1691
do_call at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_julia/julia/work/julia-0.4.6/src/interpreter.c:56
eval at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_julia/julia/work/julia-0.4.6/src/interpreter.c:230
jl_toplevel_eval_flex at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_julia/julia/work/julia-0.4.6/src/toplevel.c:527
jl_parse_eval_all at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_julia/julia/work/julia-0.4.6/src/toplevel.c:577
jl_load at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_julia/julia/work/julia-0.4.6/src/toplevel.c:619
include at /opt/local/lib/julia/sys.dylib (unknown line)
jl_apply at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_julia/julia/work/julia-0.4.6/src/./julia.h:1331
include_from_node1 at /opt/local/lib/julia/sys.dylib (unknown line)
jl_apply at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_julia/julia/work/julia-0.4.6/src/./julia.h:1331
process_options at /opt/local/lib/julia/sys.dylib (unknown line)
_start at /opt/local/lib/julia/sys.dylib (unknown line)
jlcall__start_18894 at /opt/local/lib/julia/sys.dylib (unknown line)
jl_apply at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_julia/julia/work/julia-0.4.6/src/./julia.h:1331
true_main at /opt/local/bin/julia (unknown line)
main at /opt/local/bin/julia (unknown line)
  ***   bug in PARI/GP (Segmentation Fault), please report.
  ***   Error in the PARI system. End of program.

The julia-0.5 message is similar, but without the backtrace. I'm not sure how debug this. Let me know if you need anything else.

Example:

julia> F, x = FiniteField(23, 1, "x")
(Finite field of degree 1 over F_23,5)

julia> R, t = PowerSeriesRing(F, 6, "t", model=:capped_absolute)
(Univariate power series ring in t over Finite field of degree 1 over F_23,t+O(t^6))

julia> F(1) * t
ERROR: MethodError: Cannot `convert` an object of type Type{Union{}} to an object of type Nemo.FqNmodFiniteField
This may have arisen from a call to the constructor Nemo.FqNmodFiniteField(...),
since type constructors fall back to convert methods.
 in *(::Nemo.fq_nmod, ::Nemo.fq_nmod_abs_series) at /home/grace/jkieffer/.julia/v0.5/Nemo/src/flint/fq_nmod_abs_series.jl:222

This may be fixed in the following way:

diff --git a/src/flint/fq_nmod_abs_series.jl b/src/flint/fq_nmod_abs_series.jl
index 6017892..f48a2e1 100644
--- a/src/flint/fq_nmod_abs_series.jl
+++ b/src/flint/fq_nmod_abs_series.jl
@@ -221,7 +221,7 @@ function *(x::fq_nmod, y::fq_nmod_abs_series)
    z.prec = y.prec
    ccall((:fq_nmod_poly_scalar_mul_fq_nmod, :libflint), Void, 
          (Ptr{fq_nmod_abs_series}, Ptr{fq_nmod_abs_series}, Ptr{fq_nmod}, Ptr{FqNmodFiniteField}), 
-               &z, &y, &x, &base_ring(x))
+               &z, &y, &x, &parent(x))
    return z
 end

Playing around with the new GenMpolyRing, I got this error:

julia> A,(x,y)=PolynomialRing(QQ,["x","y"])
(Multivariate Polynomial Ring in x, y over Rational Field,Nemo.GenMPoly{Nemo.fmpq}[x,y])

julia> 0*x*y
ERROR: UndefRefError: access to undefined reference
 in (::Nemo.GenMPolyRing{Nemo.fmpq})(::Array{Nemo.fmpq,1}, ::Array{UInt64,2}) at /home/defeo/.julia/v0.5/Nemo/src/generic/MPoly.jl:2594
 in *(::Nemo.GenMPoly{Nemo.fmpq}, ::Nemo.GenMPoly{Nemo.fmpq}) at /home/defeo/.julia/v0.5/Nemo/src/generic/MPoly.jl:1016
 in *(::Int64, ::Nemo.GenMPoly{Nemo.fmpq}, ::Nemo.GenMPoly{Nemo.fmpq}) at ./operators.jl:138
 in eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:64
 in macro expansion at ./REPL.jl:95 [inlined]
 in (::Base.REPL.##3#4{Base.REPL.REPLBackend})() at ./event.jl:68

At the moment we can not parse output of Nemo back into a julia REPL:

julia> Qx, x = QQ["x"]
(Univariate Polynomial Ring in x over Rational Field,x)

julia> x//2
1/2*x

julia> 1/2*x
ERROR: MethodError: no method matching *(::Float64, ::Nemo.fmpq_poly)

This is kind of annoying. Claus suggested to use // for printing of elements of type fmpq. Together with #148 this allows us to do

julia> 1//2*x
1//2*x

We would only have to change Base.show(::IO, ::fmpq) and delete the ad hoc printing functions for the other fmpq_* types. Then the generic printing functions will kick in and give us // in all the other fmpq_* types without any additional work.

Please have a look at this test run:

https://ci.appveyor.com/project/OpenLibMathSeq/intseq/build/job/w7d8uvspn4t6jlw3

It has an ErrorException:

ccall: could not find function fmpz_factor_get_fmpz in library libflint

(Note in passing that their is also a discrepancy in the printed Nemo version (0.6.0 instead of 0.6.1)).

The benchmark in solve_polynomials.jl (in the benchmark directory) now takes more than 50s, whereas we have it at 7s on our benchmark page. Reported by Bernard Parisse.

I checked out Nemo-0.4 and it completes in about 7s, but Nemo-0.5 takes more than 50s. The benchmark code is of course correct. I also compared Julia-0.4 and Julia-0.5 and only a very small amount of the regression is to do with that.

What I notice is that the memory usage has gone up from about 72Mb to 3.2Gb. This should be easy enough to track down with the Julia compiler's --track-allocations=all option.

Why:

Nemo.MatrixSpace(Nemo.QQ, 3, 4)(fill(1//2, 3, 4))

doesn't work? I expect this to return a matrix over the rationals.

Please consider the following snippet which throws an

MethodError: no method matching length(::Nemo.fmpq).

Is this an error or do I use things incorrectly?

using Nemo
function qq()
    println("--- julia-rat")
    F = [1//1]
    println(typeof(F[1]))
    println(typeof(F))
    for i in 1:6 append!(F, F[i]*i) end
    println(F)
end

function nqq()
    println("--- nemo-rat")
    # F = [QQ(1,1)]
    F = [fmpq(1,1)]
    println(typeof(F[1]))
    println(typeof(F))
    for i in 1:6 append!(F, F[i]*i) end
    println(F)
end

qq()
nqq()

Can someone reproduce the following?

julia> y = MatrixSpace(ZZ, 3, 3)([fmpz(2) for i in 1:9])
[2 2 2]
[2 2 2]
[2 2 2]

julia> z = y^30 - y^2 + y^200
[`�4`�4�ǃ�4Ь�p��p��0263�w0w�69909893760515555870994365148841350593877210124544175924� `�4`�4�ǃ�4
Ь�p��p��0263�w0w�69909893760515555870994365148841350593877210124544175924� `�4`�4�ǃ�4Ь�p��p��026
3�w0w�69909893760515555870994365148841350593877210124544175924�]
[`�4`�4�ǃ�4Ь�p��p��0263�w0w�69909893760515555870994365148841350593877210124544175924� `�4`�4�ǃ�4
Ь�p��p��0263Pmm�699098937605155558709943651488413505938772101245441759241 `�4`�4�ǃ�4Ь�p��p��0263
Pmm�699098937605155558709943651488413505938772101245441759241]
[`�4`�4�ǃ�4Ь�p��p��0263Pmm�699098937605155558709943651488413505938772101245441759241 `�4`�4�ǃ�4Ь
�p��p��0263Pmm�699098937605155558709943651488413505938772101245441759241 `�4`�4�ǃ�4Ь�p��p��0263P
mm�699098937605155558709943651488413505938772101245441759241]

Sometimes I have to repeat the z = y^30 - y^2 + y^200 step to produce garbage.

This is latest Nemo and julia 0.4.6.

edit: I can reproduce it on another machine with julia 0.4.5.