Re: [sage-devel] Re: Would it be a good idea to start working on a module on Population Dynamics?

I disagree with the conclusion of Marc's slides; in particular that it is the "right way". In fact, I am going to be bold and propose that only adding new code like that is the wrong way for developing Sage. Following the logic, we should take all of the code in Sage, put in into (separate)

Re: [sage-devel] Re: Ergodic Theory

On Monday, July 24, 2017 at 6:26:54 PM UTC-5, William wrote: > > > On Mon, Jul 24, 2017 at 4:18 PM Travis Scrimshaw <tsc...@ucdavis.edu > > wrote: > >> Yes, you can. You should create a ticket (possibly more if it makes sense >> to break it into smaller chucks

[sage-devel] Re: Ergodic Theory

Yes, you can. You should create a ticket (possibly more if it makes sense to break it into smaller chucks) and push your code there as you work on it so people can look at it. Someone will likely suggest that you should develop it as a separate package built on-top of Sage. However, I only see

Re: [sage-devel] Old-style packages

I just realized that we do not have chomp included anymore on the list of optional packages. Moreover, it is now broken! This is really the last of the old-style packages I would like to see kept. Although really we should try and upgrade it...but maybe in the short-term, we can just make it

[sage-devel] Re: About milestone sage-feature

> > As one who added the latest of the tickets with milestone sage-feature, I > want to enliven them. As I see it, a sage-feature ticket intends to provide > a sage feature branch that is not appropriate to be merged to Sage through > the normal review process, but still useful to the people

[sage-devel] Re: Category question: how to get base ring?

On Tuesday, June 27, 2017 at 4:31:44 AM UTC-5, Jeroen Demeyer wrote: > > Suppose that R is some parent which is contained in the category > Algebras(B) for some ring B, how does one determine B from the parent R? > > I am asking because I want to implement a new method in the > ParentMethods

Re: [sage-devel] Option for docbuilding without plots?

Great, thank you. I figured there was something there, but I was looking for a specific environment variable. Thanks, Travis -- 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

[sage-devel] Option for docbuilding without plots?

While I do enjoy the plots (thank you to everyone who has been working on them to improve our documentation), they take a lot of time to render while building the docs. I have to do doc-cleans often enough that I don't want to have to rebuild the plots just to check that the documentation does

[sage-devel] Re: trac notifications

> > > I've checked my trac preferences and I have "Notify" for all events > available. Although I cannot see *"Notify: Any ticket changes" *which is > mentioned in the text around settings. I do not get notifications about > closed tickets like this one https://trac.sagemath.org/ticket/21066

[sage-devel] Re: Secondl round poll for H6 a specific guideline for writing docstrings

On Friday, May 19, 2017 at 4:32:58 AM UTC-5, Kwankyu Lee wrote: > > +1 > > In English, I understand that "foo; bar" is used if "bar" gives additional > information about "foo" while "foo, bar"is used to list "foo" and "bar" on > equal level. But I am not a native speaker... > Actually, that

Re: [sage-devel] Re: Normaliz and parallel doctest

t; hardware. (I never ran into trouble with it on my machine.) > > On Wed, May 17, 2017 at 5:24 PM, Travis Scrimshaw <tsc...@ucdavis.edu > > wrote: > > Well, we could do something in each doctest, but this is cumbersome and > ugly > > IMO. I was thinking

[sage-devel] Re: Second round poll for H2 a specific guideline for writing docstrings

Strong -1 (still) On Thursday, May 18, 2017 at 5:46:35 PM UTC-5, Kwankyu Lee wrote: > > As some of you worry, I do not attempt to put some strict rules into the > developer manual so that forbid your own style in writing docstrings. These > are intended just as guidelines; these will guide him

[sage-devel] Re: Secondl round poll for H6 a specific guideline for writing docstrings

+1 (this is also my preferred format) On Thursday, May 18, 2017 at 5:28:54 PM UTC-5, Kwankyu Lee wrote: > > Hi, > > I prepared H6 from your comments on the style of INPUT block. It was hard > to make a compromise from your differing opinions and reach a proposal for > the better. So this time*

[sage-devel] Re: Second round poll for H4 a specific guideline for writing docstrings

+1 (it is also currently used in practice). On Thursday, May 18, 2017 at 5:24:12 PM UTC-5, Kwankyu Lee wrote: > > Hi, > > I prepared H4 revised from G4 based on your ideas and wishes. It was hard > to make a compromise from your differing opinions and reach a proposal for > the better. So this

[sage-devel] Re: Second round poll for H1 a specific guideline for writing docstrings

+1 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com.

Re: [sage-devel] Re: Normaliz and parallel doctest

putenv in the doctests. > > On Tue, May 16, 2017 at 2:41 PM, Travis Scrimshaw <tsc...@ucdavis.edu > > wrote: > > Hey Matthias, > >Yes, that fixes the problem. Thank you. > > > > The next question is do we want to (temporarily) set this to, say, 1 > when

Re: [sage-devel] Poll for issue G2 a specific guideline for writing docstrings

I am (still) a strong -1 on this. ``self`` is a perfectly well-defined concept in Python and is often more concise and readable. It also works better with subclasses that have different names, e.g., lattice vs poset. Granted, this is not a very strong point because one should know a lattice is

[sage-devel] Re: Normaliz and parallel doctest

lease try if setting OMP_NUM_THREADS=4 or smaller fixes this problem. > This is something that I have to do in the CI scripts for Normaliz also ( > https://github.com/Normaliz/Normaliz/blob/master/.travis-build.sh#L7) > Best, > Matthias > > On Saturday, May 13, 2017 at 12:45:46 PM UT

Re: [sage-devel] cryptominisat 2 -> 5 jump (+ test cmake)

The latest version of chomp will also need cmake. So I'm +1 for making it optional (where as a dependency, the spkg is built only when there is not a system installation). Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To

[sage-devel] Re: Error installing Cython: pip2 was not found?

Glad to hear it worked. :) Best, Travis On Sunday, May 14, 2017 at 10:10:43 AM UTC-5, Peleg Michaeli wrote: > > Hi Travis, > > Thanks, it helped (took 5 hours, but helped :)) > > On Friday, 12 May 2017 17:11:28 UTC+3, Travis Scrimshaw wrote: >> >> The gcc that is

[sage-devel] Normaliz and parallel doctest

For the combinat/rigged_configurations, I recently changed the iteration method to use lattice point counting using normaliz (if installed). However, when running the doctests in parallel with normaliz installed, this causes a significant slowdown: travis@apricot:~/sage-build$ ./sage -tp 2

[sage-devel] Re: Error installing Cython: pip2 was not found?

The gcc that is included in Sage is 5.4.0, so I'm wondering if this is a problem. However, that is not based upon real insight. Also, considering the other thread, did you try "make distclean" and then "make build"? Sometimes larger incremental builds have caused me problems in the past, where

[sage-devel] Re: You must set either the SAGE_LOCAL or SAGE_SCRIPTS_DIR environment variable to run this

Hey Peleg, I suspect what happened is you pulled a more recent version of Sage than what you had installed. I would try running "make build". Best, Travis On Friday, May 12, 2017 at 8:39:36 AM UTC-5, Peleg Michaeli wrote: > > Only now I see that I have the same problem in branch develop

[sage-devel] Re: I need advice on my paper and Sage code on "Classifying bent functions by their Cayley graphs"

Hey Paul, I have just completed the first draft of a paper, "Classifying bent > functions by their Cayley graphs". > > > The computational results of the paper are fully reproducible via

[sage-devel] Re: different output of latex of crystal graph on Sage 7.6 and Cloud

Hey Jianping, So for Sage to use dot2tex, it currently does not use the system install, but instead it has to be installed in Sage by running "sage -i dot2tex". You might also need to install graphviz on your computer for the crystal graph to work. The reason why there is different output

[sage-devel] Re: Failed transition from 8.0.beta2 to 8.0.beta3

See https://groups.google.com/forum/#!topic/sage-release/-r5nNIcmVgQ. Best, Travis -- 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] Re: Sage on Cygwin status update

More updates, I've been able to install and use most of the packages that I normally would except: - libhomfly won't compile its corresponding pyx file: https://trac.sagemath.org/ticket/22856 - gap3 installed fine but won't run (but this is currently an experimental package, so slightly less

Re: [sage-devel] Re: Sage on Cygwin status update

Okay, I can't get it to run tests: $ ./sage -t src/sage no stored timings available Running doctests with ID 2017-04-22-01-14-29-566bb225. 0 [main] python2.7 5280 child_info_fork::abort: unable to map C:\ cygwin64\home\Travis\sage\local\lib\python2.7\site-packages\psutil\

Re: [sage-devel] Re: Sage on Cygwin status update

I also used atlas as my blas, using gcc 6.3, did it in parallel, and did not build the docs. Best, Travis On Friday, April 21, 2017 at 8:03:32 PM UTC-5, Travis Scrimshaw wrote: > > I was able to build and run Sage with the positively reviewed Cygwin > tickets plus: > &g

Re: [sage-devel] Re: Sage on Cygwin status update

I was able to build and run Sage with the positively reviewed Cygwin tickets plus: - https://trac.sagemath.org/ticket/21459 - https://trac.sagemath.org/ticket/21399 (I'm not sure if this was necessary) - https://trac.sagemath.org/ticket/22628 -

Re: [sage-devel] Re: Sage on Cygwin status update

Ah, I missed https://trac.sagemath.org/ticket/22761. Best, Travis -- 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

[sage-devel] Re: Sage on Cygwin status update

That's great to hear. What about the latest version of R? This is where I'm currently stuck on my Cygwin64 build. Best, Travis -- 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,

[sage-devel] Re: sage-8.0 beta and python3

On Sunday, April 9, 2017 at 10:05:44 AM UTC-5, Marco Cognetta wrote: > > I see that there has been work on converting print statements and simple > stuff like that to be python 3 compatible. What are the other steps > involved in fully supporting python 3 that are still underway (or haven't >

Re: [sage-devel] Re: sage-8.0 beta and python3

On Sunday, April 9, 2017 at 8:00:15 AM UTC-5, Andrew wrote: > > Is there a significant change behind going from version 7.6 to 8.0? > Andrew > > The major change there will be to start using the Jupyter notebook as the default instead of the SageNB. Python3 will be a later major version bump.

[sage-devel] Re: sage-8.0 beta and python3

Not yet, but Frédéric Chapoton has been doing a lot to try and make Sage Python3 compatible. So we now have the option to try to compile with Python3. We would welcome any assistance in trying to make this transition. Best, Travis On Friday, April 7, 2017 at 9:15:16 AM UTC-5, aishen wrote: >

[sage-devel] Re: Report on WomenInSage

4sums4uc3. :D On Friday, April 7, 2017 at 4:37:40 AM UTC-5, Kwankyu Lee wrote: > > Gorgeous! -- 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] As of Sage 8.0, lcm is from sage.arith.functions but gcd is not

You're welcome, with a very special thanks to Jeroen for his help. >From a user point of view, they are already imported so you shouldn't have to do anything. However, I am split on doing imports from all or the specific module, but I defer to the latter because it could potentially not

[sage-devel] Re: Computing invariants of hyperbolic Coxeter groups

I am interested in Coxeter groups and have worked quite a bit on them in Sage. So feel free to cc me on the eventual ticket ("tscrim") and/or e-mail me if you have any questions if you don't want to post here. As Miguel said, you should consider including this as an optional spkg or including

[sage-devel] Re: Bug or Feature: assumed precision of RealNumber depends on zero(s) before decimal point

I believe this comes from if '.' in mantissa and mantissa[:2] != '0.': sigfigs -= 1 is RealNumber. Now, as to why this was decided, this is outside of my knowledge. Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-devel"

[sage-combinat-devel] Re: Improvements to FreeAlgebra

Hey Simon, > > On 2017-03-29, Nicolas M. Thiery > wrote: > > It would be interesting to know specifically on which aspects the path > > algebra is improving on the current free algebra. The data structure > > of indices (i.e. words in the generators)? The data

[sage-devel] Re: Default display for equations in notebook

On Tuesday, March 21, 2017 at 5:59:39 PM UTC-5, Volker Braun wrote: > > Instead of adding another %display option, why not fix the standard > %display typeset? If mathjax can't display some object then it just > shouldn't display using mathjax in jupyter. > Is there some way we can check if

[sage-devel] Default display for equations in notebook

Eric Gourgoulhon and I were discussing the possibility of making the default display for the (Jupyter) notebooks be latex, and we decided that this might not be a good way forward because not everything has latex that gives valid mathjax (e.g., Partition([4,3,3,1]) uses \multicol, which is not

[sage-devel] Re: Making package polymake optional

No objections from me. Although we might want to try and improve the configure script before we make it optional if it can fail without helpful error messages. Best, Travis On Tuesday, March 14, 2017 at 2:54:19 AM UTC-5, vdelecroix wrote: > > Dear all, > > Now that we are in the process of

[sage-devel] Re: sphinx_tikz() in the documentation?

On Monday, March 6, 2017 at 6:24:15 AM UTC-6, jplab wrote: > > >> Le lundi 6 mars 2017 05:12:29 UTC+1, Travis Scrimshaw a écrit : >>> >>> Are you not able to do it by putting the tikz code in a .. MATH:: block? >>> >>> >> Haven't tried! W

[sage-devel] Re: sphinx_tikz() in the documentation?

Are you not able to do it by putting the tikz code in a .. MATH:: block? -- 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.

[sage-devel] Re: Names of special methods like _pari_

I feel like we should also put this in the context of other package conversions in Sage. We also do _foo_ for any of the others, e.g., _maxima_, _singular_, etc. So I think whatever we do for pari, we should do for the others. I agree with Jeroen that a deprecation accompanying this change

Re: [sage-devel] Names of special methods like _pari_

On Tuesday, February 28, 2017 at 4:41:40 PM UTC-6, John H Palmieri wrote: > > > > On Tuesday, February 28, 2017 at 1:16:53 PM UTC-8, Jeroen Demeyer wrote: >> >> On 2017-02-28 20:46, Johan S. H. Rosenkilde wrote: >> > In that case, it >> > could be seen as an implementation detail that objects

[sage-devel] Re: "replacement" optional packages

+1 to having another marker for those alternative-to-standard packages, but I think this is a bit of a problem to do in some general framework. These packages are suppose to come in sets and one of them will have to be installed. So it might be better to think of ways to combine these packages

[sage-devel] Re: How do I handle a bug I do not have time to fix?

Hey Salvatore, The typical approach is to put a stopgap, but it is best to do it in such a way that is as minimal as possible (i.e., hopefully not every ClusterQuiver from a matrix will have this stopgap pop up, or at worst only when the input is a matrix). Best, Travis On Monday,

Re: [sage-devel] Doctests broken in ticket #20729

Could we get a little more context for your problem? In particular, is foo.py included in the Sage source tree or is it something that you are building separately? If it is the former, have you tried "from path.to.foo import bar", where the path is starting from $SAGE_ROOT/src? Best, Travis

[sage-combinat-devel] Re: Constructing elements in disjoint enumerated sets that are Cartesian products

Hey Andrew, > > > Unfortunately, now it seems that I can't access the elements of the tuple > directly: > > sage: tabs = DisjointUnionEnumeratedSets(Family(Partitions(3), lambda mu: > cartesian_product([mu.standard_tableaux(),mu.standard_tableaux()])), > facade=False) > sage:

[sage-combinat-devel] Re: Constructing elements in disjoint enumerated sets that are Cartesian products

Hey Andrew, Well, I've recently been looking at DisjointUnionEnumeratedSets (see https://trac.sagemath.org/ticket/22382) and came across this problem. The first issue is that DisjointUnionEnumeratedSets does not behave like an actual facade parent like it claims to be (at least with default

[sage-devel] Re: GSoC 2017 kickoff

On Tuesday, February 7, 2017 at 9:33:22 AM UTC-6, Travis Scrimshaw wrote: > > I added two projects with the somewhat broad subject areas: > > - Improve the representation theory in Sage > - Improve the root system code in Sage > > I added another one for quantum cl

[sage-devel] Re: GSoC 2017 kickoff

I added two projects with the somewhat broad subject areas: - Improve the representation theory in Sage - Improve the root system code in Sage -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving

[sage-devel] Re: cc1 killed in iMac

> > Btw, what is the oldest and slowest computer where SageMath currently can > be compiled (without docs, as docbuilding should preferably be done in a > supercomputer near you...)? > > Slowest is almost certainly a Raspberry Pi with compile times in the multiple days (to a week)? Best,

Re: [sage-devel] Re: Python3?

For the cmp problem, Jeroen as suggested implementing our own cmp function. Thus, we just add this to the imports of every file that we don't want to go to rich comparisons (i.e., that needs it), which tries calling __cmp__ then falls back to ordering. This should at least get all of Sage to

Re: [sage-devel] Python3?

Frédéric has been working on getting stuff Python3 compatible. When he wakes up, he probably will give us an assessment. I believe he is able to get Sage to compile with Python3 with perhaps a few small tickets. Best, Travis On Wednesday, January 18, 2017 at 10:09:50 PM UTC-6, David Roe wrote:

Re: [sage-devel] group algebra modules

> > >>> It's not clear that this desire to do something general is that well >>> grounded in practical applications. In my old java project I implemented >>> only the five simply connected exceptional groups and mostly got by just >>> fine. Still, that was the idea. I noticed that reductive

[sage-devel] Re: coercions from (quadratic) NumberFields to AA

On Sunday, January 8, 2017 at 3:03:56 AM UTC-6, Marc Mezzarobba wrote: > > Travis Scrimshaw wrote: > > If no coercion is currently known, then coerce_map_from() calls > > _coerce_map_from_(). If _coerce_map_from_() returns a map, then that > > map becomes the coercion m

Re: [sage-devel] group algebra modules

Hey Joe, Sorry for the delayed response (I've been traveling the past few days). > > > Sorry for posting and then disappearing for a bit. Thanks for your > answers. I will be very happy to have your help with the project to the > extent that you have time, and even just any quick suggestions

[sage-devel] Re: Extra blank is inserted before the output in the Sage CLI

On Saturday, January 7, 2017 at 9:30:21 PM UTC-6, Kwankyu Lee wrote: > > This was reported earlier in > > > https://groups.google.com/forum/#!msg/sage-support/F6rDRrU59W8/kVbLWAtZAAAJ;context-place=searchin/sage-support/extra$20$20line > > The presumed suspect was the recent update of the

[sage-devel] Re: coercions from (quadratic) NumberFields to AA

Mezzarobba wrote: > > Travis Scrimshaw wrote: > > That is not true. Note that Foo.has_coerce_map_from() is not > > Foo._coerce_map_from_(). The method has_coerce_map_from() calls > > _coerce_map_from_, which should either return a coercion map or True, > > and in the lat

[sage-devel] Re: coercions from (quadratic) NumberFields to AA

On Wednesday, January 4, 2017 at 7:54:57 AM UTC-6, Marc Mezzarobba wrote: > > Daniel Krenn wrote: > > In the doc of sage.rings.qqbar.AlgebraicRealField._coerce_map_from_ > > there is the following test: > > > > sage: K. = QuadraticField(7, embedding=AA(7).sqrt()) > > sage:

[sage-devel] Re: Our SSL serial drama-cum-cliffhanger

My 2 cents, not that I know too much about this, would be to openly make it a listed dependency. I don't know how difficult it would be to maintain this as an optional dependency, but it is something we could either abort or warn the user (with a prompt) should they try installing Sage without

Re: [sage-devel] group algebra modules

Hey Joseph, There is currently a fair amount implemented with root systems: sage: Phi = RootSystem(['A',2]) sage: P = Phi.root_lattice() sage: Q = Phi.root_lattice() sage: P = Phi.weight_lattice() sage: al = Q.simple_roots() sage: al[1] alpha[1] sage: al[1].weyl_action([1,2,1]) -alpha[2] sage:

[sage-devel] Re: Python3-compatible syntax

> Regression in the move to python3 is happening all the time, and it is > indeed very annoying. > > Making a test target and a buildbot may be easier once at least all our > cython files are correctly cythonized in py3. This is blocked by the > removal of cmp() in all .pyx files. Not an easy

Re: [sage-devel] Re: Indexing Sage external packages (was: Giving back to the community)

On Wednesday, December 7, 2016 at 9:41:32 AM UTC-6, Jeroen Demeyer wrote: > > On 2016-12-07 14:52, Kwankyu Lee wrote: > > What do you think? > > Why do this? I guess this will mostly lead to bitrotting code that would > better be merged into Sage. > If it is an independent package, then

[sage-devel] Re: Aliases

Hey Peleg, Here is what I think is going on, the @doc_index is modifying the method degeneracy, i.e., it creates a new method with the same name of "degeneracy" and has a link back to the actual method. Then the new degeneracy also gets assigned to the name linkage. Now when the

Re: [sage-devel] Re: Lollipop vs. Barbell

Minor note, Cython code will still use xrange, but it can (often?) optimize calls to range. Best, Travis On Wednesday, December 7, 2016 at 5:00:56 AM UTC-6, Thierry (sage-googlesucks@xxx) wrote: > > On Wed, Dec 07, 2016 at 01:05:47AM -0800, Peleg Michaeli wrote: > > I can wrap it with list

[sage-devel] Re: Cross-type comparisons

> > We need to be very careful about defining "not knowing". I (stongly) > > believe when the objects/types are incomparable (say the rings ZZ and > > QQ), then == should return False and != should return True. > > Sorry, I don't understand your example: I think everyone agrees that > ZZ ==

[sage-devel] Re: Cross-type comparisons

On Sunday, December 4, 2016 at 1:59:00 PM UTC-6, Frédéric Chapoton wrote: > > There is currently an effort being made (by me and a few referees) to get > rid of cmp() in all pyx files. And the Element/Parent is one of the hardest > cases remaining. Getting rid of all calls to cmp( ) is

[sage-devel] Re: Return false or raise error on some situations

To clarify slightly, I want both cases to return False, whereas Jori wants both cases to raise an error. Same reasoning for me as is_similar for matrices. Best, Travis On Sunday, December 4, 2016 at 1:59:47 AM UTC-6, Jori Mäntysalo wrote: > > Currently > >

[sage-devel] Re: Alias causes "Duplicate explicit target name" when building docs

Hey Peleg, You should also only define the reference (i.e., the .. [XYZ] part) in the master references file in doc/en/reference/references/index.rst. Best, Travis On Thursday, December 1, 2016 at 7:58:00 AM UTC-6, Sébastien Labbé wrote: > > $ cat file.rst > > Cite many times the same item

[sage-devel] Re: Matrix multiplication for matrices over Iwahori-Hecke algebras (bug?)

Hey Amit, I think I've found a (rather alarming) bug regarding Iwahori-Hecke algebras: > That is not true; you've found a very subtle behavior with matrices and coercion. There's nothing wrong with the Iwahori-Hecke algebra. > > sage: L.=LaurentPolynomialRing(ZZ) > sage:

[sage-combinat-devel] Re: kronecker coefficient

Perhaps Andrew can weigh in on putting Kronecker coefficients with partition tuples, but it feels somewhat artificial to me. Instead, I like the explicitness of the syntax la.kronecker_coefficient(mu, nu) and/or having some (lazily imported) global namespace function of kronecker_coefficient

[sage-devel] Re: Building 7.4.beta5 after building 7.5 betas

> Or is the current recommendation to always merge develop after every new >>> beta? >>> >> >> I think it's to use it sparingly. That the history from git log is >> gobbled is IMO a git bug. >> >> perhaps we need a policy that for a positive review of a ticket branch > things like merge

Re: [sage-devel] RFC: correct way to deal with particular methods

On Monday, November 7, 2016 at 7:26:57 AM UTC-6, Jeroen Demeyer wrote: > > On 2016-11-07 14:13, 'Martin R' via sage-devel wrote: > > I would like that these subclasses inherit the docstring of > > GrowthDiagram.__init__ (and a few other methods), but I do not know how > > to achieve this. >

Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet

#19562 is probably the best fix, but really that makes FiniteEnumeratedSet not really any different than our (finite) Sequence class. I'm thinking we need some sort of unification long-term. > Also, instead of Subsets(L), I would also use subsets(L) (or powerset(L)) > > as you don't need the

Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet

On Wednesday, November 2, 2016 at 7:59:42 PM UTC-5, Luca De Feo wrote: > > > It is not a bug, but a by product of wanted (with documentation) of the > > UniqueRepresentation and the coercion system in Sage. More below. > > This is a bug. > > The fact that it is a consequence of wanted and

Re: [sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet

Hey Johan, > From my point of view, this can only be considered a bug: extremely > surprising behaviour leading to subtle problems in user code (my code). > Possibly, the bug is higher up than FiniteEnumeratedSets, though. > It is not a bug, but a by product of wanted (with documentation) of

[sage-devel] Re: Bug in caching mechanism of FiniteEnumeratedSet

Hey Johan, The problem is that we want finite enumerated sets to be hashable, picklable, and unique as they get used as keys for CombinatorialFreeModule, among other things, and it is implemented using UniqueRepresentation. The problem is that 1 = 1 with the same hash value whether in ZZ or

Re: [sage-devel] Re: vote on behaviour of is_similar for matrices

On Thursday, October 27, 2016 at 2:12:01 PM UTC-5, William wrote: > > On Thu, Oct 27, 2016 at 11:25 AM, kcrisman > wrote: > > > > > > On Thursday, October 27, 2016 at 2:11:58 PM UTC-4, John H Palmieri > wrote: > >> > >> (1) Why should a nonsquare matrix even have an

Re: [sage-devel] vote on behaviour of is_similar for matrices

regarding this? > > On Thursday, October 27, 2016, Dima Pasechnik <dim...@gmail.com > > wrote: > >> AA >> (but make sure docs make sense after the change) >> >> On Thursday, October 27, 2016 at 4:21:02 PM UTC, Travis Scrimshaw wrote: >>> >&g

Re: [sage-devel] vote on behaviour of is_similar for matrices

I am for BB because: 1 - the definition (as even given in the docstring) still makes full sense if the matrices are not the same size or if they are not square. There does not exist such a matrix P. 2 - It puts an unnecessary burden on the average user. They have to deal with errors on a

[sage-devel] Re: Coxeter3 problem.

I also get this as well. I believe I have become the official spkg maintainer, and I will fix it within a day. Best, Travis On Monday, October 24, 2016 at 2:46:28 AM UTC-5, tdumont wrote: > > > Coxeter3 cannot be compiled (7.4 and 7.5beta0). > > Actually this does not seem too difficult (a

[sage-devel] Re: line_profiler (%lprun) also broken from IPython upgrade

On Thursday, October 20, 2016 at 5:06:58 PM UTC-5, Brett Olsen wrote: > > This was a known bug in line_profiler that is fixed with the 2.0 release. > Try upgrading to line_profiler==2.0 and let us know if there's still a > problem. > > Yes, upgrading fixed it. Thank you! Best, Travis --

Re: [sage-devel] Conversion bug: field to vector space

> It is indeed a problem! The interfaces should be compatible. Adding a > _vector_ method to the GF(p) elements should be enough. > > Also, from a quick check, all of the other implementations of finite fields provide a _vector_() method as well. So I think Vincent's fix is the way to go.

[sage-devel] Re: puzzling dev.upload_ssh_key() in developer manual

It was suppose to put your ssh key onto your trac account automatically (and generate one if you had none). I found it to be very useful. I suspect it broke when the trac server IP(?) changed. Best, Travis On Saturday, October 15, 2016 at 1:46:33 PM UTC-5, Dima Pasechnik wrote: > > Does

Re: [sage-devel] About exceptions

On Wednesday, October 12, 2016 at 9:01:51 AM UTC-5, Daniel Krenn wrote: > > On 2016-10-12 13:39, Jori Mäntysalo wrote: > > More about this: In posets.py there is > > > > try: > > elements = D.topological_sort() > > except Exception: > > raise ValueError("Hasse

[sage-devel] Re: Testing new graph algorithms

> >> Even if it does turn out that this technique performs worse than Sage on >> some graphs, is it worth trying to integrate it as an option for users? >> > > Are these algorithms published? (sorry, "Mark Bell" isn't very googleable; > e.g. I found this https://arxiv.org/a/bell_m_3.html > but

Re: [sage-devel] Should __hash__ be constant across Sage invocations?

On Friday, October 7, 2016 at 7:17:40 AM UTC-5, Johan S. R. Nielsen wrote: > > Jeroen Demeyer writes: > > $ python3 -c "print(hash('hello'))" > > -74281615791272169 > > $ python3 -c "print(hash('hello'))" > > 447613799834866972 > > $ python3 -c "print(hash('hello'))" > >

[sage-devel] Re: Failed source build

It looks like GCC 4.9.3 won't build with GCC 6.2 (probably due to an increase in compiler strictness or something). The reason Sage is building its own copy of GCC that is you need to have the same versions for gcc, gfortran, and g++. Partial builds with different compilers seems like

[sage-devel] Re: State of sage built with clang/clang++ on OS X - update

> > symmetrica > > Someone volunteered for the trivial fix of changing > "return;" to "return 0;" in a few places at #12439... > > That would be me, and I had less time than I thought I would this past week. I am working on it now. Best, Travis -- You received this message because you

[sage-devel] Re: trouble compiling latest sage development version

Perhaps this is from the same error as stack overflow post ? I remember we had to have something with '-march=native' (on OSX?) in the past. Best, Travis -- You received this message

Re: [sage-devel] Re: Sage's references: new policy?

On Wednesday, September 21, 2016 at 11:35:30 AM UTC-5, Thierry (sage-googlesucks@xxx) wrote: > > Hi, > > bikeshedding for bikeshedding: > > - if we decide to centralize everything in a single file (but we should be > aware that a backward move (e.g. for modularization) will require some >

Re: [sage-devel] Re: Sage's references: new policy?

>From working on stuff that involves 100+ references, even having [1] causes problems. Then you also have essentially random numbers that can change on every new version of Sage. Also, I feel doing stuff like "Foo in [1]" can be overly verbose to redundant at times. So I am strongly for

[sage-devel] Re: How to check that something is a real number?

The closest I can get is "foo in RR". This fails for CC(2.3, 0), but I consider that to be a real number. Best, Travis On Monday, September 19, 2016 at 9:37:18 AM UTC-5, Jeroen Demeyer wrote: > > Hello, > > is there a simple way to check in Sage that something is a real number > in some form?

Re: [sage-devel] State of sage built with clang/clang++ on OS X

clang CXX=clang++ ./sage -f symmetrica > > for example. Yes there is a possibility of your > > sage install breaking after that. But since > > symmetrica looks like just C code it shouldn’t. > > If you try to fix linbox you should get ready for > > some pain.

Re: [sage-devel] State of sage built with clang/clang++ on OS X

On Saturday, September 17, 2016 at 2:48:40 AM UTC-5, François wrote: > > Reanimating https://trac.sagemath.org/ticket/12426 > There is a ticket for symmetrica, if you still want to do it, I’d rather > you > fix the code with a patch than with a compilation flags as is suggested in > #12439.

Re: [sage-devel] State of sage built with clang/clang++ on OS X

I could look into the Symmetrica code next week for things like you mentioned, but I don't have access to an OS X machine to test. Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving

<    1   2   3   4   5   6   7   8   9   10   >