[sage-devel] Review request on small, local enhancements for parallelogram polyominoes

['Martin R' via sage-devel]

I added a second bijection between Dyck paths and parallelogram 
polyominoes, and bijections implementing the symmetries of parallelogram 
polyominoes.

The modifications are very local, all tests and linters pass.  I'd be 
grateful for a review.

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

Many thanks,

Martin

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5fee00b8-20ec-4a25-9c9e-f81a911edb23n%40googlegroups.com.

Re: [sage-devel] Review request: Choeskly-for-sparse-matrices patch

[Michael Orlitzky]

On Mon, 2021-01-25 at 23:19 -0800, Siddharth Bhat wrote:
> Hey all,
> 
> I'm very new here, so I'm unsure how this works; 
> I submitted a patch on saturday that implements chokesly
> decomposition for 
> sparse matrices by calling out to cvxopt.cholmod: 
> https://trac.sagemath.org/ticket/13674
> 
> I'm trying to figure out how I can have the patch reviewed. I set
> the 
> status to needs_review; That doesn't seem to have garnered any
> attention :) 
> 

Setting the ticket to "needs review" makes it show up in the list of
tickets needing review. Unless you know someone who might be interested
in reviewing it... the next step is simply to wait. It can take weeks
or months until someone qualified and interested stumbles upon it.

But you are in luck: on https://trac.sagemath.org/ticket/10332 I've
implemented a numerically stable block-LDLT factorization that I think
can be used in your "if not self.base_ring().is_exact()" branch, so you
don't have to call out to cvxopt or convert things to float when the
base ring is inexact. I'll take a closer look and post some comments on
your ticket.


> 1. Should I have created a new trac ticket to fix the issue?
> 2. Is there some metadata I forgot to update, and hence the patch
> does not 
> show up in the review queue?
> 3. Should I have "bump"-ed the patch in Trac?
> 

No, no, and no =)


-- 
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/ca50c38269be8058cdd3fcac23faed88e2062779.camel%40orlitzky.com.

[sage-devel] Review request: Choeskly-for-sparse-matrices patch

[Siddharth Bhat]

Hey all,

I'm very new here, so I'm unsure how this works; 
I submitted a patch on saturday that implements chokesly decomposition for 
sparse matrices by calling out to cvxopt.cholmod: 
https://trac.sagemath.org/ticket/13674

I'm trying to figure out how I can have the patch reviewed. I set the 
status to needs_review; That doesn't seem to have garnered any attention :) 

1. Should I have created a new trac ticket to fix the issue?
2. Is there some metadata I forgot to update, and hence the patch does not 
show up in the review queue?
3. Should I have "bump"-ed the patch in Trac?

Thanks a lot,
~Siddharth

-- 
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/eeda671e-892a-4cb1-b5ac-9c6f978ab5adn%40googlegroups.com.

[sage-devel] review request concerning __contains__ in a few combinatorics classes

['Martin R' via sage-devel]

Could someone please review

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

in combinat/diagram_algebras.py? It is a simple fix (making the generic 
method robust and removing the malfunctioning specialised versions, and 
adding many tests).

Two other tickets concerning malfunctioning `__contains__`, in 
`permutations.py`, which are also ready for review, 
are https://trac.sagemath.org/ticket/26809 
and https://trac.sagemath.org/ticket/26810

Would be great!

Martin

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] review request

['Martin R' via sage-devel]

Dear all,

the ticket #25662  (wrong contains 
in PartitionDiagrams) fixes a small bug that may hurt when computing in the 
diagram algebra.

Since it's finished for three months now, it would be great if someone 
could have a look at it!

Many thanks,

Martin

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Review request for global function fields into Sage

[Kwankyu Lee]

Hi,

I am in the process of bringing global function field machinery into Sage. 
But the process is getting too slow. You can help me by reviewing the ticket

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

There is not much mathematics in the ticket, and whoever has looked at the 
function field code of Sage could review it. Thank you.


Kwankyu 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] review request: patch to animate more graphics types

[Niles Johnson]

Hello all,

After a very long delay, I've finished a patch to create more animated gifs 
with sage!  The current animate command only works for plots in the plane, 
but the patch extends this in several ways.  I wrote up some examples and 
posted them here:

https://plus.google.com/+NilesJohnson/posts/UcXjavi9DDV

After a fair amount of discussion, and then a long break, the patch is 
relatively straightforward but I have no reviewers :(  If you have time and 
interest in reviewing, I'd appreciate it.  The ticket is

http://trac.sagemath.org/ticket/12827

thanks,
Niles

p.s.  If you need even *more* incentive, I'll point out that this patch 
also fixes a bug that makes animate broken on the sage cell server.  See

http://sagecell.sagemath.org/?q=zzqjqj



-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Review request for Trac #13312: Polyhedral bugfixes and improvements

[Volker Braun]

I think its time to start a tradition where I'm asking for ticket reviews 
;-)

$ git trac get 13312
==
Trac #13312: Polyhedral bugfixes and improvements

The .polar() method of the Polyhedron class is incorrect, currently it 
returns
the inversion of the correct answer.  Thanks to sarah-marie belcastro for
pointing this out.

Another bugfix/improvement is adding support for negation, which inverts
polyhedra.  Implementing this revealed that scalar multiplication by 
negative
numbers gave incorrect answers for polyhedra with rays.

Finally this adds a convenience function for obtained faces in terms of 
vertex
and inequality indices.

Status: needs_reviewComponent: geometry
Last modified: 2013-12-23 15:10:58  Created: 2012-07-31 13:34:10 UTC
Report upstream: N/A
Authors: Marshall Hampton, Volker Braun
Reviewers:
Branch: u/vbraun/polyhedral_neg_polar
Keywords: polyhedra, polar
Dependencies: #11763
--
Comment #1 by mhampton at 2012-08-03 15:50:34 UTC:
[Description] modified
--
Comment # by mhampton at 2012-08-03 15:51:17 UTC:
Fixes the polar method of Polyhedron (was inverted)
[Attachment] trac_13312_fix_polar_method_polyhedron.patch added
--
Comment #2 by mhampton at 2012-08-03 15:54:03 UTC:
[Description] modified
--
Comment #3 by mhampton at 2012-08-03 15:54:22 UTC:
[Status] changed from new to needs_review
--
Comment #4 by mhampton at 2012-08-04 16:27:56 UTC:
[Description] modified
[Summary] changed to Polyhedral bugfixes and improvements
--
Comment # by mhampton at 2012-08-04 16:28:27 UTC:
Fixes polar and scalar multiplication bugs
[Attachment] trac_13312_polyhedral_bugfixes_and_improvements.patch added
--
Comment #5 by mhampton at 2012-08-04 16:29:31 UTC:
[Cc] set to vbraun
--
Comment #6 by vbraun at 2012-08-04 22:59:17 UTC:
* rebased on top of #11763
* added commit message
* I'm against the `face_dual_descriptions` method. Never return lists
(mutable), and never return integer indices into internal data structures if
you can help it. Just return the actual object, its the same to Python 
(where
objects are really references to objects anyways). But I understand that it
would be desirable to access the faces without having to dig through the 
face
lattice. I've replaced it with a new `faces(dim)` method that returns the
faces in the given dimension. The docstring shows a one-liner to go from 
there
to the old `face_dual_descriptions` method.
[Authors] changed from Marshall Hampton to Marshall Hampton, Volker Braun
[Dependencies] set to #11763
[Description] modified
--
Comment #7 by mhampton at 2012-08-07 18:46:56 UTC:
I'd really like to have the functionality of the face_dual_descriptions
method.  I disagree that your docstring is really a one-liner, and I don't
think that would be very easy for Sage/Python newbies to figure out.  I have
talked to a couple of people who would like a platform for polyhedral
computation who have tried Sage and find it very difficult to accomplish 
what
they would like to do.  So I think perhaps we could add your faces(dim) 
method
and an improved version of the face_dual_descriptions method which could
return a tuple instead of a list if that makes you happier.
--
Comment #8 by vbraun at 2012-08-08 01:05:03 UTC:
What do you and/or your colleagues actually want to do? I doubt that anybody
''wants'' tuples of tuples of tuples of nondescript integers thrown at them.
This is both non-discoverable (no way to figure out what the integers mean)
while at the same time very error-prone (accidentally use the index in the
wrong list and you'll get hard-to-find bugs that yield the wrong result). 
Its
arguably true that many students were harmed with such anti-patterns, but 
its
never too late to to change.

Right now the `PolyhedronFace` class isn't really complete, so presumably we
need to flesh it more out so that you can get everything you need from the
face.
--
Comment #9 by mhampton at 2012-08-26 22:34:01 UTC:
OK, I am working on some sort of compromise patch and I noticed that your
patch (trac_13312_polyhedral_neg_polar.patch) doesn't apply - it looks like 

[sage-devel] review request: M4RI update M4RIE final sign-off

[Martin Albrecht]

Hi,

It would be great if someone could help with finalising the following two 
reviews:

1) M4RI update:

   http://trac.sagemath.org/sage_trac/ticket/11757

This update fixes two bugs + deals with compiler flags nicer. I tested it on 
the machine where the previous version had issues and everything works fine. 
So reading the attached patch

   trac_11757_m4ri_sse2.patch

and taking a quick look at the attached SPKG would be sufficient.

2) M4RIE:

   http://trac.sagemath.org/sage_trac/ticket/9562

It almost made it in a few weeks ago but then we discovered the SSE2 issue 
which is also dealt with in #11757. Hence, what is needed is somebody taking a 
quick look at the SPKG and playing around it with it to make sure nothing 
broke. I tested this SPKG on a wide range on machines such as iras.skynet, 
cicero,skynet, bsd.math and sage.math. Hence, I'm reasonably confident it's 
okay.

Any takers?

Cheers,
Martin


--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://martinralbrecht.wordpress.com/
_jab: martinralbre...@jabber.ccc.de

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Review request: #11115 cythonised cached methods

[Simon King]

Hi!

Since quite a long time, #5 is in need of a review. I think that
it provides quite useful stuff and should thus soon be added to Sage.

Currently, cached_method is implemented in Python, and can be so
frustratingly slow that it is faster to not cache simple routines, or
to implement a cache manually.
With #5, cached_method is rewritten in Cython and is so fast that
it beats any Python method.

Examples: A Python method
def is_exact(self):
return True
needs 690 ns on my machine, and
def prec(self):
return self._prec
even takes about 2.1 µs. Prepending @cached_method to these methods
makes them use not more than 375 ns on the same machine

So, cached_method is both comfortable and fast.

Currently, a cached_method (that may be inherited from the category
framework) does not work on instances that do not allow attribute
access (the cache would break). #5 makes it work on all parents.

Currently, cached_method can not be used at all in Cython code. Now,
it can (with some rough edges), even though a hand-written cache in
Cython is still faster (but less comfortable).

Currently, there is a class ClearCacheOnPickle, that avoids to store
the cached function values when pickling an instance. However, that
class had no example and did actually not work. #5 provides a
working implementation.

Also, #5 is currently the only dependency that prevents #11068
from being merged, that adds basic support for one- and two-sided
ideals in non-commutative rings to Sage.

Hence, I'd appreciate a review!

Best regards,
Simon

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Review request: #11115 cythonised cached methods

[Simon King]

Hi!

Since quite a long time, #5 is in need of a review. I think that
it provides quite useful stuff and should thus soon be added to Sage.

Currently, cached_method is implemented in Python, and can be so
frustratingly slow that it is faster to not cache simple routines, or
to implement a cache manually.
With #5, cached_method is rewritten in Cython and is so fast that
it beats any Python method.

Examples: A Python method
def is_exact(self):
return True
needs 690 ns on my machine, and
def prec(self):
return self._prec
even takes about 2.1 µs. Prepending @cached_method to these methods
makes them use not more than 375 ns on the same machine

So, cached_method is both comfortable and fast.

Currently, a cached_method (that may be inherited from the category
framework) does not work on instances that do not allow attribute
access (the cache would break). #5 makes it work on all parents.

Currently, cached_method can not be used at all in Cython code. Now,
it can (with some rough edges), even though a hand-written cache in
Cython is still faster (but less comfortable).

Currently, there is a class ClearCacheOnPickle, that avoids to store
the cached function values when pickling an instance. However, that
class had no example and did actually not work. #5 provides a
working implementation.

Also, #5 is currently the only dependency that prevents #11068
from being merged, that adds basic support for one- and two-sided
ideals in non-commutative rings to Sage.

Hence, I'd appreciate a review!

Best regards,
Simon

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Review Request: #1819

[Martin Albrecht]

Hi,

if someone had some time to look at #1819 it would really be appreciated. It's 
not a deep patch, just a bunch of moving around. However, because stuff is 
moved around it has the tendency to bitrot relatively fast.

http://trac.sagemath.org/sage_trac/ticket/1819

Cheers,
Martin

--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://martinralbrecht.wordpress.com/
_jab: martinralbre...@jabber.ccc.de

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] review request: add charset=utf8 to notebook pages, etc

[Dan Drake]

I'd like someone who knows the notebook code and Twisted to take a look
at tickets #4547 and #5211. Problems occur because the notebook doesn't
specify an encoding for the html pages it generates: see
http://groups.google.com/group/sage-support/t/3d4b400f5afe66fb .

In #5211, the patch adds a content-type header to all the html pages
generated by the notebook -- or tries to; I need someone who knows the
code better to make sure everything is covered.

Ticket #4547 was originally just to add content-type headers to
Twisted's HTTP responses; I added a charset specification. Again, I need
someone who knows the code better to make sure things work.

I propose that, if these patches fix the bulk of the encoding issues,
that we merge them and open new tickets for specifying content-type of
CSS and Javscript files and so on.

So, please review and comment!

Dan

-- 
---  Dan Drake dr...@kaist.edu
-  KAIST Department of Mathematical Sciences
---  http://mathsci.kaist.ac.kr/~drake


signature.asc
Description: Digital signature

[sage-devel] review request for trac #4164 (polyhedra.py)

[mhampton]

I thought I would explicitly point this one out because I had been
reviewing #4164 (work by Arnaud Bergeron), but now I am also
contributing code and I think the best scenario is to have someone
else take a look.  Mike Hansen has looked at polyhedra.py before, so
he is a candidate if willing, but it would be great if someone else
takes a look.  Polyhedra.py (in sage/geometry) is still in its early
stages; eventually I hope for it and other things in the geometry
group to provide most of the functionality of polymake and other
packages if they can't be made part of standard sage.  Because the
optimal design is far from clear to me, I want to encourage more
eyeballs on it (I am an enthusiastic amateur when it comes to
polytopes, not an expert).

Marshall Hampton
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---