Re: [sage-devel] Adopting orphaned math packages
On 1/6/20 10:35 AM, E. Madison Bray wrote: > > Sorry for the delay; I went ahead and created an empty project under > our organization and added (I assume) you as a maintainer, so have at > it: https://gitlab.com/sagemath/symmetrica > Thanks, I've gotten it to a point where it's usable. Most sage and distro patches have been applied (see the issue list for some hand wringing), and there's now a real build system thanks mainly to the Debian maintainer. Please give it a try and see what I broke. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/9939d8e6-1ecb-c427-f468-744af29f5f02%40orlitzky.com.
[sage-devel] Bug with Smith normal form for matrices over GF(4) on OS X
Dave Witte Morris pointed out the following bug (now trac 28970): M = random_matrix(GF(4), 70, 70) def test_matrix(iterations=50):for k in range(iterations): S,U,V = M.smith_form() print(k) if not S == U * M * V: raise ValueError On OS X, this will often run for a few iterations and then raise a ValueError, or run for a few iterations and then crash Sage. Note that the matrix is fixed at the start, so each iteration should be identical to the others, but this is not happening. Also, the ValueError should never be raised: the definition of Smith normal form is that S == U * M * V. (The code also sometimes raises a NotImplementedError, but this has been addressed at #28967.) The occasional crash: python3(37360,0x10f7355c0) malloc: Incorrect checksum for freed object 0x7fce33018c00: probably modified after being freed. Corrupt value: 0xc000 python3(37360,0x10f7355c0) malloc: *** set a breakpoint in malloc_error_break to debug (no backtrace available) Unhandled SIGABRT: An abort() occurred. This probably occurred because a *compiled* module has a bug in it and is not properly wrapped with sig_on(), sig_off(). Python will now terminate. What's going on? A memory leak or something along those lines? Can someone help to debug this? - https://trac.sagemath.org/ticket/28970 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/25f7d986-a5f4-4766-aa5e-7cc8be0f3b1b%40googlegroups.com.
Re: [sage-devel] Different behavior in normal usage and when building the doc (decimal separator / tachyon syntax error)
Le 07/01/2020 à 10:20, dimp...@gmail.com a écrit : > On Mon, Jan 06, 2020 at 06:37:25PM +0100, Jean-Florent Raymond wrote: >> >> I have been investigating a bug that happened when I tried to build the >> documentation of sage 9.0 on a new machine. >> It seems to be the same as described in >> >> https://groups.google.com/d/topic/sage-devel/5jajeJiJNiY/discussion >> (the thread describes a way to circumvent it) >> >> In a few words: in order to produce 3d pictures for the documentation, >> the script that builds the documentation calls tachyon (because jmol is >> not available) and the tachyon call results in a syntax error. Strangely >> I have not been able to reproduce this error except when building the >> documentation. >> The way it works is that a string describing the 3d scene is written to >> a temporary file, which is then read by tachyon. Investigating further I >> found that some decimal numbers are printed in this file with commas as >> decimal separator when building the doc and with dots when running >> sage... I highly suspect this to be the reason of the syntax error >> raised by tachyon. Below is an example of lines from the two temporary >> files corresponding to the same call, the first in normal sage and the >> second one obtained when building the doc. >> >> TRI V0 0.641519 0.179487 0.025641 V1 0.641026 0.18109 -0.025641 V2 >> 0.641519 0.179487 -0.025641 >> TRI V0 0,641519 0,179487 0,025641 V1 0,641026 0,18109 -0,025641 V2 >> 0,641519 0,179487 -0,025641 >> >> What I cannot explain is why these lines have been printed differently >> (i.e. commas instead of dots). They have been printed by the function >> format_tachyon_triangle from src/sage/plot/plot3d/index_face_set.pyx, >> whose code is the following (comment is not mine): >> >> cdef inline format_tachyon_triangle(point_c P, point_c Q, point_c R): >> cdef char ss[250] >> # PyBytes_FromFormat doesn't do floats? >> cdef Py_ssize_t r = sprintf_9d(ss, >>"TRI V0 %g %g %g V1 %g %g %g V2 %g %g >> %g", >>P.x, P.y, P.z, >>Q.x, Q.y, Q.z, >>R.x, R.y, R.z ) >> return bytes_to_str(PyBytes_FromStringAndSize(ss, r)) >> >> Does anyone here has an idea why this function behaves differently >> depending on whether it is called in sage or when building the doc? > > Are you on locale that uses commas instead of dots in representing > floating precision numbers? > If so, it could be that writing out these files happens under the > control of your locale... Indeed, and by changing the locale to en_US the problem disappears. Thanks! Here is a fix: https://trac.sagemath.org/ticket/28971 Jean-Florent. > > Just a wild guess, of course. > Dima > > >> >> Best, >> Jean-Florent. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sage-devel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sage-devel+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/sage-devel/9fcb3ff1-bedb-2a5c-af16-fcee21588e10%40uca.fr. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/f7eb4ed0-2307-40c8-34ae-60d819040c1b%40uca.fr. signature.asc Description: OpenPGP digital signature
Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?
On Tue, Jan 7, 2020 at 9:45 PM Sébastien Labbé wrote: > > The question I have is the folllowing. Suppose a user have 10k lines of > SageMath code (notebooks, files, etc.) working well in 8.9 which obviously > will get broken in the default 9.0 mostly because of: notebooks as in sagenb? This would really be not fun at all, as sagenb does not run on py3. > - print > - comparisons > - iterkeys, iteritems > - and few other particular changes > > 1. What is the best workflow for such users to adapt to the 9.0, 9.1, etc. > series? > > 2. How can the version 9.1 of SageMath be made so that it is really helpful? > > 3. How can a version 9.1 or 9.0 running Python 2 can be more helpful than the > version 8.9 running Python 2? (Let's recall that the old code was running in > 8.9 so it does not use any of the new features added in 9.0) We did see one-liners working in 8.9 and broken in 9.0, to do with graphics. Every new release not only adds features, it fixed bugs (and introduces new ones, obviously :-)) Thus, the closer you are to the current release, the better. > > Sébastien > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/bcd007fd-7b22-4d5d-9aee-44005ebd684b%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq3FVs4UfWaagUpyojn8xX8pQF5GD0SBT6uHyh%3DHiVH5vg%40mail.gmail.com.
[sage-devel] Possible bug in NumberField's valuation()
Dear all, The following code raises an unexpected AssertionError: R. = QQ[] K. = NumberField(x^6 - 18*x^4 - 24*x^3 + 27*x^2 + 36*x - 6) fp = K.fractional_ideal((2, -7/44*theta_K^5 + 19/44*theta_K^4 + 87/44* theta_K^3 - 87/44*theta_K^2 - 5/2*theta_K + 39/22)) print(fp.norm()) # yields 2 print(fp in K.primes_above(2)) # yields True v = K.valuation(fp)# raises AssertionError ... coming from the following assert(): --> 303 assert(len(candidates_for_I) > 0) # This should not be possible, unless I contains a unit Am I missing something? This was run on Sage 9.0, Linux Mint 19.2, 64 bit. Thanks, Benjamin -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/1af41bd7-df95-4fed-ab00-1ffb09a79a51%40googlegroups.com.
