Re: [sage-devel] Re: Current status of possibility of integrating libraries written in Rust into Sage

[kcrisman]

Yes. I am all for removing "no internet connection" assumption in 
installing the sage distribution from source.


Since we don't ship binaries, I'd like to hear from those who have had to 
install Sage in circumstances with slow/no internet situations about this 
(e.g. several of our French developers have had to do so in Francophone 
Africa, if I recall correctly).  Perhaps this is no longer an issue, but it 
would be nice to have confirmation.  I do agree that the issue of "certain 
customers" needing no-internet installation should no longer be a 
consideration.

-- 
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/96770e9a-58ff-470f-8397-631f255ffb28n%40googlegroups.com.

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

[kcrisman]

By choosing to be an exception in the Python world, 
Sage obviously does something quite wrong. 


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 sound like there are two pieces to it (modularization but 
also "de-vendoring"), and I can only assume that it would be possible for 
both to occur simultaneously.  It would be helpful for this to be 
clarified, though, so that one knows precisely what *piece* of their 
proposals represent the "normal Python ecosystem".

That said, "normal Python" is not necessarily as relevant for those who 
would *only* want Sage, or at least mostly so.  Having just another Python 
package might lead us to implementing powers as ** instead of ^, which 
would be a regression, or needing namespaces for almost everything, which 
again limits the value of Sage qua 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/dde441e4-e5ab-4d44-b898-90193e0c46dfn%40googlegroups.com.

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

[kcrisman]

It would be fun to continue the conversation with Dima, but clutter things 
up here too much, as David points out.  Suffice to say that certainly

What would really simplify things here is creation of a Windows based 
installer, not mere a document
on dozens of things to be done to set it all up.


this would be phenomenal (was the Cygwin installer that existed for a short 
time a version of this?) and

3manifolds app packages a completely separate full-blown Jupyter 
installation
to interact with Sage (with their standard launcher), and that's the only 
Jupyter they support.
They don't need to package "batteries" which are just ballast for their app.


got it and 

on the massive (and probably incorrect) list on Wikipedia: 
https://en.wikipedia.org/wiki/List_of_Linux_distributions  That's a massive 
duplication of effort right there.


Cf. 
https://en.wikipedia.org/wiki/List_of_the_largest_Protestant_denominations
(and that's "protestant"+"largest" only)


you might be surprised I agree that this is a relevant analogy, though 
perhaps for opposite reasons of yours :-)

-- 
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/7a8ce51d-0fff-4360-8fb8-4487ab8f3953n%40googlegroups.com.

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

[kcrisman]

Pyenv is easier than sage distro, much easier.


I meant *using* pyenv.  I just don't want to be bothered when I really just 
use Sage.  But this is quite orthogonal to the actual discussion, sorry for 
bringing up my 3.9 issues :-)

Well, depending on a legacy (3.9) Python version isn't the problem for the 
most, I hope. :-)


Yes, absolutely not!  I meant just the whole not wanting to deal with 
managing different Python installations.  I don't want to manage different 
versions of LaTeX on my computer either.  One is plenty, thank you very 
much :-) 

-- 
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/c23c661d-f378-45c8-9bd1-be7eef87f57fn%40googlegroups.com.

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

[kcrisman]

We (not just Sage, but you and I!) have been discussing this for 
almost 15 years. 


Haha, true!
 

SageMath has several other long-term contributors who also package 
software. We're all roughly on the same page about what it would take 
to fix the sage installation for end users.


And some of these people (perhaps kiwifb?) have not been as directly 
involved in some of the recent disputes.   Maybe there is a path forward (I 
also presume the CoCC is thinking about this). 
  

But so far, every attempt to disentangle the 
library/distribution to enable this division of labor has been met 
with resistance by essentially one person.


Well, more accurately there must be a critical mass of people who, like 
Kwankyu in some recent comments (apologies for not having link to hand), 
want to trust that the related process undertaken by that person is worth 
doing, and to let that proceed.  Otherwise they would have spoken up, as 
many longer-term developers are not shy of doing so on other matters. 

Regarding WSL in Dima's post, I 
thought https://github.com/sagemath/sage/pull/37184 (and the followups) 
addressed this quite a bit - that was what I was referring to.  If I could 
get it to work, I think anyone could.  But I didn't try Jupyterlab, maybe 
that's not included in it.  Anyway, I was definitely not referring to 
anyone who knows what "apt-get" is in WSL.  So am I right in your saying 
that Jupyter wouldn't work "out of the box" with Sage with the conda-based 
solution for WSL?  To me, that's an argument *for* batteries, not against.  

Same applies for the MacOS version provided by 3manifolds, my assumption 
was that this would work "out of the box" if you do sage -n jupyter or 
something.  That assumption could be wrong - but again, why put additional 
barriers to the user?  "Normal" software that "normal" i.e. non-developer 
people use in the real world doesn't do that.  Why make that a prerequisite 
for just doing math?  I hate to beat the dead horse of the now-debatable 
mission statement, but does Mathematica make you separately download and 
install a notebook?   Even LaTeX has this problem - you have to install the 
distribution separately from TeXShop or what have you - and just like the 
developer friction noted here, it's a little bit of extra friction.

> What fragmentation are you talking about? 

I meant that it's a bit silly (from the Mac or Windows perspective) that 
one even needs Arch, Ubuntu, Debian, Gentoo, Fedora, or anything else on 
the massive (and probably incorrect) list on 
Wikipedia: https://en.wikipedia.org/wiki/List_of_Linux_distributions 
 That's a massive duplication of effort right there.

> It has to be formulated and agreed upon in general lines, otherwise such 
a summit would be a waste of time.

Agreed.  All of my points are irrelevant compared to getting us back on 
some consensus track.  That means toning down the rhetoric and candidly 
saying what sub-optimal concessions might be on the table (to be clear, for 
everyone).  It's clear now that at least two visions for Sage 
packaging/modularization which, in their current technical state, are 
viewed by stakeholders as colliding in their purest forms, but it seems 
unlikely that Sage is not Turing-complete enough to support a modus vivendi.

-- 
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/7ebdcd4a-b8fa-4e1a-8f65-687730fa309bn%40googlegroups.com.

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

[kcrisman]

I understand that some macOS users are very comfortable with Sage the 
distro playing the role of a missing macOS package manager, 


The real question is about *users* in this case, not developers. I just got 
messed up the other day brew updating something which killed my Python 3.9 
I need in order to use a specific package (nothing to do with Sage, 
completely orthogonal) for a certain course, a package which doesn't 
support the most recent Pythons yet, and frankly my teaching load (unlike 
perhaps that of most Sage developers, I acknowledge) doesn't leave time to 
learn the intricacies of pyenv or whatever there is out there to rectify 
such situations (I don't *mind* having 3.12 on my box ...).  Sage's 
"batteries included" means all my Sage installations of various vintages 
stay sandboxed, essentially, and that is pretty comforting.

My guess is that most Sage *users* are in this kind of situation.  The WSL 
solution using some version of conda now might allow something similar (?) 
for the VAST number of Windows users out there.  CoCalc probably provides a 
single solution to a large number of users too (how large, I don't know) 
for people using Mac and Windows in their day-to-day work, who don't mind a 
little Terminal to get some math done but don't want to use Linux (among 
other reasons, because many of us can't afford our own personal computers 
for work, so we have to take the options work gives us, which is 
emphatically not Linux).  It's great that the fairly small number of Linux 
users wordwide have the package manager concept, but its very fragmentation 
(!!!) surely takes a lot of developer time too (not just for Sage) as well. 
 So this argument, by itself, isn't sufficient.
  

but it makes me sad that I spent many months of my time debugging and 
improving Sage on macOS, and getting this kind of cold shoulder in response 
to my requests. 


This is totally legitimate, as I've said before, and is the real crux of 
the issue.  I would hope people who don't want "batteries included" could 
live with it if there weren't a lot of unseen maintenance.  Under past 
circumstances, there would have been a Sage Days of some kind by now (in 
person) to hash out how to resolve the situation *with an acceptable 
consensus*, even if still imperfect, which lightens the load significantly 
on Linux package managers while keeping the other progress made on track. 
 We need something approximating this sort of summit now to resolve these 
issues - and I certainly do think there is an acceptable solution out 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c22329d3-cf4e-4790-80ed-869b32ad61c7n%40googlegroups.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[kcrisman]

Please don't!


+1 for sure

> The modularization project (making pip-installation packages that contain 
portions of the sage library) started years ago with a general consensus of 
the sage community. Matthias led the project and did most of hard works. 
Many others did not care much about the project and still do not feel the 
impact except when encountered with the (annoying) "# needs ..." tags. 
 Matthias is also managing much of the sage build system and the CI (mostly 
testing infrastructure) on github, partly to support the modularization 
project. Many of us would appreciate that.

Also +1 for sure

> Such allegations will have no effect other than to antagonize the other 
party. This is not helpful in fostering constructive debate. Please keep 
this thread to a simple explanation of the issues at hand, so that 
interested community members can make an informed decision on their vote 
(or on whether to vote at all).

+1 to both times this was said (even though I'm violating "issues at hand" 
with this comment)

It's worth noting that "whether to vote at all" is, as typical in Sage, 
mostly being honored by not voting.  Trac was similar - it was often hard 
to get people to review even simple tickets that weren't squarely in 
people's domain of experience within the vast Sage library.  For those of 
us who don't really know that much about .toml files, packaging, or 
modularization, we would like to trust that some roadmap that addresses all 
concerns *in an acceptable, if quite imperfect, compromise* can be come up 
with by those who *do* have expertise in those matters.  

But they'll have to ignore the personal/political matter, hard as it might 
be.  *Even if it's true* that there is "sabotage" or "refusing to assess" 
(which this post remains neutral on), if it is *possible* to interpret a 
code change request as being well-intentioned and helping some aspect of 
packaging, then that should be done.  Until such time as another Sage Days 
*in person* could be held on a topic like packaging, the best operating 
procedure for online-only discussions is to give the most charitable 
possible interpretation to a given code request - and refrain from any 
comments that imply ill will on the part of another, *even if you think 
there is ill will*.  (Then the truly ill willed statements will be clear, 
at least, instead of currently sometimes being themselves ambiguous.)

-- 
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/bb7c57ca-1f3d-4d07-8761-6214a150a179n%40googlegroups.com.

[sage-devel] Re: Downloads

[kcrisman]

Thanks very much for this important service. Looks like the homebrew cask 
that provides your app has also been updated already.



+1 

-- 
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/1085eaaa-0233-48da-9097-331a57c610b0n%40googlegroups.com.

Re: [sage-devel] Re: Vote: Sage Code of Conduct

[kcrisman]

The anonymized votes are here 
,
 
in case anyone wants to do further analysis.


Thanks, David.  This actually confirms that, as such elections go, it's 
remarkably non-controversial; a third (!) of the electorate approved 
everybody, and only one candidate got less than 2/3 (approval) votes.  And 
nearly everyone used more than half their potential votes.  There is a 
small C/D vs. E/F(/G, and certainly not uniformly anyway) bloc difference 
in a third of the voters, but that's not spectacular at all.  (If you would 
like actual harmonic analysis of more subtle potential coalitions, it will, 
alas, have to wait until well after the end of the semester - and anything 
else would probably be well within tolerations of randomness on a suitable 
probability distribution.)

-- 
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/cdc5150f-6e36-4d83-9590-3a1def6bb27dn%40googlegroups.com.

[sage-devel] Re: Vote: Sage Code of Conduct

[kcrisman]

I also want to thank Vincent Delecroix, David Joyner, Harald Schilly, and 
William Stein for their service on the committee up until this year.

 
Amen! 

-- 
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/3a75e042-00e3-4824-8771-ec20ab5f272dn%40googlegroups.com.

[sage-devel] Re: VOTE: disputed PRs

[kcrisman]

It would be helpful for anyone explicitly voting +/-1 to either link to a 
previous comment or make a new actual comment (beyond the vote) to clarify. 
 This is particularly if there have been new commits since the initial 
dispute, because for an outside reviewer it can be hard to untangle all the 
various comments before the disputed tag is placed on the PR.  

(Which would apply to any emailed requests as well.) 

-- 
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/bb229d60-d204-4d04-bc3d-2c88515a389dn%40googlegroups.com.

[sage-devel] Re: VOTE: disputed PRs

[kcrisman]

Having just encountered this "in action", I have a suggestion:
"There is no scheduled vote, but rather an ongoing poll based on opinions 
expressed by developers on the PR (these opinions can be expressed via 
previous positive reviews or explicit comments giving approval).  The PR 
author is presumed to vote in favor; if they give up or no longer favor the 
PR they have the right to close the PR overall without any further voting."
It would be helpful for anyone explicitly voting +/-1 to either link to a 
previous comment or make a new actual comment (beyond the vote) to clarify. 
 This is particularly if there have been new commits since the initial 
dispute, because for an outside reviewer it can be hard to untangle all the 
various comments before the disputed tag is placed on the PR.  
I don't know if this means I'm voting for or against the proposal, though! 
 Friendly amendment, perhaps.

-- 
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/17add435-e955-4a4f-85eb-25a1577d8354n%40googlegroups.com.

Re: [sage-devel] Re: Application for NumFOCUS affiliation of SageMath

[kcrisman]

On Tuesday, March 5, 2024 at 2:08:07 PM UTC-5 William Stein wrote:

Hi,

Related to NumFOCUS, this new proposal for Jupyter to restructure their 
relationship with NumFocus is possibly relevant:

https://jupyter.org/governance/linux-proposal.html


Interesting, and certainly relevant.  It's a little unclear to me why 
NumFOCUS is not appropriate for them, other than a vague reference to 
operations - can anyone read between the lines for those of us not as 
plugged into that world?

-- 
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/43116e40-2255-4189-a07f-ea5948a7e1d0n%40googlegroups.com.

Re: [sage-devel] VOTE: disputed PRs

[kcrisman]

Dima, I think that if anyone is incapable of posting to a particular PR, 
they should send email to someone who can post and ask them to record the 
person's vote, resulting in a comment like "I am posting to record 1 
negative vote from X, 2 positive votes from Y and Z".


Yes, that would also go for those who do not choose to use GH.   

-- 
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/0ae620d2-8a84-4290-bf03-66f2d0d03264n%40googlegroups.com.

[sage-devel] Re: VOTE: use "blocker" label only for PRs; use "critical" label for Issues

[kcrisman]

On Wednesday, February 28, 2024 at 1:45:03 AM UTC-5 Kwankyu Lee wrote:

Hi, 

Here I withdraw the early premature "giving up" on my recent proposal, 
since afterwards there were some positive comments. Hence I open a voting 
for 

Proposal: 

1. Do not use "blocker" label for Issues, as "blocker" means to delay the 
release.
2. Instead use "critical" label for a very serious and urgent Issue.


I appreciate the spirit of this request, but since Trac did not distinguish 
between issues and PRs and we used blocker regularly on Trac, it seems like 
a pretty big change, and sort of implies you can't block a release (in 
principle) even with some big problem if you can't contribute a fix 
immediately. -1 for now.

-- 
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/255e9f64-9bd5-468c-b8e3-0d56ea2aa00an%40googlegroups.com.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[kcrisman]

As part of this thread, I'd again ask for a discussion of the following 
situation I asked in the other thread.  Dima had some interesting points 
about a less-vendored approach saving disk space etc., but it would be 
helpful to have input from people who have had to install Sage in these 
kinds of situations en masse.  Separately, I'm also wondering about the 
Windows situation since much of the world, for better or worse, is not on 
Linux.

"At least in the not too distant past there have been situations where the 
non-requirement of internet connectivity alleviated issues of limited 
internet accessibility in a given locale, limited download speeds, limited 
grid electricity, etc.   This policy just as much affects those situations, 
and perhaps some people who have installed Sage in such environments 
(including Sage Days and other events) might want to weigh in on that, and 
whether such situations still obtain (as I personally assume they must 
certainly do).  I figure three-letter agencies have people with the skills 
to get around not using pip install, but if your downloads are over a 
mobile network (or, for that matter, Project Kuiper or Starlink or 
whatever), you might still want to download Sage - especially now that we 
don't have binary installs "provided"."

-- 
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/1c003881-c1c5-4d5a-8fd3-fb78d46263f7n%40googlegroups.com.

Re: [sage-devel] Proposal: Make pytest, pytest_xdist, pytest_mock, python_build standard packages

[kcrisman]

I believe I'm the person who introduced that long standing policy. It 
was indeed motivated by a significant paying customer's requirement 
to install Sage entirely from source, and without an external network. 
I believe no such customers have supported the Sage project for about 
a decade, so I'm very supportive of removing this policy. 


However, at least in the not too distant past there have been situations 
where the non-requirement of internet connectivity alleviated issues of 
limited internet accessibility in a given locale, limited download speeds, 
limited grid electricity, etc.   This policy just as much affects those 
situations, and perhaps some people who have installed Sage in such 
environments (including Sage Days and other events) might want to weigh in 
on that, and whether such situations still obtain (as I personally assume 
they must certainly do).  I figure three-letter agencies have people with 
the skills to get around not using pip install, but if your downloads are 
over a mobile network (or, for that matter, Project Kuiper or Starlink or 
whatever), you might still want to download Sage - especially now that we 
don't have binary installs "provided".

-- 
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/9e61dfb3-bdc3-4fde-8bd3-914ef39a6731n%40googlegroups.com.

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

[kcrisman]

> I don't think it's off-topic to once again point out that this way of 
phrasing it is very developer-centric.  That's not a wrong way to look at 
it, but an end-user-centric way of looking at it is also valid.  

It seems to me that "developer" here refers to a very different kind of 
developer than me, which is probably because I mostly care about getting my 
mathematics done and (probably because of that) use only linux.  I never 
had any severe build problems, although recently I have had some problems 
with TMPDIR.


When I say "developer-centric", you probably are already in this category, 
since you have quite a bit of expertise and also do development work with 
FriCAS (if I recall correctly?).  Anyone building from scratch more than 
once would probably count in this category :-) but you are right that 
especially those dealing with the non-mathematical part of the build are 
most impacted by this disagreement.

When I think of "user-centric",  I'm thinking more about the mathematicians 
John Cremona has helped install Sage, often laboriously, or the people that 
the 3_manifolds project create the Mac binary for, or (especially) people 
wanting to use Sage to help them with their undergraduate teaching and 
their research at the same time.   People who are not particularly likely 
to use Github, even if they happen to have an account, people who might not 
mind a command line to do math, but don't want to mess with things like 
homebrew or conda or whatever on a work-owned system.  (And yes, also 
people wanting to apt-get Sage, maybe with the AIMS desktop?)

My thinking is (as ever) in terms of potential users, not just the already 
committed.  Sage as such has distinct benefits over "just a Python library" 
in similar ways that M* does.  That doesn't mean we should stick with any 
particular model, but making sure it's not a big roadblock to people 
creating end-user output is key. 

-- 
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/4db1774e-716e-436e-a30e-8397e80ae0bdn%40googlegroups.com.

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

[kcrisman]

Many of these are disputed for the same underlying reasons. Appointing 
a different editor for each PR is not likely to help. If you pick an 
editor from Camp A, he or she will always rule in favor of Camp A; pick 
an editor from Camp B... 


The camps are roughly split across the question whether
Sage the distro should be deemphasized, and the development
process should be centered around sagelib, or not.

As well, and it's not a coincidence, roughly the same partition
is on the basis of the developer platform used by the camp member.
It appears that the Linux users are primarily for deemphasizing 
Sage the distro, and macOS user are primarily against.


As a general observation, this seems somewhat accurate.  That said, as 
Martin R points out, many (most?) people don't seem to be in a "Camp". 
 

I suspect it's due to the latter used to Sage the distro as a "missing macOS
package manager". 
So they are happy adding more and more spkgs to Sage.
And Linux users rightly see adding to Sage spkgs, which
package software available on their systems in a regular way,
as a bloat, which moreover needs constant attention - 
while sagelib suffers.

I don't think that without solving this conflict the disputed PRs
dispute can be solved.

I may go on discussing how the Sage macOS problems may be
mitigated, but not here and now.



I don't think it's off-topic to once again point out that this way of 
phrasing it is very developer-centric.  That's not a wrong way to look at 
it, but an end-user-centric way of looking at it is also valid.  And these 
are largely using Sage on Mac (without knowing about things like brew or 
conda, nor really wanting to) or even Windows (where not even these options 
exist, but people seem content to download whatever older version still is 
available - and they do).  Let's ignore the cloud solutions available for 
now, since I still suspect that for "ordinary" solo uses this is not as 
significant a factor (as opposed to collaborative ones).

So somewhere on sage-devel (probably not this thread) it would be really 
helpful for people *other* than the two or four primary "representatives" 
of Camps A and B to explain the vision of Camps A and B regarding both 
developers and end users.  Because the developer time/bloat issue is real, 
and the end user not being able to use Sage issue is real (on Windows, at 
the very least, and it was nearly the case on Mac).

-- 
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/34eb570c-6686-4ebd-b425-2d51a1371e11n%40googlegroups.com.

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

[kcrisman]

We do not have much time to devote to Sage development. 


And this is a great time to thank Volker for continuing to serve as release 
manager for the vast majority of Sage tickets which are not about the 
design philosophy, despite his (and William's) lack of time.  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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b635973b-08c3-4008-a1f5-9b18136a6706n%40googlegroups.com.

Re: [sage-devel] how to enter a bug in the future for sagemath in github with no github account?

[kcrisman]

It is already the norm that when people report bugs to sage-devel, when 
appropriate, a relevant GitHub issue is created. 


I can only handle login using account+password. If I have to do more to 
login to a web site, I am not going to bother and not interested.

If sagemath can setup either usenet group (can 
https://groups.google.com/g/sage-support  be used for this?) or
email address to send bug reports, that will be much better and much easier 
for many people I am sure.



If I'm not mistaken, some people working on Sage also object to Github 
(versus Gitlab or other hosts) on other grounds, and at least in some cases 
sage-devel or sage-support requests have indeed been turned into issues by 
other contributors.  Just be sure to be very specific, and hopefully to 
answer all the various questions the Github issues now ask (such as 
platform, reproducibility, etc.). 

-- 
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/734781e0-adc6-44b9-aafe-07bcd414ee06n%40googlegroups.com.

Re: [sage-devel] Re: Policy for disputed PRs: discussion

[kcrisman]

Relevant to both the overall issue of project direction *and* the specific 
one about Sage-as-distribution, I would just add keeping in mind the Sage 
mission (at least, as it currently stands):

Mission: *Creating a viable free open source alternative to Magma, Maple, 
Mathematica and Matlab*.


For those who may not have actively followed this thread: discussion on a 
possible new mission at https://github.com/sagemath/sage/issues/36827

-- 
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/16a54eb6-4677-400c-ba97-b17b8234833dn%40googlegroups.com.

Re: [sage-devel] Re: Policy for disputed PRs: discussion

[kcrisman]

To the extent that this specific PR is emblematic of a particular approach 
to Sage development (a flawed approach in Dima's view, if I understand 
right), then the whole approach should be discussed here. Probably many of 
these issues in Sage development have been discussed already, but it's 
probably time to revisit them, to see if we can reestablish a baseline 
level of consensus.


As a person who has been involved in Sage a long time, I just want to +1 
John's remark that major issues involving the direction and approach to 
Sage development, even if they have been discussed before, are definitely 
something that should be discussed again.  The optimal choices for a Sage 
can easily change as the world changes, and there are many relevant factors 
to Sage's development that are massively different now than in the past.  
 Examples: python is much more popular now than ever before; GPU's are 
vastly more powerful now than before; GitHub with its amazing free CI 
infrastructure exists; Conda exists; GCC isn't the only free C compiler; 
WebAssembly exists, ...


Thanks, William, that's great perspective.

Relevant to both the overall issue of project direction *and* the specific 
one about Sage-as-distribution, I would just add keeping in mind the Sage 
mission (at least, as it currently stands):

Mission: *Creating a viable free open source alternative to Magma, Maple, 
Mathematica and Matlab*.

Digression, but not really: That this is related to the packaging 
discussion is evident in that different packaging scenarios have different 
outcomes for end users, especially those *not* on Linux, which I for one 
would like to see more numerous than those on Linux, since that's where the 
people doing (and teaching!) math probably still are, in reality.  It would 
be great to live fully in the Python world as well as achieve this, but 
perhaps these goals are not in the same subspace.  (Or maybe they are.)

As just one example, here is a very recent discussion that (partly) is 
about how to use Sage on Windows (by people not necessarily averse to CLI 
stuff).  

https://groups.google.com/g/pretext-support/c/2_4Lz6fRKjM 

Since these people are *atypical* among people doing math in their 
proclivities to try out all kinds of new toys (as opposed to just doing 
math), I suspect strongly that the last embray-produced Windows binary is 
still used WAY more than any WSL solution, because even if people *can* 
figure out how to use it, would they bother if they have a proprietary 
option available instead?

This is a good place to thank embray and darthandrus (among many others) 
for work on previous Windows and Mac "one-click" download options, and 
especially the 3-manifolds project for the current one for Mac.  Any 
changes (or lack thereof) to Sage-as-distribution that makes one-download 
easier for Windows and Mac are probably the best in this important sense - 
and anything that makes it significantly harder for 3-manifolds is probably 
one to discuss carefully first.

-- 
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/e3239182-67c2-496d-b8b2-fc468cd1a4b5n%40googlegroups.com.

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

[kcrisman]

To John C's point, and perhaps with the humor that John P intended: 
https://daily.jstor.org/in-which-we-science-why-nouns-become-verbs-because-language/

-- 
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/5d59e7dd-4691-4977-b736-185da225a7b4n%40googlegroups.com.

[sage-devel] Re: Reviewer tools

[kcrisman]

I created a wiki page that contains simple bash scripts that may be useful 
to reviewers:

https://github.com/sagemath/sage/wiki/Reviewer-Tools

that may cure the heart missing "git trac".


Thanks! 

-- 
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/5f2c46df-5e13-44ff-8957-4c8c4f749a86n%40googlegroups.com.

Re: [sage-devel] Powers of 2

[kcrisman]

Congratulations and warmest thanks to all contributors!

Agreed! 

-- 
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/4512f9ab-6e0d-48b4-a35c-deac682c3f43n%40googlegroups.com.

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

[kcrisman]

Though I am sympathetic to the pro-deprecation arguments and recognize they 
will win, I vote do not deprecate, as mission includes Matlab, and for 
backwards compatibility.  As an example, the first edition of the 
AMS-published "Sage for Undergraduates" used the backslash operator in a 
number of examples (comparing it explicitly with other solving methods for 
linear systems), so I presume the second edition has maintained that 
(though I don't personally own it and can't verify immediately; a related 
website does not seem to have all code examples).

On Sunday, October 1, 2023 at 6:59:39 AM UTC-4 Ricardo Buring wrote:

> Deprecate the pre-parsing of \
> the backslash operator please.
>
>

-- 
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/2fce3c6a-9e03-4c3a-893d-f4f6d2473d04n%40googlegroups.com.

Re: [sage-devel] Re: keywords in github

[kcrisman]

On Thursday, September 28, 2023 at 3:52:30 PM UTC-4 Dima Pasechnik wrote:

it should be possible to search for patterns in commit messages across PRs 
- this info is in the git tree. 

GitHub metadata is harder to search, and I am quite surprised how limited 
their search options are.



GitHub search is terrible, and I don't understand why.  I often (not on 
this project) search for words (not just text strings) that I know I 
present multiple times in the codebase, and get no results at all.  Sort of 
defeats the point of a web-based interface if you end up needing to use a 
local terminal anyway.

-- 
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/935aca45-721f-416d-a750-ef54d0b3c5afn%40googlegroups.com.

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

[kcrisman]

On Wednesday, September 27, 2023 at 6:19:16 PM UTC-4 William Stein wrote:

Hi, 

I'm the guilty party who added \ to Sage notation in the first place, 
and I would definitely vote to *remove* it. I wish I had 
never added it in the first place. Nils has some very good points! 


I do think it's worth considering whether people outside of the doctests 
actually use the backslash operator in the Matlab way.  This is a 
well-known shortcut in a lot of the practical computational world, as I've 
seen when people have tried to type it in other contexts and wonder why it 
doesn't "just work".  For instance, one could look at any linear algebra 
textbooks that use Sage and see whether they use it.  Keeping the mission 
in mind!

That said, this is pretty clearly the only strong reason to implement it, 
to keep learning new syntax to a minimum for people coming from 
Matlab/Octave.  And maybe those people are not using Sage for this purpose, 
as it seems to focus more on advanced math(s) capabilities.  But one should 
at least raise the question, and if it's not actively hurting anything, 
then John's suggestion regarding adding the "usual" behavior outside of the 
very narrow matroid/ix-related contexts seems best.

-- 
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/4311cf1f-6022-4339-862e-b1e741420a7en%40googlegroups.com.

[sage-devel] Re: DeprecationWarning on sagecell in Graph([(0,1)]).vertices()

[kcrisman]

On Saturday, June 24, 2023 at 9:20:39 AM UTC-4 Georgi Guninski wrote:

https://sagecell.sagemath.org/ 

Graph([(0,1)]).vertices() 

/tmp/ipykernel_1853928/1298164553.py:1: DeprecationWarning: parameter 
'sort' will be set to False by default in the future 
See https://github.com/sagemath/sage/issues/22349 for details. 
Graph([(Integer(0),Integer(1))]).vertices() 

[0, 1] 


The docstring clarifies:

https://sagecell.sagemath.org/?z=eJxzV7BVcC9KLMjQiNYw0DHUjNXk5XLXK0stKslMTi22BwCCfwjO=sage=eJyLjgUAARUAuQ==

G = Graph([(0,1)])
G.vertices?

As of https://github.com/sagemath/sage/issues/22349, this argument must be 
explicitly specified (unless a "key" is given); otherwise a warning is 
printed and "sort=True" is used. The default will eventually be changed to 
"False". 

Interestingly, the example Harald cross-referenced 
at https://github.com/sagemathinc/cocalc/issues/6750 does not give this 
warning in the cell server.

-- 
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/be567bed-6911-42f7-a4cc-e075ba7ba2cdn%40googlegroups.com.

[sage-devel] Re: Modularation doctests

[kcrisman]

Just ... wow.  I know I don't get much of a say given my lack of recent 
development activity, but this level of granularity does seem absurd.  It 
would certainly be a (psychological) barrier to development - how do you 
know which modules some random doctest you want to include depends on? - as 
well as to bug reporting - if it's optional, the first thought would be 
it's not really necessary to test.  Travis makes some very good points.

Anyway, though I'm still not sure who is going to use sub pieces of Sage 
(the library), I understand that for development purposes, and for being 
able to add more narrow pieces (in the spirit of William's old psage, see 
https://github.com/fredstro/psage for the most recent activity there), it 
is a done deal to modularize.  Kwankyu's last "block" idea seems a good 
compromise, particularly because it could be retrofitted to many other 
optional doctests for truly "optional" packages, which might actually 
streamline documentation for those.

I also think it might be good to have a style guide telling those writing 
such tests to inform users/developers why a particular optional tag is 
needed, in a comment or something.  For a lot of the optional libraries, 
that was fairly obvious (e.g. if you didn't have Mma or Maple installed, 
don't do those tests, or for the various LP solvers), but maybe that isn't 
so clear now.  Just some thoughts.

-- 
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/5ea2b7cc-aa48-4113-b4d6-e585a191418fn%40googlegroups.com.

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

[kcrisman]

Anyway, we need you.  Both of you.



+1 

-- 
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/c667d38d-d17b-4dd7-a61f-cb77377e64b9n%40googlegroups.com.

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

[kcrisman]

(I'm planning upgrades in the next year or two, but it will be to 
relatively low power RISC-V hardware. There are moral, legal, 
environmental, and other non-financial reasons why people use "old" 
hardware. But of course the financial reasons are very real too.) 


Agreed on all points.  Access reasons too. 

-- 
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/bda86cae-9077-437f-9cf4-72cef997d85bn%40googlegroups.com.

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

[kcrisman]

As of today, it is plausible that such situations still exist. 


I am wondering about such situations existing in less-resourced areas 
globally (which would include less-resourced parts of developed countries). 
 One big advantage of Sage-the-distribution historically was the ability to 
make USB drives that had the complete thing (maybe also a Linux VM?) on 
them, from which one could boot.

It strikes me that many arguments for removing the distribution along these 
lines (not the developer side, which is also important) are akin to those 
arguments which assume one should "just" use a remote option for Sage at 
all times.  Yes, that has been seriously made on multiple occasions, though 
usually not on this list.  But even "post-pandemic" there are still plenty 
of reliable high-speed internet deserts even where I live on the US East 
Coast, much less around the world.  I wouldn't want to use CoCalc without a 
fairly new computer.

Likewise, there are plenty of people using 5-10 year old computers who, in 
principle, could be afforded Sage access, but for our continued upgrading. 
 (Again, see below for the developer side.)  Arguments about how they 
should upgrade or face security issues are fine, but in practice (whether 
for financial or other reasons) this is not how humans respond to those 
incentives, and presumably at least some of them might benefit from Sage. 
 A lot of the paradigm discussed on this list (but not all, for sure) 
focuses SO MUCH on people who have access to fairly recent technology, and 
that simply doesn't obtain.

As an example, how old of a Windows computer could one install the current 
Sage on?  I mean from scratch - not necessarily from source - using WSL, 
which I guess is now the main supported way to do so?  What about the 
Cygwin installer - does it still exist in older versions on sagemath.org 
mirrors, what does that support?  How easy is it for someone who does NOT 
know about compiling to install Sage on a not-too-recent Windows machine? 
 I bet it's easy to install the various M's ...

In any case, it would be very helpful for people who may be actively using 
Sage in less-resourced environment to chime in here.

Moving to the developer side:

a) If a critical bug is discovered, we can patch it and don't have to rely 
on people and infrastructure "outside the project" to fix things for us. 
Of course, we have been very lucky that packagers for many distributions 
have been consistently highly engaged with the project; but this is not 
something that we can take for granted.


This is basically why William started Sage in the first place.  (Well, one 
reason!)  When I still had time to be an active developer, this was a major 
source of necessary work.  It's true that a lot of packages are now more 
responsive (or have been canned/subsumed into Sage), but presumably it 
could still be a problem, especially with some extremely math-specific 
packages that might not regularly update in a platform-agnostic way.  That 
said, presumably Python and gcc are no longer in the situation where we 
need to actively maintain a lot of patches to them.
 

b) And, of course, more Sage developers can become contributors to the 
packaging communities; but there is the real danger that taking care of 
both upstream development *and* downstream packaging for the same project 
can lead to developer burnout. 


This (whether connected to upstream packaging or not) is really the most 
powerful argument for radical decoupling.  (Similarly to the GH 
transition.)  Clearly R fell in this category.  Reading the other thread 
did not really clarify for me whether python3 or gcc fell into this 
category, and I don't think it will be helpful to revisit that right now. 
 In any case, this should be weighed against Sage ease of access. 

One thing that might help all of this is having older versions of Sage 
*binaries* for such platforms readily available for download (as many of 
our upstream packages in fact do).  I don't think we are.  In 
fact, https://www.sagemath.org/mirrors.html was kind of scary - a lot of 
mirrors don't seem to have anything at all.  I will assume I missed a 
thread (quite likely that I did) that we were dropping binary support via 
mirrors completely, which needless to say would make my suggestion 
difficult to implement.  I do think it is the best way to provide quite 
fully-featured versions of Sage to people with less-modern setups (who 
probably now simply don't use Sage because they can't, or stick with older 
versions they already have, which we see from time to time on the support 
list) while still allowing for dropping some of this support when it sucks 
up too much developer effort.

-- 
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 

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

[kcrisman]

Alpha:
enter "e^1.1", press "more digits"
3.0041660239464331120584079535886723932826810260162727621297528605...

Sage:
RealLazyField()((e^1.1)).numerical_approx(200)
3.004166023946433394797850269242189824581146240234375000


Sage is not Wolfram Alpha, and neither is Mathematica. Alpha is trying to 
get at something different.  It would be GREAT if there were an open source 
natural language processing thing of that type (a few attempts have been 
made, not necessarily with Sage, if I recall correctly), but to my 
knowledge there isn't.  But that is not Sage's goal.   Sage can obviously 
do this computation:

sage: z = e^(11/10)
sage: RealField(1000)(z)
3.0041660239464331120584079535886723932826810260162727621297528605...

The real issue is that you want 1.1 to be 11/10.  I think this is a 
reasonable thing to talk about, but it's also reasonable to recognize that 
it's not inherently wrong to tell the software users they aren't the same 
thing.

We have to have some convention (and here, "we" is more than just Sage) for 
how decimals are interpreted, and the convention for most such software 
seems to be that it is interpreted as a float of some kind.  I'm super 
careful to tell students the difference between what their calculator says 
and the fractions they may or may not represent, and that includes with 
material below that of calculus, and I certainly wouldn't encourage them to 
treat 1.1 the same as 11/10 in a system beyond a hand-held calculator. 
 1.1^x is not the same as (11/10)^x in a modeling situation; the latter 
implies you know the exact growth rate, the former is a model.  (I do not 
tell them about floating-point unless they are computer science majors or 
are likely to take additional mathematics where this becomes relevant, such 
as linear algebra.)

I strongly doubt I am the only teaching mathematician who does that. 
 Though it seems Dima has a potential approach, maybe we just have to agree 
to disagree on this.  To bring reasonably independent evidence, here is a 
quote from a book on Sage NOT written by a developer (Gregory Bard's "Sage 
for Undergraduates"):

"The number 0.5 is already a decimal and thus Sage assumes that it is a 
mere numerical approximation.  However, the number 1/2 ... " and (a few 
paragraphs earlier), "However, if our project becomes an important part in 
a larger program ... then wasting half the computation time would be 
exceptionally unwise."

That seems appropriate for this level in explaining the issue at hand. 
 This text is intended for high school and (mostly) college educators and 
their students, and is written by someone with plenty of non-Sage 
programming, experience, but also plenty of practical teaching experience 
at an engineering school.  I hope it is clear from this example that 
reasonable people who care about end users can come to different 
conclusions about whether 1.1 should be treated the same as 11/10, and 
whether this is (at least in the educational context) something that can be 
effectively communicated to students.

-- 
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/6e664940-e644-4960-8229-feaca2f99b5an%40googlegroups.com.

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

[kcrisman]

Just to say a big *Thank You!* to you all for being utterly patient and 
polite and positive


 +100

-- 
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/06e60cb8-d883-45e4-863f-59af4bfbcc59n%40googlegroups.com.

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

[kcrisman]

This has been an interesting discussion, because it brings up again the 
inherent tradeoffs present in writing general-purpose software.  We (not 
just Sage, but other similar systems) want something that is usable by 
those who need floating-point to do what it must do, as well as be 
intelligible to those who write 1/3 = 0.333 and assume it is correct.

Although the discussion is not about teaching, it seems that the worst-case 
scenario of users are in that context.  I think the compromise reached in 
Sage is acceptable for all teaching purposes I have ever had to encounter, 
for two reasons.

1) For many things, instructors need to provide an extra layer of sugar 
anyway.  I have a nice activity I stole from someone else for showing the 
effect of various matrices on simple graphics, and for students just seeing 
matrices for the first time, I am not going to expect them to program the 
whole thing yet.  In such cases, an instructor should understand at least 
the basics that can "go wrong" and shield users if necessary.  The rank 
example falls into this category - as soon as we are doing actual matrix 
computations "for realsies", students MUST be led to understand that there 
is numerical error inherent.  

Michael said, "But if you're learning linear algebra for the first time and 
typing a matrix into the Sage notebook, typing 0.5 instead of 1/2 should 
not ruin the entire assignment without so much as a warning." 
 Unfortunately, having taught this materials to complete beginners many 
time, I have to say that anything that goes beyond integer values to learn 
the terminology should be mentioning this issue in class, even in an 
Excel-based math for business course (for example).  What level we go to in 
explaining why they should be careful will depend on their background, but 
explaining that Excel (or Sage, or whatever) has this limit is very 
important, even if we then say, "our examples will be selected to avoid 
this in our beginners' course, but be sure to work with your quantitative 
people/statisticians if you get weird answers."  Maybe that means Nils' 
allusion is right and rank needs to be disabled (or yield error) on 
non-exact matrices?  I'd be loathe to do that, I'd rather have to deal with 
the issue in class (and have done so, answering exactly these kinds of 
questions.).  I have to talk about NOT using Excel to get determinants for 
this reason :-)


2) For other things, anyone using them should know the conventions.  The 
RealField(120)(RR(13/10)) is an example of this - no one who doesn't know 
what RealField is doing should be put in a position to even worry about 
this.  This particular example was discussed very fully above, but my point 
on it is that if someone encounters this before a numerical analysis course 
(in which case it is expected behavior), then someone is asking students to 
do a computation in a way that isn't appropriate for that course.  (That 
doesn't mean students shouldn't see this kind of thing earlier - there are 
some very nice examples with things like limits [1] which are very 
appropriate to talk about in calculus, but we don't talk about 
floating-point precision in detail, just that we have to be careful 
"trusting" the computer instead of using analytical tools.)

[1] 
https://sagecell.sagemath.org/?z=eJwrSyzSUM_MKygtUdfk5SpKLS7NKVGwVdBIzi_WAAtr6hpq6oNZcUa8XAU5-SUaEFU6EHkdXT0DMDDUgTE0NQGwjxmm=sage=eJyLjgUAARUAuQ==

I used to feel more like the OP about " A user should be able to send any 
argument to a function, and it's the responsibility of the programmer to 
make sure one of two things happen ..." but when I found out why PARI does 
not return an error message when you ask for the primitive root of a number 
that doesn't have a primitive root (namely, efficiency in avoiding the 
process of checking for bad input), I modified that to take into account 
who the intended end users are.  Anyone using RealField(120) should be 
aware of these issues.  It's possible that the conventions are wrong, but 
they are spelled out.

-- 
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/86a1734c-21cb-4ad2-9401-feaf09454f23n%40googlegroups.com.

Re: [sage-devel] Github Discussions

[kcrisman]

Personal feeling is that a lot of people who have Sage *questions* are less 
likely to have GH accounts.  I mean, some will.  But a lot won't.  So the 
friction for them would be similar to the other options - though 
sage-support maybe less so, as probably more people have Google accounts. 
 And for what it's worth, recent questions on ask.sagemath seem to still be 
getting decent traction - though we do have a fragmentation problem that is 
not likely to disperse no matter what solution we use, because in the end 
people ask questions about Sage coming from everything from high school 
users to developers.

-- 
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/42f564b8-052a-4759-ac4a-b0ddd1392812n%40googlegroups.com.

Re: [sage-devel] online talk about the github workflow

[kcrisman]

My recording of the talk is now available at: 
https://www.youtube.com/watch?v=p3-W43ijTUg


Great, thanks!  See https://github.com/sagemath/website/issues/453

-- 
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/9fd197d6-379b-449e-a457-5c2482cfb546n%40googlegroups.com.

Re: [sage-devel] online talk about the github workflow

[kcrisman]

 
For people who for some reason cannot get such an address, we can make an 
exception, on an individual basis (we are not in business of providing free 
email access, you know) and provide such persons with @sagemath.org emails 
-  email server runs on Unix VM, accessible via ssh and hosted in EU. (this 
machine is relieved now from sending trac notifications:-)).

Haha, that is a good thing for bandwidth!   

-- 
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/0954579a-f5df-49c1-9116-4c7f99144272n%40googlegroups.com.

[sage-devel] Re: Migration to GitHub complete

[kcrisman]

https://github.com/sagemath/sage

See 
https://github.com/sagemath/trac-to-github/blob/master/docs/Migration-Trac-to-Github.md
 
for a transition guide from Trac to GitHub.


Gratuliere and congratulations to all the many people who made this huge 
task possible! 

-- 
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/d71a475d-8cd9-433a-82e0-5b8480ccc687n%40googlegroups.com.

Re: [sage-devel] online talk about the github workflow

[kcrisman]

On Thursday, February 2, 2023 at 4:36:35 PM UTC-5 François Bissey wrote:
On 3/02/23 10:30, David Joyner wrote: 
> Hi Vincent: 
> Will this be recorded and posted on youtube, 
> or something like that? 
> - David 
> 

I am seconding that request. That time is 5:30am in my time zone. 


And I and perhaps others teach during that time.  Plus, if it were a pretty 
good recording, it could be added with some fanfare to "both" home pages to 
welcome developers in as something they can just watch to learn.

-- 
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/377f69d2-b2d4-46b5-bdd7-383bc85cd3b7n%40googlegroups.com.

[sage-devel] Re: Closing the old Sage wiki

[kcrisman]

Thanks, that's very helpful.

On Tuesday, November 15, 2022 at 2:12:32 PM UTC-5 Matthias Koeppe wrote:

> No decision has been made on this, but a plan is described in 
> https://trac.sagemath.org/ticket/33725. Discussion & help is very welcome.
>
> On Tuesday, November 15, 2022 at 10:57:59 AM UTC-8 kcrisman wrote:
>
>> Query: What is the final decision on these pages (not Trac wiki) 
>> vis-a-vis the vote to move development to GH?   I don't find at least some 
>> of that material on the sample GH wiki, e.g. 
>> https://wiki.sagemath.org/interact/ or 
>> https://wiki.sagemath.org/Workshops but I presume there is a plan. 
>>  Thanks for any info!
>
>

-- 
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/ae86efd5-42b4-4ca3-961d-71e84ef794a8n%40googlegroups.com.

[sage-devel] Re: Closing the old Sage wiki

[kcrisman]

Query: What is the final decision on these pages (not Trac wiki) vis-a-vis 
the vote to move development to GH?   I don't find at least some of that 
material on the sample GH wiki, e.g. https://wiki.sagemath.org/interact/ 
or https://wiki.sagemath.org/Workshops but I presume there is a plan. 
 Thanks for any info!

-- 
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/699153a9-c617-436f-8a87-cbdc7e5dbc43n%40googlegroups.com.

[sage-devel] Re: Help wanted: Trac wiki migration, improve markup conversion code

[kcrisman]

Question (which I am unfortunately unable to assess): Is it possible that 
Trac ticket link of the form #xyzwv could automatically become links to the 
same GH issues once all migration is complete?  I'm thinking of pages 
like https://github.com/sagemath/trac_to_gh/wiki/symbolics - the Trac 
version of this was quite useful.
 
On Monday, November 14, 2022 at 3:55:33 PM UTC-5 Matthias Koeppe wrote:

> As the next step in our migration to GitHub, let's migrate the Trac wiki.
>
> I have done a preliminary conversion of the using our conversion script (
> https://github.com/sagemath/trac-to-github.git) to markdown files, now at 
> https://github.com/sagemath/trac_to_gh/wiki
>
>

-- 
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/b2108d90-af07-4cf0-8f34-0bb52971a5f2n%40googlegroups.com.

[sage-devel] Re: Different results for numerical and symbolic integration

[kcrisman]

> please post here the link to your report
>
>>
https://sourceforge.net/p/maxima/bugs/4037/ 

-- 
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/44ce3946-3dd4-4402-9c71-faadca6366e5n%40googlegroups.com.

Re: [sage-devel] Re: Democratic issue: rushing decisions

[kcrisman]

> If we limit such powers, e.g. allowing just one delaying request per year 
> per person, then another vote can be called on a slightly different 
> question, effectively overruling the delaying request.
>

Whether two requests are two similar is the sort of thing a parliamentarian 
decides in (US-based, at least) committee procedures, e.g. Robert's Rules 
or Keesey, so it is plausible to have in some contexts.  I don't think we 
want to go that route in this forum, of course. 

There is also a question of deciding whether the delaying request is 
> reasonable. The only possibility seems to be to give no reason whatsoever, 
> but this is then effectively a veto power, albeit a temporary one...
>

-- 
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/ab7c19de-0b08-4e6b-8443-613a11d94948n%40googlegroups.com.

[sage-devel] Re: Democratic issue: rushing decisions

[kcrisman]

several developers asked for delays, to respect people with a busy 
> schedule, 
> [6] Thierry : "one month break is a bare minimum." 
> https://groups.google.com/g/sage-devel/c/ayOL8_bzOfk/m/STo_AT9qFgAJ 
>
>
In general I am very sympathetic to having "all deliberate speed" on big 
decisions like this, and John has brought some good relevant points to the 
discussion.  The question of exactly what we were voting on does seem to 
have been not voted on, precisely, but we don't need infinite regress, and 
the consensus did seem to be that these two options were the only ones that 
were feasible for the people who were actually currently volunteering 
effort, and that they did not rule out work on the other possible options 
for when people interested in those would be able to also give time and 
energy to that potential migration/mirroring.

Moreover, it has in fact been over three weeks since this message was sent, 
and the vote only closed yesterday.  A month does seem like a long time to 
wait on an yes/no online vote, particularly when it is neither the Northern 
nor Southern Hemisphere summer breaks, and given that quite a bit of 
explicit fleshing out happened on the proposal.  After all, at different 
times each one of us may have a "busy schedule".  The implied presumption 
seems to be that only things like conferences and beginnings to academic 
years, as opposed to far heavier teaching loads and number of children than 
most people on this list are likely to have, count for "busy", though I 
hope that was not actually the intention.  Nonetheless, probably *everyone* 
on this list has a busy schedule, which is why it is good that the vote was 
only for one specific thing, and it was not a vote that keeps other options 
off the table in the long (or even fairly near) term.  Even for me, this 
seems to have been a decent compromise between all these conflicting things.

(And for the record, I chose to abstain since I have not been able to 
actively contribute code in the last few years because of ... a busy 
schedule.)

-- 
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/321f829a-0322-4c41-a67f-da650ebfde29n%40googlegroups.com.

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

[kcrisman]

On Sunday, October 2, 2022 at 2:16:00 PM UTC-4 Nils Bruin wrote:

> Speaking of backups ... do we backup the sage-devel, sage-support news 
> groups? It contains a lot of stuff that loses relevance with time, but 
> every now and again there are discussions that contain important bits of 
> information. In fact, they are sometimes referred to on trac, via 
> super-opaque URLs. So I suspect google groups going down (which is probably 
> a less unlikely event than github ending) would actually damage those links 
> irretrievably.
>

I guess they are "backed up" by  other news aggregators?  Sometimes those 
are the hits that come up first in Google search, ironically. 
 E.g. https://www.mail-archive.com/sage-devel@googlegroups.com/msg105313.html

Which also points out that we already rely on proprietary software for 
something fairly vital ... not judging that either way, but it's worth 
mentioning.


-- 
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/06028961-8a39-458b-9093-08b8aa8654e9n%40googlegroups.com.

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

[kcrisman]

> I think part of a solution could be PR templates, which add structure to 
> the PR description (= the first comment). That could be a way of adding 
> Authors (and Reviewers) to a PR.


If there's a way to (lightly) enforce that via some kind of bot, that 
sounds very reasonable.

On another note, I realize that the comment I made 6 years ago after 
Volker's comment is still relevant:  
"There's also the non-trivial (though not blocker, probably) issue that 
zillions of links to trac.sagemath.org would instantly be obsolete"

How long do we want to have Trac still exist, but be read-only?  Obviously 
we wouldn't take it down right away, but presumably eventually we would 
need to do so.  

-- 
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/70d22072-efe0-4248-a1f5-3704769722d5n%40googlegroups.com.

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

[kcrisman]

Not sure where to ask this - here?  On the GH page documenting the 
transition and new workflow proposal, I don't see a way to have multiple 
AUTHORs in the way we usually kept track of it.  Note that often there were 
people who were authors who didn't show up on a specific commit, but which 
the discussion on a ticket made clear there was a consensus they should be. 
 (For instance, one might propose some code on sage-devel or sage-support, 
which then someone else puts on a branch.)  Do we have a proposal for a 
mechanism to keep track of this beyond PR-associated emails?  I realize 
that it's possible to put a different author than committer, but I'm not 
sure how that would work with multiple of both.  

If not, hat would not be an insurmountable difference for contributors, but 
would be a change from our historic practice which assigned credit 
"liberally", as it were.  For context, I thought of this as a potential 
contributor was asking about credit issues (not this precise issue, more 
generally) on a ticket.

-- 
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/87584831-2a22-4f43-be96-046840ac480an%40googlegroups.com.

Re: [sage-devel] Re: is it intentional that prod does not stop when it hits 0?

[kcrisman]

On Thursday, September 22, 2022 at 6:06:19 PM UTC-4 wst...@gmail.com wrote:

> Note also that prod(range(1,n)) does *NOT* just multiple 1 times 2 
> times 3 in order. Instead, it uses a tree approach so that the 
> multiplications involve objects with more balanced sizes, which is
>

Thanks for that clarification - I was too lazy to look at the 
balanced_list_prod code :-)

-- 
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/09548ba8-4375-419c-a50c-b40ef5d9bfe9n%40googlegroups.com.

[sage-devel] Re: is it intentional that prod does not stop when it hits 0?

[kcrisman]

I'm not sure what you were expecting.  It does return 0, but it does so 
after all the print statements are done.  Remember, your "test" function 
just returns the input, so the map function just returns a list (well, a 
map object, but ...) and then we prod everything in the list.  But that 
happens AFTER you have done the map on test, and that requires printing out 
all of them.  The prod can't finish up until the entire list has been 
processed via map and the function "test".  I could imagine an alternate 
implementation of prod which checked each time whether zero had been 
produced in an intermediate step, but that doesn't appear to be in the code 
in "prod??".

On Thursday, September 22, 2022 at 10:39:03 AM UTC-4 axio...@yahoo.de wrote:

> sage: def test(n):
> : print("n:", n)
> : return n
> : 
> sage: l = [2,3,5,0,7,11,17,19]
> sage: prod(map(test, l))
> n: 2
> n: 3
> n: 5
> n: 0
> n: 7
> n: 11
> n: 17
> n: 19
> 0
> I expected that it would return 0 once we multiply with 0.
>
> Martin
>

-- 
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/9c864eb6-b8fd-42c4-b1e7-b7eef89deae0n%40googlegroups.com.

Re: [sage-devel] Re: Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[kcrisman]

> Given the tensions, I'd be more careful here. We're really not too 
> interested in opinions of random subscribers to sage-devel 
> (I don't have enough rights to see who's there). 
>

That's a plausible argument, but as with most real-life elections in 
countries without compulsory voting, I suspect our problem will rather be 
too few voters. In any case, it also seems likely that not too many 
"random" subscribers will vote, so hopefully this point will end up being 
moot.  (Other than Harald, whom I hope everyone fully supports getting to 
vote!  Also Andrey N. who may have unsubscribed from this list but is still 
obviously quite active on sage-cell.)

-- 
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/ecafaefb-12cc-4a4c-ab03-1ce8189d0142n%40googlegroups.com.

Re: [sage-devel] Re: Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[kcrisman]

> "Subscribed to sage-devel" might not be a good criteria. For example,
>> Harald Schilly has been the webmaster of Sage since 2007 and likely
>> cares about this switch since it can impact him, but I don't think he
>> reads sage-devel.
>>
>
>>
If we're going to talk about previous practice, I can't remember there ever 
being any criterion other than the sage-devel one.  (And I think a few 
votes have been received by proxy in the past.) 

I still can't find a thread about rules for voting, but I did find this 
presumably relevant one, on another at-least-as controversial topic (but 
please let's not revisit past controversies): So I'll withdraw my 2/3 
proposal, but suggest we do keep sage-devel as the criterion. 
 https://groups.google.com/g/sage-devel/c/dR3_eyIUyac/m/LyALpiLcHuQJ 
 Quoting from William (8 years ago!!!)

This is a simple majority vote for ...
 I will close voting on Monday at midnight PST. (If the vote 
is an exact tie, then that means "No" - there must be a simple 
majority for this to pass.) Any member of the sage-devel mailing 
list may vote or abstain. I will delete any messages in this thread 
that is not a vote -- if you want to make further arguments for or 
against, do so elsewhere. 

And from https://groups.google.com/g/sage-devel/c/dR3_eyIUyac/m/Ooek9-z_oQgJ
I kept the voting simple and 
consistent with how we've done all past votes, rather than using a 
more complicated voting system, since I didn't want to make even the 
voting process itself contentious.

-- 
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/ea60ae31-33c6-45d3-86d5-4ca14169bcf0n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[kcrisman]

> I think the 1st vote should be on moving from trac to Git**b; besides it 
> appears that, technically, move to Github is much easier than to Gitlab 
> (while there are migration tools available for trac->github, I could not 
> find anything for trac->gitlab).
>
> On the other hand github->gitlab move is easy (that's where gitlab gets 
> its business from).
>

Thanks for confirming that, this makes it clearer what the *current* 
options are (simplifying the voting, whether 1/2 or 2/3 or 601/1200 or ...).

On a separate note, can someone explain to me why GL is preferable to those 
who prefer as open of tools as possible to GH?  At first I was under the 
impression that GL was not a business and was largely self-hosted, but it 
appears it's basically similar to GH or indeed Bitbucket (not that I'm 
suggesting we do BB!).  This question is *purely* technical and not 
intended to start a different set of arguments, i just feel that for those 
of us less familiar with GL it is helpful to know why it's preferable to 
some to GH.  (From https://about.gitlab.com/solutions/open-source/ it 
appears to be "open core" but with some important features only 
"source-available"; is that the reasoning?)

-- 
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/4b4aab3b-7067-4106-86cf-6b09f3448031n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[kcrisman]

> I'd rather focus the vote primarily on the move away from trac, not 
> specifying whether it's GitHub or GitLab. 
>
>
>
> > Given that, we face Arrow's theorem in picking a voting system 
> (especially if we also want to allow people to abstain). I'm normally in 
> favor of a Borda count variant, but with three options and Github and 
> Gitlab more similar to each other than to trac, I propose Ranked pairs for 
> a voting system. I suspect there may be voting theory experts lurking, so 
> I'm happy to hear other opinions. 
>
> I'll have a word with my in-house voting theory expert :-) 
>

Who will surely point out the inseparability of the various yes/no options 
here.  Voting system choice is more a sociological matter, in my view, 
which I think is well supported by the arguments of the authors of 
"Properties of Multiwinner Voting Rules, Soc. Ch. Welf. 48:599-632" about 
different goals for "committee" choices in different contexts.

> * There was a proposal to require 2/3 either in favor of a switch or not 
> opposing. I'm open to this, but would be interested in hearing other 
> opinions. Perhaps we allow people to abstain, and then require that at 
> least 2/3 either abstain or prefer the winner to trac? With this in place, 
> maybe our voting system doesn't actually matter, but it's probably safer to 
> pick one. 
>
> I don't see why all of a sudden we talk about 2/3rds, not a simple 
> majority. Have we ever had a vote which was not a simple majority vote 
> here?
>

This was my suggestion (suggestion only).  Namely, with a 2/3 vote, half 
the people who voted in favor would have to change their mind to then vote 
for a different switch.  (Of course, the place that most benefits is if all 
votes are 2/3, which wouldn't be the case here.)  I do feel like we have 
had one or two "supermajority" consensus-seeking situations, but not 
formally so, and no, I can't find them now.

The primary reason I suggested it, though, was to take the emphasis away 
from the controversial aspect, and have the community feel like whatever 
decision is made is one there is strong support for, which then the rest 
might grudgingly agree to for the good of the project (in a worst-case 
scenario; my hope is no grudges!).  Moving to GH to potentially attract new 
developers isn't super helpful if a significant number of long-time, 
*experienced* developers might leave; likewise, staying on Trac isn't 
helpful if some developers (and particularly maintainers) say they just 
can't do it any more because it's so broken.  So this is a real danger. 
 Since a choice of system could lead to a very divisive result, or 
alternately be too confusing for many people to fully participate, I made a 
possible suggestion.

However the vote is structured (yes, we voting theorists also do stupid 
things like voting on voting systems ...), in my view the primary 
importance is finding a solution that dozens of our most valuable 
contributors (front-end and back-end) can at least live with, and then have 
a purely pro forma vote on that.  Otherwise we could have literally dozens 
of options, many of which it's unclear from this thread whether they are 
even realistic.   Is the following link helpful in that regard?  

https://docs.gitlab.com/ee/user/project/import/github.html#mirror-a-repository-and-share-pipeline-status

It seems like it really would be possible to move to GH, and then have any 
interested volunteers who care deeply about GH versus GL set up a mirror. 
 (Presumably Premium GL is still a lot cheaper than Google Cloud hosting of 
Trac?  That might be wrong.)  Or even to set up a self-hosted GL mirror on 
an academic account.I feel like something along these lines would a) 
not waste the effort already made at putting together a proposal to move to 
GH b) alleviate some concerns over GH longevity/policies c) put the work on 
the GH move on people who want to leave Trac and the work on a GL move on 
those who want to stay, so such load seems more equitable.

Perhaps one could then have a true (even majority up/down) vote on leaving 
Trac, with the understanding that there is no objection or even 
encouragement to finding GH substitutes to stand in if/when necessary, 
maybe even for syncing.  Sort of like how many of the 13 North American 
British colonies only voted for the Constitution with the guarantee 
(implicit) that the Bill of Rights would be immediately forthcoming ... 
nah, that's a bit too dramatic!

-- 
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/f92bd0d2-f732-4abd-b874-ffbbe6df2189n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[kcrisman]

> > Consensus ?!  Hmm - consensus means that everyone is for. I don't think 
> we will have it. So we can stop now, no?  I think a simple majority is a 
> meaningful way to vote here. 
>

Also, given the level of activity here, a separate thread for voting on 
this (whenever that becomes appropriate, presumably one would want at least 
a full week of discussion on the current one to allow for people on 
vacation, etc. to catch up) probably will also attract a high level of 
interest from anyone who cares, and be easily completable in a short time 
period.

-- 
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/c5ac66f7-fb0d-48a1-a708-5780e09ce9ebn%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[kcrisman]

> While I strongly support the shift to github, I also agree with Travis 
> that we should vote on a change this major, and give the community enough 
> time to weigh in.  I would also encourage people on both sides of the 
> debate to give everyone the benefit of the doubt.  To those who have been 
> putting in a ton of work attempting to fix trac in recent weeks, our broken 
> infrastructure is both frustrating and gives a sense of urgency.  To those 
> who have spent over a decade using trac, the most recent iteration of this 
> discussion (starting four days ago) feels very rushed.
>

Well said on both counts.

> Consensus ?!  Hmm - consensus means that everyone is for. I don't think 
we will have it. So we can stop now, no?  I think a simple majority is a 
meaningful way to vote here. 
 
I think that's been the historical practice (recall the document William 
refers to in the Bernoulli # thread, which I think said something like at 
least 5 or 10 total votes + majority, though I also no longer know where it 
resides), but it probably wouldn't hurt to ask for a 2/3 majority to work 
against buyer's regret (see Saari's Basic Geometry of Voting for a nice 
historical example of this still in use) since that is as close to a "true" 
consensus we are likely to achieve here.  Or at least a 2/3 majority of 
"Yes" and "Won't oppose" combined, since I find myself in the latter camp - 
and I think with continued careful discussion of the technical challenges 
of keeping Trac alive combined with continued concrete proposals for how to 
most safely transition to GH (GL?) that won't be a problem to get.

-- 
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/51062568-886c-495e-9672-cce4d702de80n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[kcrisman]

For what it's worth, I think that Jan makes some very salient points, such 
as

> I'd be happy to assist with self-hosting (so gitlab) and perhaps sponsor 
a container (even a separate machine for CI) but I think the sagemath 
project would probably be better off on git**b. I'm also hesitant to invest 
my time in learning trac/gitolite. The bus problem Dima mentioned with 
self-hosting is valid. But nice to have it as an option for a quick exit 
(from either git**b) when whatever happens to the companies... 

The real problem with GH is if we end up locked in.  As much hassle as Trac 
is (and once again, for what it's worth, let me gratefully acknowledge 
those who are keeping it up and running in whatever state is possible), not 
being able to get stuff OFF GH is the real issue.

For me, the comparison is with learning management systems that many people 
who have higher teaching loads than the typical core Sage developer (!) are 
required to use.  While there are import-export tools from one to another, 
they are nontrivial and do not always bring by any means the full content 
with.  In addition, the internal export (say, to pdf or some other 
transferable medium) can be tiresome in the extreme, when it's even 
possible.  So in some sense we don't have very good control of our own 
content, which is very frustrating when I want to use something from our 
LMS that is wholly inside of it.

The advantage of Trac is having full control of all the data (among others, 
but for the sake of this point), as well as the VERY extensive ticket 
history and seemingly endless discussions (I view those as a strength of 
the community, on the whole).  One really doesn't want to underestimate 
that.  The advantage of GH is nearly completely convenience (and there are 
many conveniences, Aram's point is very well taken).  It sounds like there 
is a pretty reliable GH -> Gitlab mechanism as well, and people willing to 
host a GL instance on (French?) academic computers.

So is a possible solution to migrate Trac, *including the entire history of 
discussions*, to GH, and then have a GL mirror of this?  It was unclear 
from the comments in this thread whether one can actually real-time mirror 
GH in GL, or only export  via discrete actions (and presumably not 
realistically to mirror).  Secondarily, one could imagine an automated 
action that on (say) a point-release basis exports to GL, and that we can 
point people to that.  I'm not sure how contributions from folks who on 
principle do not want to support GH would work, but doubtless we aren't the 
only project to have that problem.

- kcrisman


-- 
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/b4bbb5db-2a41-4683-a811-f44e04d472efn%40googlegroups.com.

[sage-devel] Re: BROADCAST MESSAGE

[kcrisman]

And let's all broadcast a hearty thanks to the many people working hard to 
figure out what's going on and keep Sage development going!!!

On Friday, September 2, 2022 at 2:47:04 AM UTC-4 Frédéric Chapoton wrote:

> Dear Sage developers,
>
> in order to try to fix the recent upgrade, the *trac web server will be 
> turned off this saturday 03/09/2022*, from 7.00 (Paris time) to 23:00 
> (Paris time ; https://time.is/Paris).
>
> PLEASE take again a short break and resume using trac next week!
>
> Sorry for the inconvience, and thanks for your patience.
>
> Frédéric
>

-- 
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/00800c6e-920e-435f-bd7c-d7ce62a2f41an%40googlegroups.com.

Re: [sage-devel] Solving quintics

[kcrisman]

For reference, is there a Trac ticket for this?  (But don't look now, wait 
until the current outage is resolved!)

On Tuesday, August 30, 2022 at 6:01:35 AM UTC-4 achi...@gmail.com wrote:

> Hello all,
>
> with the described class library, it is now possible to solve irreducible 
> solvable Bring-Jerrard quintics, i.e. f(x) = x^5 + ax + b. Coefficients are 
> calculated up to a certain limit which is based on the Cantor counting 
> scheme of rational numbers with default maxValue = 20. Higher number 
> coefficients max be generated if needed; however, due to O(n^4) complexity 
> in generating the Spearman Williams coefficients, this is limited to 
> maxValue = 100 currently. Contact the author for an extension if higher 
> number coefficients are required.
>
> I have copied over the updated files, including a test script called  
> TestWorksheetBJ.sagews.
>
> Any feedback is appreciated. It might be interesting also to look at 
> quartic Tschirnhaus transformations of general quintics which yield 
> solvable Bring-Jerrard quintics.
> Best regards
> Achim
>
> Fat i schrieb am Samstag, 6. August 2022 um 08:40:59 UTC+2:
>
>> Thanks, David, that´s very helpful. I will look a bit deeper into these 
>> approaches.
>>
>> Kind regards
>> Achim
>>
>> David Roe schrieb am Freitag, 5. August 2022 um 23:11:54 UTC+2:
>>
>>> Hi Achim,
>>> Many of the polynomials you mention can be factored by Sage if you use 
>>> number fields for your coefficients rather than the symbolic ring.  For 
>>> example:
>>>
>>> sage: R. = ZZ[]
>>> sage: K. = NumberField(x^2 + x + 1)
>>> sage: f = x^5 + 9/2 * x^4 - 5/2 * x^3 - 2*w * x^2 - 9*w * x + 5*w
>>> sage: f.factor()
>>> (x - 1/2) * (x + 5) * (x^3 - 2*w)
>>>
>>> There's a separate question of trying to write the roots of an 
>>> irreducible polynomial in terms of radicals.  The process for doing this 
>>> depends on the Galois group (you can find examples of number fields with 
>>> each of the possible degree 5 Galois groups 
>>>  using LMFDB searches like this 
>>> ).  If the Galois 
>>> group is not solvable (S5 or A5 in the degree 5 case), it's not possible to 
>>> write roots in radicals.  If it is solvable, you can find a chain of 
>>> subgroups where each successive quotient in the chain is cyclic, and then 
>>> use Kummer theory to express each extension as adjoining an nth root.  
>>> After expressing the Galois closure as an iterated extension in this way, 
>>> you can then factor your original polynomial in this field.  
>>> Computationally, this gets to be very expensive as the degree of the Galois 
>>> closure increases, but it's totally doable for quintics.
>>>
>>> If you want to learn more about this topic there are plenty of good 
>>> references on Galois theory.  I think a function that used Sage's Galois 
>>> groups (which are computed by Pari under the hood) in order to express 
>>> roots of a polynomial symbolically in terms of nth roots (when possible) 
>>> would be a nice contribution.
>>> David
>>>
>>> On Fri, Aug 5, 2022 at 1:44 PM Fat i  wrote:
>>>
 Hello,

 I am new to this group and got the suggestion to post this here which I 
 am happy to do. If you are interested in polynomials, esp. solving 
 quintics, you may have a look at

 CoCalc -- Development 
 

 I have spent some time studying quintics and implemented a class 
 library which wraps and extends SAGE capabilities., Happy to receive your 
 feedback or questions, or let me know if you would like to contribute or 
 collaborate.

 Check the README.md file for an overview.

 Kind regards
 Achim

 -- 
 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+...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/sage-devel/b5a63fbb-456b-446e-b270-abcefad57dabn%40googlegroups.com
  
 
 .

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/41888d64-69c8-496c-ad9d-bfcd3e127939n%40googlegroups.com.

Re: [sage-devel] Re: MSC-2020 -- Class 52: Convex and Discrete Geometry -- CAS Citations from 2000 to 2021

[kcrisman]

> let me take the opportunity to promote the use of the get_systems 
> function from sage.misc.citation which allows to see and acknowledge 
> which upstream packages were used by Sage for some computation, e.g. 
>
>
+1 

-- 
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/df5cabdf-9ac3-4da0-8b3f-b61dae75e26cn%40googlegroups.com.

[sage-devel] Re: MSC-2020 -- Class 52: Convex and Discrete Geometry -- CAS Citations from 2000 to 2021

[kcrisman]

> I take this opportunity to thank the Sage community and the developers of 
> related softwares integrated for this Huge effort and to let you know of 
> the positive comments that I receive form the research community in MSC-52. 
> THANK YOU SO MUCH!
>
> If you are interested in a deeper analysis, I produced detailed graphics 
> and provide the raw data in a Jupyter notebook on my webpage:
>
> https://jplab.github.io/sage_cite.html


Great post! 

-- 
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/df751ae8-4a28-400e-bb32-191fe82c4cbbn%40googlegroups.com.

[sage-devel] Re: Display of scale multiplier in scientific notation (the e notation for powers of ten) is missing for plots starting with 0

[kcrisman]

This looks likely, thanks!  The next step for you (and all of us) would be 
as follows:

1) Neither of these codes are so long that you couldn't put them as 
formatted text in comments on the relevant ticket.  Use {{{ code }}} to 
format them.

2) If you could (on the ticket) attach or link to images of the 
before/after, that would be very helpful.  Particularly the `use_mathtext` 
option being different would need discussion and comparison.

Thanks! I hope others look at this issue too, as I may not have margin for 
a full review at this time.

On Friday, July 29, 2022 at 4:31:02 PM UTC-4 niran...@gmail.com wrote:

> Wait, i just solved it!
>  It is not the issue with matplotlib but with the construction of 
> SelectiveFormatter. 
> This formatter construction is incomplete. I have created two new 
> customized ScalarFormatters (default formatters used by matplotlib), the 
> second one would be a good new addition to sage along with the first one. 
> We can have both. I have worked out same situation but in native python 
> with matplotlib. Only thing is to adapt it to sage. It won't be hard to do 
> that, just need slight adjustments. Please look into the attached two 
> example python files.
>
> Inspired from:
> https://stackoverflow.com/questions/11244514/modify-tick-label-text
> <-- Discusses similar issue (see second answer from last)
>
> https://stackoverflow.com/questions/63475934/skipping-certain-values-in-python-with-matplotlib
>
> https://github.com/matplotlib/matplotlib/blob/4f5cacfde9024076d9ab0cb6ad1c9a7cf352d5f9/lib/matplotlib/ticker.py
>
>
> On Saturday, July 30, 2022 at 12:05:24 AM UTC+5:30 kcrisman wrote:
>
>> Time being solution would be to drop use of  SelectiveFormatter to get 
>>> rid of 0 tick label if the axes cross. Let the origin be visible for some 
>>> time.
>>>
>>
>> My guess is that this would not be seen as a great fix, but let's put 
>> images and other followup on the ticket.
>>
>

-- 
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/4dae16a5-3024-46de-bf86-1cd5a233858fn%40googlegroups.com.

[sage-devel] Re: Display of scale multiplier in scientific notation (the e notation for powers of ten) is missing for plots starting with 0

[kcrisman]

> Time being solution would be to drop use of  SelectiveFormatter to get 
> rid of 0 tick label if the axes cross. Let the origin be visible for some 
> time.
>

My guess is that this would not be seen as a great fix, but let's put 
images and other followup on the ticket.

-- 
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/40e9f372-8e0a-4887-a6b0-ae984de05a19n%40googlegroups.com.

[sage-devel] Re: Display of scale multiplier in scientific notation (the e notation for powers of ten) is missing for plots starting with 0

[kcrisman]

This is now https://trac.sagemath.org/ticket/34233

-- 
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/03391f57-609e-492b-8a78-1fa1c6fdef0cn%40googlegroups.com.

[sage-devel] Re: Display of scale multiplier in scientific notation (the e notation for powers of ten) is missing for plots starting with 0

[kcrisman]

Thanks for the continued conversation.  I hope it was clear that "we would 
be grateful" implied that there was no compulsion on your part, as well as 
on the part of any other contributor.

I did notice the mathtext option, but since our previous version had used 
the e notation, changing that would be a separate ticket, and probably need 
some discussion.

I found it ! The problem is  in use of  SelectiveFormatter to get rid of 0 
> tick label if the axes cross. Commenting out lines
>

Great! That is half the battle, good detective work.. 

However, I couldn't replicate the example you gave - among other thing, 
show(p) gave me something that wasn't plottable (I had to use savefig etc. 
on the figure itself).  Also, what is your modified version trying to show 
- the missing part, or a potential solution?  Thanks!
 

>
> https://github.com/sagemath/sage/blob/develop/src/sage/plot/graphics.py#L2983
> to
>
> https://github.com/sagemath/sage/blob/develop/src/sage/plot/graphics.py#L2986
> from sage.plot.plot import SelectiveFormatter
> subplot.yaxis.set_major_formatter(SelectiveFormatter(
> subplot.yaxis.get_major_formatter(), skip_values=[0]))
> subplot.xaxis.set_major_formatter(SelectiveFormatter(
> subplot.xaxis.get_major_formatter(), skip_values=[0]))
>
> will bring back the scaling factor in scientific notation. But on the 
> downside it will print the origin 0.
>
> SelectiveFormatter use itself has this issue. A modified version of usage 
> example of SelectiveFormatter in Sage reference >> 2D Plotting
>
> from sage.plot.plot import SelectiveFormatter
> import matplotlib.pyplot as plt
> import numpy
>
> fig=plt.figure()
> ax=fig.add_subplot(111)
> t = numpy.arange(1000, 1010, 100)
> s = t
> p = ax.plot(t, s)
>
> formatter=SelectiveFormatter(ax.xaxis.get_major_formatter(),skip_values=[0,1])
>
> formatter=SelectiveFormatter(ax.yaxis.get_major_formatter(),skip_values=[0,1])
> ax.xaxis.set_major_formatter(formatter)
> ax.yaxis.set_major_formatter(formatter)
>
> show(p)
>
>>
>> ​
>>>
>>

-- 
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/4f7359fd-3b14-4f03-9cd6-0f953d8c5567n%40googlegroups.com.

[sage-devel] Re: Display of scale multiplier in scientific notation (the e notation for powers of ten) is missing for plots starting with 0

[kcrisman]

This is a good question, and one that has been around for a while in some 
form, unfortunately; see https://trac.sagemath.org/ticket/7964 for a 
related ticket.   See https://trac.sagemath.org/ticket/30983 for a ticket 
that complains instead about something else but which is closely related.

We would be grateful for any additional insight you might provide.  Here 
are some pieces of info about where we use matplotlib that you might find 
useful in that regard.

We use some specific matplotlib ticker and formatter options which don't 
always play well here. 
 See 
https://github.com/sagemath/sage/blob/develop/src/sage/plot/graphics.py#L2326 
for _matplotlib_tick_formatter in sage/plot/graphics.py

In particular, note that, under ordinary circumstances,

y_locator = MaxNLocator(**locator_options)
y_formatter = ScalarFormatter()

That is very close to the defaults for matplotlib, but maybe we are using 
things in an antiquated way.  See 
e.g. 
https://matplotlib.org/stable/api/ticker_api.html#matplotlib.ticker.ScalarFormatter
 

On the other hand, if (as I suspect) that isn't the root issue, it probably 
is in the save method 
(https://github.com/sagemath/sage/blob/develop/src/sage/plot/graphics.py#L3198).
 
 My first thought was that somehow fig_tight played a role, but 

sage: plot(x^2,(x,0,5000),fig_tight=False)

doesn't seem to be any different than the one you pointed out.  Another 
possibility is tight_layout 
(https://matplotlib.org/stable/api/tight_layout_api.html) which we do use, 
but which a little experimentation doesn't seem to indicate is the problem 
either.
On Tuesday, July 26, 2022 at 5:15:11 AM UTC-4 niran...@gmail.com wrote:

> Dear all,
> "2D plotting" doc says,
> "Another thing to be aware of with axis labeling is that when the labels 
> have quite different orders of magnitude or are very large, scientific 
> notation (the e  notation for powers of ten) is used."
>
> But display of this multiplier power for the scaled y-axis is missing if 
> the plot starts with x=0 or at most will be missing till the x-axis 
> detaches from the origin. Following examples illustrates it,
>
> *sage:*  plot(x^2,(x,0,5000))  # missing display of 1e7 above y-axis
> *sage:*  plot(x^2,(x,50,5000))  # missing display of 1e7 above y-axis
> *sage:*  plot(x^2,(x,100,5000))  # display of 1e7 above y-axis is visible
>
> On the other side matplotlib natively always displays the scale multiplier 
> (if any) whenever numbers are large. For example:
>
> *sage:*  import matplotlib.pyplot as plt
> *sage:*  import numpy as np
> *sage:*  z = np.linspace(0, 5000, 100)
> *sage:*  plt.plot(z, z**2)
> *sage:*  plt.show()
>
> My other plots involved electric field calculations which had magnitudes 
> around 1/epsilon_0 which is 1/(8.85E-12) =~ 10^11. For those plots starting 
> with x=0 the display of multiplier used for y-axis were missing.
>
> With regards
> Niranjana
>

-- 
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/146eb3ef-49bf-4f06-8e40-3c21c7a67bd5n%40googlegroups.com.

Re: [sage-devel] Introduction to differentiable manifolds in SageMath

[kcrisman]

By the way, addressing the original topic, there is still the possibility 
of adapting these to the Sage tutorials 
at https://doc.sagemath.org/html/en/thematic_tutorials/index.html which 
would be a great contribution - just a suggestion in case the authors are 
interested.

-- 
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/9f7800b4-30c0-4315-8ad7-e88abc643443n%40googlegroups.com.

Re: [sage-devel] orbit decompositions

[kcrisman]

On Tuesday, May 3, 2022 at 7:48:07 AM UTC-4 axio...@yahoo.de wrote:

> Won't you be better off thinking of it as a representation, then?
>
>
Correct, but I don't know how to construct those on arbitrary vector spaces 
in Sage.  That is to say, if I know the vector space, and I know the 
action, but it's not some well-known one like the permutation 
representation on a finite set by the symmetric group on that set. 

-- 
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/d3ecc07e-7235-4dc4-bbb4-0652cdfbbb71n%40googlegroups.com.

Re: [sage-devel] orbit decompositions

[kcrisman]

On Monday, May 2, 2022 at 11:24:44 AM UTC-4 axio...@yahoo.de wrote:

> I am actually not sure anymore, which methods or functionality this class 
> should provide.
>
> Would it possibly be better to enhance PermutationGroup with an additional 
> optional "from_action" and "from_cyclic_action" argument?  Eg.:
>
> PermutationGroup(domain = X, cyclic_action = lambda x: f(x))
>
> PermutationGroup(domain = X, group_action = (G, lambda g, x: f(g, x)))
>

I'm thinking here also of actions on other sets, though, which wouldn't 
just be a matrix representation, unless I'm misunderstanding the purpose of 
these function signatures.   In particular, an action of a group on set of 
vectors, which stay vectors.  Examples:
* Permutation group of 3 elements on 3-vectors in obvious manner
* Permutation group of 3 elements on 6-vectors in non-obvious manner where 
they are indexed [e,(12),(13),(23),(123),(132)] or something like that

-- 
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/0c9ee591-092d-4c93-a6d7-d219f936b327n%40googlegroups.com.

Re: [sage-devel] orbit decompositions

[kcrisman]

On Sunday, May 1, 2022 at 7:32:01 PM UTC-4 Travis Scrimshaw wrote:

> Sorry, I don't know an easy way. I've always just defined them by hand 
>>> whenever needed. 
>>> However, I agree with you that a better way is needed. 
>>>
>>
>> I would love for there to be some standard way to define a group action 
>> on a set - preferably maintaining other algebraic properties of the set, 
>> such as addition!  But I don't know if there is even close to a standard 
>> way to do this either. 
>>
>
> - There is a standard way to do this, but not a generic method/class for 
> it IIRC. You can do this by implementing an _act_on_() method on a wrapper 
> class. Yet, this requires some manual input.
> - For cyclic actions, there is the DiscreteDynamicalSystem class 
> introduced in https://trac.sagemath.org/ticket/24128.
> - There is also the Representation class in 
> modules/with_basis/representation.py if you want to want to extend the 
> action on the set to the module with a basis given by that set.
>
> Likely we will want to implement a class SetWithAction that automates a 
> collects the orbit_decomposition functions and similar together as methods 
> as a single global entry point.
>
>
Hmm, maybe a tutorial is needed for this.  I would imagine that a lot of 
people who aren't familiar with how to create a new wrapper class would be 
the ones who need this.   Of course, the FiniteGroupAction suggestion 
sounds quite welcome, too, though really having both options would be best.

-- 
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/5300f5bd-7e75-41d5-980d-cf207ce2e40fn%40googlegroups.com.

Re: [sage-devel] orbit decompositions

[kcrisman]

On Thursday, April 28, 2022 at 11:26:12 AM UTC-4 David Joyner wrote:

> On Thu, Apr 28, 2022 at 9:35 AM 'Martin R' via sage-devel 
>  wrote: 
> > 
> > I don't know about OrbitDomains, how does it work / how do you use it? 
> > 
>
> The documentation has an example: 
> https://www.gap-system.org/Manuals/doc/ref/chap41.html 
>
> > Is there a standard (and easy) way to define an action (in particular, a 
> cyclic action) on a set in sage? 
> > 
>
> Sorry, I don't know an easy way. I've always just defined them by hand 
> whenever needed. 
> However, I agree with you that a better way is needed. 
>

I would love for there to be some standard way to define a group action on 
a set - preferably maintaining other algebraic properties of the set, such 
as addition!  But I don't know if there is even close to a standard way to 
do this either. 

-- 
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/7cf623b6-fa29-4dc5-b81b-f2da3f96ff55n%40googlegroups.com.

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

[kcrisman]

On Tuesday, April 26, 2022 at 10:31:17 PM UTC-4 Matthias Koeppe wrote:

> An update: The latest version of the installation manual (from 
> https://trac.sagemath.org/ticket/33655) is available here: 
> https://7896a56df78170d5bab0f306d1a7230986a4206a--sagemath-tobias.netlify.app/installation/index.html
>
>
Thanks, much improved! 

-- 
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/1fa37c3a-3766-42cd-9947-acb0adc05225n%40googlegroups.com.

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

[kcrisman]

If we're moving away from providing binaries, then this is a good way to 
go, well organized.  Below a few minor notes about the sagemath-tobias 
link, I hope they are helpful.  My apologies in advance for any bike 
shedding, though I tried to be pretty concrete.

1. Is it possible to have a short bullet list for the three/four options
* Linux
* Mac
* Windoze
* Cloud
that link to those, immediately below "Where would you like to run 
SageMath?"?  I'm pretty sure Sphinx makes that possible.  Even a little bit 
of needed scrolling leads to people just not caring.

2. I'd also recommend Linux be last - this page is designed for people who 
are not comfortable installing source software, I guess.  (Similarly, no 
development as first option?)

e. Alternately, one could have the first decision point be "develop or not" 
- that would be my preference, but obviously would be an annoying bit of 
work with perhaps not that much marginal gain.  Still, that seems to be the 
great divide in Sage, not so much platform, and would allow for people who 
want to just use Sage in the cloud to see that option very early.  It's not 
like people on (say) Windows don't also use the cloud, so the four-way 
partition could be somewhat misleading to less careful readers (which many 
internet users are when in a hurry) in practice, though of course not in 
principle.

3. Do the binaries/packaging allow for all optional packages and/or using 
Cython/Fortran?  I recall this coming up not only on this list, but also 
sometimes when I've tried to show people Cython usage as a "great feature" 
of Sage that doesn't work in some environments.  If the answer to any of 
these is not, you might need another part of the decision tree, or at least 
a link to something about optional packages in each "no development" part.

4. A link to some Windows doc on what WSL is would probably be pretty 
helpful, since presumably a lot of Windows users who like doing math have 
never heard of it.

-- 
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/9d1a5022-ad08-4fd7-8ec4-1132ab4257b9n%40googlegroups.com.

[sage-devel] Re: Sage binary for macOS

[kcrisman]

Thanks for all your work on this!

On Saturday, April 23, 2022 at 6:39:16 PM UTC-4 marc@gmail.com wrote:

> A prelease version of the macOS Sagemath app based on Sage 9.6.rc0 has 
> been available  on 
> github for about a week now.  I am writing to ask people with Apple 
> computers to test the app and report problems as github issues.
>
>  
The basics look okay on Big Sur, M1 Chip.
 

> So far there have been 42 downloads for arm64 and 29 downloads for Intel, 
> which I find interesting.  It is hard to believe that the M1 SOC has 
> already become the dominant macOS platform for Sage.  But, who knows?
>
>
For developers, perhaps, who in some cases are the sort of people who like 
having shiny new things and in other cases have their shiny things 
semi-regularly replaced by their employers.  (Of course, this doesn't at 
all universally obtain!)

-- 
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/fd4fc06f-a7a7-45f5-84de-be5519df58a5n%40googlegroups.com.

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

[kcrisman]

> Everyone agrees on that part, but how to go about it is a religious 
> matter.


Truth.
 

> I've been using sage, teaching with sage, writing papers that 
> cite sage, and giving presentations about my research that use sage for 
> about fifteen years. I have literally never met someone besides myself 
> who has managed to install it. The only installation procedure that 
> anyone uses is, 
>
> 1. Give the computer to mjo 
> 2. It comes back in the morning with sage installed 
>
>
Though I can identify with the frustration from personal experience, 
thankfully, for at least half of Sage's history (non-consecutive, to be 
sure), that hasn't been literally true on Mac.  And for Windows, it still 
seems pretty reasonable to say that if we don't have a 
drag-and-double-click solution (whether using Cygwin or WSL or whatever), 
many will use it via Cocalc or (more likely) not at all.

On a seemingly unrelated note which is actually quite related, I don't 
think it would be possible to find this out, but it would be interesting to 
know at what rate there has been user -> developer conversion over the 
years.  

-- 
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/c2d96638-1490-4106-9b05-79de75faa3afn%40googlegroups.com.

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

[kcrisman]

On Friday, April 22, 2022 at 2:10:45 PM UTC-4 David Roe wrote:

> I haven't been following the copy and paste thread, but I'm in favor of 
> keeping sage -i xyz functional, even at the cost of some hacks in our 
> codebase.  There are a lot of existing Sage users who are familiar with 
> that command as a mechanism to install optional packages, even if it's not 
> a priori discoverable for new users of Sage.
> David
>>
>>
>>
+1

 

-- 
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/550e6002-e9e1-411c-80bf-555841e3eb44n%40googlegroups.com.

Re: [sage-devel] divmod() vs .quo_rem()

[kcrisman]

Just for reference, Sage already has divmod() (e.g. 
https://sagecell.sagemath.org/?q=owmsez) and returns a tuple of Sage 
integers, so maybe we already do?  I don't know about the magic method 
though.  quo_rem() was the one new to me, and doesn't actually appear to be 
defined - did you maybe mean the other way around?

On Tuesday, April 12, 2022 at 10:46:31 AM UTC-4 David Roe wrote:

> I see no reason why Sage couldn't support divmod() in addition to 
> quo_rem().
> David
>
> On Tue, Apr 12, 2022 at 9:46 AM Lorenz Panny  wrote:
>
>>
>> Python defines divmod() and the associated .__divmod__() magic method
>> for what Sage calls .quo_rem().
>>
>> Is there any reason why Sage shouldn't or cannot support divmod()?
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/20220412214635.2dd69295%40l.
>>
>

-- 
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/d13cb046-14d2-49ba-bc02-644862f41779n%40googlegroups.com.

[sage-devel] Re: _SAGE_VAR_minus and Maxima limit direction

[kcrisman]

https://trac.sagemath.org/ticket/33692

On Monday, April 11, 2022 at 6:38:28 PM UTC-4 Nils Bruin wrote:

> That's a fairly straightforward thing to fix: it just means that the 
> sage-to-maxima interface needs to learn how to translate "plus" and "minus" 
> in limit expressions.
>
> The easiest way would be to tell the interface that "plus" and "minus" are 
> symbols that need a hardcoded translation. A more subtle version would put 
> a special translation in place for a symbolic "limit" to treat the 
> direction argument separately.
>
> Perhaps a slightly cleaner way of triggering the error:
>
> function('f')
> limit(f(x),x=0,dir="-").simplify()
>
> Someone should file a bug report.
> On Monday, 11 April 2022 at 05:17:22 UTC-7 jkma...@gmail.com wrote:
>
>> `integrate()' function on non-elementary integrals outputs sometimes a 
>> limit function, ie:
>> In: k = var("m", domain='positive', latex_name=r"\hat k" );
>> In: N_nr = integrate(k^2/(exp(k)+1), (k, 0, oo))
>> Out: `limit(1/3*k^3 - k^2*log(e^k + 1) - 2*k*dilog(-e^k) + 2*polylog(3, 
>> -e^k), k, +Infinity, minus) + 3/2*zeta(3)`
>>
>> Analytically, the part under the limit is equal to 0 (compare to 
>> mathematica's  N_nr = Integrate[k^2/(Exp[k] + 1), {k, 0, Infinity}]
>>
>> On simplify, the engine tries to evaluate the limit using maxima and fails
>> In: N_nr.simplify()
>> Out: TypeError: ECL says: Error executing code in Maxima: limit: 
>> direction must be either 'plus' or 'minus'; found: _SAGE_VAR_minus 
>>
>> Something seems to be off from putting this sage expression to maxima.
>>
>> Version: Sage 9.3
>> OS: Windows 10 Pro, 21H2, x64
>>
>

-- 
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/2226fe11-5263-4ccb-abad-1d71364ca638n%40googlegroups.com.

[sage-devel] default interact widget for single value

[kcrisman]

Thanks to a lot of good work a few years back, we have fairly close 
alignment between historic @interact behavior on the Jupyter notebook (from 
ipywidgets) and the previous sagenb behavior.  Sage cell server and CoCalc 
Sage worksheets are very close indeed.

One fairly glaring difference I'm noting is the default for a single 
integer or real value.  In the past (and on Sage cell) this would uniformly 
give a text box which would allow for the user to input different values - 
not a slider or drop-down list, for which we have other syntax. 
 See 
https://sagecell.sagemath.org/?z=eJxzyMwrSS1KTC7h5UpJTVOI10i0NdW04uVSAILijPxyjcQ4I00A0wwKWA===sage=eJyLjgUAARUAuQ==

However, at the time that support was given to have single objects like 
matrices and colors (again, awesome!), apparently this fell through the 
cracks. 
 At 
https://github.com/sagemath/sage/blob/develop/src/sage/repl/ipython_kernel/interact.py#L150
 
after those cases are handled, then they are sent to ipywidget defaults, 
which are pretty ad-hoc - see this, which has things like 
elif value > 0:
vrange = (-value, 3*value)
else:
vrange = (3*value, -value)
https://github.com/jupyter-widgets/ipywidgets/blob/fcadca8fbdc18ef1d8dc5694e8e6e759af6c7749/ipywidgets/widgets/interaction.py#L96

I think it would be pretty easy to restore previous behavior by simply 
removing the attempt at existing ipywidgets here.  However, it's probably 
been long enough now that there are too many different implementations to 
do so without at least asking on sage-devel.  I would definitely be in 
favor of making the behavior as similar on all outputs as possible (note: I 
have not used Jupyterlab yet, so I haven't a clue what will happen there, 
hopefully same as Jupyter proper w/ipywidgets).  I probably could even dust 
off my git skillz enough to send a branch to Trac.  

Any thoughts, including from Andrey and/or William as caretakers of Sage 
cell and CoCalc implementations, would be most welcome.  Thanks!
- crisman

-- 
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/3e34f4ee-12b6-4686-b019-3cf4fb7dcc2fn%40googlegroups.com.

[sage-devel] Re: Proposal: make Jupyterlab a standard package

[kcrisman]

Sorry for a tangential question - the overview page seems to imply that 
*everything* from a (current) Jupyter notebook will work in a Jupyterlab 
instance (and, by extension, presumably can easily be imported).  Would 
that include the widgets we use for @interact?

(Tail wagging the dog here is that upgrading sagenb -> jupyter was already 
nontrivial for many "customers", though thanks to a huge amount of work by 
people-not-me a good export solution was found.)

PS: Would I be right in saying Jupyterlab is RStudio for Jupyter?
On Tuesday, March 22, 2022 at 6:44:37 AM UTC-4 Eric Gourgoulhon wrote:

> Hi,
>
> The optional package Jupyterlab has been upgraded to version 3.3.1 in 
> https://trac.sagemath.org/ticket/32069
> (merged in Sage 9.6.beta5)
>
> Jupyterlab offers more functionalities than the classic Jupyter Notebook 
> and is aimed to replace it, see e.g.
> https://jupyterlab.readthedocs.io/en/stable/getting_started/overview.html
>
> Maybe it is time to make it a standard package in Sage. 
>
> To be clear, this is not to switch (yet) the default notebook interface 
> from the  classic Jupyter Notebook to Jupyterlab, but simply to make the 
> following commands work out of the box:
>
> (1) sage -n   
> (2) sage -n jupyterlab
>
> with (1) launching the classic Jupyter Notebook (current behavior).
> At the moment, (2) fails by complaining that Jupyterlab is not installed. 
>
> In a second stage, we could get rid of the Jupyter Notebook as a standard 
> package, but still keeping the same user interface as (1) and (2)  thanks 
> to the extension nbclassic of Jupyterlab. This extension has been added to 
> #32069. Then (1) will run Jupyterlab with the nbclassic interface, which is 
> identical to the classic Jupyter Notebook one. 
>
> In a third stage, we could make Jupyterlab the default by having (1) 
> running it and having the old interface still accessible via
>
> (3) sage -n nbclassic
>
> Please vote. 
>
> Eric. 
>

-- 
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/dabcaa2e-e2bb-498f-bfef-3c9c8f39a2b6n%40googlegroups.com.

[sage-devel] Re: arctanh vs. artanh

[kcrisman]

In terms of the missions statement, apparently we aren't the only ones, so 
consistency might be more important in any 
case: https://reference.wolfram.com/language/ref/ArcTanh.html

Note e.g. sympy uses atanh as the 
"ordinary": 
https://docs.sympy.org/latest/modules/functions/elementary.html#atanh

On Wednesday, March 23, 2022 at 4:54:16 AM UTC-4 Samuel Lelievre wrote:

> Note that Sage also provides aliases with `a-`
> (the display is still with `arc-`):
> ```
> sage: asinh, acosh, atanh, acoth, asech, acsch
> (arcsinh, arccosh, arctanh, arccoth, arcsech, arccsch)
> ```
>
>

-- 
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/66965b2a-7741-4805-a097-f2d0c022344cn%40googlegroups.com.

Re: [sage-devel] Can we restore `mean`?

[kcrisman]

My original ticket title was "Clarify stats module role", not deprecate.   
"This ticket is to split the more technical stuff (which presumably may 
still be used for researchers, but not for the sort of things basic R or 
pandas data frames would be) into a separate module where it can be taken 
care of."  The whole notion of removing something as basic as "mean" from 
global namespace is not something I would support.

However, that does bring up a broader issue of who the end users of Sage 
are supposed to be.  I understand the idea of Sage solely as a Python 
library like Sympy or whatever.  However, not just historically have we 
behaved otherwise, but it seems rather opposed to the mission statement of 
Sage.  Our goal isn't to be "best standard Python library for math" but 
"open-source competitor to ..." and they are stand-alone programs, by 
design and rightly so. (This could include having a pip-installable 
version, obviously.) This question is naturally not directly part of this 
thread, but it seems to come up fairly often.  As for me, too many memories 
of needing warnings in Maple like "Did you remember to load the plots 
package via the with(plots): command?"   Nils has a good quote on the 
ticket, "A python library is just not a very good match for what people 
expect from an interactive CAS, so I think it's good we have a shim layer 
that makes sagemath behave a little more like a traditional CAS."

On Saturday, February 12, 2022 at 10:28:43 PM UTC-5 wst...@gmail.com wrote:

> This happened in https://trac.sagemath.org/ticket/29662, as requested
> by kcrisman. I just looked at that
> ticket and added a comment about several additional examples where
> deprecating mean breaks things
> in subtle ways...
>
> On Sat, Feb 12, 2022 at 7:14 PM Samuel Lelievre
>  wrote:
> >
> > Dear sage-devel,
> >
> > Taking averages is a common operation, and a `mean` function
> > such that `mean(xx)` returns `sum(xx) / len(xx)` regardless of
> > the type of objects in the iterable `xx` is extremely convenient.
> >
> > For instance, for a polygon whose vertices `uu` have coordinates
> > in a number field and are represented as vectors over that field,
> > `mean(uu)` finds the centre of that polygon. To center the polygon
> > at the origin, use `c = mean(uu)` and `vv = [u - c for u in uu]`.
> >
> > In Sage 9.5, using `mean` displays a warning:
> > ```
> > DeprecationWarning: sage.stats.basic_stats.mean is deprecated;
> > use numpy.mean or numpy.nanmean instead
> > ```
> > This is after #29662 was merged in SageMath 9.5.beta1.
> >
> > Alas, `numpy.mean` cannot find the mean of a list of vectors
> > over a number field.
> >
> > Of course, as a workaround, I can define
> >
> > def mean(xx):
> > r"""
> > Return the mean of this iterable.
> > """
> > return sum(xx) / len(xx)
> >
> > and place that in an `init.sage` file in my `~/.sage` folder.
> >
> > Having that built into Sage is so much more convenient though.
> > Can we have it back?
> >
> > Kind polygonal regards, --Samuel
> >
> > --
> > 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+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/60fe4b1c-db88-4caa-8d13-670b9b3edb79n%40googlegroups.com
> .
>
>
>
> -- 
> William (http://wstein.org)
>

-- 
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/c7c66de5-c7b0-4003-8066-6b67a4926a78n%40googlegroups.com.

Re: [sage-devel] Re: 32768

[kcrisman]

> In addition, for me its a matter of sustainability to use things as long 
> as they work.


+1 

-- 
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/d127ad35-4685-4034-b039-da75cfc10c1cn%40googlegroups.com.

Re: [sage-devel] trac.sagemath.org down

[kcrisman]

On Sunday, December 12, 2021 at 12:41:39 PM UTC-5 Matthias Koeppe wrote:

> Many thanks to all who are keeping our project infrastructure going!
>
>>
+100 

-- 
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/9f4b8d0e-818d-4b37-b7c9-a5f102e8d2a9n%40googlegroups.com.

[sage-devel] Re: ask.sagemath.org issues - do we need it?

[kcrisman]

Some hopefully-useful comments:

Overall, I am not sure why the project is running this server. I think we 
> are spreading ourselves pretty thin here. There is also:
> - https://groups.google.com/g/sage-support
> - https://stackoverflow.com/questions/tagged/sage
>
50 questions in last 6 months - thankfully, not as many about the Sage ERP 
software as in the past - so nowhere near the volume of ask.sagemath?  But 
see below.

> - https://stackexchange.com/search?q=sage
> - https://mathoverflow.net/search?q=sage
>
negligible
 
Also https://math.stackexchange.com/questions/tagged/sagemath - 50 
questions in the past 18 months. 

Though I haven't had time to contribute to any of these regularly since 
somewhat before the pandemic, my observations are twofold on this:
1) The same people were helping on both the SE sites and ask.sagemath
2) The response time and quality (and number of answers) were all better on 
ask.sagemath
It's possible this has changed recently, but more likely it is just that 
some of the networking issues have made it less reliable, but haven't 
improved service on the other sites. Contributors to answers have liked 
ask.sagemath.

I do notice that ask.sagemath has for some time only reported "0 years ago" 
for recent questions - I don't think the askbot developer 
(https://askbot.com) has been super productive lately and of course we 
don't have the ability to support that software as well as Sage itself. 
 That seems to be more of a sticking point, though I think Thierry and 
Samuel will have some relevant comments on that.
 
As for sage-support, it's always surprising to me how many "customers" 
simply disappear as soon as you mention asking a question there - somehow 
they either want a Q site, or to ask on Facebook, or whatever.  I don't 
really know why this happens, but clearly the Q sites (in toto) are 
necessary.

Finally, to anticipate a question that has come up in the past on this 
issue, I had previously inquired with a SE employee about transferring 
data, and it seems it's not really a viable option.  (As a very tangential 
note, one could make a similar observation about Trac versus GH/GL - could 
one take all those very useful discussions and import them?)

-- 
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/3ab714cf-5987-4a1d-9f99-471e616e83a8n%40googlegroups.com.

[sage-devel] Re: Demote SageTeX to an optional package?

[kcrisman]

Having a *standard* way to integrate Sage’s results in a document is 
> **crucial*.
>
> Since Sage is not (yet) in the position of R to have many user packages in 
a standardized place like CRAN, and since things like knitr are (hah!) 
crucial in that ecosystem, we almost certainly should continue providing 
this service directly.  
 

-- 
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/345c6eb1-145e-46cf-b758-ae16874c7d25n%40googlegroups.com.

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

[kcrisman]

>
>
> The way to spoil users of Sage on MacOS (or anywhere) is to create a 
> binary installer that work really well,
>

Correct.  This is what all this discussion should be aiming toward - 
including a binary installer that *allows for compiling/installing of 
optional packages and Cython*.  (Or gives not just a meaningful error if 
you try to do that and fail, but a precise thing to click on to do it.)

The reason why building Sage from source is so important historically is 
that a newbie on any platform, WITH NO EXPERIENCE USING ANY COMMAND LINE 
TOOLS, was able to download something, open a Terminal, and get a version 
of Sage that worked on their particular platform.  And to easily update it 
to the *next* version, or use Cython, or whatever.

In the event, this didn't end up being the case long-term - on Mac, at 
least, largely due to Apple's doing annoying things and then partly due to 
our changing how to "upgrade".  But that is what one would want, to have a 
"viable open-source competitor to ..."

If we can decouple those things from having to build from source, great. 
 It's not clear to me that is the case, because there is so much 
fragmentation in the computer space.  That's not our problem, but it is if 
we want to attract as many users as possible - including ones who will not 
be able to follow the instructions in a few posts in this thread, or who 
have no choice but to stick on older "EOL" platforms - that is what is out 
there.  You can mock people on them, but many of them really cannot afford 
to upgrade or whoever is controlling their computers will not do it.

Obviously it would good to make things less work for both our very 
hard-working developers and for users.  If we can disentangle from 
Sage-the-distribution effectively, that is fine.  Please, let's not have to 
have Fortran - I guess we already have disentangled R, or else someone 
would have mentioned that as requiring Fortran?  

But so far, it's only been demonstrated that either 1) viable easier 
distros are from projects not in the Sage core codebase like the new Mac 
app that Nathan D.'s group has created (I know it wasn't just him, I just 
forget who else) or like Isuru's distribution 2) you need to be well within 
the Linux ecosystem and conversant with things that a large number of users 
will not be familiar with.  Including some who are highly 
computer-literate, but not shell-literate.  And having the gcc/gfortran, 
again historically, was a great way to fix that.  Apparently that is still 
the case in a number of situations, or we wouldn't be having this 
conversation.  It's a failsafe for those times, which keep creeping in, and 
unless Apple itself starts providing the full ecosystem (fat chance), we'll 
still be relying on the good graces of projects like Homebrew.

The point is made several times that an internet solution may work for 
this.  But I have to point out YET AGAIN that not everyone lives in happy 
internet-land with great connectivity all day long.  And Cocalc is a big 
app for some connectivity situations too ... so that's not the long-term 
answer.  As many of us discovered during the pandemic and all of a sudden 
even some colleagues in "the West" (whatever that means) did not have as 
good of internet as we thought.

-- 
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/c2bfb4c7-fa05-4b59-9c2a-7a5755bb22dfn%40googlegroups.com.

Re: [sage-devel] Re: Outdated instructions in "git the hard way"

[kcrisman]

> Also a brief explanation of that "git trac" magic does in terms of 
> plain git should be helpful. 
>
>
That is a very good point that might lead people starting with git trac to 
use "standard" git. 

-- 
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/7410291a-822d-4581-a0c4-8ef71b7bf28en%40googlegroups.com.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[kcrisman]

> > How are these integrals above computed by Sage? Via Maxima, or in some 
> > other way? 
>
> When I implemented this, they were all computed in Maxima by default, 
> unless otherwise requested. Thus symbolic integration may be 
> orthogonal to the pynac vs symengine discussion. 
>
 
That is still the case (as Emanuel points out).  We now have more possible 
engines for integrals, but Maxima is still the default.

-- 
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/ea4a3905-27d9-44ae-9bf9-228879eae67an%40googlegroups.com.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[kcrisman]

> E.g. it looks like integration is not there. 
>
 
If I recall correctly, we use ginac/pynac only for symbolics proper (i.e. 
not calculus), as well as for differentiation.   I don't know if symengine 
is something to switch to (and Matthias is surely right about developer 
time, given the amazing and very long effort involved in switching to pynac 
all these years ago), but integration isn't something to worry about with 
that.  (Whether it's time to start having sympy as default integration 
engine is another question.)

-- 
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/009310e6-580c-4a17-b255-43585e1c1177n%40googlegroups.com.

Re: [sage-devel] Re: proposal - remove gcc, gfortran, python building/spkgs

[kcrisman]

My biggest concern on this is how flexible things like conda (which I don't 
know much about) is for different versions of Mac.  I presume that:

* If you are on Linux, you know how to use a package manager (though there 
may be some Ubuntu users who do not, I have known some)
* If you are on Windows, you will have one of the precompiled ready-to-go 
solutions we (?) provide

So, do these solutions work for all current versions of Mac?  And none of 
this "only the most recent Mac versions that Apple hasn't ended support 
for", because many academic and hobbyist users are not always in a position 
to upgrade those easily.  I've seen this many times (and not just with 
myself).  

Also, I'd like to hear from those who have tried to set up Sage installs in 
no/low-internet situations (e.g. in developing world).

-- 
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/93b36cc8-1921-439d-967a-eb8e0125d147n%40googlegroups.com.

Re: [sage-devel] attempting Sage build on M1

[kcrisman]

On what appears to be a completely different note, I cannot use Jupyter.  I 
can do sage -n and it opens the GUI in the browser, but actually attempting 
to start a worksheet leads to a massive failure.


$ ./sage -n

┌┐

│ SageMath version 9.4.beta0, Release Date: 2021-05-25   │

│ Using Python 3.9.5. Type "help()" for help.│

└┘

┏┓

┃ Warning: this is a prerelease version, and it may be unstable. ┃

┗┛

Please wait while the Sage Jupyter Notebook server starts...

[I 09:47:39.007 NotebookApp] Serving notebooks from local directory: 
/Users/karl.crisman/Downloads/BrewSage/sage-9.4.beta0

[I 09:47:39.008 NotebookApp] Jupyter Notebook 6.1.1 is running at:

[I 09:47:39.008 NotebookApp] 
http://localhost:/?token=152f2191ce419309f6f6bb52d6dadf9c960f9f7b79b6bd32

[I 09:47:39.008 NotebookApp]  or 
http://127.0.0.1:/?token=152f2191ce419309f6f6bb52d6dadf9c960f9f7b79b6bd32

[I 09:47:39.008 NotebookApp] Use Control-C to stop this server and shut 
down all kernels (twice to skip confirmation).

[C 09:47:39.021 NotebookApp] 



To access the notebook, open this file in a browser:


file:///Users/karl.crisman/Library/Jupyter/runtime/nbserver-56274-open.html

Or copy and paste one of these URLs:


http://localhost:/?token=152f2191ce419309f6f6bb52d6dadf9c960f9f7b79b6bd32

 or 
http://127.0.0.1:/?token=152f2191ce419309f6f6bb52d6dadf9c960f9f7b79b6bd32

[I 09:47:53.685 NotebookApp] Creating new notebook in 

[I 09:47:54.755 NotebookApp] Kernel started: 
b33e9093-4b5c-4adc-bdd5-00c77dc8f021, name: sagemath

[W 09:47:54.785 NotebookApp] 404 GET 
/nbextensions/jupyter_jsmol/extension.js (::1) 12.22ms 
referer=http://localhost:/notebooks/Untitled.ipynb?kernel_name=sagemath

2021-06-04 09:47:55.787 Python[56372:297026] *** Terminating app due to 
uncaught exception 'NSInvalidArgumentException', reason: '*** +[NSString 
stringWithUTF8String:]: NULL cString'

*** First throw call stack:

(

0   CoreFoundation  0x00019e434c78 
__exceptionPreprocess + 240

1   libobjc.A.dylib 0x00019e15d0a8 
objc_exception_throw + 60

2   Foundation  0x00019f11f0f8 
__destroy_helper_block_e8_32o40r + 0

3   libffi.dylib0x0001ab174050 ffi_call_SYSV + 
80

4   libffi.dylib0x0001ab17c9e4 ffi_call_int + 
948

5   _ctypes.cpython-39-darwin.so0x0001065d0740 _ctypes_callproc 
+ 864

6   _ctypes.cpython-39-darwin.so0x0001065cb1b8 PyCFuncPtr_call 
+ 220

7   Python  0x000104a69590 
_PyObject_MakeTpCall + 132

8   Python  0x000104b5ecd8 call_function + 
268

9   Python  0x000104b5c664 
_PyEval_EvalFrameDefault + 39880

10  Python  0x000104b51a9c _PyEval_EvalCode 
+ 444

11  Python  0x000104a6a2b4 
_PyFunction_Vectorcall + 364

12  Python  0x000104b5ec4c call_function + 
128

13  Python  0x000104b5c664 
_PyEval_EvalFrameDefault + 39880

14  Python  0x000104a6a1fc 
_PyFunction_Vectorcall + 180

15  Python  0x000104b5ec4c call_function + 
128

16  Python  0x000104b5c640 
_PyEval_EvalFrameDefault + 39844

17  Python  0x000104b51a9c _PyEval_EvalCode 
+ 444

18  Python  0x000104a6a2b4 
_PyFunction_Vectorcall + 364

19  Python  0x000104a6cc98 
method_vectorcall + 124

20  Python  0x000104a69e40 
PyVectorcall_Call + 184

21  Python  0x000104b5c80c 
_PyEval_EvalFrameDefault + 40304

22  Python  0x000104b51a9c _PyEval_EvalCode 
+ 444

23  Python  0x000104a6a2b4 
_PyFunction_Vectorcall + 364

24  Python  0x000104a698ac 
_PyObject_FastCallDictTstate + 208

25  Python  0x000104addbf4 slot_tp_init + 
188

26  Python  0x000104ae3850 type_call + 300

27  Python  0x000104a6a018 _PyObject_Call + 
128

28  Python  0x000104b5c80c 
_PyEval_EvalFrameDefault + 40304

29  Python  0x000104b51a9c _PyEval_EvalCode 
+ 444

30  Python  0x000104a6a2b4 
_PyFunction_Vectorcall + 364

31  Python  

Re: [sage-devel] attempting Sage build on M1

[kcrisman]

>
>> Perhaps you need to run 
>>>
>>> brew install openjpeg 
>>>
>>> (or brew reinstall openjpeg) 
>>>
>>>
>> Apparently doing this and sage -f pillow (+ its dependencies) fixed this 
>> problem.  I'm not sure why it was a problem in the first place, though.
>>
>
> basically, openjpeg  install was broken in your Homebrew. As it is an 
> optional dependency of pillow, no need to do anything with it.
>
>>
>>
If I interpret that correctly, it means that only people who already have a 
non-M1 version of openjpeg in /usr/local would need to then install this 
version in /opt/homebrew ?  One could imagine that happening to more than 
one person.  Maybe I misunderstand the word "optional" here.

-- 
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/c5dd266f-d1e6-4f8a-95c3-8c2d584c74f9n%40googlegroups.com.

Re: [sage-devel] attempting Sage build on M1

[kcrisman]

> Perhaps you need to run 
>
> brew install openjpeg 
>
> (or brew reinstall openjpeg) 
>
>
Apparently doing this and sage -f pillow (+ its dependencies) fixed this 
problem.  I'm not sure why it was a problem in the first place, though. 
 Think we need to add openjpeg to the brew list 
at 
https://doc.sagemath.org/html/en/installation/source.html#macos-recommended-installation
 
?

-- 
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/311a33d4-ca3e-481c-a47e-6cf150cd3e33n%40googlegroups.com.

Re: [sage-devel] attempting Sage build on M1

[kcrisman]

On Thursday, June 3, 2021 at 1:05:17 PM UTC-4 dim...@gmail.com wrote:

> For cvxopt, you need to patch its setup.py (we already patch it, but 
> not this bit), 
> which at the moment says 
> if sys.platform.startswith("darwin"): 
> SUITESPARSE_LIB_DIR = '/usr/local/lib' 
> SUITESPARSE_INC_DIR = '/usr/local/include' 
>
> That is, replace /usr/local/ with the correct prefix for M1 Homebrew. 
>
>
https://trac.sagemath.org/ticket/31905

I can report this upstream like you did for 
https://github.com/cvxopt/cvxopt/issues/174 but I'm not sure whether they 
would see this as a cvxopt bug since perhaps they don't intend to support 
Homebrew directly. 

-- 
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/507ceacd-85a2-4a8b-8b71-8407428a67fcn%40googlegroups.com.

Re: [sage-devel] attempting Sage build on M1

[kcrisman]

> Update: It still is looking in /usr/local even though 
> /opt/homebrew/Cellar/openjpeg/2.4.0/ exists (and probably already did).  It 
> also looks for little-cms2 in /usr/local/Cellar even though that also 
> exists in /opt/homebrew.  Everything else it is looking for in 
> /opt/homebrew, it seems.


Any thoughts on how to get Sage to look for the correct openjpeg and 
little-cms2, or in general to proceed?  But on the plus side most of Sage 
seemed to work, with that deployment change (though I know we just tried to 
get rid of it).

-- 
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/cfca3025-9092-423d-9a6e-617e5c2a1ccbn%40googlegroups.com.

Re: [sage-devel] attempting Sage build on M1

[kcrisman]

Update: It still is looking in /usr/local even though 
/opt/homebrew/Cellar/openjpeg/2.4.0/ exists (and probably already did).  It 
also looks for little-cms2 in /usr/local/Cellar even though that also 
exists in /opt/homebrew.  Everything else it is looking for in 
/opt/homebrew, it seems.

-- 
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/31c19542-42fc-4656-9cb6-5fd8a49aafecn%40googlegroups.com.