Re: [sage-devel] Unreasonably slow piecewise function

On Thu, 2024-05-02 at 02:13 -0700, Kwankyu Lee wrote: > Moreover, this case seems to spur the need to introduce timing tests to > watch out regressions in code performance without a failure. > Shameless plug: https://github.com/sagemath/sage/pull/36226 I see these regressions (old

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On 2024-04-20 15:33:51, Matthias Koeppe wrote: > Michael, I think you may be using too much jargon to get your point across > to the general readership of this list. > > Let's maybe use this opportunity to make this as concrete as possible and > explain it in the most plain terms. > What

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Sat, 2024-04-20 at 15:01 -0700, kcrisman wrote: > > Can someone who is not Dima or Matthias explain to us how it is possible > that they both are claiming to represent the normal Python way of doing > things? There have been numerous statements by both of them about this, > which makes it

Re: [sage-devel] On backdooring open source projects

On Sat, 2024-04-20 at 12:53 -0700, Emmanuel Charpentier wrote: > > Do we have the manpower necessary to such development ? . Linux distributions (or e.g. Conda) already do it for us. What we don't have is the manpower to do what we currently do, but *correctly*. The sage distribution sucks.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Sat, 2024-04-20 at 10:07 +0100, Dima Pasechnik wrote: > > Apart from Lisp, there is GAP (with the corresponding effort stalled). > > That's what is much more urgent than attempting to slice up the maths > functionality of sagelib. > Also the ancient copy of ginac/pynac we bundle. -- You

Re: [sage-devel] Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Sat, 2024-04-20 at 02:22 -0700, Volker Braun wrote: > Yes in a perfect world, but then you don't get a gold star for satisfying > some purity test. We should just do the minimal amount of work to get us > where we want to be. Lets focus on the direction to go and not too much on > the

Re: [sage-devel] Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Fri, 2024-04-19 at 09:46 -0700, Matthias Koeppe wrote: > > Michael, note that in my message I asked for a vote on that dependency > https://github.com/sagemath/sage/pull/36676. > Even if 36676 gets approval, 36964 must be reverted. It was not meaningfully voted upon. -- You received this

Re: [sage-devel] On backdooring open source projects

On 2024-04-18 16:04:43, Lorenz Panny wrote: > > > > It's also 214 software packages which might, for all we know, at any > > time be hijacked by The Bad Guys to run arbitrarily malicious code on > > every Sage user's machine. > > > > This is terrifying. 276 now -- You received this message

Re: [sage-devel] Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On 2024-04-18 14:18:37, Matthias Koeppe wrote: > Dear all: > > As an alternative to the proposal to back out the > PR https://github.com/sagemath/sage/pull/36964 whose *disputed dependency > PR https://github.com/sagemath/sage/pull/36676 which had not reached the > required 2:1 supermajority

Re: [sage-devel] VOTE: Revert merged PR with unreviewed dependencies

On Thu, 2024-04-18 at 11:54 -0400, David Roe wrote: > I am therefore asking you to vote (+1 means merge #37796 > in order to revert #36964 > ). +1 -- You received this message because you are subscribed

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

On 2024-04-15 04:20:59, kcrisman wrote: > > The real question is about *users* in this case, not developers. The solution for users is pretty simple. You should be able to install a sage that works and will remain working with one command using homebrew, conda, guix, etc. The reason you can't is

Re: [sage-devel] Re: xz/liblzma has been compromised

On 2024-03-30 07:08:45, Marc Culler wrote: > > Potentially, any tarfile we host may contain an exploit. > > Potentially, any file may contain an exploit. > > This hack specifically targeted ssh. When used by ssh to verify keys, the > hacked liblzma would validate certain invalid keys,

Re: [sage-devel] No MathJax display in Sage 10.3.beta notebooks when offline

On Thu, 2024-02-15 at 13:13 -0800, Nils Bruin wrote: > According to the jupyter notebook documentation: > > https://jupyterbook.org/en/stable/content/math.html > > it should be possible to switch jupyter from using mathjax 2 to mathjax 3 > by some configuration option (no clue where those

Re: [sage-devel] One year of Sage development on GitHub

On Thu, 2024-02-08 at 11:30 +, Dima Pasechnik wrote: > > We should not try to compete, in effect, with Conda etc, yet we do. This is > the primary reason for slowness. > My personal stats for the year 2023-02-08 through 2024-02-08: Commits: 423 Reviews: 38 Zero of those have anything

Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages

On Sat, 2024-01-13 at 14:54 +0530, Niranjana K M wrote: > > I thought the installation would replace the previous builds when new > system packages are available. It is preferring old local spkg installs, if > already present, than new versions in system. But if it is spkg only it is > going for

Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages

On Fri, 2024-01-12 at 09:25 -0800, Niranjana K M wrote: > Should I have had started by cleaning the previous builds? It may be still > using old Cython spkg, built when it was sage 10.0 release. Because in venv > site-packages, it still says >

Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages

On Fri, 2024-01-12 at 08:33 -0500, Michael Orlitzky wrote: > > One thing I noticed is that you said "master" branch. Please try the > "develop" branch instead -- that's where the actual development takes > place. Both Sage and Gentoo are fast-moving and you'll ha

Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages

On Fri, 2024-01-12 at 18:24 +0530, Niranjana K M wrote: > It is attached in the previous mail. > Indeed, sorry, it was my first email of the day. I have to get warmed up first. One thing I noticed is that you said "master" branch. Please try the "develop" branch instead -- that's where the

Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages

On Thu, 2024-01-11 at 20:56 -0800, Niranjana K M wrote: > > I am running on Gentoo Linux and sagemath is from git master branch. > I am having system cython-3.0.6 built on python-3.11.7. > > Please help me to resolve it. > Can you post your config.log? -- You received this message because

Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

On Wed, 2024-01-10 at 06:49 -0800, William Stein wrote: > Dear Sage Developers, > > 1. There are over 20 pull requests labeled as "disputed" [1]. To > resolve these pull requests, we will be appointing an editor with no > direct involvement in the pull request to make a judgement call on > that

Re: [sage-devel] Unable to compile JuPiMake

On Wed, 2023-12-20 at 16:42 +0100, Salvatore Stella wrote: > > Did you build polymake with USE=libpolymake? > > I did, before I did not and sage build system refused to use my system's > polymake. > Hm, my next guess is then https://github.com/sebasguts/JuPyMake/issues/4 since I think

Re: [sage-devel] Unable to compile JuPiMake

On Wed, 2023-12-20 at 16:13 +0100, Salvatore Stella wrote: > > I have polymake 4.11 installed through my system package manager (gentoo) and > I am using gcc 13.2.1. The same issue happens if I try to install JuPiMake > though the sage build system, using pip through PyPi in a virtualenv, and

[sage-devel] Removing Cygwin support

We dropped Cygwin support in September 2022, https://github.com/sagemath/sage/wiki/Sage-9.7-Release-Tour but that was mainly a documentation change reflecting the fact that Cygwin support had bit-rotted. Anyone could have fixed it at that point -- or in the meantime -- but no one has done so.

Re: [sage-devel] Pillow built without jpeg support in Sage 10.2.rc3

On Fri, 2023-11-17 at 10:49 -0800, Marc Culler wrote: > I expect to receive lots of flak for saying this, but I support making > libjpeg be a standard spkg using the source code from > https://libjpeg.sourceforge.net. I just built version jpeg-9e on Ubuntu > 18.04 and macOS 10.13. The

Re: [sage-devel] Pillow built without jpeg support in Sage 10.2.rc3

On Fri, 2023-11-17 at 17:26 +, Dima Pasechnik wrote: > > Why can't Features be set up by ./configure ? You'll tell me that > (some) distributions don't run ./configure, but this is beside the > point. > They have ways to know what's installed and what's not installed. > I think the problem

Re: [sage-devel] Pillow built without jpeg support in Sage 10.2.rc3

On Fri, 2023-11-17 at 02:33 -0800, Eric Gourgoulhon wrote: > On 17 November 2023 04:35:53 GMT, Matthias Koeppe > wrote: > > Or we just let pillow use a system libjpeg if it finds one. > > This would probably be the easiest solution: I cannot imagine a system > without libjpeg... I don't know

Re: [sage-devel] Pillow built without jpeg support in Sage 10.2.rc3

On Thu, 2023-11-16 at 06:48 -0800, Eric Gourgoulhon wrote: > > If we agree to restore jpeg support in Pillow, I have prepared a branch > that does this for Sage 10.2 (simply suppressing the option "jpeg=disable"): > https://github.com/egourgoulhon/sage/tree/pillow_jpeg > and I am happy to submit

Re: [sage-devel] eclib dependencies

On 2023-11-16 09:23:15, John Cremona wrote: > > If no-one has any reason to keep things as they are I will make a PR with > the relevant changes to build/pkgs/eclib. >From a packaging standpoint, fewer dependencies is better. For example, upgrading flint would become a tiny bit easier if we

Re: [sage-devel] Re: Cython errors when building p_group_cohomology

On 2023-11-16 00:51:12, Dima Pasechnik wrote: > This package produces mathematically incorrect results, as was shown > on a trac ticket a couple of years ago, and no movement then. Demote > to experimental? There's not much distinction at this point, but if we're going by the "builds on supported

Re: [sage-devel] Re: Question about make dependencies

On 2023-11-14 23:44:50, Dima Pasechnik wrote: > I have not invented the verb "to vendor" Don't worry, you are in good company: https://www.gocomics.com/calvinandhobbes/1993/01/25 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe

Re: [sage-devel] Re: Question about make dependencies

On Tue, 2023-11-14 at 09:42 -0800, Marc Culler wrote: > Of course I meant that I have to wait for everything that *depends on* gmp > to be recompiled. Also, this happens when there is nothing wrong with the > gmp build. The make system decides that it is out of date even though the > build

Re: [sage-devel] Fedora sagemath package maintainer

On Sat, 2023-09-30 at 14:36 -0700, enriqu...@gmail.com wrote: > I have learnt that at this momente there is no Fedora sagemath package > maintainer. I am a Fedora user but I do not use the rpm package; more > relevant, I do not have the skills for this maintenance. > Would anyone take the task?

Re: [sage-devel] Poll: deprecate backslash operator

On Sat, 2023-09-30 at 14:47 -0700, John H Palmieri wrote: > > This is not used much: for matrices, matroids, and a tiny bit (at least in > the Sage library) for binary trees. Should we deprecate it? Deprecate it, it's a big WTF for most people. -- You received this message because you are

Re: [sage-devel] Discussion and poll: should Sage Integers have a backslash operator?

On Wed, 2023-09-27 at 14:44 -0700, Nils Bruin wrote: > Searching the codebase currently only shows "_backslash_" implemented on > matroid, matrix, and binary_tree, so extinguishing it should be doable. We > should definitely not entrench its use further. > > If you want to write your

Re: [sage-devel] @options() decorators in sagemath library code and Sphinx 7.1+

On 2023-09-16 14:09:04, Dima Pasechnik wrote: > > Anyhow, if this is the only problem with upgrading to Sphinx 7.1+ (or 8) > it ought to be fixed, so that we can move on on Sphinx update. > (see https://github.com/sagemath/sage/pull/35658) My vote would be to replace the weird sageism with the

Re: [sage-devel] @options() decorators in sagemath library code and Sphinx 7.1+

On Sat, 2023-09-16 at 13:16 +0100, Dima Pasechnik wrote: > Isn't it true that the above may be simplified, removing foo=bar from > @options() and putting this in the function definition, i.e. > AFAIK it's just dictionary unpacking that happens by default. You can already create your own options

Re: [sage-devel] pull requests recently updated

On Wed, 2023-08-23 at 01:36 -0700, 'Martin R' via sage-devel wrote: > > Is there a way to fix this? > Now's an OK time to stop adding meaningless milestones to every open ticket. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe

Re: [sage-devel] why sagemath creates so many file in TMPDIR and how to prevent this?

On Tue, 2023-08-15 at 08:09 -0700, 'Nasser M. Abbasi' via sage-devel wrote: > Here is the basic flow of the script: (this is not the real script but > a stripped down version) > For now at least, initializing the sage library creates one directory under /tmp where all of sage's other temporary

Re: [sage-devel] why sagemath creates so many file in TMPDIR and how to prevent this?

On Tue, 2023-08-15 at 03:33 -0700, 'Nasser M. Abbasi' via sage-devel wrote: > Each time I run a sagemath script, I see 10's of thousands of files created > in my TMPDIR which I have to keep manually deleting. There aren't too many parts of sage that use temporary files. What's the script doing?

Re: [sage-devel] Re: How to use maxima 5.47 with sagemath 10.1 beta?

On 2023-07-15 19:05:42, 'Nasser M. Abbasi' via sage-devel wrote: > Maxima uses SBCL lisp: > > >maxima > Maxima 5.47.0 https://maxima.sourceforge.io > using Lisp SBCL 2.3.3 > > Are there any step-by-step instructions then how to make sagemath 10.1 use > maxima 4.7? > Not really. You need

Re: [sage-devel] Re: How to use maxima 5.47 with sagemath 10.1 beta?

On 2023-07-15 18:56:09, Nils Bruin wrote: > It must be maxima running on ECL and there must be a > maxima.fas lisp package for ecl (which isn't built in the vanilla maxima > build). That part is finally upstream in maxima-5.47. -- You received this message because you are subscribed to the

Re: [sage-devel] Memory leak (quite bad)

On 2023-07-06 09:16:46, Nils Bruin wrote: > > On Wednesday, 5 July 2023 at 08:29:44 UTC-7 Edgar Costa wrote: > > > > Hi Gonzalo, > > > > I highly recommend using https://github.com/rfjakob/earlyoom instead of > > waiting for OOM to kick in. > > Wouldn't setting ulimit with -m (memory) or -v

Re: [sage-devel] Question about reading Sage documentation

On 2023-06-29 20:50:11, Marc Culler wrote: > I was asking a very specific question about SageMath on Ubuntu 22.04: Are > Ubuntu 22.04 users who install the sagemath-doc package able to read those > (Sage 9.5) docs with Firefox? If you use pip, or ./configure && make && make install to /usr/local,

Re: [sage-devel] Question about reading Sage documentation

On 2023-06-29 14:46:00, Marc Culler wrote: > During our recent release of SnapPy we ran across an issue which is likely > relevant to whether Sage's documentation is viewable on newer Ubuntu > systems (such as 22.04). The issue is that these newer Ubuntu systems ship > Firefox as a snap. A

Re: [sage-devel] Graphics files in Sage documentation

On 2023-06-29 23:30:57, Dima Pasechnik wrote: > On Thu, Jun 29, 2023 at 3:24 AM Michael Orlitzky wrote: > > > > On 2023-06-28 23:27:22, Dima Pasechnik wrote: > > > One can always start a web server on localhost, instead of using file:/// > > > :P > >

Re: [sage-devel] Graphics files in Sage documentation

On 2023-06-28 23:27:22, Dima Pasechnik wrote: > One can always start a web server on localhost, instead of using file:/// :P > I know you're mostly joking, but that's not as easy as it sounds. To start the local web server as a non-root user, you have to run it on an unprivileged (i.e. not the

Re: [sage-devel] Graphics files in Sage documentation

On Wed, 2023-06-28 at 13:50 -0400, Michael Orlitzky wrote: > > * gzipped SVG doesn't work over the file:/// protocol in my firefox. > This hasn't been a big enough problem for me yet to diagnose it, > so I can't say how serious a problem it is. (I'll play around later

Re: [sage-devel] Graphics files in Sage documentation

On Wed, 2023-06-28 at 10:07 -0700, Marc Culler wrote: > > BOTTOM LINE: we get more than a 90% reduction in size simply by choosing to > use the .svg extension when saving the plot instead of the .png extension. > SVG is the right choice for most graphics, but there are some practical problems:

Re: [sage-devel] Modularization project: I. The goals

On Thu, 2023-06-22 at 14:41 -0700, William Stein wrote: > > WebAssembly is not an experimental linux distribution, and it has very > little overlap with linux distributions. The WebAssembly ecosystem is > built from the ground up, primarily on the LLVM (and Rust) toolchain, and > an ecosystem of

Re: [sage-devel] Modularization project: I. The goals

On Thu, 2023-06-22 at 13:56 -0700, William Stein wrote: > > (5) provide a WebAssembly option > > WebAssembly is typically about half the speed as native code (at best), but > it is highly cross platform and self contained. WebAssembly is difficult > mainly when you have to deal with the OS

Re: [sage-devel] Modularization project: I. The goals

> On 2023-06-15 18:08:35, 'Travis Scrimshaw' via sage-devel wrote: > > That is simply not true right now. The # optional sage.* doctests as a > user-visible change. > These tags aren't essential to the modularization itself. They're an artifact of bad tests: * doctests are in general just a

Re: [sage-devel] Modularization project: I. The goals

On Thu, 2023-06-08 at 14:09 -0700, Matthias Koeppe wrote: > > *D. *As a consequence of B and C, it was *impossible to build or run parts > of the Sage library.* And it is *impossible to install the whole Sage > library using Python infrastructure* (pip). (Yes, I know that conda exists.) > Of

Re: [sage-devel] ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

On Tue, 2023-05-30 at 10:15 +0100, Dima Pasechnik wrote: > So far we only had very few votes cast. > We probably should have started with the discussion and then voted afterwards. FWIW I'm still not sure. I basically agree with Matthias's points. If (for example) supporting python-3.8 costs us

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

On 2023-05-28 16:20:02, Dima Pasechnik wrote: > > indeed, https://github.com/sagemath/sage/issues/29023 is the meta-ticket to > oversee this process. Needless to say this needs more effort. I'm sure it's out of date for boring reasons, but the branch from 29665 worked great:

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

On Fri, 2023-05-26 at 18:15 +0100, Oscar Benjamin wrote: > > What is wrong with Sage just saying that an older version of an > operating system only works with an older version of Sage? Matthias alluded to this when he mentioned that we only have one release branch of sage. Our version numbers

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

On Mon, 2023-05-22 at 12:50 -0700, Matthias Koeppe wrote: > > On Saturday, April 29, 2023 at 1:45:31 PM UTC-7 TB wrote: > > Should `sage -i pandoc`, at least in an interactive session, first > recommend to install it from the distro, and not default to conda? > Eventually I think the "sage"

Re: [sage-devel] Meson Build System

On Tue, 2023-05-02 at 10:35 -0700, Volker Weißmann wrote: > Hello, > > I'm a developer that worked quite a bit with the meson build system and > looked at sagemath for a few days. I thought that redoing the build > system with meson instead of autoconf would be quite a bit of work, but >

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

On Sat, 2023-04-29 at 13:10 -0700, Matthias Koeppe wrote: > > This drops platform support for 32-bit Linux (see > https://github.com/sagemath/sage/wiki/Sage-9.8-Release-Tour#availability-of-sage-98-and-installation-help) > > for these optional packages. We will need a decision if this OK. >

Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?

On Fri, 2023-04-28 at 18:06 +0100, Dr. David Kirkby wrote: > > To me at least, it would be unwise not run the test suite. > > If you are choosing to use 15-20 year old hardware, you can not reasonably > to handle a large modern program like Sagemath. More modern machines than > that get thrown

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Thu, 2023-04-27 at 12:37 -0700, Matthias Koeppe wrote: > A problem only arises when you try to build a bleeding-edge sage on an older > stable distro -- an undertaking unsupported by most projects. > > Is it? I would say that Sage is very special in this regard because of its > extreme

Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?

On Thu, 2023-04-27 at 05:49 -0700, William Stein wrote: > Hi, > > To what extent does or could Conda with a little more work solve most > of these problems? There are some notes below from me poking around, > and I'm very optimistic. This isn't the first time the idea has come up. Burcin got

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Thu, 2023-04-27 at 08:38 -0700, Nils Bruin wrote: > > But another problem before was that the different packages would not > develop in lockstep. Some components might need one specific version of > prerequisites and others another. So one could run into genuine version > conflicts. In

Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?

On Thu, 2023-04-27 at 05:12 -0700, kcrisman wrote: > > As an example, how old of a Windows computer could one install the current > Sage on? ... > > In any case, it would be very helpful for people who may be actively using > Sge in less-resourced environment to chime in here. > My desktop

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On 2023-04-26 19:59:01, Matthias Koeppe wrote: > On Wednesday, April 26, 2023 at 7:37:17 PM UTC-7 Michael Orlitzky wrote: > > Just as a data point, eliminating the spkg and only supporting system PARI > 2.15.x would have the effect to eliminate support of: > - all versions o

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On 2023-04-26 18:38:32, Matthias Koeppe wrote: > Michael, do you happen to have a suggestion what version range of PARI the > Sage library should be supporting? PARI doesn't strictly follow semver, so whatever I say here, PARI will eventually make a fool of me. Still, I think a fair goal is to

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wed, 2023-04-26 at 13:06 -0700, Matthias Koeppe wrote: > > 2. I'm not in favor of chipping away 1 package at a time in the name > of unsubstantiated, vague notions that a package is "ballast slowing > down Sage's progress". > There's a ticket open to update PARI within Sage. First, upstream

Re: Re: [sage-devel] ChatGPT is an expert in SageMath too

On Fri, 2023-04-21 at 08:22 +0100, Dima Pasechnik wrote: > > > > > > Sadly it's not. The American legal system isn't built for this. The > > fact that they're clearly doing something illegal and that it's hurting > > people isn't grounds for a third-party lawsuit. The victims can file > > suits,

Re: Re: [sage-devel] ChatGPT is an expert in SageMath too

On Thu, 2023-04-20 at 20:37 +0100, Dima Pasechnik wrote: > > > > https://www.theverge.com/2023/1/28/23575919/microsoft-openai-github-dismiss-copilot-ai-copyright-lawsuit > > > A cursory reading of this wish to dismiss the case sounds to me as the > usual M$ chutzpah. > Of course they want it

Re: [sage-devel] RealField isn't doing it right

On Sun, 2023-04-16 at 19:46 -0700, aw wrote: > > Unbelievable. > This is failing a basic consistency check: if x==y, then we should have > f(x)==f(y) for any function f. > > The problem here is that float literals are being mishandled. The string > "0.5" should be interpreted as 1/2, unless

Re: [sage-devel] RealField isn't doing it right

On Sun, 2023-04-16 at 12:47 +0100, Dima Pasechnik wrote: > > perhaps the preparser should have an option to convert the floating > point input into rationals. We should try ZZ first, but yeah, something like that. If Sage thinks QQ(x) == float(x), then the former should be preferred. Or maybe it

Re: [sage-devel] RealField isn't doing it right

On Sun, 2023-04-16 at 10:50 -0700, Nils Bruin wrote: > > That's a facetious example that sticks to values that can be exactly > represented in binary floats. These identities don't hold generally: > > sage: 49*(1.0/49) == ZZ(1) > False > > (it depends on your working precision if rounding

Re: [sage-devel] RealField isn't doing it right

On Sat, 2023-04-15 at 19:11 -0700, Nils Bruin wrote: > > I fail to see what the reasonable expectations are here. As soon as you > multiply by "0.5" you now have an "imprecise" result. When people learn to > use a scientific calculator properly they are very quickly confronted with > the

Re: [sage-devel] RealField isn't doing it right

On Sat, 2023-04-15 at 16:56 -0700, William Stein wrote: > > I agree with you that it's best to assume that the original poster "aw" does > understand the semantics of floating point numbers in Sage, and just doesn't > like them. I think you also understand the semantics of floating point in >

Re: [sage-devel] RealField isn't doing it right

On Sat, 2023-04-15 at 18:20 -0400, David Roe wrote: > I agree with William that you should refrain from insulting the Sage > developers, especially when the underlying problem comes from your > misunderstanding of how floating point arithmetic works. I was given this response many times, and I

Re: [sage-devel] FlintQS upstream

On Thu, 2023-03-23 at 22:05 +, Dima Pasechnik wrote: > > I promoted you to a maintainer of this repo. > I updated the README to say that FlintQS is obsolete, and there's a PR at https://github.com/sagemath/sage/pull/35419 to replace it within Sage. I also filed a CVE for the /tmp issues to

Re: Private message regarding: [sage-devel] external libraries - is Rust allowed?

in case other people > have > this question in future? > No problem. I only interact with the group via email, but I'll CC this message to the list (sage-devel@googlegroups.com) so that the quoted conversation below shows up. > Best, > > Curran > > On Thu, Mar 30, 2023

Re: [sage-devel] external libraries - is Rust allowed?

On 2023-03-30 10:50:32, Curran McConnell wrote: > Hi folks! > > I am scoping out a project to write an algebra/combinatorics package. It > would be a shame if the project was a success, and then there was > difficulty integrating with Sage if people wanted to redistribute the > routines there.

Re: [sage-devel] FlintQS upstream

On Thu, 2023-03-23 at 22:05 +, Dima Pasechnik wrote: > On Thu, Mar 23, 2023 at 9:14 PM Michael Orlitzky wrote: > > > > Does someone have access to https://github.com/sagemath/FlintQS ? > > > > The build is broken with clang-16 and there's an open pull request t

[sage-devel] FlintQS upstream

Does someone have access to https://github.com/sagemath/FlintQS ? The build is broken with clang-16 and there's an open pull request to fix it. A new release would be helpful. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from

Re: [sage-devel] Can I easily prove a contradiction of the form 0=1 in sage?

On Sat, 2023-02-11 at 13:13 +0200, Georgi Guninski wrote: > Without doubts, sage and its library have bugs. > > Are the bugs "powerful enough" to prove contradiction of the form 0=1? > In addition to all the good reasons why this might happen: Sage includes all of python, and python DGAF. --

Re: [sage-devel] Re: VOTE: move Sage development to Github

-1 Proprietary platforms are against the spirit of free software, science, and mathematics. It is also a step backwards from what we have now. Microsoft is one of the oldest, most resourceful, and most consistent enemies of open software and standards. Letting them control the platform is

Re: [sage-devel] Temporary files problems

On Tue, 2022-09-27 at 18:10 +0100, Dima Pasechnik wrote: > Basically, we should deprecate and remove tmp_dir() and tmp_filename() > from Sage. > Does Sagecell use them? It should not, Python3 has perfectly good > replacements... > That was always the plan. From #33213: > Afterward, the custom

Re: [sage-devel] trailing sage-ipython processes in patchbots

On 2022-07-17 17:42:34, Dima Pasechnik wrote: > On Sun, Jul 17, 2022 at 5:08 PM Thierry > wrote: > > while running a patchbot client, i see a lot of unfinished processes > > whose command is "python3 /home/sagemath/sage/src/bin/sage-ipython -i" > > at various dates, indicating that something is

Re: [sage-devel] 2 basic questions on sagemath programming with external CAS systems

On Thu, 2022-05-12 at 20:28 -0700, 'Nasser M. Abbasi' via sage-devel wrote: > > > And with maxima it does not even time out. It hanged > Integrating with maxima doesn't use the pexpect interface. There *is* a pexpect interface to maxima, but there is also a library interface that is faster.

Re: [sage-devel] 2 basic questions on sagemath programming with external CAS systems

On Thu, 2022-05-12 at 03:32 -0700, 'Nasser M. Abbasi' via sage-devel wrote: > 1) I just want to confirm if this is what happens ( I could find > information on this googling). > > If from sagemath, one makes a call to an external CAS, does sagemath create > a subprocess, starts the external

Re: [sage-devel] Factoring for Fun and Profit

On Tue, 2022-05-10 at 09:54 -0700, John H Palmieri wrote: > Regarding the very last question: the decision many years ago was that the > startup scripts for Sage should be shell scripts, because using Python > scripts seemed to add to the startup time. If anyone wants to change this, > they

Re: [sage-devel] Factoring for Fun and Profit

On Tue, 2022-05-10 at 00:41 -0400, ph h wrote: > > and exported: > > export READLINKPY=$SAGE_ROOT/readlink.py > > How do you know $SAGE_ROOT? That's what we're trying to determine in the first place. This is a code smell, and an easy problem to fix, but to be blunt: you're not going to fix

Re: [sage-devel] Factoring for Fun and Profit

On Wed, 2022-05-04 at 01:56 -0400, ph h wrote: > Hi, > > > Sadly, readlink is not a POSIX standard utility; otherwise we would > > already be using it in place of resolvelinks(). > > In that case, please try this: > > #SELF=$(readlink -f $0) > SELF=$(cd `dirname $0` ; pwd)/`basename $0` >

Re: [sage-devel] Factoring for Fun and Profit

On Tue, 2022-05-03 at 22:21 -0400, ph h wrote: > > Those are C functions: > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/readlink.html > > Is it installable at configuration time? It just means that those functions are "guaranteed" to be present in the C standard library on most

Re: [sage-devel] Factoring for Fun and Profit

On Tue, 2022-05-03 at 21:07 -0400, ph h wrote: > Hi, > > > Sadly, readlink is not a POSIX standard utility; otherwise we would > > already be using it in place of resolvelinks(). > > Thank you so much. That's the constraint that Sage must face. > > BTW, which of the platforms that Sage supports

Re: [sage-devel] Factoring for Fun and Profit

On Tue, 2022-05-03 at 21:33 -0400, ph h wrote: > P.S: What does this mean? Thanks. > > https://man7.org/linux/man-pages/man2/readlink.2.html > CONFORMING TO top > > >*readlink*(): 4.4BSD (*readlink*() first

Re: [sage-devel] Factoring for Fun and Profit

On Tue, 2022-05-03 at 14:30 -0700, ph h wrote: > > *SELF=$(readlink -f $0) Sadly, readlink is not a POSIX standard utility; otherwise we would already be using it in place of resolvelinks(). -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To

Re: [sage-devel] [sage-release] Re: Sage 9.5 released

On Tue, 2022-04-26 at 16:41 -0700, Matthias Koeppe wrote: > > The same is also standard practice in the Python world. In modern Python > packaging, there is no such thing as a build-time optional dependency. The > build environment is fully specified in pyproject.toml. Additional >

Re: [sage-devel] Re: [sage-release] Re: Sage 9.5 released

On Tue, 2022-04-26 at 15:12 -0700, Matthias Koeppe wrote: > On Tuesday, April 26, 2022 at 2:07:40 PM UTC-7 Michael Orlitzky wrote: > > > On Tue, 2022-04-26 at 12:20 -0700, Matthias Koeppe wrote: > > > This makes no sense on any distribution other than build-from-source >

Re: [sage-devel] Re: [sage-release] Re: Sage 9.5 released

On Tue, 2022-04-26 at 12:20 -0700, Matthias Koeppe wrote: > > This makes no sense on any distribution other than build-from-source > distributions like gentoo. > Homebrew, Conda, and sage itself are all source-based. -- You received this message because you are subscribed to the Google

Re: [sage-devel] Re: [sage-release] Re: Sage 9.5 released

On Tue, 2022-04-26 at 10:26 -0700, Nils Bruin wrote: > > If packaging is going to play a more important role in the distribution of > sage, I think we need to make a distinction between build-time optional > packages and packages that can be installed after sage has been built. And > ideally

Re: [sage-devel] Re: [sage-release] Re: Sage 9.5 released

On Mon, 2022-04-25 at 00:39 -0700, seb@gmail.com wrote: > > So, what do we advertise to potential newcomers to Sage? I think despite > such great things as Cocalc, SageMathCell and Gitpod, there should be > something easy to install that can be used offline, too. > Everyone agrees on that

Re: [sage-devel] "Copy" vs "Refactor"

On Sat, 2022-04-23 at 08:28 -0400, ph h wrote: > Dear All, > > If the three files: > >1. sage/sage >2. sage/src/bin/sage >3. sage/src/bin/sage-env > > are to be factored out into > >1. sage/resolvelinks.in >2. sage/sage.sage.in >3. sage/sage.src.bin.sage.in >4.

Re: [sage-devel] Re: [sage-release] Re: Sage 9.5 released

On Fri, 2022-04-22 at 08:16 -0700, seb@gmail.com wrote: > > (./sage -i should be deprecated and removed…) > > — or just have ‘sage -i xyz’ do whatever ‘make xyz’ now does, perhaps. > > +1 > This only works if you don't ever want to e.g. rename sage to sage.in to fix the copy & paste from

Re: [sage-devel] "Copy" vs "Refactor"

On Fri, 2022-04-22 at 01:03 -0400, ph h wrote: > > Is this use case scenario, (running a script before building anything) > documented or undocumented? > I'm not sure if it still is, but running things like "sage -b" and "sage -i" was for 15+ years the documented way to build parts of sage.

  1   2   3   4   5   6   >