[sage-devel] Re: valuation() for relative number fields raises errors
Hi Evan, this is fixed in https://trac.sagemath.org/ticket/28976 which is awaiting review. julian On Friday, April 17, 2020 at 10:15:00 PM UTC+2, Evan O'Dorney wrote: > > Hi all, > > Running the code > K. = NumberField([x^2 - 2, x^2 + x + 1]); > K.valuation(pi) > yields a strange AssertionError. Oddly enough, constructing the same > number field in this way: > K2. = NumberField([x^2 + x + 1, x^2 - 2]); > K2.valuation(pi2) > works just fine. > > I'm running SageMath 8.8 on Linux Mint 18 Cinnamon 64-bit. > > Thanks, > Evan > -- 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/f6b8ad97-cdff-404d-84e1-9be6c63a4acc%40googlegroups.com.
[sage-devel] Using travis-ci on Sage with both py2 and py3
Hi Simon, the py3 image has the tag :develop-py3 instead of :develop. That image is a bit old unfortunately since https://trac.sagemath.org/ticket/28041 (positive review) has not been merged yet. I'm not a travis expert but I think you want to add a matrix that adds an environment variable say SUFFIX and sets it to "" and "-py3". Then just pull with :develop$SUFFIX instead of what you are doing now. Does that work? julian -- 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/19eb19a1-6187-4fdf-85fe-dea069838d9f%40googlegroups.com.
Re: [sage-devel] docker images "latest" and "develop" are old
Hi Erik, I think this is not a problem on GitLab anymore. I can restart protected jobs at least, so probably also entire pipelines. On Friday, August 2, 2019 at 11:14:24 AM UTC+2, E. Madison Bray wrote: > > Wow--do I understand you correctly that, if a branch is marked > "unprotected" , GitLab won't receive the secrets credentials? And yet > the only way to manually restart a pipeline is to "unprotect" the > branch (which I did, as you say, in order to restart)? > -- 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/b845cefb-67a8-4c01-be7b-ce0e4b3b0227%40googlegroups.com.
Re: [sage-devel] docker images "latest" and "develop" are old
Hi Markus, Sorry, I had missed this discussion initially. The credentials for docker hub are protected secrets in GitLab CI. They are only provided to protected branches and tags. All tags are protected so they were correctly uploaded to Docker Hub. However, as I wrote on another thread, the branch were unprotected (probably because somebody wanted to restart the pipelines manually?) so they did not receive the secrets and (as you found) were missing the credentials to upload. It seems to work again now. julian On Thursday, August 1, 2019 at 12:19:03 PM UTC+2, Markus Wageringel wrote: > > There also appears to be a problem with the credentials, causing the last > step, pushing the image to DockerHub, to silently fail. For example, this > is the log for the last run on the develop branch [1], which last ran for > 8.8.rc1. > > $ sh .ci/push-dockerhub.sh sagemath > + sh .ci/push-dockerhub.sh sagemath > + '[' -z develop ] > + '[' -z -o -z ] > + echo 'DOCKER_USER/SECRET_DOCKER_PASS variables have not been configured > in your Continuous Integration setup. Not pushing built images to Docker > Hub.' > DOCKER_USER/SECRET_DOCKER_PASS variables have not been configured in your > Continuous Integration setup. Not pushing built images to Docker Hub. > Job succeeded > > I am not sure why this has not run for any more recent updates to the > develop branch, though. The sagemath:develop image at [2] is up to date at > least. Perhaps, the develop branch in the gitlab mirror just does not get > updated regularly. > > > [1] https://gitlab.com/sagemath/sage/-/jobs/231098209 > [2] https://gitlab.com/sagemath/dev/trac/container_registry > > > Am Freitag, 26. Juli 2019 16:28:02 UTC+2 schrieb E. Madison Bray: >> >> On Thu, Jul 25, 2019 at 10:49 PM Vincent Delecroix >> <20100.d...@gmail.com> wrote: >> > >> > Dear all, >> > >> > According to the page [docker] the images with tag "latest" and >> > "develop" are supposed to be the latest stable and development >> > versions. However sagemath/sagemath-dev:latest is stuck at 8.7 >> > while 8.8 is released since July 7th (and the corresponding >> > docker image is available on docker hub). Similarly, >> > sagemath/sagemath-dev:develop is 8.8.beta5 while we are now >> > at 8.9.beta3 (8.9.beta2 is available on docker but not >> > 8.9.beta3). >> > >> > Shouldn't "latest" and "develop" be automatically updated? >> > >> > [docker] https://hub.docker.com/u/sagemath/sagemath >> >> According to one of the build scripts [1], if the "master" branch is >> built, it will be tagged as "latest". I'm not sure about "develop". >> Apparently, although the build for the 8.8 *tag* completed >> successfully [2], the one for "master" (at 8.8) failed sort of >> randomly [3], due to a problem we've been seeing where `make` is >> taking longer and longer (and longer than it should) so the build >> times out. Need to investigate why it's taking so much longer. >> >> In general, it would certainly be welcome to have more volunteers >> monitoring and debugging issues with the CI pipeline, since getting >> this working smoothly would be a huge benefit. But we haven't had >> enough resources or people looking at it... >> >> [1] >> https://gitlab.com/sagemath/sage/blob/b5c9cf037cbce672101725f269470135b9b2c5c4/.ci/update-env.sh#L37 >> >> [2] https://gitlab.com/sagemath/sage/pipelines/68209174 >> [3] https://gitlab.com/sagemath/sage/pipelines/68212724 >> > -- 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/13dadffa-c0a0-44ed-881c-ced687209b90%40googlegroups.com.
[sage-devel] Re: Possible to use current Sage version in travis-ci?
Hi Simon, > On Thursday, August 1, 2019 at 12:52:38 PM UTC+2, Simon King wrote: Is it possible to automatically go to the latest available tag? "latest" is the latest stable release of SageMath, and "develop" is the latest beta (see also the README at https://hub.docker.com/r/sagemath/sagemath). Unfortunately, the master/develop branch in GitLab had been unprotected somehow which is why these tags where not updated. I made them protected again, so the tags should update in a few minutes. julian -- 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/c1a083b0-cda2-488f-bafa-00c777cf3501%40googlegroups.com.
Re: [sage-devel] delay 8.8?
There shouldn't be a problem with using the latest 8.8rc in binder. On Saturday, June 22, 2019 at 1:54:26 PM UTC+2, Eric Gourgoulhon wrote: > > [...] It would be nice if 8.8 is released by then. Otherwise, I will of > course warn the audience that these features are not available yet (in > particular, they will not work in Binder demos). > The rcs (and all the betas) have corresponding docker images on https://hub.docker.com/r/sagemath/sagemath/tags. If that's what you are using for binder, then there shouldn't be a problem. You can also use conda-forge's sage for binder which has rc1 packaged. [Btw., there is a docker image for every push to a trac ticket, so you can even add some features that only exist on a certain ticket to your binder instance, see https://gitlab.com/sagemath/dev/trac/container_registry] julian -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/b90e6dcb-0fb3-44e7-a5bd-ff6640151197%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Building fails with missing GiNaC symbol
I never use nm. I didn't know that you need to pass -D. Yes, with -D I see the symbols as well. On Wednesday, June 19, 2019 at 12:21:08 PM UTC+2, François Bissey wrote: > > > > > On 19/06/2019, at 10:17 PM, Julian Rüth > > wrote: > > > > Not sure why nm does not see any symbols here. > > > > nm -D doesn’t show anything? -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/358091dc-28a9-4472-aba5-154081f93063%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Building fails with missing GiNaC symbol
On k8s, I see this symbol when doing objdump -TC local/lib/libpynac.so.13.0.2 Not sure why nm does not see any symbols here. julian On Wednesday, June 19, 2019 at 10:29:10 AM UTC+2, Isuru Fernando wrote: > > Hi, > > I'm trying to build sage 8.8.rc1 on conda with conda built dependencies > and I'm getting the following error. > > ImportError: /_h_env/lib/python2.7/site-packages/sage/symbolic/ring.so: > undefined symbol: _ZN5GiNaC9containerISt6vectorEC1ERKS1_INS_2exESaIS3_EEb > > Demangled, this is > > GiNaC::container::container(std::vector std::allocator > const&, bool) > > This is with pynac 0.7.25. I can send more details if required. > > Has anybody seen this error before? > > Isuru > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/25d89eef-115f-402e-84e2-52c070717a93%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Downgrade rubiks to optional
I agree that we should consider making it optional. I had a look at the examples in the doctests with the current default algorithm (hybrid) and gap: The timings were, respectively: 933ms 2.41s 927ms 1.18s 937ms 1.13s So, gap seems to be fast enough imho and people can install the optional SPKG if it's not. julian On Wednesday, June 19, 2019 at 1:15:57 AM UTC+2, Isuru Fernando wrote: > > Hi, > > Rubiks package is a combination of 3 packages with lots of patches to the > build system > > Keeping it standard requires package managers to package this strange > package of 3 packages and wastes time if nobody is using it. > > Users can use gap to solve the rubik's cube or install the rubiks spkg if > sage was built using source. > > Isuru > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/b0f79bd5-40fc-471a-9e96-cc2ed999c901%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] updating README.md
On Monday, May 20, 2019 at 1:48:40 PM UTC+2, Dima Pasechnik wrote: > > How about using conda's > goodies for Sage deps which already optionally may come from the > "system", as on https://trac.sagemath.org/ticket/27330 > (that is, gmp, yasm, pcre, etc etc etc) > It's possible but it won't work out of the box so I wouldn't recommend it. julian -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/9f356ae5-71cd-4f1e-82fd-3a3980d1d8f0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] updating README.md
On Monday, May 20, 2019 at 12:21:05 PM UTC+2, Dima Pasechnik wrote: > > * what is the status of Sage's support in conda(-forge). Sage is packade by conda-forge but stuck at 8.3 and needs to be updated. For people familiar with conda the installation instructions would be `conda install -c conda-forge sage`, more detailed instructions are at https://wiki.sagemath.org/Conda. > Specifically, > is it possible to build Sage in (mini)-conda environment? > If you mean using dependencies from conda-forge instead of SPKGs, then no, there is at least no reasonably documented way to do this. Building from source with SPKGs should work fine (on Linux & macOS.) The necessary dependencies can be installed with `conda install -c conda-forge make cxx-compiler c-compiler m4 perl git tar fortran-compiler binutils`. Does that answer your question? julian -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/601dd8b1-dc01-4d16-ad15-98b83253ce29%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] gitlab status?
Hi Erik, thanks for trying to make GitLab CI work again. On Wednesday, April 17, 2019 at 3:46:44 PM UTC+2, E. Madison Bray wrote: > > Well it was hard to tell from the logs, but the main problem turned > out to be running out of disk space. I don't know why--the worker > machines had 20GB each which you'd think should be enough, and that it > wasn't is something worth investigating in its own right. > I wrote a comment in the `.gitlab-ci.yml` at some point that says # * runners tagged as "gce" (Google Compute Engine) provide about 22GB of HDD , # a single core, 4GB of RAM. Since we are relying on OverlayFS, the disk # space is not sufficient to build sage from scratch. It seems that with overlayfs we need lots of disk space temporarily. I forgot about the details but I think it could be how the copy-on-write works that we basically need space for several copies of Sage's local/ directory. Anyway, requiring that much temporary disk space is probably nothing we can do much about in a docker setup easily. julian -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Poll: set online=True as the default for threejs viewer
Actually, I changed it now to just include the full three.js script with every plot. Sure, it keeps your browser from doing smart caching but at least it's going to always work and there are no privacy concerns anymore. So, that's what I propose as a temporary fix until somebody really understands how to do this properly in Jupyter & CoCalc. On Saturday, February 16, 2019 at 4:50:25 PM UTC+1, Julian Rüth wrote: > > I would not mind `online=True` to be the default but apparently there is > too much opposition to that. > I added a simple warning if three.js does not work in > https://trac.sagemath.org/ticket/26434 since I am touching related code > there anyway. I have not tested this at all but feel free to comment there. > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Poll: set online=True as the default for threejs viewer
I would not mind `online=True` to be the default but apparently there is too much opposition to that. I added a simple warning if three.js does not work in https://trac.sagemath.org/ticket/26434 since I am touching related code there anyway. I have not tested this at all but feel free to comment there. -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Workflows on GitLab
Hello Jeroen, I agree that fragmentation can be a problem. Then again, I think that sometimes splitting discussion on the issue and the discussion on an actual attempt to solve that issue can be useful; at least it doesn't feel unnatural to me. Also being able to create a new merge request can be nice if you actually want to start from scratch. But sure, what you described is much more common: On Wednesday, August 22, 2018 at 9:24:36 PM UTC+2, Jeroen Demeyer wrote: > > [...] Something that regularly happens on the Sage Trac: > > 1. Somebody creates an issue > 2. Somebody (the same or other person) adds a branch > 3. Somebody else forks that branch and adds a reviewer patch > > In the GitHub model, you now have 1 issue and 2 pull requests for > exactly the same issue. Even if cross-links are added, you still end up > with spaghetti discussions. > In most projects, the reviewers are the people who actually have the power to merge and so GitHub/GitLab want you to check "allow edit from maintainers" when creating a Pull/Merge Request to allow reviewer patches. But that won't work for Sage's development model. One way around this would be to encourage creation of Merge Requests from a shared namespace such as https://gitlab.com/sagemath/dev/sage where everybody developing Sage would have push access. This would be somewhat similar to the current public namespace in the git repository that is connected to trac. julian -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Track performance regressions
Hi Travis, I am not sure I understand what you are observing. On Saturday, August 18, 2018 at 5:59:55 AM UTC+2, Travis Scrimshaw wrote: > > Thank you for working towards giving us extra tools to help us prevent > regressions. It is definitely something we can put to good use. However, > the total time it takes to test a file is somewhat of a bad metric > Where does it show the total time for a file for you? Currently, this is always for a block of doctest, i.e., typically all the tests defined by a single docstring. When a docstring changes the old and the new docstring are not going to show up as the same benchmark as the included hash value has then changed. > as adding lots of (sometimes relatively computationally intensive) tests > to a file will make it look like it had a regression, which is the case you > mentioned for Lie algebras (e.g., see > https://trac.sagemath.org/ticket/22883). Perhaps it would be better to > normalize the differences based on the change in the number of doctests, so > when doctests are added, it is less likely to show a large increase. > > For me, the x-axis marks on the graphs are obscured by the top bar, so it > makes it harder to understand what the commits are referring to. > Could you provide me with a screenshot to explain the confusion? The x-axis should be marked with the tags of the 8.3 cycle, i.e., 8.3.beta0 ... 8.3.rc0 ... 8.3. (There is some noise due to some extra docker tags that exist in my local repository.) julian -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Track performance regressions
Hello. At #25262 [1] I am trying to use airspeed velocity (asv) [2] to track performance regressions in Sage. In a first metaclass hack, I had asv benchmark all "long time" doctests in Sage for all the tags between 8.2 and 8.3 (i.e., all the beta and rc versions of 8.3.) I ran this on my laptop computer over the past 48 or so hours. Since I used it for quite some other stuff there is a lot of noise in the data but you might still like to have a look at the result [3]. Strangely, the 8.2 tag did not run so you can't really see 8.2 as a baseline unfortunately. Btw., the tool detected serious regressions in finite_dimensional_lie_algebras_with_basis and classical_lie_algebra. If care about these you might want to double check what happened there. If you think it's a good idea to do this kind of regression tracking or would like to see this being done differently, please join the discussion at #25262 :) julian [1] https://trac.sagemath.org/ticket/25262 [2] https://github.com/airspeed-velocity/asv [3] https://saraedum.github.io/sage/ -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[sage-devel] Re: incorrect behavior of residue for p-adics
I don't think this is a known issue. I created https://trac.sagemath.org/ticket/25879 to track it. Thanks for reporting this :) On Wednesday, July 18, 2018 at 3:59:06 PM UTC+2, srozensz wrote: > Hello, > > I'm running Sage 8.2 and this is what I have observed: > > sage: R = Zp(3,type = 'fixed-mod', prec = 5) > sage: S. = R[] > sage: W. = R.extension(t^2-3) > sage: w.residue() > 1 > > the output here should be 0. > > The bug also appears with ZpCA(3,5) instead of Zp(3,type = 'fixed-mod', > prec = 5), but the output is OK for R = Zp(3,5) > > Is this bug already known? I could not find trace of it. > > Thank you! > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: How parallel should @parallel be?
Thanks for the feedback so far. It seems that there are pros and cons to all of the options. What about the following: We go with the somewhat random min(8, number of threads) and print a warning once if "number of threads" > 8 (telling the user to export SAGE_NUM_THREADS)? Note that this won't affect doctests as SAGE_NUM_THREADS=2 in that context. That way, we provide a good experience for the typical laptop/desktop user and don't risk angry emails from admins after somebody convinced them to install Sage on their shiny server. What do you think? julian PS: I am also fine with "number of threads" as a default. But I am opposed to "1" as that provides a poor experience for the casual user who won't dig into the documentation to find out what's going on. On Monday, July 9, 2018 at 6:35:22 PM UTC+2, Julian Rüth wrote: > > Hello. > > since Sage 8.2 sage.parallel.ncpus.ncpus() returns 1 if you have no > environment variables such as MAKE, SAGE_NUM_THREADS, MAKEOPTS set. > > This number is used by the @parallel decorator and similar constructions > to determine the number of processes to run in parallel. (Unless during > doctests, then it's set to 2 I think.) > > The question is: What is a good default for things such as @parallel when > SAGE_NUM_THREADS has not been set? I think that 1 is not a good one. The > actual number of cores/threads on a system probably isn't either on servers > with lots of cores. At some point we had `min(8, number of threads)` which > appears reasonable to me. > > Please join the discussion at https://trac.sagemath.org/ticket/24937 :) > > julian > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] How parallel should @parallel be?
Hello. since Sage 8.2 sage.parallel.ncpus.ncpus() returns 1 if you have no environment variables such as MAKE, SAGE_NUM_THREADS, MAKEOPTS set. This number is used by the @parallel decorator and similar constructions to determine the number of processes to run in parallel. (Unless during doctests, then it's set to 2 I think.) The question is: What is a good default for things such as @parallel when SAGE_NUM_THREADS has not been set? I think that 1 is not a good one. The actual number of cores/threads on a system probably isn't either on servers with lots of cores. At some point we had `min(8, number of threads)` which appears reasonable to me. Please join the discussion at https://trac.sagemath.org/ticket/24937 :) julian -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: SageMath 8.2 Docker image: pip lacks SSL support
Thanks for reporting this and even providing a workaround :)
You are right, Sage was built with libssl-dev but the final container had
been missing openssl. I fixed it for the 8.2 build and pushed a new image
to the Docker Hub.
julian
On Wednesday, May 16, 2018 at 10:06:54 PM UTC+2, Nathan Dunfield wrote:
>
> Just tried out the latest Sage Docker image and, unlike all previous
> versions, I can no longer use pip to fetch packages off PyPI:
>
> docker run -it sagemath/sagemath:8.2 /bin/bash
> sage@6bf664a266cd:~/sage$ sage -pip install FXrays
> pip is configured with locations that require TLS/SSL, however the ssl
> module in Python is not available.
> Collecting FXrays
> Retrying (Retry(total=4, connect=None, read=None, redirect=None,
> status=None)) after connection broken by 'SSLError("Can't connect to HTTPS
> URL because the SSL module is not available.",)': /simple/fxrays/
> [...]
> Retrying (Retry(total=0, connect=None, read=None, redirect=None,
> status=None)) after connection broken by 'SSLError("Can't connect to HTTPS
> URL because the SSL module is not available.",)': /simple/fxrays/
> Could not fetch URL https://pypi.python.org/simple/fxrays/: There was a
> problem confirming the ssl certificate: HTTPSConnectionPool(host='
> pypi.python.org', port=443): Max retries exceeded with url:
> /simple/fxrays/ (Caused by SSLError("Can't connect to HTTPS URL because the
> SSL module is not available.",)) - skipping
> Could not find a version that satisfies the requirement FXrays (from
> versions: )
> No matching distribution found for FXrays
>
> If I do
>
> sudo apt-get update; sudo apt-get install -y openssl
>
> in the container then pip starts working again. So it looks like Python
> was compiled with SSL support but somehow the openssl module itself gets
> removed somewhere in the process.
>
> Thanks,
>
> Nathan
>
>
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Somebody relying on make micro_release?
Hi, in #24655 I am working on docker images of Sage. One thing I am trying to achieve is to make the images smaller than they currently are. (I am now at 577MB with all doctests passing.) I assume that the `micro_release` target of our Makefile is meant for that purpose: drop everything that is not essential to running Sage. But I am not sure, maybe somebody is using this in their workflow for some other purposes and if I change that target their workflow might break now? If you are currently relying on `micro_release`, please have a look at the proposed changed at https://gitlab.com/saraedum/sage/blob/ci/Makefile#L90 and comment on #25655. cheers, julian -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Inverse of a p-adic matrix fails. Is this a bug?
Hi Simon, Linear Algebra is known to have issues over the p-adics in Sage. The generic algorithms used are mostly unaware of precision issues. Xavier Caruso has been working on improving Sage's Linear Algebra capabilities for example at https://trac.sagemath.org/ticket/23505 and https://trac.sagemath.org/ticket/23450. You might want to raise this issue again on the sage-padics list (https://groups.google.com/forum/#!forum/sage-padics) julian On Tuesday, January 30, 2018 at 4:50:45 PM UTC+1, Simon Brandhorst wrote: > > The following may be a bug or me not understanding p-adic floating point > computations: > > > sage: R = Qp(2,type='floating-point',print_mode='terse') > sage: M = Matrix(R,4,[0, 0, 1, 1, 2^20, 1, 0, 1, 1, 1, 1, 1, 1, 0, 1, 1]) > sage: M.det() > 1048575 > sage: M.inverse() > --- > ZeroDivisionError Traceback (most recent call last > ) > > > ZeroDivisionError: input matrix must be nonsingular > > sage: M = Matrix(R,4,[0, 0, 1, 1, 2^19, 1, 0, 1, 1, 1, 1, 1, 1, 0, 1, 1]) > sage: M.inverse() > [ 1048575201] > [274878955520 5242881 1048575] > [ 524289 5242871 524287] > [274877382656 524289 1048575 524289] > > Works. > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Reworked configure
Hi Erik, I am happy to review your proposed changes and will try to do so today. I have to have a look first to have an opinion about the comments that Jeroen made here and on the ticket. julian On Tuesday, January 30, 2018 at 1:19:45 PM UTC+1, Erik Bray wrote: > > Hi anyone interested in Sage (the distribution's) build system, > > I have a ticket that's been languishing for months now which makes > some significant overhauls to how Sage's build/make/Makefile is > generated and structured: https://trac.sagemath.org/ticket/21524 > I know we're all very busy and that it's a difficult patch to > evaluate, so I haven't been too pushy about trying to get eyes on it. > > But I've been doing some new work (rather successful so far) to > implement a general method for how I can easily add configure-time > checks to use system packages for more of Sage's dependencies, and > I've been doing this work on top of #21524. So if I want to proceed > any further with that work I think progress is needed on this ticket. > > The basic issue is that Sage's old configure.ac contains code in it > for directly writing the Makefile, rather than using a template (a > Makefile.in) per the usual autoconf pattern. Of course, the fact that > we weren't doing that isn't *wrong*--after all there's nothing else > very "standard" about Sage's Makefile--so there was some question as > to why this was worth doing at all. I think my approach to fixing the > issue answers that question: I think the resulting Makefile, and its > template, are easier to understand for one. And the resulting > configure script runs *much* faster. Especially on Cygwin where it has > always been painfully slow, but the speedup is even noticeable on a > fast Linux machine. > > To summarize what this ticket changed: > > 1) The configure.ac template does not contain code that directly > writes the Makefile. Instead, it loops *once* over all the packages > in build/pkgs, classifies them into various categories, and generates > some variables that are easily consumed by make (e.g. a list of > standard packages, and variables containing each package's > dependencies). > > 2) These variables are then inserted into a Makefile template > (Makefile.in) by config.status, at the end of running the configure > script, via the standard AC_OUTPUT mechanism. > > 3) Unlike the old Makefile, neither the new Makefile nor the template > it is generated from contain explicit rules for building each package. > As a result it's actually quite a bit shorter. Instead it uses > relatively advanced features of GNU make (but easy to understand, I > think, especially with the inline comments I've added)--it uses the > variables substituted into the Makefile.in by configure along with > some simple templates and foreach/eval loops to generate the build and > clean rules for each package. > > The result is a more compact Makefile that, for the most part, just > contains some variables with information about the individual > packages, and some templates for generating rules for the packages. > > Most other parts of the Makefile, such as those included from > build/make/deps, remain mostly unchanged for now. > > The resulting configure script is also much faster, as it only loops > over the packages once and performs some relatively simple checks, > since it has much less text to generate. The old configure had a > shell function in it called filtered_packages_list that would loop > over all the packages and filter them according to some criteria, and > the old configure script called this four or five times, which was > responsible for much of the slowness. The new script loops over the > packages only once to generate the variables needed by the Makefile. > > Hopefully this makes sense, and will be of interest to someone. I'm > not 100% married to all the details of my current approach, but I > think the general approach is much cleaner and, as I've noted, faster. > > Best, > E > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] sage-packaging list
Hello. At Sage Days 77 we felt that it would be helpful to have a mailing list for people who package Sage for (Linux) distributions. I created sage-packaging for that purpose. You can join the list here: http://groups.google.com/group/sage-packaging/boxsubscribe?email=myid To post to the list, write to sage-packag...@googlegroups.com. We will of course also invite packagers of sage to join this list. But let's coordinate that on sage-packaging :) julian -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[sage-devel] Re: Docstring-wide "# optional" markup (#20427)
On Monday, April 11, 2016 at 11:43:46 PM UTC+1, Volker Braun wrote: > > IMHO thats terrible; When you copy an example it should either work > or say very clear why it is optional. > I disagree. I remember that when my students saw sage documentation for the first time they did not understand what the `#` were about. (Because they were not aware that they are just comments.) Also, the repetition of these markers is just confusing. Often the just the first line is really about the optional feature. The following lines would work but the object under consideration could not be created. I think that having an "optional" marker at a function level is a very good idea. Of course, copying and pasting such lines should produce a clear error messages. We are working on that… julian -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The Sage dev scripts
* Nathann Cohen nathann.co...@gmail.com [2014-12-26 19:37:55 +0530]: 1) should we keep the Sage dev scripts in Sage ? I regularly use the dev scripts so I would prefer to keep them. I could of course adapt to using git trac instead if they disappeared so this is really only a preference. julian -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. pgpBt7MpjVWMI.pgp Description: PGP signature
Re: [sage-devel] Re: Faster roots computation for Sparse Polynomial
* Bruno Grenet bruno.gre...@gmail.com [2014-06-19 09:21:29 +0200]: Le 17/06/2014 00:01, Julian Rüth a écrit : In your case you would add a method _roots_univariate_polynomial to sage.rings.integer_ring.IntegerRing_class. I have the following problem using this strategy of a _roots_univariate_polynomial method. The new algorithm I add only deals with a very specific case, namely integer roots of integer sparse polynomials. In the method _roots_univariate_polynomial of the IntegerRing_class, what I'd like to do is in some sense to test whether ring=self (that is we want integer roots) and whether the polynomial is sparse, and if it is not the case to call back the roots method. Of course, this would create an endless loop... The other solution is to copy-paste the code of the roots method corresponding to an integer input polynomial into the new IntegerRing_class._roots_univariate_polynomial method. Is this second solution acceptable? My concern is that duplicate code does not seem a very nice idea ;-). It makes sense that _roots_univariate_polynomial can somehow call the generic implementation. If the code that you would copy is specific to integer polynomials, then it should go into _roots_univariate_polynomial() anyway. Otherwise copying it is not such a nice idea. The easiest solution is probably to modify roots() to look at the return value of _roots_univariate_polynomial(): if it is None, run the generic code, otherwise return whatever _roots_univariate_polynomial() computed. julian pgpxSOOhtsrJn.pgp Description: PGP signature
Re: [sage-devel] Re: Faster roots computation for Sparse Polynomial
* Bruno Grenet bruno.gre...@gmail.com [2014-06-16 23:41:31 +0200]: First, I looked for these _roots_univariate_polynomial functions but they do not seem to be defined anywhere (grep -rl _roots_univariate_polynomial SAGE_ROOT/src/sage/ only gives rings/polynomial/polynomial_element.c and rings/polynomial/polynomial_element.pyx). In other words, it does not seem that this functionality is ever used. You are right. It is not used yet. Afaik _roots_univariate_polynomial was introduced together with _factor_univariate_polynomial (which is used in a few places.) It probably helps if you have a look at factor (in sage/rings/polynomial/polynomial_element.pyx) and _factor_univariate_polynomial (e.g. in sage/rings/qqbar.py). The relation of roots and _roots_univariate_polynomial is essentially the same. In your case you would add a method _roots_univariate_polynomial to sage.rings.integer_ring.IntegerRing_class. julian Le 14/06/2014 16:06, leif a écrit : Julian Rüth wrote: Bruno Grenet bruno.gre...@gmail.com [2014-06-12 13:47:59 +0200]: - The algorithm I implemented uses some auxiliary functions that are not of real interest outside the algorithm. How should I do to avoid this functions be available for the users? If you turn these auxiliary functions into methods of the ring Z, you can hide them by adding a single (or double but many people dislike this) underscore to the method name. If they are only used by your method to compute roots, you could probably name these methods _roots_from_factorization_method_name(). ... or make them local to that method, if it's unlikely that they'll be used by other methods in the future. -leif -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. pgpJ640PNgZTj.pgp Description: PGP signature
Re: [sage-devel] Faster roots computation for Sparse Polynomial
Hello Bruno, * Bruno Grenet bruno.gre...@gmail.com [2014-06-12 13:47:59 +0200]: Now comes my question, which is basically: How to introduce this new code into Sage? [...] What I'd like to do is to branch a new algorithm there. So my more specific question: Where should the new algorithm go? A solution may be to have somewhere a specific code for the sparse polynomials over ZZ, and there put a a function roots(self,multiplicities=True) to avoid going into the big roots function from rings/polynomial/polynomial_element.pyx. Since your algorithm is specific to the ring Z your code should probably go there. A ring can define a method _roots_univariate_polynomial() which will be called by the generic method roots(). There you could check whether the polynomial is sparse and use the algorithm you implemented or the generic _roots_from_factorization(). I have side questions, which may improve my code (or my tests): [...] - The algorithm I implemented uses some auxiliary functions that are not of real interest outside the algorithm. How should I do to avoid this functions be available for the users? If you turn these auxiliary functions into methods of the ring Z, you can hide them by adding a single (or double but many people dislike this) underscore to the method name. If they are only used by your method to compute roots, you could probably name these methods _roots_from_factorization_method_name(). julian pgpNzbrQiU2nW.pgp Description: PGP signature
Re: [sage-devel] Re: Unpickling dictionaries with unhashable keys
Thanks for your answers.
* Peter Bruin pjbr...@gmail.com [2014-05-13 01:23:56 -0700]:
Here is my solution to a similar problem in #15158:
def __setstate__(self, state):
The problem is that __setstate__ never gets called because the error
happens earlier, during the unpickling of state.
In other words, if I change DirichletGroup to
sage: class DirichletGroup(object):
: def __setstate__(self, state):
: assert(False) # I never get here
then the assertion is not triggered by loads(s).
julian
Op dinsdag 13 mei 2014 03:16:28 UTC+1 schreef Julian Rüth:
Hello sage-devel,
at #11895 I'm trying to make p-adic numbers unhashable. This works
nicely except for one pickle from the pickle jar that I can't seem to
fix.
The problem is that DirichletGroup_class used to have a dict which uses
p-adic numbers as keys. That dict used to be a cache which is not used
anymore, so dropping it would be no problem. However, I can only drop it
after the dict has been unpickled. But this fails since the unhashable
p-adic numbers can not be used as keys anymore.
Here is a minimal example to illustrate the problem:
sage: class DirichletGroup(object): pass
sage: class pAdicNumber(object): pass # the old hashable p-adic number
sage:
sage: G = DirichletGroup()
sage: G._cache = { pAdicNumber() : 0 }
sage: s = dumps(G)
sage:
sage: class pAdicNumber(object):
: __hash__ = None # now p-adics are not hashable anymore
:
sage: loads(s)
TypeError: unhashable type: 'pAdicNumber'
Any ideas how I could influence the unpickling so that the string s can
be unpickled with the _cache dropped in this example?
Thanks,
julian
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
pgpFAtdO_YJTN.pgp
Description: PGP signature
Re: [sage-devel] Re: Unpickling dictionaries with unhashable keys
Hello Peter,
* Peter Bruin pjbr...@gmail.com [2014-05-13 07:05:43 -0700]:
OK, I see the problem. It seems that it is not unique to DirichletGroup,
but is more general:
sage: class pAdicNumber(object): pass
sage: d = { pAdicNumber(): 0 }
sage: s = dumps(d)
sage: pAdicNumber.__hash__ = None
sage: loads(s)
...
TypeError: unhashable type: 'pAdicNumber'
For all we know, old pickles everywhere (e.g. on people's computers, not in
the pickle jar) may contain dictionaries where p-adic numbers are used as
keys. What to do about this? It sounds a bit drastic to generally change
unpickling of dictionaries so that keys whose type is unhashable are
silently dropped.
I agree. We probably want to be able to unpickle these old dictionaries.
Btw. you can not use an override to change the unpickling of dicts.
Do we have to create special hashable subclasses of
previously-hashable-but-now-unhashable types?
That could be an option. It is not pretty but I don't see a better
solution. We would have subclasses of all unhashable types which are
hashable and print some deprecation warning if their __hash__ is called.
If unhashable p-adics and hashable p-adics mix in a @cached_method
probably strange things will happen but at least we printed a warning
and told the user how to upgrade the old p-adics.
I'll try to implement something along these lines in #11895.
Thanks for the input,
julian
pgpjnNwm871aS.pgp
Description: PGP signature
[sage-devel] Unpickling dictionaries with unhashable keys
Hello sage-devel,
at #11895 I'm trying to make p-adic numbers unhashable. This works
nicely except for one pickle from the pickle jar that I can't seem to
fix.
The problem is that DirichletGroup_class used to have a dict which uses
p-adic numbers as keys. That dict used to be a cache which is not used
anymore, so dropping it would be no problem. However, I can only drop it
after the dict has been unpickled. But this fails since the unhashable
p-adic numbers can not be used as keys anymore.
Here is a minimal example to illustrate the problem:
sage: class DirichletGroup(object): pass
sage: class pAdicNumber(object): pass # the old hashable p-adic number
sage:
sage: G = DirichletGroup()
sage: G._cache = { pAdicNumber() : 0 }
sage: s = dumps(G)
sage:
sage: class pAdicNumber(object):
: __hash__ = None # now p-adics are not hashable anymore
:
sage: loads(s)
TypeError: unhashable type: 'pAdicNumber'
Any ideas how I could influence the unpickling so that the string s can
be unpickled with the _cache dropped in this example?
Thanks,
julian
pgp_3_LNMXzGK.pgp
Description: PGP signature
Re: [sage-devel] Re: Sage library license
* William Stein wst...@gmail.com [2014-02-24 11:34:25 -0800]: Thus I find no code in the core Sage library that is GPLv3(+). I found these three matches: $ grep -r version 3 . ./schemes/toric/points.py:# as published by the Free Software Foundation; either version 3 of ./rings/number_field/splitting_field.py:# the Free Software Foundation, either version 3 of the License, or ./libs/readline.pyx:# as published by the Free Software Foundation; either version 3 of julian pgpWY4XL4lYBu.pgp Description: PGP signature
Re: [sage-devel] Re: Sage library license
* Volker Braun vbraun.n...@gmail.com [2014-02-24 12:20:43 -0800]: IMHO GPLv3+ is the recommended license by the FSF. What exactly is there to fix? In many places we have GPLv2 (without the +). GPLv3+ is incompatible with GPLv2 (http://gplv3.fsf.org/wiki/index.php/Compatible_licenses). julian pgpjF7vfst4ln.pgp Description: PGP signature
Re: [sage-devel] Re: Sage library license
* Jeroen Demeyer jdeme...@cage.ugent.be [2014-02-24 21:37:23 +0100]: On 2014-02-24 21:32, Julian Rüth wrote: In many places we have GPLv2 (without the +) I hope not, that would be a big problem. You're right. But there are actually a few: plot/plot3d/transform.pyx combinat/words/words.py combinat/words/word_options.py combinat/words/word_infinite_datatypes.py combinat/words/word_generators.py combinat/words/word_datatypes.pyx combinat/words/word.py combinat/words/suffix_trees.py combinat/words/paths.py combinat/words/notes/word_inheritance_howto.txt combinat/words/morphism.py combinat/words/infinite_word.py combinat/words/finite_word.py combinat/words/alphabet.py combinat/words/abstract_word.py julian pgpc4elJD9xHx.pgp Description: PGP signature
Re: [sage-devel] Re: Sage library license
* Volker Braun vbraun.n...@gmail.com [2014-02-24 13:15:25 -0800]: Did you open a ticket for that? Not yet. I do not have access to trac from this machine. I can create a ticket later today. julian pgpjxOBzubZ8e.pgp Description: PGP signature
Re: [sage-devel] Re: Sage library license
* Julian Rüth julian.ru...@fsfe.org [2014-02-24 22:28:37 +0100]: * Volker Braun vbraun.n...@gmail.com [2014-02-24 13:15:25 -0800]: Did you open a ticket for that? Not yet. I do not have access to trac from this machine. I can create a ticket later today. This is now http://trac.sagemath.org/ticket/15858 julian pgpB7EdVu_6kX.pgp Description: PGP signature
Re: [sage-devel] Re: Motivation for ElementMethods in categories
Hello Simon, * Simon King simon.k...@uni-jena.de [2013-09-14 19:59:38 +]: On 2013-09-14, Peter Bruin pjbr...@gmail.com wrote: - Do the methods coming from ElementMethods always take priority over (override) those from the base classes? No, it is the other way around. True, and anything else would be extremely confusing. However, this is the actual problem with Fields.ElementMethods.is_unit(): RingElement defines is_unit(), so if an element inherits from RingElement it will never use that method. Clearly, in the case of residue fields we can change them to inherit from FieldElement but more generally, would it not make sense to move RingElement.is_unit() to Rings.ElementMethods.is_unit()? Since any RingElement's parent will be in the category of Rings anyway the ring elements will still have their is_unit() but if it turns out that we are in a field, then they get a better is_unit(). Or is there a scenario where the parent of a RingElement is not in Rings()? julian pgpHISt4hQVqk.pgp Description: PGP signature
Re: [sage-devel] Re: Motivation for ElementMethods in categories
* Simon King simon.k...@uni-jena.de [2013-09-16 11:50:35 +]: On 2013-09-16, Julian Rüth julian.ru...@fsfe.org wrote: True, and anything else would be extremely confusing. However, this is the actual problem with Fields.ElementMethods.is_unit(): RingElement defines is_unit(), so if an element inherits from RingElement it will never use that method. Sadly yes. Or is there a scenario where the parent of a RingElement is not in Rings()? The parent of RingElement can be *anything*, the type or the category of the parent is not tested when an element is created. But at least it is the case that any sage.rings.ring.Ring instance is in Rings()---provided that its __init__() is called. Sadly, there are some classes that don't call __init__() of their base classes, IIRC. So in the (very strange) case that the parent of a RingElement() is not in Rings(), then the implementation of is_unit() probably does not make any sense anyway, right? So, is there any problem with removing is_unit() from RingElement() and adding it to Rings.ElementMethods? I can not see where this would cause a problem. julian pgpFRHEvwxLOi.pgp Description: PGP signature
Re: [sage-devel] Re: absolute value in a p-adic quotient field
This is http://trac.sagemath.org/sage_trac/ticket/13662 julian * Frédéric Chapoton fchapot...@gmail.com [2013-07-11 02:11:24 -0700]: Well, the problem comes from a.matrix() which does not work. This is because it receives an incorrect number of terms, so it cannot build the matrix. In turn, this is because the length of (a**i).list() depends on i, which is maybe unexpected. I have not tried to look further. Frederic Le mercredi 10 juillet 2013 23:49:54 UTC+2, Paul Mercat a écrit : If I define 'a' like this: R.x=PolynomialRing(Qp(2)); P=2*x^2+1; K.a=P.root_field(); why 'a' has no attribute abs ? It's not a big problem, because it's easy to compute the absolute value from the norm, but it don't work : a.norm() gives TypeError: cannot construct an element of Full MatrixSpace of 2 by 2 dense matrices over 2-adic Field with capped relative precision 20 from [0, 1 + O(2^20), 2^-1 + 1 + 2 + 2^2 + 2^3 + 2^4 + 2^5 + 2^6 + 2^7 + 2^8 + 2^9 + 2^10 + 2^11 + 2^12 + 2^13 + 2^14 + 2^15 + 2^16 + 2^17 + 2^18 + O(2^19), 0, O(2^20)]! Somebody knows why this don't work ? -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out. pgpYzHCAXSDn2.pgp Description: PGP signature
Re: [sage-devel] proposal: make the Sage build system more distribution friendly
* Felix Salfelder fe...@salfelder.org [2013-04-22 13:01:20 +0200]: On Mon, Apr 22, 2013 at 03:15:54AM -0700, Timo Kluck wrote: We're trying to replace the current spkg system (actually the spkg system like it exists in the git repo) by some version of Gentoo's portage. This would be similar to the lmonade project, except that it's trying to be a smooth transition from the current source distribution. are you targeting sage-upstream or is this a local hack that is doomed to fail some releases (and several git-transitions) later? We're targeting sage/git upstream. As soon as this works, then it would be possible to use this to generate debian packages, since portage keeps track of installed binary files for packages. So the debian/rules file could query portage for which files should go into which binary package. the goal of the/my gsoc project would be streamlining the packaging of debian/gentoo/whatever packaging process. having to use an extra layer (portage), makes things worse. no debian maintainer i can think of would seriously use it. You don't have to use portage. If all spkgs are debian packages, then there is no point in using portage since you won't be using any spkgs anyway. You could of course use it as part of the build process and unmerge portage in a final step to remove it again. PS: i don't want to make your work obsolete, but it's obviously too gentoo centric I don't believe it is gentoo centric. Actually, I'm not even using gentoo myself anymore. The current SPKG approach has its problems, especially with the new git layout. One main problem being that you cannot uninstall an SPKG when you switch to a branch where it is not present. That's where we want to use portage. I at least don't think of portage here as a distribution system, but just as a tool to configure/install/uninstall things in a local prefix. julian signature.asc Description: Digital signature
Re: [sage-devel] SAT and MAXSAT in Sage
The author of akmaxsat is a good friend of mine. He was excited to hear that an interface to his solver might be added to Sage. So if you need any additional interface in akmaxsat, he should be able to do something about it. If you start writing a wrapper, please CC me (saraedum) on the ticket — I'd like to help to such efforts. julian * Dima Pasechnik dimp...@gmail.com [2012-05-01 09:07:51 +]: Has there been any discussion and/or consensus on how to encode boolean formulae in Sage? I, incidentally, need to solve some MAXSAT problems from Sage-generated data, and am musing about writing a proper interface to akmaxsat, see http://www.uni-ulm.de/fileadmin/website_uni_ulm/iui.inst.190/Mitarbeiter/kuegel/akmaxsat_1.1.tgz which has a Sage-compatible licence, by the way... Dima -- 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 URL: http://www.sagemath.org -- 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 URL: http://www.sagemath.org
Re: [sage-devel] Rational Extension Representation for function fields
I already have some code that does that for function fields. I just have not turned it into a sage patch yet. I'll CC you on the ticket for this. julian * syd.lavas...@gmail.com syd.lavas...@gmail.com [2011-12-20 00:59:53 -0800]: I think it is essential (speaking priority) to have a parallel to Magam RationalExtensionRepresentation(F) : FldFunG - FldFun The function field F represented as an extension of a rational function field. This function gives the representation of function fields F/k as finite extensions. This basically collapses the extension tower to one extension. It significantly speeds up any computation which happens at the top of the tower. If sage has such a method for number fields, it should be fairly straight forward to recycle for the function field class. Does anybody knows if we have such a method for number fields? -- 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 URL: http://www.sagemath.org -- 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 URL: http://www.sagemath.org
Re: [sage-devel] The status of function field development
Hi Syd, * Jeroen Demeyer jdeme...@cage.ugent.be [2011-11-16 14:36:24 +0100]: On 2011-11-16 09:12, syd.lavas...@gmail.com wrote: (Should I write directly to William Stein). Probably not, sage-devel is the right place to ask. Or also, the comment section on http://trac.sagemath.org/sage_trac/ticket/9054 I'm not sure if this could be relevant to you, but I use a number of (dirty) patches related to iterated extensions and isomorphisms of function fields. Now that #9054 seems to be stable I should probably turn these into actual tickets...I might do so in the next few days and add pointers to them at #9054. I never used magma so I don't know what their function fields can do, but if you have any specific questions or stumble on any problems feel free to contact me (saraedum) in the #sagemath IRC channel. (http://www.sagemath.org/help-irc.html) cheers, julian -- 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 URL: http://www.sagemath.org
Re: [sage-devel] help needed with making FreeModule_generic_pid work with generic pid's
Maarten and I discussed this issue in a chat yesterday and it seems that we've found the source of the problem (described in the ticket). I'm working on a fix now. julian * Maarten Derickx m.derickx.stud...@gmail.com [2011-08-31 19:58:52 -0700]: At http://trac.sagemath.org/sage_trac/ticket/11751 I try to fix some problems with FreeModule_generic. I've put a patch up there wich makes the code work wich I want to work (only very small changes where needed, since it is just fixing some bugs in the code wich is already there). The only problem is that the my changes make other doctests not work. I've been trying to find the source of the problem for some time now but fail miserably. I hope there is someone here willing to help me out. The main goal why I want that ticket to work is to finally get the function fields code into sage. For that we need to do calculation in free modules over univariate polynomial rings over fields. The patch there makes this possible (as shown in the description) of the patch. Thanks in advance, BTW, sorry for the large ammount of messages from me lately, but I just want to do a lot of sage stuff before college starts again. -- 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 URL: http://www.sagemath.org -- 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 URL: http://www.sagemath.org
Re: [sage-devel] Re: profiling Sage startup
* William Stein wst...@gmail.com [2011-08-12 11:30:21 -0700]:
On Fri, Aug 12, 2011 at 10:05 AM, Julian Rüth julian.ru...@gmail.com wrote:
I'm not sure if this discussion has been picked up in a different thread
since February but the problem with zipimport seems to be that it can't load
.so files. Since we have plenty of them, just loading the .py files from a
zip file and the .so files from the file system might not be such a big
improvement anymore.
To address the problem with high latency filesystems why don't we unzip a
file containing all of site-packages/sage to some directory in /tmp and
import everything from there?
That might be interesting to try. Can you give it a shot and report back?
Starting sage from a (relatively responsive) nfs filesystem here takes about
2 seconds:
$ time ./sage --startuptime /dev/null
real0m2.012s
user0m0.741s
sys 0m0.283s
Unzipping a zip-file (200M) containing site-packages/sage to /tmp/ already
takes a while:
$ time unzip sage.zip -d /tmp/sage_zip /dev/null
real0m1.236s
user0m0.881s
sys 0m0.316s
Starting sage using the site-packages directory in /tmp/ is then
somewhat faster than before:
$ time ./sage --startuptime /dev/null
real0m1.223s
user0m0.759s
sys 0m0.178s
In total it is no improvement if I do the unzip on every start of sage.
I'm not sure how much latency some people are experiencing - the nfs I
have here seems to be quite responsive anyway.
Maybe someone with an nfs that is causing more trouble could give this a
try?
Btw moving all sage to /tmp/ doesn't make that much of a difference:
$ cd /tmp/sage
$ time ./sage --startuptime /dev/null
real0m1.028s
user0m0.829s
sys 0m0.151s
cheers,
julian
-- William
julian
On Wednesday, February 23, 2011 10:47:14 PM UTC+1, jason wrote:
On 2/23/11 3:06 PM, Robert Bradshaw wrote:
On Wed, Feb 23, 2011 at 11:34 AM, William Steinwst...@gmail.com wrote:
On Wed, Feb 23, 2011 at 10:57 AM, Jason Grout
jason...@creativetrax.com wrote:
On 2/23/11 12:28 PM, William Stein wrote:
At lunch yesterday Robert Bradshaw made the interesting suggestion to
read the docs for importlib
(http://docs.python.org/dev/library/importlib.html) and write a
customized import hook, so that every time during Sage startup that a
module is imported, the import is done from a single big in-memory zip
file instead of done using the filesystem. If this can be made to
work, it would be a huge win for slow filesystems. The basic problem
is that some filesystems are fast but have huge*latency*.
Is it a big win primarily because the zip file contents can be read in
and
cached by us? I'm just trying to understand it better.
Which would you rather do on a high latency filesystem:
(1) Read/stat 20,000 little files, or
(2) Read exactly one 40MB file.
Is this the same idea as Jar files in java?
I don't know.
Yep. In that case the high latency file system was a webserver.
You mean like http://docs.python.org/library/zipimport.html ?
Cool.
Note that this should just involve putting the zip file first in the
python path.
I don't know for a fact that Robert Bradshaw's suggestion will be a
big win, since nobody has tried this yet. But I'm optimistic. The
idea would be to make a zip archive of
$SAGE_ROOT/local/lib/python/site-packages (say), and do *all* imports
using that massive zip archive.
I'm optimistic too. This would, of course, make more sense for
system-wide installs than development versions, but the former are
more likely to be on a non-local filesystem anyways.
Sounds like it is time for a trial!
I created a directory of 2000 .py files and an __init__.py file to make
it a module
for i in range(2000):
with open('importtest/test_%s.py'%i,'w') as f:
f.write(VALUE=%s\n%i)
with open('importtest/__init__.py','w') as f:
f.write(' ')
Then I imported each of these so that .pyc files were created.
for i in range(2000):
exec 'import importtest.test_%s'%i
Okay, then I copied the directory and zipped it up (in the shell now):
$ cp -r importtest zipimporttest
$ zip -r tmp.zip zipimporttest
$ rm -rf zipimporttest
One nice side effect is that the zip file is less than one MB, while the
directory of python files is around 16M.
Now for the test. Here are my two scripts. One imports each module in
the directory and adds up the VALUE in each module:
% cat mytest.py
s=0
for i in range(2000):
exec 'import importtest.test_%s as tt'%i
s+=tt.VALUE
print s
The other first adds the zip to the front of sys.path and then does the
same imports and summing, but using the zipped module:
% cat mytestzip.py
import sys
sys.path.insert(0,'./tmp.zip')
s=0
for i in range(2000):
exec 'import zipimporttest.test_%s as tt'%i
s+=tt.VALUE
print s
And now for the timings:
% time sage -python mytest.py
Detected
[sage-devel] Re: profiling Sage startup
I'm not sure if this discussion has been picked up in a different thread
since February but the problem with zipimport seems to be that it can't load
.so files. Since we have plenty of them, just loading the .py files from a
zip file and the .so files from the file system might not be such a big
improvement anymore.
To address the problem with high latency filesystems why don't we unzip a
file containing all of site-packages/sage to some directory in /tmp and
import everything from there?
julian
On Wednesday, February 23, 2011 10:47:14 PM UTC+1, jason wrote:
On 2/23/11 3:06 PM, Robert Bradshaw wrote:
On Wed, Feb 23, 2011 at 11:34 AM, William Steinwst...@gmail.com wrote:
On Wed, Feb 23, 2011 at 10:57 AM, Jason Grout
jason...@creativetrax.com wrote:
On 2/23/11 12:28 PM, William Stein wrote:
At lunch yesterday Robert Bradshaw made the interesting suggestion to
read the docs for importlib
(http://docs.python.org/dev/library/importlib.html) and write a
customized import hook, so that every time during Sage startup that a
module is imported, the import is done from a single big in-memory zip
file instead of done using the filesystem. If this can be made to
work, it would be a huge win for slow filesystems. The basic problem
is that some filesystems are fast but have huge*latency*.
Is it a big win primarily because the zip file contents can be read in
and
cached by us? I'm just trying to understand it better.
Which would you rather do on a high latency filesystem:
(1) Read/stat 20,000 little files, or
(2) Read exactly one 40MB file.
Is this the same idea as Jar files in java?
I don't know.
Yep. In that case the high latency file system was a webserver.
You mean like http://docs.python.org/library/zipimport.html ?
Cool.
Note that this should just involve putting the zip file first in the
python path.
I don't know for a fact that Robert Bradshaw's suggestion will be a
big win, since nobody has tried this yet. But I'm optimistic. The
idea would be to make a zip archive of
$SAGE_ROOT/local/lib/python/site-packages (say), and do *all* imports
using that massive zip archive.
I'm optimistic too. This would, of course, make more sense for
system-wide installs than development versions, but the former are
more likely to be on a non-local filesystem anyways.
Sounds like it is time for a trial!
I created a directory of 2000 .py files and an __init__.py file to make
it a module
for i in range(2000):
with open('importtest/test_%s.py'%i,'w') as f:
f.write(VALUE=%s\n%i)
with open('importtest/__init__.py','w') as f:
f.write(' ')
Then I imported each of these so that .pyc files were created.
for i in range(2000):
exec 'import importtest.test_%s'%i
Okay, then I copied the directory and zipped it up (in the shell now):
$ cp -r importtest zipimporttest
$ zip -r tmp.zip zipimporttest
$ rm -rf zipimporttest
One nice side effect is that the zip file is less than one MB, while the
directory of python files is around 16M.
Now for the test. Here are my two scripts. One imports each module in
the directory and adds up the VALUE in each module:
% cat mytest.py
s=0
for i in range(2000):
exec 'import importtest.test_%s as tt'%i
s+=tt.VALUE
print s
The other first adds the zip to the front of sys.path and then does the
same imports and summing, but using the zipped module:
% cat mytestzip.py
import sys
sys.path.insert(0,'./tmp.zip')
s=0
for i in range(2000):
exec 'import zipimporttest.test_%s as tt'%i
s+=tt.VALUE
print s
And now for the timings:
% time sage -python mytest.py
Detected SAGE64 flag
Building Sage on OS X in 64-bit mode
1999000
sage -python mytest.py 0.26s user 1.47s system 75% cpu 2.282 total
% time sage -python mytestzip.py
Detected SAGE64 flag
Building Sage on OS X in 64-bit mode
1999000
sage -python mytestzip.py 0.21s user 0.11s system 99% cpu 0.327 total
It looks like the zip is a clear winner in this case. And this is with
the directory presumably in the FS cache.
Thanks,
Jason
--
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
URL: http://www.sagemath.org
