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

[Kwankyu Lee]

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.
3. A PR fixing the "critical" Issue will likely get the "blocker" label.
4. Old Issues converted from trac with "critical" label will get the 
"major" label instead. 

Voting will end when there is no new vote for a week.

This is a simple majority voting (following the standard on sage-devel 
proposal)!

A positive vote is for all parts of the Proposal. So if you do not like any 
of (1) -- (4), cast a negative vote (-1).


Happy voting! 

-- 
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/0f9b1d58-a50e-437b-a914-f0a31731626cn%40googlegroups.com.

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

[Kwankyu Lee]

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. 
3. A PR fixing the "critical" Issue will likely get the "blocker" label.
4. Old Issues converted from trac with "critical" label will get the 
"major" label instead.

Voting will end when there is no new vote for a week.

If the number of positive votes (+1) is at least twice of the number of 
negative votes (-1), then the Proposal will be accepted. A positive vote is 
for all parts of the Proposal. So if you do not like any of (1) -- (4), 
cast a negative vote (-1).

Happy voting! 

-- 
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/0c1fbb03-0b08-4270-b572-a5d6696117d7n%40googlegroups.com.

Re: [sage-devel] Re: Labels and Reviewing

[David Roe]

On Wed, Feb 28, 2024 at 1:01 AM Kwankyu Lee  wrote:

> Thank you for making progress on these urgent issues. I suggest the
> following:
>
> 1. Open two other new threads, each of which is for voting on each
> proposal.
> 2. On a proposal, it should be clear that *a positive vote (+1) is for
> the whole proposal,* and if one is negative to any part of the proposal,
> (s)he should give a negative vote (-1).
>

Voting threads seem reasonable.  I'll wait a day or two to see if people
have any final comments before voting.


> 3. A proposal is accepted if the number of positive votes is at least
> twice of the number of the negative votes.
>

Despite the fact that we're asking for this threshold in voting on a PR,
the standard for votes on proposals on sage-devel is just a plain majority
(though of course I hope that we can come to a 2-1 consensus!).

A minor suggestion for Proposal 2: for the label to be readable, I suggest
> "CI fix" for the name of the label (a blank between words).
>

I'm happy to adjust the label to be "CI fix."


> We may use this thread to get more comments on the Proposals before
> opening voting threads.
>
> --
> 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/554961a0-4ace-4317-bfcf-55b6a128bcden%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/CAChs6_%3DWSQ9s_kqtMocoHnwuiGYp-Ad%2B6RmgEvpZOMNjx4sZxA%40mail.gmail.com.

[sage-devel] Re: Labels and Reviewing

[Kwankyu Lee]

Thank you for making progress on these urgent issues. I suggest the 
following:

1. Open two other new threads, each of which is for voting on each 
proposal. 
2. On a proposal, it should be clear that *a positive vote (+1) is for the 
whole proposal,* and if one is negative to any part of the proposal, (s)he 
should give a negative vote (-1).  
3. A proposal is accepted if the number of positive votes is at least twice 
of the number of the negative votes.

A minor suggestion for Proposal 2: for the label to be readable, I suggest 
"CI fix" for the name of the label (a blank between words). 

We may use this thread to get more comments on the Proposals before opening 
voting threads.

-- 
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/554961a0-4ace-4317-bfcf-55b6a128bcden%40googlegroups.com.

Re: [sage-devel] Re: CenOS installation issue:

[Jyoti Prajapati]

Thank you sir.

Yesterday night, I followed instructions from these two sites:

Firstly, I installed miniconda and activated automatically initialization
of conda using this site:
https://deeplearning.lipingyang.org/2018/12/24/install-miniconda-on-centos-7-redhat-7/
.
Then, I installed sage using commands from this site:
https://huyle84.github.io/2021-04-06-install-sagemath-on-linux-using-miniconda/
. And to launch the sagemath in centos, I used the instructions from this
site: https://doc.sagemath.org/html/en/installation/launching.html.
And yes now its working fine.

Thank you very much sir.
But I am providing all commands here, in case if any other user needs it.

*Step 1:* Open a Terminal window, type

$ wget https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh

*Step2: * Run the following bash script to install it

$ sh Miniconda3-latest-Linux-x86_64.sh

*Step3:* To make the changes take effect, close the terminal and open a new
Terminal window.

*Step 4:* Test conda

In the newly open Terminal window, type the following

$ conda -V

# If you see something like the following, it means Miniconda is
successfully installed on your Linux OS.

conda 4.5.11

*Step 5:* Using Conda to install Mamba (This way is recommended to get a
better speed) as follows:

   $ conda install mamba -c conda-forge

*Step 6:* Using Mamba to install SageMath

   $ mamba create -n sage sage -c conda-forge

*Step 7:* Every time we use SageMath, we activate SageMath in Conda by the
command (in Terminal):

   $ conda activate sage

*Step 7:* Launch Sagemath using any of the given two command:

   $ sage -n jupyter
   $ sage -n jupyter --port 8899


Best wishes,
Jyoti


On Wed, Feb 28, 2024 at 4:25 AM Matthias Koeppe 
wrote:

> That's normal. In Sage we only maintain one list of packages for the whole
> family of distributions (CentOS, CentOS stream, RHEL, Fedora).
> Only the newest versions of Fedora have all the packages.
>
> However, likely on your system you will not be able to build Sage.
> We test centos-7 only on a configuration with updated compilers,
> "devtoolset-gcc_11".
> See the file build/pkgs/gcc/SPKG.rst for details.
>
> On Tuesday, February 27, 2024 at 5:30:06 AM UTC-8 Jyoti Prajapati wrote:
>
>> Dear sir,
>> Hope you are doing well!
>> I am trying to follow the instruction to install sagemath in centos7
>> using the given commands for centos provided in the link :
>>
>> https://doc.sagemath.org/html/en/installation/source.html#fedora-redhat-centos-package-installation
>>
>> But most of the packages are not available.
>>
>> Please guide me so that I can install sagemath in centos properly without
>> any error.
>>
>> Thank you,
>> Best wishes
>> Jyoti
>>
>> code: >>
>> Loading mirror speeds from cached hostfile
>> epel/x86_64/metalink| 5.4 kB
>>  00:00:00
>>  * centos-sclo-rh: bd.mirror.vanehost.com
>>  * centos-sclo-sclo: bd.mirror.vanehost.com
>>  * epel: mirror.nyist.edu.cn
>> Package Cython-0.19-5.el7.x86_64 already installed and latest version
>> No package L-function available.
>> No package L-function-devel available.
>> No package Singular available.
>> No package Singular-devel available.
>> No package arb available.
>> No package arb-devel available.
>> Package babel-0.9.6-8.el7.noarch already installed and latest version
>> Package binutils-2.27-34.base.el7.x86_64 already installed and latest
>> version
>> Package boost-devel-1.53.0-27.el7.x86_64 already installed and latest
>> version
>> No package brial available.
>> No package brial-devel available.
>> Package bzip2-1.0.6-13.el7.x86_64 already installed and latest version
>> Package bzip2-devel-1.0.6-13.el7.x86_64 already installed and latest
>> version
>> No package cddlib available.
>> No package cliquer available.
>> No package cliquer-devel available.
>> Package cmake-2.8.12.2-2.el7.x86_64 already installed and latest version
>> Package curl-7.29.0-51.el7.x86_64 already installed and latest version
>> Package diffutils-3.3-4.el7.x86_64 already installed and latest version
>> No package ecl available.
>> No package eclib available.
>> No package eclib-devel available.
>> No package fflas-ffpack-devel available.
>> Package 1:findutils-4.5.11-6.el7.x86_64 already installed and latest
>> version
>> No package flint available.
>> No package flint-devel available.
>> Package gc-7.2d-7.el7.x86_64 already installed and latest version
>> Package gc-devel-7.2d-7.el7.x86_64 already installed and latest version
>> Package gcc-4.8.5-36.el7.x86_64 already installed and latest version
>> Package gcc-c++-4.8.5-36.el7.x86_64 already installed and latest version
>> Package gcc-gfortran-4.8.5-36.el7.x86_64 already installed and latest
>> version
>> Package gd-2.0.35-26.el7.x86_64 already installed and latest version
>> Package gd-devel-2.0.35-26.el7.x86_64 already installed and latest version
>> Package gengetopt-2.23-1.el7.x86_64 already installed and 

[sage-devel] Re: int vs long in cython

[Nils Bruin]

On Tuesday 27 February 2024 at 18:09:42 UTC-8 Travis Scrimshaw wrote:

I am not sure it is purely about Python types since it gets changed into C 
code.


well ... code dealing with python ints in Py3 needs to deal with 
multi-precision PyInt objects, so it can't unwrap these. Whether they are 
internally represented as "compact" integers is an implementation detail 
(see https://docs.python.org/3/c-api/long.html#c.PyUnstable_Long_IsCompact)

I have no succeeded in finding the exact place where the bindings for the 
`int` and `long` names are made for the cython namespace -- but we've 
already established that they refer in runtime to identical objects. This 
was a reasonable indication:

https://github.com/cython/cython/blob/03d982be010b7b94a3c3317c462b2b803ce916af/Cython/Compiler/Code.py#L46-L47

and for pure python mode, there are the type wrappers:

https://github.com/cython/cython/blob/03d982be010b7b94a3c3317c462b2b803ce916af/Cython/Shadow.py#L426-L427
 
(where we also see the instructive comment for `py_long` "# for legacy Py2 
code only" -- so I think cython is indeed only keeping "long" bound for 
legacy reasons)

On the original ticket we actually found that `int_to_Z` was really just 
literally kept from Py2, so was actually buggy! (in Py2, a py_int was 
guaranteed to fit in a system integer, but in Py3 it's just a multiprec 
integer) So removing it was actually beneficial (although it was only used 
in a dead branch of the code, so can code that is guaranteed to be never 
called be buggy?)

-- 
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/34d80bc9-c77b-4c74-a758-510ad4595c6dn%40googlegroups.com.

[sage-devel] Labels and Reviewing

[David Roe]

Dear Sage developers,
The conflicts we've seen in the last several months are multifaceted, but
one of the central issues at hand is how we decide what code is
incorporated into Sage through our review process.  I have two goals for
this thread: to describe our current standards (as codified in the Developer
Guide ) and ask for
help in enforcing them, and to call a vote on several changes.

*Our current standards*:
1. A PR must be positively reviewed by another sage developer; there is no
notion of negative review.  If you come across a ticket that has positive
review and you notice a problem that the reviewer missed, you have several
options.  First, you can just make a comment drawing attention to the
matter.  If the problem causes repeatable build/test failures,
mathematically incorrect output or causes Sage's documentation to not
build, you should change the label from Positive Review to Needs Work and
make a comment describing the problem.  If the author and reviewer do not
agree that it is actually a problem, they should set the ticket back to
Positive Review and you *should not engage more on that PR*.  You are free
to create another issue or PR addressing the problem that you have noticed.
2. We have recently started using Disputed as a tag for PRs where there is
disagreement about how to proceed.  This is not mentioned in the Developer
Guide, and there has been no vote on sage-devel about how it should be
used.  But the purpose seems clear to me: it indicates the presence of
disagreement.  As such, once a PR has been marked Disputed, *do not remove
this tag*: you cannot unilaterally decide that there is no controversy.
3. We have no set process for deciding whether a PR should be marked as a
blocker; our guide currently just says "developers should use blocker
priority sparingly and should indicate the rationale on the PR. Though
there is no one fixed rule or authority that determines what is appropriate
for blocker status, PRs introducing new features and PRs that make big
changes are usually not blockers."  I make some proposals below to clarify
the situation, but in the meantime the sage-abuse committee will be
enforcing the following standards to prevent label wars: *if there is
disagreement about whether a PR should be marked as a blocker, mark it as
critical instead*.

All three of these standards have been frequently violated in the last
several months.  The sage-abuse committee intends to enforce them more
vigorously; a consistent pattern of violations will result in the loss of
Triage privileges (resulting in an inability to review PRs and change
labels).  If you notice violations of these standards, please draw them to
the committee's attention by emailing sage-ab...@googlegroups.com.


Proposals
I have two separate proposals related to the above issues; feel free to
vote on them separately.  Voting will be open until Friday, March 8.

1. Using Github to vote on disputed PRs.  Working things out amicably is
preferable, and anyone is welcome to ask on sage-devel for more eyes on a
PR.  If you notice a serious issue with a PR, it is acceptable to change it
to Needs Work (and make a comment!) as an initial step, but if the
author/reviewer don't agree the process below should be followed instead.
This process is intended as a lower-intensity method for resolving
disagreements, and full votes on sage-devel override the process described
below.
a. When there is disagreement about whether a PR should be merged, anyone
may mark a PR as disputed.
b. 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.
c. If the total number of positive votes is at least twice the number of
negative votes, anyone involved may set the status to *positive review*; if
the total number of positive votes is less than twice the number of
negative votes, anyone involved may set the status to *needs review*.  When
either of these actions is taken, the person changing the status must list
the people they are counting as positive and negative votes in a comment
using @ mentions.
d. The final decision on merging a disputed PR remains with the release
manager, and we encourage the release manager to give enough time for
everyone to express an opinion.


2. We use CIfix rather than Blocker to determine whether an open PR should
be merged before running CI.  The process below describes how to resolve
disagreements about whether this label should be applied.
a. Only PRs with positive review should be marked with the CIFix label.
This should be done if both author and reviewer agree that it is
appropriate, and a rationale should be given in a comment on the ticket.

[sage-devel] Looking for volunteers

[David Roe]

Hi Sage developers,
As some of you may be aware, there has been more conflict in the last
several months than normal, including multiple violations of our Code of
Conduct.  Sage's mechanism for moderating conflicts and addressing such
violations is a committee, reachable at sage-ab...@googlegroups.com.  I
announced the membership of this committee a few days ago in another
thread; since then one member has resigned and another has expressed
willingness to be replaced.  The current membership is
William Stein
John Palmieri
David Roe
Vincent Delecroix
David Joyner
As a group, we believe that this committee would benefit from new members,
so we are opening a process to add and/or change the membership (the five
of us will go through the same process described below as anyone else
interested in serving on the committee).

We propose the following voting system.
1. A nomination period of 1 week, where any Sage developer can nominate
someone to serve on the committee by emailing sage-ab...@googlegroups.com.
You are allowed to nominate yourself (and we encourage it); if you nominate
someone else we will email them and ask if they are willing to serve.  To
be eligible you should have
a. Contributed code to Sage at some point in the past
b. Not been subject to a complaint to the committee at any point.
During the nomination period, you may also write to sage-abuse with names
of people who you believe should not serve on the committee; if one of
these people is nominated we will write to you asking for more
justification.  If you have a reservation about someone already on the
committee, you should feel free to write to us individually.
2. After the nomination period, we will announce nominees on sage-devel,
and ask for votes (which will also be sent to sage-ab...@googlegroups.com).
Voting will be by approval voting (you can select an arbitrary number of
people to vote for, unordered).  The committee will include at least the
top 5 candidates, and will be enlarged to include all tied candidates if
there is a tie for 5th place.
3. After a week of voting, we will announce the new composition of the
committee.

We're aware that this process is not optimal (and welcome suggestions for
improvement).  But we'd like more help, soon.  So we will open nominations
in parallel to discussion of the process.  We anticipate running this
process every 3 years to refresh membership.

Qualities that we're looking for are
1. Tactfulness and judgement in moderating conflicts and addressing abuse
2. Willingness to put time and effort into repairing some of the problems
that we've seen in our community.
If you have any questions, feel free to reach out to us individually, or as
a group.  We will be following this with some proposed changes to the Code
of Conduct, as well as a new document describing how we handle reports
(following the example of SciPy and NumFocus).  Thanks,
David
for the sage-abuse committee

-- 
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/CAChs6_kDCa8TYWnQ10pLtpOewSKaCQBFkhb6w3hZ%2BLbQEgsN2A%40mail.gmail.com.

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

[Matthias Koeppe]

On Monday, February 19, 2024 at 1:08:44 PM UTC-8 Matthias Koeppe wrote:

On Monday, February 19, 2024 at 12:46:01 PM UTC-8 Dima Pasechnik wrote:

I don't think the docs describe the interaction between package-version.txt 
and install-requires.txt
(and between potential version constraints in spkg-configure.m4)


Let's take this as an opportunity to improve the documentation where 
needed. 
I have opened https://github.com/sagemath/sage/pull/37401 for this, let's 
take the discussion there.


Much of a discussion didn't happen on that PR, but now I have added more 
material, salvaged from the sage-devel thread 'allow standard packages to 
be pip packages'. Thanks to John, Nils, Kwankyu, Nathan for the thoughtful 
posts over there. I'd appreciate a review of the PR and of course any 
further suggestion how to improve the 
writing. https://github.com/sagemath/sage/pull/37401/files

-- 
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/68040250-1090-48ad-9cf2-c00fa2e38e0cn%40googlegroups.com.

Re: [sage-devel] Re: Unload "blocker" label

[Travis Scrimshaw]

For me, big +1 on (mostly) decoupling (2) from the rest. I think Kwankyu's 
suggestion for blockers with positive review being added to all CIs is a 
good way to do this. I don't see much utility in doing this at any other 
stage.

Best,
Travis


On Tuesday, February 27, 2024 at 3:10:09 PM UTC+9 David Roe wrote:

> On Mon, Feb 26, 2024 at 8:06 PM John H Palmieri  
> wrote:
>
>> I think that usage (1) is the correct use of "blocker," and usage (3) is 
>> not. Usage (2) should have a new name, as Vincent proposes. Failing that, 
>> this new use of "blocker" must be documented in 
>> https://doc.sagemath.org/html/en/developer/review.html.
>>
>
> I also agree that usage (2) should get a new name.  How about "CIFix?"
> David
>
>
>> On Monday, February 26, 2024 at 4:21:58 PM UTC-8 Kwankyu Lee wrote:
>>
>>> On Tuesday, February 27, 2024 at 2:43:18 AM UTC+9 Vincent Delecroix 
>>> wrote:
>>>
>>> In that case, let me do a proposal. 
>>>
>>> Introduce a new label distinct from "blocker" for
>>>
>>> usage 2: PRs that should be merged temporarily before CI tests run
>>>
>>>
>>> I meant by "merged temporarily" the "CI fixes" in Matthias' 
>>> explanation:  
>>>
>>>- *Within the release candidate stage,* developers who mark a PR as 
>>>a "blocker" so that it be merged in the upcoming stable release need to 
>>>know whether their blocker PR will be conflicting with other blockers (= 
>>>candidates for merging in the next rc). Having the "blocker" label 
>>> double 
>>>as the "CI fixes" trigger takes care of this.
>>>
>>> So blocker PRs get the chance to be tested together before the release 
>>> by the "CI fixes" mechanism. Thus "usage 1" and "usage 2" are connected. 
>>> Having distinct labels for them does not reflect the connection.
>>>
>>> I propose (as this discussion is a place to give proposals :-) to give 
>>> "the chance to be tested together" only to blocker PRs with "positive 
>>> review". This slightly separates "usage 1" and "usage 2". This proposal was 
>>> suggested when the "CI fixes" mechanism was introduced, and can be 
>>> activated easily.
>>>
>>>  
>>>  
>>>  
>>>
>> -- 
>>
> 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/001204a7-53fe-43ec-8be6-d2dbdd15b69dn%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/11ac4c06-9ba4-46f4-b6fe-08cf1024a8c7n%40googlegroups.com.

[sage-devel] Re: int vs long in cython

[Travis Scrimshaw]

I am not sure it is purely about Python types since it gets changed into C 
code. (For reference, I changed your snippet to cpdef and got the same 
result too.)  It would be nice if there was an actual specification for 
this in Cython. I just get slightly worried after getting translated into C 
code, it then depends on the compiler. 

Anyways, such changes should be fine (this was my initial reaction too) 
except in perhaps very extraordinary circumstances...

Best,
Travis

On Monday, February 26, 2024 at 1:34:31 AM UTC+9 Nils Bruin wrote:

> Hi Travis,
>
> No, these routines are about the python types. They get used as `type(x) 
> is int` and `type(x) is long`. They are used in a different namespace from 
> `cdef int x` and `cdef long x` and cdef long long x` (well, the `x` is in 
> the cython object namespace. The C-types don't make it into the cython 
> object namespace. They are in a C type namespace).
>
>  The cython test routine above confirms that the objects `int` and `long` 
> (not the cdef type names!) are indeed the same object in cython
> The code below confirms they are the python `int` type object:
>
> sage: cython("""
> : def test(x):
> : return (x is long, x is int)
> : """)
> sage: test(int)
> (True, True)
> On Sunday 25 February 2024 at 01:48:09 UTC-8 Travis Scrimshaw wrote:
>
>> Sorry for the delayed response.
>>
>> If the C compiler can't tell the difference between an int and a long, 
>> then that suggests that there is still a difference. I am not sure that 
>> Cython has any specification that these are different. My understanding is 
>> Cython treats these as C types. Can we be certain that an int that is not a 
>> long will not find its way in? Could it also depend on someone's version of 
>> C/Python?
>>
>> Best,
>> Travis
>>
>>
>> On Thursday, February 22, 2024 at 2:52:25 PM UTC+9 Nils Bruin wrote:
>>
>>> I tried removal here:
>>> https://github.com/sagemath/sage/pull/37420
>>> and as expected it looks like it's working fine.
>>>
>>> On Wednesday 21 February 2024 at 19:06:50 UTC-8 Nils Bruin wrote:
>>>
 well, I don't expect the C compiler to be smart enough to recognise the 
 second is an "elif False:", so the "hurt" would be in additional code 
 executed. Plus, having hidden "elif False:"s in a code base is a really 
 bad 
 code smell, so I think there is a penalty. What do you want to guard 
 against? "int" and "long" becoming not synonyms in cython again? There 
 will 
 be probably other py2/3 relics in our code base. I think we should clean 
 them up when encountered, unless we have a good reason not to.

 On Wednesday 21 February 2024 at 17:55:48 UTC-8 Travis Scrimshaw wrote:

> I think so, but it might not hurt to have it.
>
> Best,
> Travis
>
> On Thursday, February 22, 2024 at 9:54:32 AM UTC+9 Nils Bruin wrote:
>
>> I noticed the following cython code
>>
>> if S is long:
>> return sage.rings.integer.long_to_Z()
>> elif S is int:
>> return sage.rings.integer.int_to_Z()
>>
>>
>> https://github.com/sagemath/sage/blob/30fecca1981087a88eb8db2cf05e18edbb50d16f/src/sage/rings/integer_ring.pyx#L589C1-L593C1
>>
>> However, in cython with python3 we now have:
>>
>> sage: cython("""
>> : def tst():
>> : return int is long
>> : """)
>> sage: tst()
>> True
>>
>> so I think the `elif` can be deleted. Is that correct?
>>
>

-- 
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/0f6ec32b-68ff-425b-81a7-05cc75e72013n%40googlegroups.com.

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

[Dima Pasechnik]

Blocking on GitHub, I presume, is due to disagreements on a number of topics, 
including the topic discussed in this thread. So it's related to the topic, and 
personal only as it was done by a person, not by an AI.



On 27 February 2024 22:17:50 GMT, John H Palmieri  
wrote:
>That's called "whataboutism". Invoking what you consider inappropriate 
>behavior by others is not relevant. Please stay on topic, and please follow 
>Sage's code of conduct in your posts.
>
>On Tuesday, February 27, 2024 at 1:01:25 PM UTC-8 Dima Pasechnik wrote:
>
>>
>>
>> On 27 February 2024 20:44:50 GMT, John H Palmieri  
>> wrote:
>> >Sentences like "At the moment you are actively breaking down the precious 
>> >project fabric, all in the name of you having your way" are personal 
>> >attacks. Please stop.
>>
>> Blocking on GitHub members of the project is not a personal attack? 
>> Of course it is.
>>
>>
>> >
>> >On Tuesday, February 27, 2024 at 12:36:44 PM UTC-8 Dima Pasechnik wrote:
>> >
>> >>
>> >>
>> >> On 27 February 2024 19:37:31 GMT, Matthias Koeppe  
>>
>> >> wrote:
>> >> >On Tuesday, February 27, 2024 at 10:50:55 AM UTC-8 John H Palmieri 
>> wrote:
>> >> >
>> >> >A pretty safe second choice would be to have "make download" also 
>> >> download 
>> >> >the relevant files for pip installation and tell pip where to find 
>> them. 
>> >> If 
>> >> >we implemented this second choice [...]
>> >> >
>> >> >
>> >> >The problem is that such tooling, even if "trivial", would need to be 
>> >> >implemented, tested, and maintained as well. And typically this just 
>> does 
>> >> >not work when there is no developer who is actually interested in 
>> using 
>> >> it.
>> >>
>> >> It is a largely artificially invented, by you, problem, to shoot my 
>> >> proposal down. Besides, these tools are trivial to build and maintain, 
>> much 
>> >> easier than your ever growing and breaking maze of packages we don't 
>> even 
>> >> need to vendor.
>> >>
>> >> At the moment you are actively breaking down the precious project 
>> fabric, 
>> >> all in the name of you having your way: 
>> >>
>> >> you blocked me (without bothering yo even tell me) and perhaps other 
>> >> developers on GitHub, meaning that you effectively want to shut me up.
>> >> (Well, I had no other choice but to block you too, as a countermeasure; 
>> I 
>> >> installed this block about 12:00 GMT, today.)
>> >>
>> >> Of course it's easy to skip this message. But tomorrow it might be you 
>> who 
>> >> Matthias might block, for disagreements with him.
>> >> Why is this tolerated? This is a naked attempt to shut down the 
>> opposition.
>> >>
>> >>
>> >> >
>> >> >We are better off with improving the tooling that we already know 
>> *will* 
>> >> >continue to be used: Namely the tooling for creating and maintaining 
>> our 
>> >> >metadata in build/pkgs.
>> >>
>> >> Or it will be discarded as useless, because doing things the way 
>> projects 
>> >> like scipy do is better.
>> >>
>> >> Your package tooling is makework, repeating with worse tools what 
>> already 
>> >> is done by Conda, Homebrew, Linux distros, etc. We are mainly a maths 
>> >> project, not a distro project. Let us stay this way, and actually do 
>> more 
>> >> maths and less distro-like stuff.
>> >>
>> >> Dima
>> >>
>> >>
>> >> > Issues such as:
>> >> >- https://github.com/sagemath/sage/issues/36356, 
>> >> >- https://github.com/sagemath/sage/pull/37322, 
>> >> >- https://github.com/sagemath/sage/issues/37323, 
>> >> >- https://github.com/sagemath/sage/issues/37314
>> >> >
>> >>
>> >
>>
>
>-- 
>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/3f85faf4-840a-4965-bd81-797f2733843fn%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/6D2FFF01-A6CB-4398-87A7-171B07D521FB%40gmail.com.

[sage-devel] Re: CenOS installation issue:

[Matthias Koeppe]

That's normal. In Sage we only maintain one list of packages for the whole 
family of distributions (CentOS, CentOS stream, RHEL, Fedora).
Only the newest versions of Fedora have all the packages. 

However, likely on your system you will not be able to build Sage.
We test centos-7 only on a configuration with updated compilers, 
"devtoolset-gcc_11". 
See the file build/pkgs/gcc/SPKG.rst for details.

On Tuesday, February 27, 2024 at 5:30:06 AM UTC-8 Jyoti Prajapati wrote:

> Dear sir,
> Hope you are doing well!
> I am trying to follow the instruction to install sagemath in centos7 using 
> the given commands for centos provided in the link :
>
> https://doc.sagemath.org/html/en/installation/source.html#fedora-redhat-centos-package-installation
>
> But most of the packages are not available. 
>
> Please guide me so that I can install sagemath in centos properly without 
> any error.
>
> Thank you,
> Best wishes
> Jyoti
>
> code: >>
> Loading mirror speeds from cached hostfile
> epel/x86_64/metalink| 5.4 kB 
>  00:00:00
>  * centos-sclo-rh: bd.mirror.vanehost.com
>  * centos-sclo-sclo: bd.mirror.vanehost.com
>  * epel: mirror.nyist.edu.cn
> Package Cython-0.19-5.el7.x86_64 already installed and latest version
> No package L-function available.
> No package L-function-devel available.
> No package Singular available.
> No package Singular-devel available.
> No package arb available.
> No package arb-devel available.
> Package babel-0.9.6-8.el7.noarch already installed and latest version
> Package binutils-2.27-34.base.el7.x86_64 already installed and latest 
> version
> Package boost-devel-1.53.0-27.el7.x86_64 already installed and latest 
> version
> No package brial available.
> No package brial-devel available.
> Package bzip2-1.0.6-13.el7.x86_64 already installed and latest version
> Package bzip2-devel-1.0.6-13.el7.x86_64 already installed and latest 
> version
> No package cddlib available.
> No package cliquer available.
> No package cliquer-devel available.
> Package cmake-2.8.12.2-2.el7.x86_64 already installed and latest version
> Package curl-7.29.0-51.el7.x86_64 already installed and latest version
> Package diffutils-3.3-4.el7.x86_64 already installed and latest version
> No package ecl available.
> No package eclib available.
> No package eclib-devel available.
> No package fflas-ffpack-devel available.
> Package 1:findutils-4.5.11-6.el7.x86_64 already installed and latest 
> version
> No package flint available.
> No package flint-devel available.
> Package gc-7.2d-7.el7.x86_64 already installed and latest version
> Package gc-devel-7.2d-7.el7.x86_64 already installed and latest version
> Package gcc-4.8.5-36.el7.x86_64 already installed and latest version
> Package gcc-c++-4.8.5-36.el7.x86_64 already installed and latest version
> Package gcc-gfortran-4.8.5-36.el7.x86_64 already installed and latest 
> version
> Package gd-2.0.35-26.el7.x86_64 already installed and latest version
> Package gd-devel-2.0.35-26.el7.x86_64 already installed and latest version
> Package gengetopt-2.23-1.el7.x86_64 already installed and latest version
> Package gf2x-1.1-5.el7.x86_64 already installed and latest version
> Package gf2x-devel-1.1-5.el7.x86_64 already installed and latest version
> No package gfan available.
> No package giac available.
> No package giac-devel available.
> No package givaro available.
> No package givaro-devel available.
> Package glpk-4.52.1-2.el7.x86_64 already installed and latest version
> Package glpk-devel-4.52.1-2.el7.x86_64 already installed and latest version
> Package glpk-utils-4.52.1-2.el7.x86_64 already installed and latest version
> Package 1:gmp-6.0.0-15.el7.x86_64 already installed and latest version
> Package 1:gmp-devel-6.0.0-15.el7.x86_64 already installed and latest 
> version
> No package gmp-ecm available.
> No package gmp-ecm-devel available.
> Package gsl-1.15-13.el7.x86_64 already installed and latest version
> Package gsl-devel-1.15-13.el7.x86_64 already installed and latest version
> Package iml-1.0.5-32.el7.x86_64 already installed and latest version
> Package iml-devel-1.0.5-32.el7.x86_64 already installed and latest version
> Package info-5.1-5.el7.x86_64 already installed and latest version
> Package python-ipython-3.2.3-1.el7.noarch already installed and latest 
> version
> No package libatomic_ops available.
> Package libatomic_ops-devel-7.2d-7.el7.x86_64 already installed and latest 
> version
> Package libbraiding-1.1-9.el7.x86_64 already installed and latest version
> Package libcurl-devel-7.29.0-51.el7.x86_64 already installed and latest 
> version
> Package libffi-3.0.13-18.el7.x86_64 already installed and latest version
> Package libffi-devel-3.0.13-18.el7.x86_64 already installed and latest 
> version
> No package libfplll available.
> No package libfplll-devel available.
> No package libhomfly-devel available.
> Package libmpc-1.0.1-3.el7.x86_64 already installed and 

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

[John H Palmieri]

That's called "whataboutism". Invoking what you consider inappropriate 
behavior by others is not relevant. Please stay on topic, and please follow 
Sage's code of conduct in your posts.

On Tuesday, February 27, 2024 at 1:01:25 PM UTC-8 Dima Pasechnik wrote:

>
>
> On 27 February 2024 20:44:50 GMT, John H Palmieri  
> wrote:
> >Sentences like "At the moment you are actively breaking down the precious 
> >project fabric, all in the name of you having your way" are personal 
> >attacks. Please stop.
>
> Blocking on GitHub members of the project is not a personal attack? 
> Of course it is.
>
>
> >
> >On Tuesday, February 27, 2024 at 12:36:44 PM UTC-8 Dima Pasechnik wrote:
> >
> >>
> >>
> >> On 27 February 2024 19:37:31 GMT, Matthias Koeppe  
>
> >> wrote:
> >> >On Tuesday, February 27, 2024 at 10:50:55 AM UTC-8 John H Palmieri 
> wrote:
> >> >
> >> >A pretty safe second choice would be to have "make download" also 
> >> download 
> >> >the relevant files for pip installation and tell pip where to find 
> them. 
> >> If 
> >> >we implemented this second choice [...]
> >> >
> >> >
> >> >The problem is that such tooling, even if "trivial", would need to be 
> >> >implemented, tested, and maintained as well. And typically this just 
> does 
> >> >not work when there is no developer who is actually interested in 
> using 
> >> it.
> >>
> >> It is a largely artificially invented, by you, problem, to shoot my 
> >> proposal down. Besides, these tools are trivial to build and maintain, 
> much 
> >> easier than your ever growing and breaking maze of packages we don't 
> even 
> >> need to vendor.
> >>
> >> At the moment you are actively breaking down the precious project 
> fabric, 
> >> all in the name of you having your way: 
> >>
> >> you blocked me (without bothering yo even tell me) and perhaps other 
> >> developers on GitHub, meaning that you effectively want to shut me up.
> >> (Well, I had no other choice but to block you too, as a countermeasure; 
> I 
> >> installed this block about 12:00 GMT, today.)
> >>
> >> Of course it's easy to skip this message. But tomorrow it might be you 
> who 
> >> Matthias might block, for disagreements with him.
> >> Why is this tolerated? This is a naked attempt to shut down the 
> opposition.
> >>
> >>
> >> >
> >> >We are better off with improving the tooling that we already know 
> *will* 
> >> >continue to be used: Namely the tooling for creating and maintaining 
> our 
> >> >metadata in build/pkgs.
> >>
> >> Or it will be discarded as useless, because doing things the way 
> projects 
> >> like scipy do is better.
> >>
> >> Your package tooling is makework, repeating with worse tools what 
> already 
> >> is done by Conda, Homebrew, Linux distros, etc. We are mainly a maths 
> >> project, not a distro project. Let us stay this way, and actually do 
> more 
> >> maths and less distro-like stuff.
> >>
> >> Dima
> >>
> >>
> >> > Issues such as:
> >> >- https://github.com/sagemath/sage/issues/36356, 
> >> >- https://github.com/sagemath/sage/pull/37322, 
> >> >- https://github.com/sagemath/sage/issues/37323, 
> >> >- https://github.com/sagemath/sage/issues/37314
> >> >
> >>
> >
>

-- 
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/3f85faf4-840a-4965-bd81-797f2733843fn%40googlegroups.com.

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

[Dima Pasechnik]

On 27 February 2024 20:44:50 GMT, John H Palmieri  
wrote:
>Sentences like "At the moment you are actively breaking down the precious 
>project fabric, all in the name of you having your way" are personal 
>attacks. Please stop.

Blocking on GitHub members of the project is not a personal attack? 
Of course it is.


>
>On Tuesday, February 27, 2024 at 12:36:44 PM UTC-8 Dima Pasechnik wrote:
>
>>
>>
>> On 27 February 2024 19:37:31 GMT, Matthias Koeppe  
>> wrote:
>> >On Tuesday, February 27, 2024 at 10:50:55 AM UTC-8 John H Palmieri wrote:
>> >
>> >A pretty safe second choice would be to have "make download" also 
>> download 
>> >the relevant files for pip installation and tell pip where to find them. 
>> If 
>> >we implemented this second choice [...]
>> >
>> >
>> >The problem is that such tooling, even if "trivial", would need to be 
>> >implemented, tested, and maintained as well. And typically this just does 
>> >not work when there is no developer who is actually interested in using 
>> it.
>>
>> It is a largely artificially invented, by you, problem, to shoot my 
>> proposal down. Besides, these tools are trivial to build and maintain, much 
>> easier than your ever growing and breaking maze of packages we don't even 
>> need to vendor.
>>
>> At the moment you are actively breaking down the precious project fabric, 
>> all in the name of you having your way: 
>>
>> you blocked me (without bothering yo even tell me) and perhaps other 
>> developers on GitHub, meaning that you effectively want to shut me up.
>> (Well, I had no other choice but to block you too, as a countermeasure; I 
>> installed this block about 12:00 GMT, today.)
>>
>> Of course it's easy to skip this message. But tomorrow it might be you who 
>> Matthias might block, for disagreements with him.
>> Why is this tolerated? This is a naked attempt to shut down the opposition.
>>
>>
>> >
>> >We are better off with improving the tooling that we already know *will* 
>> >continue to be used: Namely the tooling for creating and maintaining our 
>> >metadata in build/pkgs.
>>
>> Or it will be discarded as useless, because doing things the way projects 
>> like scipy do is better.
>>
>> Your package tooling is makework, repeating with worse tools what already 
>> is done by Conda, Homebrew, Linux distros, etc. We are mainly a maths 
>> project, not a distro project. Let us stay this way, and actually do more 
>> maths and less distro-like stuff.
>>
>> Dima
>>
>>
>> > Issues such as:
>> >- https://github.com/sagemath/sage/issues/36356, 
>> >- https://github.com/sagemath/sage/pull/37322, 
>> >- https://github.com/sagemath/sage/issues/37323, 
>> >- https://github.com/sagemath/sage/issues/37314
>> >
>>
>

-- 
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/4465036B-3AF2-45ED-BCAA-9903B13757ED%40gmail.com.

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

[Dima Pasechnik]

On 27 February 2024 20:21:26 GMT, Nils Bruin  wrote:
>On Tuesday 27 February 2024 at 10:50:55 UTC-8 John H Palmieri wrote:
>
>
>As Nathan points out, this will likely lead to instability. Someone will 
>upgrade some component, and most of the time that will be fine, but 
>occasionally it will break something on some platform, and it could be 
>annoying to track down the cause. If this leads to Sage failing to build, 
>that's not great, but it would be *far worse* if Sage built and ran but 
>produced some mathematically incorrect answers. Being able to control all 
>of the versions means that our doctests are pretty robust. If we really 
>want to go down the road of unpinning version requirements, I propose that 
>we *always* pin version requirements for the mathematical components of 
>Sage. If Jupyter or Sphinx doesn't work right, it doesn't affect the 
>mathematics, but if linbox or pari don't work right (or ore_algebra, if you 
>want a pip package), people could be getting different answers on different 
>platforms and we might not know about it for a while. To maintain the 
>mathematical integrity of the project, we should keep very careful control 
>of the mathematical components of Sage.
>
>+1 to this. There is another difference: The jupyter notebook server - 
>notebook kernel interface is not a binary one: it's a protocol. As such, 
>it's hopefully narrower in its definition and a bit more stable. So 
>offering that sagemath offers a notebook kernel that a separately 
>distributed notebook server can connect to is a different dependency 
>structure than depending on libraries being provided. There are some super 
>stable libraries for which external dependencies are OK, but generally 
>(especially components under active development) they are a lot more 
>sensitive.
>
>For full functionality we depend on more than vanilla jupyter notebook, 
>though: at some point, jupyter notebook server shipped with a pared-down 
>mathjax and I have not been able to to get proper mathjax working in my 
>system-provided jupyter notebook. 

The reason for having a bad integration with upstream Jupyter is simple - we 
haven't really tried to do it properly, that's all. 

And I am not able to get Sage's Jupyter properly working. Also people here 
complain that they can't use Sage's Jupyter offline (it's cause we keep on 
using Mathjax2, for the sole reason that long formulas dont wrap around, 
instead there is a slider to view them). So if one wants offline MathJax, e.g. 
for a presentation, Sage's Jupyter is useless.

With an ability to have standard pip packages, this would be something to look 
at - cause without this ability it's always some ad hoc non-official stuff, may 
work, or not, no one  cares much.

> We have other components, such as 
>documentation and various plug-ins that we need in jupyter notebook too. 
>This has made the shipped-with-sage jupyter notebook server more reliable 
>to me, even if I'd prefer the system notebook server if that would be 
>reliable to get working.
>
>Sphinx is another part of such tooling: it should be able to just read and 
>process markup. We tend to not ship a latex installation with our 
>preprints.
>  However, I don't have experience with how stable sphinx on its 
>own is to judge how much trouble one would get from relying on an external 
>sphinx.

If you pin a version, or even if you don't, there should be no difference 
between what we install, and what comes from pip install. Gentoo provides a 
very modern upstream Sphinx, and it works with Sage, for quite some time.


>  Personally, I don't bother building the sage documentation and rely 
>on what is available online instead, so that one wouldn't affect me.  
>

-- 
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/978D1F98-CC2C-404A-84DB-110025C7FDB3%40gmail.com.

Re: [sage-devel] jupyterlab on sage 10.2

[François Bissey]

If you do that from a terminal, there should be a number of messages 
spat back at you before the browser start jupyterlab.

Can you post them?

François

On 28/02/24 09:41, Jan Groenewald wrote:

Hi

sage 10.2 on Debian 12, and
sage -i jupyterlab

sage --notebook=jupyterlab

launches, and the logo displays and animates, and then stops. I can't 
get further. Any ideas?


This was working in sage 10.1.

Regards,
Jan

--
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/CAAg%3Dp_1eYsYAHsZF_6fYNnGOQqLrzoCSROyakXz%3DiQ3KMWd8gw%40mail.gmail.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/873a42dd-8f9a-4d51-80e5-284f48af8dc8%40gmail.com.

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

[John H Palmieri]

Sentences like "At the moment you are actively breaking down the precious 
project fabric, all in the name of you having your way" are personal 
attacks. Please stop.

On Tuesday, February 27, 2024 at 12:36:44 PM UTC-8 Dima Pasechnik wrote:

>
>
> On 27 February 2024 19:37:31 GMT, Matthias Koeppe  
> wrote:
> >On Tuesday, February 27, 2024 at 10:50:55 AM UTC-8 John H Palmieri wrote:
> >
> >A pretty safe second choice would be to have "make download" also 
> download 
> >the relevant files for pip installation and tell pip where to find them. 
> If 
> >we implemented this second choice [...]
> >
> >
> >The problem is that such tooling, even if "trivial", would need to be 
> >implemented, tested, and maintained as well. And typically this just does 
> >not work when there is no developer who is actually interested in using 
> it.
>
> It is a largely artificially invented, by you, problem, to shoot my 
> proposal down. Besides, these tools are trivial to build and maintain, much 
> easier than your ever growing and breaking maze of packages we don't even 
> need to vendor.
>
> At the moment you are actively breaking down the precious project fabric, 
> all in the name of you having your way: 
>
> you blocked me (without bothering yo even tell me) and perhaps other 
> developers on GitHub, meaning that you effectively want to shut me up.
> (Well, I had no other choice but to block you too, as a countermeasure; I 
> installed this block about 12:00 GMT, today.)
>
> Of course it's easy to skip this message. But tomorrow it might be you who 
> Matthias might block, for disagreements with him.
> Why is this tolerated? This is a naked attempt to shut down the opposition.
>
>
> >
> >We are better off with improving the tooling that we already know *will* 
> >continue to be used: Namely the tooling for creating and maintaining our 
> >metadata in build/pkgs.
>
> Or it will be discarded as useless, because doing things the way projects 
> like scipy do is better.
>
> Your package tooling is makework, repeating with worse tools what already 
> is done by Conda, Homebrew, Linux distros, etc. We are mainly a maths 
> project, not a distro project. Let us stay this way, and actually do more 
> maths and less distro-like stuff.
>
> Dima
>
>
> > Issues such as:
> >- https://github.com/sagemath/sage/issues/36356, 
> >- https://github.com/sagemath/sage/pull/37322, 
> >- https://github.com/sagemath/sage/issues/37323, 
> >- https://github.com/sagemath/sage/issues/37314
> >
>

-- 
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/15220b4c-09f8-4408-9152-816ef45b4261n%40googlegroups.com.

[sage-devel] jupyterlab on sage 10.2

[Jan Groenewald]

Hi

sage 10.2 on Debian 12, and
sage -i jupyterlab

sage --notebook=jupyterlab

launches, and the logo displays and animates, and then stops. I can't get
further. Any ideas?

This was working in sage 10.1.

Regards,
Jan

-- 
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/CAAg%3Dp_1eYsYAHsZF_6fYNnGOQqLrzoCSROyakXz%3DiQ3KMWd8gw%40mail.gmail.com.

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

[Dima Pasechnik]

On 27 February 2024 19:37:31 GMT, Matthias Koeppe  
wrote:
>On Tuesday, February 27, 2024 at 10:50:55 AM UTC-8 John H Palmieri wrote:
>
>A pretty safe second choice would be to have "make download" also download 
>the relevant files for pip installation and tell pip where to find them. If 
>we implemented this second choice [...]
>
>
>The problem is that such tooling, even if "trivial", would need to be 
>implemented, tested, and maintained as well. And typically this just does 
>not work when there is no developer who is actually interested in using it.

It is a largely artificially invented, by you, problem, to shoot my proposal 
down. Besides, these tools are trivial to build and maintain, much easier than 
your ever growing and breaking maze of packages we don't even need to vendor.

At the moment you are actively breaking down the precious project fabric, all 
in the name of you having your way: 

you blocked me (without bothering yo even tell me) and perhaps other developers 
on GitHub, meaning that you effectively want to shut me up.
(Well, I had no other choice but to block you too, as a countermeasure; I 
installed this block  about 12:00 GMT, today.)

Of course it's easy to skip this message. But tomorrow it might be you who 
Matthias might block, for disagreements with him.
Why is this tolerated? This is a naked attempt to shut down the opposition.


>
>We are better off with improving the tooling that we already know *will* 
>continue to be used: Namely the tooling for creating and maintaining our 
>metadata in build/pkgs.

Or it will be discarded as useless, because doing things the way projects like 
scipy do is better.

Your package tooling is makework, repeating with worse tools what already is 
done by Conda, Homebrew, Linux distros, etc. We are mainly a maths project, not 
a distro project. Let us stay this way, and actually do more maths and less 
distro-like stuff.

Dima


>  Issues such as:
>- https://github.com/sagemath/sage/issues/36356, 
>- https://github.com/sagemath/sage/pull/37322, 
>- https://github.com/sagemath/sage/issues/37323, 
>- https://github.com/sagemath/sage/issues/37314
>

-- 
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/06BFE7EF-F2E0-4072-B8A0-390DA9947AE6%40gmail.com.

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

[Nils Bruin]

On Tuesday 27 February 2024 at 10:50:55 UTC-8 John H Palmieri wrote:


As Nathan points out, this will likely lead to instability. Someone will 
upgrade some component, and most of the time that will be fine, but 
occasionally it will break something on some platform, and it could be 
annoying to track down the cause. If this leads to Sage failing to build, 
that's not great, but it would be *far worse* if Sage built and ran but 
produced some mathematically incorrect answers. Being able to control all 
of the versions means that our doctests are pretty robust. If we really 
want to go down the road of unpinning version requirements, I propose that 
we *always* pin version requirements for the mathematical components of 
Sage. If Jupyter or Sphinx doesn't work right, it doesn't affect the 
mathematics, but if linbox or pari don't work right (or ore_algebra, if you 
want a pip package), people could be getting different answers on different 
platforms and we might not know about it for a while. To maintain the 
mathematical integrity of the project, we should keep very careful control 
of the mathematical components of Sage.

+1 to this. There is another difference: The jupyter notebook server - 
notebook kernel interface is not a binary one: it's a protocol. As such, 
it's hopefully narrower in its definition and a bit more stable. So 
offering that sagemath offers a notebook kernel that a separately 
distributed notebook server can connect to is a different dependency 
structure than depending on libraries being provided. There are some super 
stable libraries for which external dependencies are OK, but generally 
(especially components under active development) they are a lot more 
sensitive.

For full functionality we depend on more than vanilla jupyter notebook, 
though: at some point, jupyter notebook server shipped with a pared-down 
mathjax and I have not been able to to get proper mathjax working in my 
system-provided jupyter notebook. We have other components, such as 
documentation and various plug-ins that we need in jupyter notebook too. 
This has made the shipped-with-sage jupyter notebook server more reliable 
to me, even if I'd prefer the system notebook server if that would be 
reliable to get working.

Sphinx is another part of such tooling: it should be able to just read and 
process markup. We tend to not ship a latex installation with our 
preprints. However, I don't have experience with how stable sphinx on its 
own is to judge how much trouble one would get from relying on an external 
sphinx. Personally, I don't bother building the sage documentation and rely 
on what is available online instead, so that one wouldn't affect me.  

-- 
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/88accdbb-7d2a-4860-8791-787bf52a8a89n%40googlegroups.com.

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

[Dima Pasechnik]

On 27 February 2024 18:50:55 GMT, John H Palmieri  
wrote:
>Regarding the proposal to allow standard packages to be pip packages, no 
>one really knows how much people rely on the all-in-one tarball that we 
>currently distribute. No one really knows how often the "make download" 
>option is used for people who just clone the git repo and want to do all of 
>their downloads at once. Since we don't know, the absolute safest course of 
>action is to not change anything, but maybe that's too conservative. A 
>pretty safe second choice would be to have "make download" also download 
>the relevant files for pip installation and tell pip where to find them. If 
>we implemented this second choice, I would support this aspect of Dima's 
>proposal.

At the moment we are talking about using this option,
have pytest* and build, as standard pip packages, whereas they are now optional 
pip packages.

This is all by now. We lived for years with them as optional packages, nobody 
had problems with them, why would they all of a sudden started causing problems?

>
>My impression from Dima's posts is that he would like us to frequently not 
>provide version information for pip packages. Here are some of my thoughts:
>
>As Nathan points out, this will likely lead to instability. 


No known to me project vendors pytest on the basis that doing otherwise would 
"lead to instability".

Let us be practical - there is no reason whatsoever to vendor pytest*.
Therefore standard pip packages should be allowed.

No known to me project vendors jupyterlab, either.

This is just FUD that a well maintained package like 
pytest must be vendored.
It's as believable as saying that tar must be vendored, cause a version not 
tested might lead to maths errors.


> Someone will 
>upgrade some component, and most of the time that will be fine, but 
>occasionally it will break something on some platform, and it could be 
>annoying to track down the cause. If this leads to Sage failing to build, 
>that's not great, but it would be *far worse* if Sage built and ran but 
>produced some mathematically incorrect answers.
> Being able to control all 
>of the versions means that our doctests are pretty robust. If we really 
>want to go down the road of unpinning version requirements, I propose that 
>we *always* pin version requirements for the mathematical components of 
>Sage.

We can still pin version requirements on pip packages. And indeed for maths 
packages,
a handful of these which are maths, we can always do this, why not?

> If Jupyter or Sphinx doesn't work right, it doesn't affect the 
>mathematics, but if linbox or pari don't work right (or ore_algebra, if you 
>want a pip package), people could be getting different answers on different 
>platforms and we might not know about it for a while. To maintain the 
>mathematical integrity of the project, we should keep very careful control 
>of the mathematical components of Sage.

Sure, I am fine with this. All what my proposal meant to do is to be able to 
get rid of lots of vendored packages which have nothing to do with maths, they 
are just guts of pytest, Jupyter, other common place packages.


>
>
>On Saturday, February 24, 2024 at 3:40:02 PM UTC-8 Matthias Koeppe wrote:
>
>> On Monday, February 12, 2024 at 6:42:07 PM UTC-8 Matthias Koeppe wrote:
>>
>> On Monday, February 12, 2024 at 3:52:29 PM UTC-8 Matthias Koeppe wrote:
>>
>>
>> *Proposed action items: *
>> *A.* Change https://github.com/sagemath/sage/blob/develop/README.md so 
>> that "git clone" is described as the primary way to obtain the Sage 
>> sources. That the big release tarball is available can be a footnote in the 
>> Installation Guide (
>> https://deploy-livedoc--sagemath.netlify.app/html/en/installation/source#installation-steps)
>>  
>> for the limited no-internet connectivity use case.
>>
>>
>> That's now https://github.com/sagemath/sage/pull/37309 (needs review)
>>
>>
>> Thanks for all comments on the PR. Ready for final review. 
>>  
>>
>>  *B. *Likewise, get rid of all of these "Download Sage source code" pages 
>> (https://www.sagemath.org/download-source.html, 
>> https://www.sagemath.org/download-latest.html), mirror selection, etc. 
>> from the Sage website. 
>>
>> That's now https://github.com/sagemath/website/pull/466
>>
>>
>> This one has already been merged, thanks, Harald! 
>> The "Download" menu no longer sends people to the tarball download pages. 
>> The pages are, of course, still there, and links from the installation 
>> guide point to them.
>>
>> [image: Screenshot 2024-02-24 at 3.34.47 PM.png]
>>
>> On Tuesday, February 20, 2024 at 6:44:32 PM UTC-8 Matthias Koeppe wrote:
>>
>> On Monday, February 19, 2024 at 12:09:54 PM UTC-8 Matthias Koeppe wrote:
>>
>> Prompted by the discussion of space use on the *local machines* of users 
>> and developers, I propose another item in addition to A and B:
>>
>> *C. Advertise use of "git worktree" and recommend symlinking the 
>> "upstream" directory.* For 

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

[Matthias Koeppe]

On Tuesday, February 27, 2024 at 10:50:55 AM UTC-8 John H Palmieri wrote:

A pretty safe second choice would be to have "make download" also download 
the relevant files for pip installation and tell pip where to find them. If 
we implemented this second choice [...]


The problem is that such tooling, even if "trivial", would need to be 
implemented, tested, and maintained as well. And typically this just does 
not work when there is no developer who is actually interested in using it.

We are better off with improving the tooling that we already know *will* 
continue to be used: Namely the tooling for creating and maintaining our 
metadata in build/pkgs. Issues such as:
- https://github.com/sagemath/sage/issues/36356, 
- https://github.com/sagemath/sage/pull/37322, 
- https://github.com/sagemath/sage/issues/37323, 
- https://github.com/sagemath/sage/issues/37314

-- 
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/0dc81e8a-d3c1-488f-9c53-580f21af2821n%40googlegroups.com.

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

[John H Palmieri]

Regarding the proposal to allow standard packages to be pip packages, no 
one really knows how much people rely on the all-in-one tarball that we 
currently distribute. No one really knows how often the "make download" 
option is used for people who just clone the git repo and want to do all of 
their downloads at once. Since we don't know, the absolute safest course of 
action is to not change anything, but maybe that's too conservative. A 
pretty safe second choice would be to have "make download" also download 
the relevant files for pip installation and tell pip where to find them. If 
we implemented this second choice, I would support this aspect of Dima's 
proposal.

My impression from Dima's posts is that he would like us to frequently not 
provide version information for pip packages. Here are some of my thoughts:

As Nathan points out, this will likely lead to instability. Someone will 
upgrade some component, and most of the time that will be fine, but 
occasionally it will break something on some platform, and it could be 
annoying to track down the cause. If this leads to Sage failing to build, 
that's not great, but it would be *far worse* if Sage built and ran but 
produced some mathematically incorrect answers. Being able to control all 
of the versions means that our doctests are pretty robust. If we really 
want to go down the road of unpinning version requirements, I propose that 
we *always* pin version requirements for the mathematical components of 
Sage. If Jupyter or Sphinx doesn't work right, it doesn't affect the 
mathematics, but if linbox or pari don't work right (or ore_algebra, if you 
want a pip package), people could be getting different answers on different 
platforms and we might not know about it for a while. To maintain the 
mathematical integrity of the project, we should keep very careful control 
of the mathematical components of Sage.


On Saturday, February 24, 2024 at 3:40:02 PM UTC-8 Matthias Koeppe wrote:

> On Monday, February 12, 2024 at 6:42:07 PM UTC-8 Matthias Koeppe wrote:
>
> On Monday, February 12, 2024 at 3:52:29 PM UTC-8 Matthias Koeppe wrote:
>
>
> *Proposed action items: *
> *A.* Change https://github.com/sagemath/sage/blob/develop/README.md so 
> that "git clone" is described as the primary way to obtain the Sage 
> sources. That the big release tarball is available can be a footnote in the 
> Installation Guide (
> https://deploy-livedoc--sagemath.netlify.app/html/en/installation/source#installation-steps)
>  
> for the limited no-internet connectivity use case.
>
>
> That's now https://github.com/sagemath/sage/pull/37309 (needs review)
>
>
> Thanks for all comments on the PR. Ready for final review. 
>  
>
>  *B. *Likewise, get rid of all of these "Download Sage source code" pages 
> (https://www.sagemath.org/download-source.html, 
> https://www.sagemath.org/download-latest.html), mirror selection, etc. 
> from the Sage website. 
>
> That's now https://github.com/sagemath/website/pull/466
>
>
> This one has already been merged, thanks, Harald! 
> The "Download" menu no longer sends people to the tarball download pages. 
> The pages are, of course, still there, and links from the installation 
> guide point to them.
>
> [image: Screenshot 2024-02-24 at 3.34.47 PM.png]
>
> On Tuesday, February 20, 2024 at 6:44:32 PM UTC-8 Matthias Koeppe wrote:
>
> On Monday, February 19, 2024 at 12:09:54 PM UTC-8 Matthias Koeppe wrote:
>
> Prompted by the discussion of space use on the *local machines* of users 
> and developers, I propose another item in addition to A and B:
>
> *C. Advertise use of "git worktree" and recommend symlinking the 
> "upstream" directory.* For testing a new release when you have an 
> existing clone of the repository, using "git clone" another time is 
> overkill as it creates another copy of the .git directory. And there is no 
> point in having multiple copies of the "upstream" directory, as the 
> filenames of the tarballs change whenever the contents change.
>
>
> That's now https://github.com/sagemath/sage/pull/37411 (needs review)
>
>
> This one has been positively reviewed. Thanks, Lorenz! 
>
>

-- 
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/b448c1da-eb22-4402-aea7-09bec2ab88e9n%40googlegroups.com.

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

[Dima Pasechnik]

On 27 February 2024 17:25:51 GMT, 'Animesh Shree' via sage-devel 
 wrote:
>This works good if input is square and I also checked on your idea of 
>padding zeros for non square matrices.
>I am currently concerned about the permutation matrix and L, U in case of 
>padded 0s. Because if we pad then how will they affect the outputs, so that 
>we can extract p,l,u for unpadded matrix.

please read details I wrote on how to deal with the non-square case. There is 
no padding needed.


>
>On Tuesday, February 27, 2024 at 10:03:25 PM UTC+5:30 Dima Pasechnik wrote:
>
>>
>>
>> On 27 February 2024 15:34:20 GMT, 'Animesh Shree' via sage-devel <
>> sage-...@googlegroups.com> wrote:
>> >I tried scipy which uses superLU. We get the result but there is little 
>> bit 
>> >of issue.
>> >
>> >
>> >--For Dense--
>> >The dense matrix factorization gives this output using permutation matrix
>> >sage: a = Matrix(RDF, [[1, 0],[2, 1]], sparse=True)
>> >sage: a
>> >[1.0 0.0]
>> >[2.0 1.0]
>> >sage: p,l,u = a.dense_matrix().LU()
>> >sage: p
>> >[0.0 1.0]
>> >[1.0 0.0]
>> >sage: l
>> >[1.0 0.0]
>> >[0.5 1.0]
>> >sage: u
>> >[ 2.0 1.0]
>> >[ 0.0 -0.5]
>> >
>>
>> you'd probably want to convert the permutation matrix into a permutation.
>>
>>
>> >--For Sparse--
>> >But the scipy LU decomposition uses permutations which involves taking 
>> >transpose, also the output permutations are represented as array.
>>
>> It is very normal to represent permutations as arrays.
>> One can reconstruct the permutation matrix from such an array trivially 
>> (IIRC, Sage even has a function for it)
>>
>> I am not sure what you mean by "taking transpose".
>>
>> >sage: p,l,u = a.LU(force=True)
>> >sage: p
>> >{'perm_r': [1, 0], 'perm_c': [1, 0]}
>> >sage: l
>> >[1.0 0.0]
>> >[0.0 1.0]
>> >sage: u
>> >[1.0 2.0]
>> >[0.0 1.0]
>> >
>> >
>> >Shall I continue with this?
>>
>> sure, you are quite close to getting it all done it seems.
>>
>>
>> >On Tuesday, February 6, 2024 at 11:29:07 PM UTC+5:30 Dima Pasechnik wrote:
>> >
>> >> Non-square case for LU is in fact easy. Note that if you have A=LU as
>> >> a block matrix
>> >> A11 A12
>> >> A21 A22
>> >>
>> >> then its LU-factors L and U are
>> >> L11 0 and U11 U12
>> >> L21 L22 0 U22
>> >>
>> >> and A11=L11 U11, A12=L11 U12, A21=L21 U11, A22=L21 U12+L22 U22
>> >>
>> >> Assume that A11 is square and full rank (else one may apply
>> >> permutations of rows and columns in the usual way). while A21=0 and
>> >> A22=0. Then one can take L21=0, L22=U22=0, while A12=L11 U12
>> >> implies U12=L11^-1 A12.
>> >> That is, we can first compute LU-decomposition of a square matrix A11,
>> >> and then compute U12 from it and A.
>> >>
>> >> Similarly, if instead A12=0 and A22=0, then we can take U12=0,
>> >> L22=U22=0, and A21=L21 U11,
>> >> i.e. L21=A21 U11^-1, and again we compute LU-decomposition of A11, and
>> >> then L21=A21 U11^-1.
>> >>
>> >> 
>> >>
>> >> Note that in some cases one cannot get LU, but instead must go for an
>> >> PLU,with P a permutation matrix.
>> >> For non-square matrices this seems a bit more complicated, but, well,
>> >> still doable.
>> >>
>> >> HTH
>> >> Dima
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, Feb 5, 2024 at 6:00 PM Nils Bruin  wrote:
>> >> >
>> >> > On Monday 5 February 2024 at 02:31:04 UTC-8 Dima Pasechnik wrote:
>> >> >
>> >> >
>> >> > it is the matter of adding extra zero rows or columns to the matrix 
>> you 
>> >> want to decompose. This could be a quick fix.
>> >> >
>> >> > (in reference to computing LU decompositions of non-square matrices) 
>> -- 
>> >> in a numerical setting, adding extra zero rows/columns may not be such 
>> an 
>> >> attractive option: if previously you know you had a maximal rank 
>> matrix, 
>> >> you have now ruined it by the padding. It's worth checking the 
>> >> documentation and literature if padding is appropriate/desirable for 
>> the 
>> >> target algorithm/implementation.
>> >> >
>> >> > --
>> >> > 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/622a01e0-9197-40c5-beda-92729c4e4a32n%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/2D2A6AC7-2C4F-486F-B19A-1ECEAE704D4B%40gmail.com.

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

[Nils Bruin]

See the documentation:

https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.SuperLU.html

As you can see there it computes permutation matrices Pr and Pc and lower 
and upper triangular matrices L,U such that

Pr*A*Pc = L*U

so it's not computing a normal LU decomposition of a PLU decomposition: 
it's doing both row- and column permutations on A; presumably to condition 
it to get  a more numerically stable L,U.

It's a different decomposition. You may be able to solve similar problems 
with it, but you'll have to expose the computed data to the user. I don't 
think it's suitable for wrapping as a normal LU-decomposition, as it won't 
be a drop-in substitute for it.

You do get

A = Pr^(-1) *L*U * Pc^(-1)




On Tuesday 27 February 2024 at 10:02:19 UTC-8 Animesh Shree wrote:

> Sorry for multiple messages
>
> I just want to say
>
> >sage: p,l,u = a.LU(force=True)
> >sage: p
> >{'perm_r': [1, 0], 'perm_c': [1, 0]}
>
> It  (  {'perm_r': [1, 0], 'perm_c': [1, 0]}  )  represents transpose and 
> it cannot be represented as permutation matrix.
> Similar cases may arise for other matrices.
>
> On Tuesday, February 27, 2024 at 11:29:44 PM UTC+5:30 Animesh Shree wrote:
>
>> For transpose :
>>
>> In  the example we can see permutations are provided as arrays for rows 
>> and cols.
>> The permutation is equivalent of taking transpose of matrix.
>> But we cant represent transpose as a permutation matrix.
>>
>>
>> >>> a = np.matrix([[1,2],[3,5]])
>> >>> # a * perm = a.T
>> >>> # perm = a.I * a.T
>> >>> a.I*a.T
>> matrix([[-1., -5.],
>> [ 1.,  4.]])
>> >>>
>>
>> the output is not permutation matrix. 
>>
>> On Tuesday, February 27, 2024 at 10:03:25 PM UTC+5:30 Dima Pasechnik 
>> wrote:
>>
>>>
>>>
>>> On 27 February 2024 15:34:20 GMT, 'Animesh Shree' via sage-devel <
>>> sage-...@googlegroups.com> wrote: 
>>> >I tried scipy which uses superLU. We get the result but there is little 
>>> bit 
>>> >of issue. 
>>> > 
>>> > 
>>> >--For Dense-- 
>>> >The dense matrix factorization gives this output using permutation 
>>> matrix 
>>> >sage: a = Matrix(RDF, [[1, 0],[2, 1]], sparse=True) 
>>> >sage: a 
>>> >[1.0 0.0] 
>>> >[2.0 1.0] 
>>> >sage: p,l,u = a.dense_matrix().LU() 
>>> >sage: p 
>>> >[0.0 1.0] 
>>> >[1.0 0.0] 
>>> >sage: l 
>>> >[1.0 0.0] 
>>> >[0.5 1.0] 
>>> >sage: u 
>>> >[ 2.0 1.0] 
>>> >[ 0.0 -0.5] 
>>> > 
>>>
>>> you'd probably want to convert the permutation matrix into a 
>>> permutation. 
>>>
>>>
>>> >--For Sparse-- 
>>> >But the scipy LU decomposition uses permutations which involves taking 
>>> >transpose, also the output permutations are represented as array. 
>>>
>>> It is very normal to represent permutations as arrays. 
>>> One can reconstruct the permutation matrix from such an array trivially 
>>> (IIRC, Sage even has a function for it) 
>>>
>>> I am not sure what you mean by "taking transpose". 
>>>
>>> >sage: p,l,u = a.LU(force=True) 
>>> >sage: p 
>>> >{'perm_r': [1, 0], 'perm_c': [1, 0]} 
>>> >sage: l 
>>> >[1.0 0.0] 
>>> >[0.0 1.0] 
>>> >sage: u 
>>> >[1.0 2.0] 
>>> >[0.0 1.0] 
>>> > 
>>> > 
>>> >Shall I continue with this? 
>>>
>>> sure, you are quite close to getting it all done it seems. 
>>>
>>>
>>> >On Tuesday, February 6, 2024 at 11:29:07 PM UTC+5:30 Dima Pasechnik 
>>> wrote: 
>>> > 
>>> >> Non-square case for LU is in fact easy. Note that if you have A=LU as 
>>> >> a block matrix 
>>> >> A11 A12 
>>> >> A21 A22 
>>> >> 
>>> >> then its LU-factors L and U are 
>>> >> L11 0 and U11 U12 
>>> >> L21 L22 0 U22 
>>> >> 
>>> >> and A11=L11 U11, A12=L11 U12, A21=L21 U11, A22=L21 U12+L22 U22 
>>> >> 
>>> >> Assume that A11 is square and full rank (else one may apply 
>>> >> permutations of rows and columns in the usual way). while A21=0 and 
>>> >> A22=0. Then one can take L21=0, L22=U22=0, while A12=L11 U12 
>>> >> implies U12=L11^-1 A12. 
>>> >> That is, we can first compute LU-decomposition of a square matrix 
>>> A11, 
>>> >> and then compute U12 from it and A. 
>>> >> 
>>> >> Similarly, if instead A12=0 and A22=0, then we can take U12=0, 
>>> >> L22=U22=0, and A21=L21 U11, 
>>> >> i.e. L21=A21 U11^-1, and again we compute LU-decomposition of A11, 
>>> and 
>>> >> then L21=A21 U11^-1. 
>>> >> 
>>> >>  
>>> >> 
>>> >> Note that in some cases one cannot get LU, but instead must go for an 
>>> >> PLU,with P a permutation matrix. 
>>> >> For non-square matrices this seems a bit more complicated, but, well, 
>>> >> still doable. 
>>> >> 
>>> >> HTH 
>>> >> Dima 
>>> >> 
>>> >> 
>>> >> 
>>> >> 
>>> >> On Mon, Feb 5, 2024 at 6:00 PM Nils Bruin  wrote: 
>>> >> > 
>>> >> > On Monday 5 February 2024 at 02:31:04 UTC-8 Dima Pasechnik wrote: 
>>> >> > 
>>> >> > 
>>> >> > it is the matter of adding extra zero rows or columns to the matrix 
>>> you 
>>> >> want to decompose. This could be a quick fix. 
>>> >> > 
>>> >> > (in reference to computing LU decompositions of non-square 
>>> matrices) -- 
>>> >> in a numerical setting, adding extra zero 

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

['Animesh Shree' via sage-devel]

Sorry for multiple messages

I just want to say

>sage: p,l,u = a.LU(force=True)
>sage: p
>{'perm_r': [1, 0], 'perm_c': [1, 0]}

It  (  {'perm_r': [1, 0], 'perm_c': [1, 0]}  )  represents transpose and it 
cannot be represented as permutation matrix.
Similar cases may arise for other matrices.

On Tuesday, February 27, 2024 at 11:29:44 PM UTC+5:30 Animesh Shree wrote:

> For transpose :
>
> In  the example we can see permutations are provided as arrays for rows 
> and cols.
> The permutation is equivalent of taking transpose of matrix.
> But we cant represent transpose as a permutation matrix.
>
>
> >>> a = np.matrix([[1,2],[3,5]])
> >>> # a * perm = a.T
> >>> # perm = a.I * a.T
> >>> a.I*a.T
> matrix([[-1., -5.],
> [ 1.,  4.]])
> >>>
>
> the output is not permutation matrix. 
>
> On Tuesday, February 27, 2024 at 10:03:25 PM UTC+5:30 Dima Pasechnik wrote:
>
>>
>>
>> On 27 February 2024 15:34:20 GMT, 'Animesh Shree' via sage-devel <
>> sage-...@googlegroups.com> wrote: 
>> >I tried scipy which uses superLU. We get the result but there is little 
>> bit 
>> >of issue. 
>> > 
>> > 
>> >--For Dense-- 
>> >The dense matrix factorization gives this output using permutation 
>> matrix 
>> >sage: a = Matrix(RDF, [[1, 0],[2, 1]], sparse=True) 
>> >sage: a 
>> >[1.0 0.0] 
>> >[2.0 1.0] 
>> >sage: p,l,u = a.dense_matrix().LU() 
>> >sage: p 
>> >[0.0 1.0] 
>> >[1.0 0.0] 
>> >sage: l 
>> >[1.0 0.0] 
>> >[0.5 1.0] 
>> >sage: u 
>> >[ 2.0 1.0] 
>> >[ 0.0 -0.5] 
>> > 
>>
>> you'd probably want to convert the permutation matrix into a permutation. 
>>
>>
>> >--For Sparse-- 
>> >But the scipy LU decomposition uses permutations which involves taking 
>> >transpose, also the output permutations are represented as array. 
>>
>> It is very normal to represent permutations as arrays. 
>> One can reconstruct the permutation matrix from such an array trivially 
>> (IIRC, Sage even has a function for it) 
>>
>> I am not sure what you mean by "taking transpose". 
>>
>> >sage: p,l,u = a.LU(force=True) 
>> >sage: p 
>> >{'perm_r': [1, 0], 'perm_c': [1, 0]} 
>> >sage: l 
>> >[1.0 0.0] 
>> >[0.0 1.0] 
>> >sage: u 
>> >[1.0 2.0] 
>> >[0.0 1.0] 
>> > 
>> > 
>> >Shall I continue with this? 
>>
>> sure, you are quite close to getting it all done it seems. 
>>
>>
>> >On Tuesday, February 6, 2024 at 11:29:07 PM UTC+5:30 Dima Pasechnik 
>> wrote: 
>> > 
>> >> Non-square case for LU is in fact easy. Note that if you have A=LU as 
>> >> a block matrix 
>> >> A11 A12 
>> >> A21 A22 
>> >> 
>> >> then its LU-factors L and U are 
>> >> L11 0 and U11 U12 
>> >> L21 L22 0 U22 
>> >> 
>> >> and A11=L11 U11, A12=L11 U12, A21=L21 U11, A22=L21 U12+L22 U22 
>> >> 
>> >> Assume that A11 is square and full rank (else one may apply 
>> >> permutations of rows and columns in the usual way). while A21=0 and 
>> >> A22=0. Then one can take L21=0, L22=U22=0, while A12=L11 U12 
>> >> implies U12=L11^-1 A12. 
>> >> That is, we can first compute LU-decomposition of a square matrix A11, 
>> >> and then compute U12 from it and A. 
>> >> 
>> >> Similarly, if instead A12=0 and A22=0, then we can take U12=0, 
>> >> L22=U22=0, and A21=L21 U11, 
>> >> i.e. L21=A21 U11^-1, and again we compute LU-decomposition of A11, and 
>> >> then L21=A21 U11^-1. 
>> >> 
>> >>  
>> >> 
>> >> Note that in some cases one cannot get LU, but instead must go for an 
>> >> PLU,with P a permutation matrix. 
>> >> For non-square matrices this seems a bit more complicated, but, well, 
>> >> still doable. 
>> >> 
>> >> HTH 
>> >> Dima 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> On Mon, Feb 5, 2024 at 6:00 PM Nils Bruin  wrote: 
>> >> > 
>> >> > On Monday 5 February 2024 at 02:31:04 UTC-8 Dima Pasechnik wrote: 
>> >> > 
>> >> > 
>> >> > it is the matter of adding extra zero rows or columns to the matrix 
>> you 
>> >> want to decompose. This could be a quick fix. 
>> >> > 
>> >> > (in reference to computing LU decompositions of non-square matrices) 
>> -- 
>> >> in a numerical setting, adding extra zero rows/columns may not be such 
>> an 
>> >> attractive option: if previously you know you had a maximal rank 
>> matrix, 
>> >> you have now ruined it by the padding. It's worth checking the 
>> >> documentation and literature if padding is appropriate/desirable for 
>> the 
>> >> target algorithm/implementation. 
>> >> > 
>> >> > -- 
>> >> > 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/622a01e0-9197-40c5-beda-92729c4e4a32n%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 

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

['Animesh Shree' via sage-devel]

For transpose :

In  the example we can see permutations are provided as arrays for rows and 
cols.
The permutation is equivalent of taking transpose of matrix.
But we cant represent transpose as a permutation matrix.


>>> a = np.matrix([[1,2],[3,5]])
>>> # a * perm = a.T
>>> # perm = a.I * a.T
>>> a.I*a.T
matrix([[-1., -5.],
[ 1.,  4.]])
>>>

the output is not permutation matrix. 

On Tuesday, February 27, 2024 at 10:03:25 PM UTC+5:30 Dima Pasechnik wrote:

>
>
> On 27 February 2024 15:34:20 GMT, 'Animesh Shree' via sage-devel <
> sage-...@googlegroups.com> wrote:
> >I tried scipy which uses superLU. We get the result but there is little 
> bit 
> >of issue.
> >
> >
> >--For Dense--
> >The dense matrix factorization gives this output using permutation matrix
> >sage: a = Matrix(RDF, [[1, 0],[2, 1]], sparse=True)
> >sage: a
> >[1.0 0.0]
> >[2.0 1.0]
> >sage: p,l,u = a.dense_matrix().LU()
> >sage: p
> >[0.0 1.0]
> >[1.0 0.0]
> >sage: l
> >[1.0 0.0]
> >[0.5 1.0]
> >sage: u
> >[ 2.0 1.0]
> >[ 0.0 -0.5]
> >
>
> you'd probably want to convert the permutation matrix into a permutation.
>
>
> >--For Sparse--
> >But the scipy LU decomposition uses permutations which involves taking 
> >transpose, also the output permutations are represented as array.
>
> It is very normal to represent permutations as arrays.
> One can reconstruct the permutation matrix from such an array trivially 
> (IIRC, Sage even has a function for it)
>
> I am not sure what you mean by "taking transpose".
>
> >sage: p,l,u = a.LU(force=True)
> >sage: p
> >{'perm_r': [1, 0], 'perm_c': [1, 0]}
> >sage: l
> >[1.0 0.0]
> >[0.0 1.0]
> >sage: u
> >[1.0 2.0]
> >[0.0 1.0]
> >
> >
> >Shall I continue with this?
>
> sure, you are quite close to getting it all done it seems.
>
>
> >On Tuesday, February 6, 2024 at 11:29:07 PM UTC+5:30 Dima Pasechnik wrote:
> >
> >> Non-square case for LU is in fact easy. Note that if you have A=LU as
> >> a block matrix
> >> A11 A12
> >> A21 A22
> >>
> >> then its LU-factors L and U are
> >> L11 0 and U11 U12
> >> L21 L22 0 U22
> >>
> >> and A11=L11 U11, A12=L11 U12, A21=L21 U11, A22=L21 U12+L22 U22
> >>
> >> Assume that A11 is square and full rank (else one may apply
> >> permutations of rows and columns in the usual way). while A21=0 and
> >> A22=0. Then one can take L21=0, L22=U22=0, while A12=L11 U12
> >> implies U12=L11^-1 A12.
> >> That is, we can first compute LU-decomposition of a square matrix A11,
> >> and then compute U12 from it and A.
> >>
> >> Similarly, if instead A12=0 and A22=0, then we can take U12=0,
> >> L22=U22=0, and A21=L21 U11,
> >> i.e. L21=A21 U11^-1, and again we compute LU-decomposition of A11, and
> >> then L21=A21 U11^-1.
> >>
> >> 
> >>
> >> Note that in some cases one cannot get LU, but instead must go for an
> >> PLU,with P a permutation matrix.
> >> For non-square matrices this seems a bit more complicated, but, well,
> >> still doable.
> >>
> >> HTH
> >> Dima
> >>
> >>
> >>
> >>
> >> On Mon, Feb 5, 2024 at 6:00 PM Nils Bruin  wrote:
> >> >
> >> > On Monday 5 February 2024 at 02:31:04 UTC-8 Dima Pasechnik wrote:
> >> >
> >> >
> >> > it is the matter of adding extra zero rows or columns to the matrix 
> you 
> >> want to decompose. This could be a quick fix.
> >> >
> >> > (in reference to computing LU decompositions of non-square matrices) 
> -- 
> >> in a numerical setting, adding extra zero rows/columns may not be such 
> an 
> >> attractive option: if previously you know you had a maximal rank 
> matrix, 
> >> you have now ruined it by the padding. It's worth checking the 
> >> documentation and literature if padding is appropriate/desirable for 
> the 
> >> target algorithm/implementation.
> >> >
> >> > --
> >> > 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/622a01e0-9197-40c5-beda-92729c4e4a32n%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/ff4bb798-5634-4d9b-84e9-4f1a132f3e10n%40googlegroups.com.

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

['Animesh Shree' via sage-devel]

This works good if input is square and I also checked on your idea of 
padding zeros for non square matrices.
I am currently concerned about the permutation matrix and L, U in case of 
padded 0s. Because if we pad then how will they affect the outputs, so that 
we can extract p,l,u for unpadded matrix.

On Tuesday, February 27, 2024 at 10:03:25 PM UTC+5:30 Dima Pasechnik wrote:

>
>
> On 27 February 2024 15:34:20 GMT, 'Animesh Shree' via sage-devel <
> sage-...@googlegroups.com> wrote:
> >I tried scipy which uses superLU. We get the result but there is little 
> bit 
> >of issue.
> >
> >
> >--For Dense--
> >The dense matrix factorization gives this output using permutation matrix
> >sage: a = Matrix(RDF, [[1, 0],[2, 1]], sparse=True)
> >sage: a
> >[1.0 0.0]
> >[2.0 1.0]
> >sage: p,l,u = a.dense_matrix().LU()
> >sage: p
> >[0.0 1.0]
> >[1.0 0.0]
> >sage: l
> >[1.0 0.0]
> >[0.5 1.0]
> >sage: u
> >[ 2.0 1.0]
> >[ 0.0 -0.5]
> >
>
> you'd probably want to convert the permutation matrix into a permutation.
>
>
> >--For Sparse--
> >But the scipy LU decomposition uses permutations which involves taking 
> >transpose, also the output permutations are represented as array.
>
> It is very normal to represent permutations as arrays.
> One can reconstruct the permutation matrix from such an array trivially 
> (IIRC, Sage even has a function for it)
>
> I am not sure what you mean by "taking transpose".
>
> >sage: p,l,u = a.LU(force=True)
> >sage: p
> >{'perm_r': [1, 0], 'perm_c': [1, 0]}
> >sage: l
> >[1.0 0.0]
> >[0.0 1.0]
> >sage: u
> >[1.0 2.0]
> >[0.0 1.0]
> >
> >
> >Shall I continue with this?
>
> sure, you are quite close to getting it all done it seems.
>
>
> >On Tuesday, February 6, 2024 at 11:29:07 PM UTC+5:30 Dima Pasechnik wrote:
> >
> >> Non-square case for LU is in fact easy. Note that if you have A=LU as
> >> a block matrix
> >> A11 A12
> >> A21 A22
> >>
> >> then its LU-factors L and U are
> >> L11 0 and U11 U12
> >> L21 L22 0 U22
> >>
> >> and A11=L11 U11, A12=L11 U12, A21=L21 U11, A22=L21 U12+L22 U22
> >>
> >> Assume that A11 is square and full rank (else one may apply
> >> permutations of rows and columns in the usual way). while A21=0 and
> >> A22=0. Then one can take L21=0, L22=U22=0, while A12=L11 U12
> >> implies U12=L11^-1 A12.
> >> That is, we can first compute LU-decomposition of a square matrix A11,
> >> and then compute U12 from it and A.
> >>
> >> Similarly, if instead A12=0 and A22=0, then we can take U12=0,
> >> L22=U22=0, and A21=L21 U11,
> >> i.e. L21=A21 U11^-1, and again we compute LU-decomposition of A11, and
> >> then L21=A21 U11^-1.
> >>
> >> 
> >>
> >> Note that in some cases one cannot get LU, but instead must go for an
> >> PLU,with P a permutation matrix.
> >> For non-square matrices this seems a bit more complicated, but, well,
> >> still doable.
> >>
> >> HTH
> >> Dima
> >>
> >>
> >>
> >>
> >> On Mon, Feb 5, 2024 at 6:00 PM Nils Bruin  wrote:
> >> >
> >> > On Monday 5 February 2024 at 02:31:04 UTC-8 Dima Pasechnik wrote:
> >> >
> >> >
> >> > it is the matter of adding extra zero rows or columns to the matrix 
> you 
> >> want to decompose. This could be a quick fix.
> >> >
> >> > (in reference to computing LU decompositions of non-square matrices) 
> -- 
> >> in a numerical setting, adding extra zero rows/columns may not be such 
> an 
> >> attractive option: if previously you know you had a maximal rank 
> matrix, 
> >> you have now ruined it by the padding. It's worth checking the 
> >> documentation and literature if padding is appropriate/desirable for 
> the 
> >> target algorithm/implementation.
> >> >
> >> > --
> >> > 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/622a01e0-9197-40c5-beda-92729c4e4a32n%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/85dbeb00-ec87-4012-b0fc-06baff9cef6dn%40googlegroups.com.

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

[Dima Pasechnik]

On 27 February 2024 15:34:20 GMT, 'Animesh Shree' via sage-devel 
 wrote:
>I tried scipy which uses superLU. We get the result but there is little bit 
>of issue.
>
>
>--For Dense--
>The dense matrix factorization gives this output using permutation matrix
>sage: a = Matrix(RDF, [[1, 0],[2, 1]], sparse=True)
>sage: a
>[1.0 0.0]
>[2.0 1.0]
>sage: p,l,u = a.dense_matrix().LU()
>sage: p
>[0.0 1.0]
>[1.0 0.0]
>sage: l
>[1.0 0.0]
>[0.5 1.0]
>sage: u
>[ 2.0  1.0]
>[ 0.0 -0.5]
>

you'd probably want to convert the permutation matrix into a permutation.


>--For Sparse--
>But the scipy LU decomposition uses permutations which involves taking 
>transpose, also the output permutations are represented as array.

It is very normal to represent permutations as arrays.
One can reconstruct the permutation matrix from such an array trivially (IIRC, 
Sage even has a function for it)

I am not sure what you mean by "taking transpose".

>sage: p,l,u = a.LU(force=True)
>sage: p
>{'perm_r': [1, 0], 'perm_c': [1, 0]}
>sage: l
>[1.0 0.0]
>[0.0 1.0]
>sage: u
>[1.0 2.0]
>[0.0 1.0]
>
>
>Shall I continue with this?

sure, you are quite close to getting it all done it seems.


>On Tuesday, February 6, 2024 at 11:29:07 PM UTC+5:30 Dima Pasechnik wrote:
>
>> Non-square case for LU is in fact easy. Note that if you have A=LU as
>> a block matrix
>> A11 A12
>> A21 A22
>>
>> then its LU-factors L and U are
>> L11 0 and U11 U12
>> L21 L22 0 U22
>>
>> and A11=L11 U11, A12=L11 U12, A21=L21 U11, A22=L21 U12+L22 U22
>>
>> Assume that A11 is square and full rank (else one may apply
>> permutations of rows and columns in the usual way). while A21=0 and
>> A22=0. Then one can take L21=0, L22=U22=0, while A12=L11 U12
>> implies U12=L11^-1 A12.
>> That is, we can first compute LU-decomposition of a square matrix A11,
>> and then compute U12 from it and A.
>>
>> Similarly, if instead A12=0 and A22=0, then we can take U12=0,
>> L22=U22=0, and A21=L21 U11,
>> i.e. L21=A21 U11^-1, and again we compute LU-decomposition of A11, and
>> then L21=A21 U11^-1.
>>
>> 
>>
>> Note that in some cases one cannot get LU, but instead must go for an
>> PLU,with P a permutation matrix.
>> For non-square matrices this seems a bit more complicated, but, well,
>> still doable.
>>
>> HTH
>> Dima
>>
>>
>>
>>
>> On Mon, Feb 5, 2024 at 6:00 PM Nils Bruin  wrote:
>> >
>> > On Monday 5 February 2024 at 02:31:04 UTC-8 Dima Pasechnik wrote:
>> >
>> >
>> > it is the matter of adding extra zero rows or columns to the matrix you 
>> want to decompose. This could be a quick fix.
>> >
>> > (in reference to computing LU decompositions of non-square matrices) -- 
>> in a numerical setting, adding extra zero rows/columns may not be such an 
>> attractive option: if previously you know you had a maximal rank matrix, 
>> you have now ruined it by the padding. It's worth checking the 
>> documentation and literature if padding is appropriate/desirable for the 
>> target algorithm/implementation.
>> >
>> > --
>> > 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/622a01e0-9197-40c5-beda-92729c4e4a32n%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/92DC3275-89B9-407B-AE90-E37AD207140E%40gmail.com.

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

['Animesh Shree' via sage-devel]

I tried scipy which uses superLU. We get the result but there is little bit 
of issue.


--For Dense--
The dense matrix factorization gives this output using permutation matrix
sage: a = Matrix(RDF, [[1, 0],[2, 1]], sparse=True)
sage: a
[1.0 0.0]
[2.0 1.0]
sage: p,l,u = a.dense_matrix().LU()
sage: p
[0.0 1.0]
[1.0 0.0]
sage: l
[1.0 0.0]
[0.5 1.0]
sage: u
[ 2.0  1.0]
[ 0.0 -0.5]

--For Sparse--
But the scipy LU decomposition uses permutations which involves taking 
transpose, also the output permutations are represented as array.
sage: p,l,u = a.LU(force=True)
sage: p
{'perm_r': [1, 0], 'perm_c': [1, 0]}
sage: l
[1.0 0.0]
[0.0 1.0]
sage: u
[1.0 2.0]
[0.0 1.0]


Shall I continue with this?
On Tuesday, February 6, 2024 at 11:29:07 PM UTC+5:30 Dima Pasechnik wrote:

> Non-square case for LU is in fact easy. Note that if you have A=LU as
> a block matrix
> A11 A12
> A21 A22
>
> then its LU-factors L and U are
> L11 0 and U11 U12
> L21 L22 0 U22
>
> and A11=L11 U11, A12=L11 U12, A21=L21 U11, A22=L21 U12+L22 U22
>
> Assume that A11 is square and full rank (else one may apply
> permutations of rows and columns in the usual way). while A21=0 and
> A22=0. Then one can take L21=0, L22=U22=0, while A12=L11 U12
> implies U12=L11^-1 A12.
> That is, we can first compute LU-decomposition of a square matrix A11,
> and then compute U12 from it and A.
>
> Similarly, if instead A12=0 and A22=0, then we can take U12=0,
> L22=U22=0, and A21=L21 U11,
> i.e. L21=A21 U11^-1, and again we compute LU-decomposition of A11, and
> then L21=A21 U11^-1.
>
> 
>
> Note that in some cases one cannot get LU, but instead must go for an
> PLU,with P a permutation matrix.
> For non-square matrices this seems a bit more complicated, but, well,
> still doable.
>
> HTH
> Dima
>
>
>
>
> On Mon, Feb 5, 2024 at 6:00 PM Nils Bruin  wrote:
> >
> > On Monday 5 February 2024 at 02:31:04 UTC-8 Dima Pasechnik wrote:
> >
> >
> > it is the matter of adding extra zero rows or columns to the matrix you 
> want to decompose. This could be a quick fix.
> >
> > (in reference to computing LU decompositions of non-square matrices) -- 
> in a numerical setting, adding extra zero rows/columns may not be such an 
> attractive option: if previously you know you had a maximal rank matrix, 
> you have now ruined it by the padding. It's worth checking the 
> documentation and literature if padding is appropriate/desirable for the 
> target algorithm/implementation.
> >
> > --
> > 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/622a01e0-9197-40c5-beda-92729c4e4a32n%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/01a88e23-12e5-46f9-a33d-16101896eabbn%40googlegroups.com.

[sage-devel] CenOS installation issue:

[Jyoti Prajapati]

Dear sir,
Hope you are doing well!
I am trying to follow the instruction to install sagemath in centos7 using 
the given commands for centos provided in the link :
https://doc.sagemath.org/html/en/installation/source.html#fedora-redhat-centos-package-installation

But most of the packages are not available. 

Please guide me so that I can install sagemath in centos properly without 
any error.

Thank you,
Best wishes
Jyoti

code: >>
Loading mirror speeds from cached hostfile
epel/x86_64/metalink| 5.4 kB 
 00:00:00
 * centos-sclo-rh: bd.mirror.vanehost.com
 * centos-sclo-sclo: bd.mirror.vanehost.com
 * epel: mirror.nyist.edu.cn
Package Cython-0.19-5.el7.x86_64 already installed and latest version
No package L-function available.
No package L-function-devel available.
No package Singular available.
No package Singular-devel available.
No package arb available.
No package arb-devel available.
Package babel-0.9.6-8.el7.noarch already installed and latest version
Package binutils-2.27-34.base.el7.x86_64 already installed and latest 
version
Package boost-devel-1.53.0-27.el7.x86_64 already installed and latest 
version
No package brial available.
No package brial-devel available.
Package bzip2-1.0.6-13.el7.x86_64 already installed and latest version
Package bzip2-devel-1.0.6-13.el7.x86_64 already installed and latest version
No package cddlib available.
No package cliquer available.
No package cliquer-devel available.
Package cmake-2.8.12.2-2.el7.x86_64 already installed and latest version
Package curl-7.29.0-51.el7.x86_64 already installed and latest version
Package diffutils-3.3-4.el7.x86_64 already installed and latest version
No package ecl available.
No package eclib available.
No package eclib-devel available.
No package fflas-ffpack-devel available.
Package 1:findutils-4.5.11-6.el7.x86_64 already installed and latest version
No package flint available.
No package flint-devel available.
Package gc-7.2d-7.el7.x86_64 already installed and latest version
Package gc-devel-7.2d-7.el7.x86_64 already installed and latest version
Package gcc-4.8.5-36.el7.x86_64 already installed and latest version
Package gcc-c++-4.8.5-36.el7.x86_64 already installed and latest version
Package gcc-gfortran-4.8.5-36.el7.x86_64 already installed and latest 
version
Package gd-2.0.35-26.el7.x86_64 already installed and latest version
Package gd-devel-2.0.35-26.el7.x86_64 already installed and latest version
Package gengetopt-2.23-1.el7.x86_64 already installed and latest version
Package gf2x-1.1-5.el7.x86_64 already installed and latest version
Package gf2x-devel-1.1-5.el7.x86_64 already installed and latest version
No package gfan available.
No package giac available.
No package giac-devel available.
No package givaro available.
No package givaro-devel available.
Package glpk-4.52.1-2.el7.x86_64 already installed and latest version
Package glpk-devel-4.52.1-2.el7.x86_64 already installed and latest version
Package glpk-utils-4.52.1-2.el7.x86_64 already installed and latest version
Package 1:gmp-6.0.0-15.el7.x86_64 already installed and latest version
Package 1:gmp-devel-6.0.0-15.el7.x86_64 already installed and latest version
No package gmp-ecm available.
No package gmp-ecm-devel available.
Package gsl-1.15-13.el7.x86_64 already installed and latest version
Package gsl-devel-1.15-13.el7.x86_64 already installed and latest version
Package iml-1.0.5-32.el7.x86_64 already installed and latest version
Package iml-devel-1.0.5-32.el7.x86_64 already installed and latest version
Package info-5.1-5.el7.x86_64 already installed and latest version
Package python-ipython-3.2.3-1.el7.noarch already installed and latest 
version
No package libatomic_ops available.
Package libatomic_ops-devel-7.2d-7.el7.x86_64 already installed and latest 
version
Package libbraiding-1.1-9.el7.x86_64 already installed and latest version
Package libcurl-devel-7.29.0-51.el7.x86_64 already installed and latest 
version
Package libffi-3.0.13-18.el7.x86_64 already installed and latest version
Package libffi-devel-3.0.13-18.el7.x86_64 already installed and latest 
version
No package libfplll available.
No package libfplll-devel available.
No package libhomfly-devel available.
Package libmpc-1.0.1-3.el7.x86_64 already installed and latest version
Package libmpc-devel-1.0.1-3.el7.x86_64 already installed and latest version
No package linbox available.
No package lrcalc-devel available.
Package m4-1.4.16-10.el7.x86_64 already installed and latest version
No package m4ri-devel available.
No package m4rie-devel available.
Package 1:make-3.82-23.el7.x86_64 already installed and latest version
Package meson-0.55.1-1.el7.noarch already installed and latest version
Package mpfr-devel-3.1.1-4.el7.x86_64 already installed and latest version
No package nauty available.
Package ncurses-devel-5.9-14.20130511.el7_4.x86_64 already installed and 
latest version
Package ninja-build-1.10.2-3.el7.x86_64 already