2009/9/1 Paulo César Pereira de Andrade <
paulo.cesar.pereira.de.andr...@gmail.com>

>
>  Hi,
>
>  The package I am building uses newer versions of several components,
> and while I believe most of these tests probably are correct, I may be
> missing some patch, so, if you can confirm it is correct, or is an
> alternate correct response, please let me know.
>  These are not the only errors, but are a sampling of similar errors:
>
> doc/en/constructions/polynomials.rst +45
>    sage: print gap.eval("R:= PolynomialRing( GF(97))")
> Expected:
>    PolynomialRing(..., [ x_1 ])
> Got:
>    GF(97)[x_1]
> * this should be due to using gap 4.4.12, while sage uses gap 4.4.10
>

looks fine


>
> doc/en/constructions/rings.rst +58
>    sage: R = singular.ring(97, '(a,b,c,d)', 'lp')
>    sage: I = singular.ideal(['a+b+c+d', 'ab+ad+bc+cd',
> 'abc+abd+acd+bcd', 'abcd-1'])
>    sage: R
> Expected:
>    //   characteristic : 97
>    //   number of vars : 4
>    //        block   1 : ordering lp
>    //                  : names    a b c d
>    //        block   2 : ordering C
> Got:
>    //   characteristic : 97
>    //   number of vars : 4
>    //        block   1 : ordering lp
>    //                  : names    abcd
>    //        block   2 : ordering C
> * The sage spkg don't have a patch to separate the names, so I am
> assuming it is a minor change in singular
>


looks safe


>
> doc/en/tutorial/tour_numtheory.rst +94
>    sage: x = crt(2, 1, 3, 5); x
> Expected:
>    -4
> Got:
>    11
> * This is caused by using pari 2.3.4 while sage uses pari 2.3.3
>


safe


>
> libs/pari/gen.pyx +6781
>            sage: y = QQ['yy'].0; _ = pari(y) # pari has variable ordering
> rules
>            sage: x = QQ['zz'].0; nf = pari(x^2 + 2).nfinit()
>            sage: nf.nfroots(y^2 + 2)
> Expected:
>    [-zz, zz]
> Got:
>    [Mod(-zz, zz^2 + 2), Mod(zz, zz^2 + 2)]
> * Again, due to using newer version of pari
>

ok


>
> matrix/matrix_double_dense.pyx +983
>            sage: m = matrix(RDF, 2, range(6)); m
>            [0.0 1.0 2.0]
>            [3.0 4.0 5.0]
>            sage: U, S, V = m.SVD()
>            sage: U*S*V.transpose()           # random low bits
>            [7.62194127257e-17               1.0               2.0]
>            [              3.0               4.0               5.0]
>            sage: U
>            [-0.274721127897 -0.961523947641]
>            [-0.961523947641  0.274721127897]
>            sage: S
>            [7.34846922835           0.0           0.0]
>            [          0.0           1.0           0.0]
>            sage: V
> Expected:
>    [-0.392540507864  0.824163383692  0.408248290464]
>    [-0.560772154092  0.137360563949 -0.816496580928]
>    [ -0.72900380032 -0.549442255795  0.408248290464]
> Got:
>    [-0.392540507864  0.824163383692 -0.408248290464]
>    [-0.560772154092  0.137360563949  0.816496580928]
>    [ -0.72900380032 -0.549442255795 -0.408248290464]
>

last eigenvector is just off by sign?


> * This one gives significantly different result, but is not easy to do
> an alternate build with sage's version of quaddouble
>




> * I think I will switch to use sage's version. Sage uses quaddouble
> 2.2.p9 (patchlevel 9), while I packaged upstream
>  quaddouble 2.2.7
>
> rings/real_rqdf.pyx +463
>            sage: RQDF(2^60 + 9 )
> Expected:
>    1.15292150460684698500000000000000000000000000000000000000000000e18
> Got:
>    1e+18
> * Again should be a quaddouble issue. But I can see that sage result
> is correct, while the quaddouble I am using is truncating the result.
>

We voted a loooong time ago to completely remove quaddouble from Sage, since
it causes too much trouble for too little gain.  This needs to happen asap.
Anyway, quaddouble will vanish from sage soon, so I wouldn't worry too much
about quaddouble issues.


>
> rings/polynomial/toy_d_basis.py +171
>        sage: from sage.rings.polynomial.toy_d_basis import gpol
>        sage: P.<x, y, z> = PolynomialRing(IntegerRing(), 3, order='lex')
>        sage: f = x^2 - 1
>        sage: g = 2*x*y - z
>        sage: gpol(f,g)
> Expected:
>    x^2*y - y
> Got:
>    x^2*y - x*z + y
> * Not sure what is the cause, neither if this is an alternate correct
> result...]
>

Martin -- any thoughts?


>
> calculus/calculus.py +1068
>        sage: f = log(log(x))/log(x)
>        sage: forget(); assume(x<-2); lim(f, x=0, taylor=True)
> Expected:
>    limit(log(log(x))/log(x), x, 0)
> Got:
>    0
> * This is when using newer maxima
>
>
That agrees with Mathematica at least:


In[4]:= Limit[Log[Log[x]]/Log[x],x->0]

Out[4]= 0


So it seems like it is just an improvement we'll get in Sage.

It sounds like Sage in Mandriva will be better than our Sage, until we
update a few packages.

William

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to