Re: [sage-devel] semantics of ... in doctests

strange, because this line has been there since 2015. Am Mittwoch, 26. September 2018 10:54:17 UTC+2 schrieb Jeroen Demeyer: > > On 2018-09-26 10:10, 'Martin R' via sage-devel wrote: > > In https://trac.sagemath.org/ticket/26348 a doctest is failing, because > > appare

[sage-devel] semantics of ... in doctests

In https://trac.sagemath.org/ticket/26348 a doctest is failing, because apparently the semantics of "..." has changed. Here is the test: ## sage: r = findstat(Permutations, lambda pi: pi.saliances()[0]); r # optional -- internet, random ... ...

[sage-devel] Re: Py3, sorting vertices of graph

Would it be hard to separate vertex labels and vertices? In other words, vertices would always be 0,...,n-1, and there would be an additional array containing the vertex labels. (I would prefer to have this for many "labelled" combinatorial objects, such as set partitions, permutations,

[sage-devel] Re: New code to generate finite lattices

That would be great! (in particular, if it's fast :-) Am Sonntag, 26. August 2018 06:36:24 UTC+2 schrieb Jori Mäntysalo: > > Might be of interest to some that there is now a GPLv3 code for > generating finite lattices. Paper is at > > https://arxiv.org/pdf/1609.08255.pdf > > code can be

[sage-devel] please review a (small but important) improvement of the FriCAS interface

Title says it all, ticket is https://trac.sagemath.org/ticket/25602 (This was conceptually a lot of work, because I had to understand what precisely FriCAS is returning. It should be straightforward to check.) -- You received this message because you are subscribed to the Google Groups

Re: [sage-devel] Re: trac error again

oh, thanks, that fixes it for me, too! Am Dienstag, 19. Juni 2018 22:26:01 UTC+2 schrieb John H Palmieri: > > I fixed my own problem: I had pushed without committing anything first. > After committing, I can view the ticket. > > > On Tuesday, June 19, 2018 at 1:14:52 PM UTC-7, Jeroen Demeyer

[sage-devel] trac error again

if I recall correctly, there was a similar issue recently, but I don't know how it was fixed. This time it concerns https://trac.sagemath.org/ticket/25606 Martin -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group

[sage-devel] Re: performance problems with Set (again)

Dear Travis, I am sorry, I certainly did not want to offend. Please excuse me. Thank you also for your explanation of the reason for having Set. Related to this: is OK if sage: [b for b in my_set_partition] yields a list of frozensets? If so, I am almost done (currently running all

[sage-devel] Re: performance problems with Set (again)

Actually, I wonder whether it wouldn't be better to change the internal representation of set partitions to restricted growth words (together with a fixed ordering of the base set). On the one hand, very likely everything becomes much faster. On the other hand, this may make the code slightly

[sage-devel] Re: performance problems with Set (again)

sage: hash(frozenset()) 133156838395276 Am Dienstag, 29. Mai 2018 20:44:48 UTC+2 schrieb Sébastien Labbé: > > Is there any point at all in having "Set"? > > sage: hash(Set()) > 133156838395276 > sage: hash(set()) > --- >

[sage-devel] performance problems with Set (again)

Dear all, I am frustrated with the following and would like to fix it: Is "Set" supposed to be slow? Replacing "Set" with "set" in "SetPartition.__init__" is a huge improvement, we go down to about 5.5 ms per loop, but "Set" has bitten me performance (https://trac.sagemath.org/ticket/23877)

[sage-devel] trac problem

Clicking on the branch at https://trac.sagemath.org/ticket/25434 I get: Oops… *Trac detected an internal error:* TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' There was an internal error in Trac. It is recommended that you notify your local Trac administrator with the

Re: [sage-devel] optional package doctests badly broken

As far as I remember, no. But I may be mistaken. Am Donnerstag, 10. Mai 2018 21:00:12 UTC+2 schrieb Jeroen Demeyer: > > On 2018-05-10 20:40, 'Martin R' via sage-devel wrote: > > If there would have been a patchbot running the FriCAS doctests back > then > &

Re: [sage-devel] optional package doctests badly broken

Taken to the extreme, we should get rid of doctests altogether, since they don't solve anything :-) Seriously, at least the FriCAS interface was broken several times because of trivial modifications. If there would have been a patchbot running the FriCAS doctests back then, this would have

Re: [sage-devel] Re: Improving code with AI?

would it be easy to have the patchbots run such a tool? if so, one could at least have the information, without being forced to do anything. Martin Am Mittwoch, 2. Mai 2018 16:41:48 UTC+2 schrieb John Cremona: > > On another python project I contribute to (LMFDB) we have for some time > only

[sage-devel] Re: cython 0.28.1 and sagemath

> > In any case, setup.py should really work. > > indeed, it was easier than I thought! I simply copied the first example from http://cython.readthedocs.io/en/latest/src/reference/compilation.html

[sage-devel] Re: cython 0.28.1 and sagemath

It just ocurred to me: why does all this work with sage 8.1? Is it only the cython upgrade? 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] Re: cython 0.28.1 and sagemath

Would a setup.py be an alternative to pyximport? If so, how would I go about it (making the example at hand work would probably be sufficient.) Thanks in any case! Martin > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe

[sage-devel] Re: cython 0.28.1 and sagemath

Here goes the new minimal non working example. (I would use setup.py, if I knew how and if I knew that it would cure this problem) Thanks for any help! Martin minimal.py import sage.all import pyximport; pyximport.install(); from minimal_pyx import minimal_fun

[sage-devel] Re: cython 0.28.1 and sagemath

Thank you! This gets me past the first problem. Unfortunately, I now get further compilation errors, like Building module sage.graphs.base.sparse_graph failed: ["CompileError: command 'gcc' failed with exit status 1\n"] and

[sage-devel] cython 0.28.1 and sagemath

Hi there, Since 8.2.rc0 (the update to cython 0.28.1) I'm having trouble using pyximport. Here is a minimal non working example: minimal.py import pyximport; pyximport.install(); from minimal_pyx import minimal_fun end minimal.py

[sage-devel] Re: Wrong result for definite integral of sin(x)*exp(I*x)

FriCAS also would get it right, except that there is a bug in the interface, see https://trac.sagemath.org/ticket/25174 If someone can give me a hint on how to send %i instead of I for the imaginary unit to fricas, I'll fix it... (1) -> integrate(sin(x)*exp(%i*x),x=-%pi..0) %i %pi

Re: [sage-devel] Re: How much do we support the casual user

I also think that this (restricting the global function is_prime to input that look like integers) is a very elegant solution. I would actually guess that novice users tend to try global functions first, and I am often surprised how long it takes some people to discover tab-completion. Martin

Re: [sage-devel] How much do we support optional packages.

There is another problem, which should be treated separately: sometimes doctests of optional packages fail because of newly introduced bugs or modifications in sage core. An example is https://trac.sagemath.org/ticket/24827 (now fixed and closed). I think one point of having the label

[sage-devel] Re: Nauty as a default generator for graphs

Besides, it would also be supercool to have a class Graphs analogous to the class Posets, and have the cardinality of the first few layers built in (analogous to Posets(16).cardinality()). Martin Am Freitag, 9. März 2018 07:19:24 UTC+1 schrieb Jori Mäntysalo: > > It is much faster to say sum(1

Re: [sage-devel] Re: Feature requests: Composition of binary relations

DiagramAlgebra is the abstract class, so BinaryRelationAlgebra would inherit from DiagramAlgebra. The base_ring argument is necessary, because to make the diagrams into an algebra, you want to be able to add them - of course, this is just a formal sum. In general, the composition of two

[sage-devel] Re: Feature requests: Composition of binary relations

Dear Victor, let me be more explicit: using sage.combinat.diagram_algebras.DiagramAlgebra you would be able to implement the algebra of binary relations on a fixed set X. The diagrams are the relations, that is, subsets of X x X. I am not sure whether this is already available for easy

[sage-devel] Re: Feature requests: Composition of binary relations

Maybe this can be done using http://doc.sagemath.org/html/en/reference/algebras/sage/combinat/diagram_algebras.html -- 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

[sage-devel] Re: Difference between the R set and other sets

Sorry for the noise - it's probably not a bug: class sage.categories.sets_cat.Sets(s=None) The category of sets. The base category for collections of elements with = (equality). This is also the category whose objects are all parents. Martin Am Sonntag, 31. Dezember 2017 09:15:50 UTC+1

[sage-devel] Re: Difference between the R set and other sets

Besides, I somewhat doubt that you want the category of sets - the objects would be *arbitrary* sets then. I am guessing that you want to consider only subsets of complex numbers, perhaps together with infinity, right? Or do you want finite fields, too? Martin Am Sonntag, 31. Dezember 2017

[sage-devel] Re: Difference between the R set and other sets

> > The problem is: "r" (the R interpreter object), as well as other > interpreters, is in the Sets category too, and converting it to symbolic > should raise an error. How can interpreters be differentiated from domain > sets, if not by category? > But why should an interface like "r" or

[sage-devel] Re: sets and sorted tuples, possibly python 3 related

Am Sonntag, 8. Oktober 2017 14:10:21 UTC+2 schrieb Maarten Derickx: > > In Python 3 you can still sort. But the elements that you are sorting have > to be of the same type. So no mixing of lists with strings, integers and > tuples anymore. But sorting a list of strings is no problem. OK, I'll

[sage-devel] Re: sets and sorted tuples, possibly python 3 related

One further thing to consider: for some methods of PerfectMatching (eg., crossings) we need a totally ordered ground set. Does frozenset respect a total order, if there is one - eg. over the integers? -- You received this message because you are subscribed to the Google Groups "sage-devel"

[sage-devel] sets and sorted tuples, possibly python 3 related

Dear all, what is the recommended way to store a small set, for example, a pair? I am currently looking at perfect matchings (https://trac.sagemath.org/ticket/23982), where we have a set of pairs. The current implementation is slightly broken, it represents the matching as a list of tuples,

[sage-devel] cannot push to trac

I was trying to push to #23847, but get an unhelpful error message... please help! martin@Martin-Laptop:~/sage-patchbot$ git trac push Pushing to Trac #23847... Guessed remote branch: u/mantepse/make_the_experimental_fricas_package_optional Traceback (most recent call last): File

Re: [sage-devel] let's make FriCAS optional

So, apart from the fact that emacs is the only thing a computer should ever run, here is something that might be useful, related to #12589. Of course, the three-liner below is just a proof of concept, but could easily be expanded into something that works reliably. Martin """ sage: var('q')

Re: [sage-devel] let's make FriCAS optional

I vote for making sage part of emacs, actually. Well, in fact, it *is* part of emacs. Martin Am Mittwoch, 27. September 2017 19:46:09 UTC+2 schrieb John H Palmieri: > > > > On Wednesday, September 27, 2017 at 10:40:36 AM UTC-7, Jeroen Demeyer > wrote: >> >> On 2017-09-27 16:10, Vincent

[sage-devel] Re: let's make FriCAS optional

Could you please be more specific? * there are currently 170 doctests in the interface itself (93% coverage, including quite a few testing the conversion to sage objects), and some more in the symbolic directory. Which parts of the interface would you like to be more tested? * Which parts of

[sage-devel] let's make FriCAS optional

Dear all, I would like to propose to make the package FriCAS optional. FriCAS provides some functionality which is otherwise either mostly missing (e.g., guessing formulas, lazy powerseries), or not as complete as might be desirable (e.g., symbolic integration, solving differential

Re: [sage-devel] Re: docstring and lazyimport

Note however that not even the class documentation of an inheriting class is displayed. Explicitely, if I have class A(): "my beautiful doc" pass class B(A): "my very beautiful dog" pass and then do lazy_import("test_doc", "B") B? I get the following: Type:

Re: [sage-devel] Re: docstring and lazyimport

So, the INPUT section should be at class level? Maybe that would indeed be better because there is __init__ and __call__ and _element_constructor_,... Martin Am Freitag, 22. September 2017 01:56:07 UTC+2 schrieb Travis Scrimshaw: > > IMO, __init__ should not be included in the docstring

Re: [sage-devel] Re: docstring and lazyimport

So, to try it, is it enough to (rebase and) apply #22752? Am Donnerstag, 21. September 2017 15:46:53 UTC+2 schrieb Jeroen Demeyer: > > On 2017-09-21 15:34, 'Martin R' via sage-devel wrote: > > It turns out that this has been noticed before: > > > > https://trac.s

[sage-devel] Re: docstring and lazyimport

It turns out that this has been noticed before: https://trac.sagemath.org/ticket/20626#comment:2 -- 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] docstring and lazyimport

I just discovered something puzzling with lazyimport: if I import the classes below with from test_doc import * I have the following (desirable) behaviour: * Instance1? gives me the "Generic" class docstring together with the __init__ docstring of Instance1 * Instance2? gives me the

Re: [sage-devel] help needed with git schlamassel

t; > > On Tue, Sep 19, 2017 at 10:19:09PM -0700, 'Martin R' via sage-devel wrote: > > Dear git gurus, > > > > I accidentally pushed a merge to https://trac.sagemath.org/ticket/22921. > > > Locally, I can "undo" this with > > > > git reset --h

[sage-devel] help needed with git schlamassel

Dear git gurus, I accidentally pushed a merge to https://trac.sagemath.org/ticket/22921. Locally, I can "undo" this with git reset --hard 84093c4bc19d2aa7e353dfa2b2436a5bf56b96b8 but I do now know how to do this on the ticket, and I am afraid of following advice of some random git blog page.

[sage-devel] Re: trying to speed up construction of sets in setpartition

I must admit that I don't really know what parents are created. A profile is at https://trac.sagemath.org/ticket/23877 How could I find out? Am Montag, 18. September 2017

[sage-devel] trying to speed up construction of sets in setpartition

In https://trac.sagemath.org/ticket/23873 I was innocently trying to be mathematically correct and let the method to_noncrossing_partition of DyckWords return a set partition, instead of a nested list. Christian warned me that there might be a performance penalty. He was right, with the patch

[sage-devel] Re: yet another sage-python performance puzzle

Am Freitag, 15. September 2017 23:28:06 UTC+2 schrieb Travis Scrimshaw: > > > Why are you proposing local imports? If python puts a performance penalty >> on them (in fact a significant performance penalty), they should be >> avoided, no? >> >> It is a relatively small penalty, so when it is

[sage-devel] Re: yet another sage-python performance puzzle

I agree. Then I have to remove the local import. Am Freitag, 15. September 2017 21:50:01 UTC+2 schrieb Travis Scrimshaw: > > > > On Friday, September 15, 2017 at 2:39:29 PM UTC-5, Martin R wrote: >> >> I haven't done any "professional" profiling, but it seems to me that the >> 10% are stable,

[sage-devel] Re: yet another sage-python performance puzzle

Why are you proposing local imports? If python puts a performance penalty on them (in fact a significant performance penalty), they should be avoided, no? It's not that I'm doing these optimizations just for fun. I am applying many of these little maps very very very often. I am now

[sage-devel] Re: yet another sage-python performance puzzle

I haven't done any "professional" profiling, but it seems to me that the 10% are stable, i.e., roughly independent of the size of the permutation. I just found a much faster alternative: simply bypass MatrixSpace.matrix completely: entries = { (v-1, i): 1 for i, v in enumerate(self) }

[sage-devel] yet another sage-python performance puzzle

I am now trying to speed up Permutation.to_matrix, which is meanwhile one of the worst offenders in my application. After some profiling I found the following, which is quite a mystery to me. Apparently it is possible that importing a module in a method costs a significant amount of time!

[sage-devel] Re: sage-python puzzle

Thanks for the hint. I am currently happy with %prun followed by %lprun. The only thing I dislike about this is that I have to guess who calls the most offending method or function, but it's not much of a hassle, since %prun also includes the cumulative timings. Martin Am Freitag, 15.

[sage-devel] Re: sage-python puzzle

Dear Samuel, almost by accident, I just noticed the following: def to_matrix_1(self): entries = { (v-1, i): 1 for i, v in enumerate(self) } return MatrixSpace(ZZ, len(self), sparse = True)(entries) def to_matrix_2(self): entries = { (v-1, i): 1 for i, v in enumerate(self) }

[sage-devel] Re: [sagemath-admins] git trac connection problems from continental Europe

It worked for me after I rebooted my laptop (in Vienna, Austria). I guess it's a coincidence, but who knows... Martin Am Dienstag, 12. September 2017 13:26:03 UTC+2 schrieb Dima Pasechnik: > > I've created a trac mirror repo on github: > https://github.com/dimpase/sagetrac-mirror > Please

[sage-devel] Re: sage-python puzzle

Thank you! Is there a recommended (fast) way to turn input into a (square) matrix (with entries in ZZ)? currently I do "corner = matrix(corner)" Thanks again, Martin Am Montag, 11. September 2017 17:00:20 UTC+2 schrieb Samuel Lelievre: > > Mon 2017-09-11, 9:38:45 (UTC-5), Martin R: > >

[sage-devel] Re: sage-python puzzle

Apparently, corner[i,j] is a lot faster than corner[i][j]. With this modification, the two versions are roughly equally fast. I don't get it, though, because the second version should be doing a lot more work. Martin Am Montag, 11. September 2017 16:23:07 UTC+2 schrieb Martin R: > > I don't

[sage-devel] sage-python puzzle

I don't understand the following timings: sage: A = AlternatingSignMatrices(6) sage: lC = [a.corner_sum_matrix() for a in A] sage: timeit("[from_corner_sum_1(corner) for corner in lC]", number=1, repeat=1) 1 loops, best of 1: 63 s per loop sage: timeit("[from_corner_sum_2(corner) for corner in

[sage-devel] performance issue with poset constructor

Dear all! I need some guidance with yet another initializer, this time posets. The ticket is https://trac.sagemath.org/ticket/23825, the crucial issue is that, to create a poset, it seems that we first create a digraph corresponding to the data, then turn this digraph into a Hasse diagram,

[sage-devel] Re: performance issue with initialization of trees

Great! I created #23821 to collect improvements! Martin Am Sonntag, 10. September 2017 08:19:02 UTC+2 schrieb Travis Scrimshaw: > > Hey Martin, >I am also getting similar timings, but actually testing Permutations(7) > both times. :P What is more interesting is %prun: > > sage: %prun L =

[sage-devel] performance issue with initialization of trees

Dear all, I'm having a performance problem, and I believe I have successfully located it in the initialization code of LabelledBinaryTrees. Part of my code is simply computing the binary tree corresponding to a permutation. I have the following timing: sage: timeit("[pi.binary_search_tree()

[sage-devel] Re: Plotting of digraphs with multiple edges

It might be helpful to know where in GraphPlot the layout engine is chosen, and which one corresponds to which picture. I think I understand that it depends on GraphPlot._arcs and GraphPlot._arcdigraph. However, I cannot find out why the first graph D gets pinkish vertices, and the second

[sage-devel] Plotting of digraphs with multiple edges

I am not sure whether this is a bug, in any case I'd need a workaround. Consider (with dot2tex installed) D = DiGraph([(0, 1, 0), (1, 2, 0), (2, 3, 0), (2, 4, 0)], multiedges=True); D.plot(layout="acyclic") E = DiGraph([(0, 1, 0), (1, 2, 0), (2, 3, 0), (2, 4, 0), (2, 4, 1)], multiedges=True);

Re: [sage-devel] Surprising behaviour of Set

This is now https://trac.sagemath.org/ticket/23324 Am Sonntag, 25. Juni 2017 19:47:36 UTC+2 schrieb vdelecroix: > > On 25/06/2017 19:10, 'Martin R' via sage-devel wrote: > > I just noticed that Set([[], []]).cardinality() yields 2. In earlier > > versions, a TypeError: unha

[sage-devel] Surprising behaviour of Set

I just noticed that Set([[], []]).cardinality() yields 2. In earlier versions, a TypeError: unhashable type: 'list' was raised. I think the behaviour was modified in https://trac.sagemath.org/ticket/22597. Is this intended? It seems to me that it would be safer if cardinality would raise an

[sage-devel] Re: [sage-release] Sage 8.0.beta12 released

I'm afraid I stumbled across something potentially dangerous: https://trac.sagemath.org/ticket/23317 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] Re: Blog post "Sphinx documentation of Cython code using ``binding=True``"

Does this mean that eventually a solution to the texinfo crossreferencing problem in https://trac.sagemath.org/ticket/21734 could be found? (essentially, the problem was, if I remember correctly, that the way sphinx for sage is set up, sage is not a single project. Instead, we have many

[sage-devel] Re: Error building openblas-0.2.19

You will probably need a variation of the following: https://groups.google.com/d/msg/sage-release/3QJoAgg9bgo/5uvnTLV1AwAJ 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,

[sage-devel] Re: Recurrences and Sequence Formula Guessing Functions in Sage

> > 2.As to guessing holonomic recurrences there is the Ore algebra package. > It would be nice to have a tutorial. > what's wrong with https://arxiv.org/abs/1306.4263 ? Martin -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe

[sage-devel] Re: Recurrences and Sequence Formula Guessing Functions in Sage

Did anybody ever compare the possibilities speed-wise? The scope of these packages is quite different: ore_algebra is for the holonomic and q-holonomic universe, the guessing facility in fricas is for guessing only - but covers also polynomial recurrences and differential equations (and their

Re: [sage-devel] Re: Recurrences and Sequence Formula Guessing Functions in Sage

Am Samstag, 19. November 2016 21:23:10 UTC+1 schrieb Maxie Schmidt: > > Thanks for all of the suggestions. I think I will start by getting all of > Martin's package routines working under a single wrapper function and try > to improve from there. > I think that one question is how you want to

[sage-devel] Re: Recurrences and Sequence Formula Guessing Functions in Sage

I forgot to add: once a diffeq for a generating function is found, the package can also give you the 1783-th coefficient of the generating function. And, most importantly: the main thing to do to make it really useful for sage, is to implement a better conversion from sage lists to fricas

[sage-devel] Re: Recurrences and Sequence Formula Guessing Functions in Sage

out off the box, the FriCAS package can do the following (described in some detail in https://arxiv.org/abs/math/0702086, the journal published a shortened version): 1) Generating functions: * rational (guessPade) * algebraic (guessAlg) * linear diffeq (guessHolo) * polynomial diffeq

[sage-devel] Re: Recurrences and Sequence Formula Guessing Functions in Sage

I'd be interested in what output you'd like to have. The hard part in the FriCAS package was to get decent speed, changing output should be relatively straightforward. (I guess that you are aware of the possibility of using the package from within sage) Martin Am Samstag, 19. November 2016

[sage-devel] Re: Hermite normal form of matrix over polynomial ring

An optimised version is implemented in fricas, available as fricas. HP_solve It might provide a good benchmark. 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

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

That's actually precisely what I'd like. So, what are metaclass conflicts? Martin Am Dienstag, 8. November 2016 12:37:20 UTC+1 schrieb Erik Bray: > > On Tue, Nov 8, 2016 at 8:58 AM, 'Martin R' via sage-devel > <sage-...@googlegroups.com > wrote: > > Thanks for these hint

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

verwritten are not taken from the parent class. Martin Am Montag, 7. November 2016 16:04:07 UTC+1 schrieb Travis Scrimshaw: > > > > 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: >> >

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

I have a possibly related question on documentation. At https://trac.sagemath.org/ticket/21594 I have an class GrowthDiagram, which is not intended for the end user. Instead, there are several subclasses (GrowthDiagramRSK, GrowthDiagramBinWord, GrowthDiagramDomino, etc.), which, however,

[sage-devel] Re: Multivariate polynomial factoring and bug(?)

Actually, I didn't even know that I changed the variable (because the fricas interface treats all these as POLY INT). So I did a test in fricas, and indeed, the bad ordering seems to be with y as first variable. Having t first takes no time even on my (old) laptop, having z first takes a

[sage-devel] Re: Multivariate polynomial factoring and bug(?)

FriCAS does this in no time: sage: R. = PolynomialRing(QQ) sage: f = z^40*y^6*x^2100 + 2*t^15*z^53*y^9*x^2078 + z^40*y^7*x^2003 + z^40*y^6*x^2000 - 14*z^31*y^6*x^1102 - 2*t*z^20*y^3*x^1101 + 78*z^20*y^3*x^1100 - 28*t^15*z^44*y^9*x^1080 - 4*t^16*z^33 : *y^6*x^1079 +

[sage-devel] Re: sphinx, texinfo and emacs

the key is what gets written into conf.py by class SingleFileBuilder(DocBuilder) from docbuild/__init__py. what would be a good naming scheme for the files? I assume something like the name of the python source directory, right? Martin Am Samstag, 22. Oktober 2016 17:42:42 UTC+2 schrieb

[sage-devel] Re: sphinx, texinfo and emacs

apparently the name sagereferencemanualstandardcommutativerings.info is autogenerated by sphinx and could be customized somehow, just I do not know how yet. See http://www.sphinx-doc.org/en/1.4.8/config.html (options for texinfo output). Martin Am Samstag, 22. Oktober 2016 13:52:13 UTC+2

[sage-devel] Re: sphinx, texinfo and emacs

I guess you need more than the filename, you also need the info node, no? 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] Re: sphinx, texinfo and emacs

Am Freitag, 21. Oktober 2016 23:51:18 UTC+2 schrieb Matthias Koeppe: > > > We already have makeinfo as part of the autotools package. > great! one further question: I noticed that there may also be other files such as pictures (in .png) format which "sage -docbuild DOCUMENT texinfo" puts

[sage-devel] Re: sphinx, texinfo and emacs

Am Freitag, 21. Oktober 2016 22:18:48 UTC+2 schrieb John H Palmieri: > > > > On Friday, October 21, 2016 at 12:31:01 PM UTC-7, Martin R wrote: >> >> Eli Zaretskii from the texinfo team helped me with two problems I had, >> and texinfo documentation is now almost ready to go. I need help with

[sage-devel] Re: sphinx, texinfo and emacs

Eli Zaretskii from the texinfo team helped me with two problems I had, and texinfo documentation is now almost ready to go. I need help with three things, which I report here, because trac is down. 1.) for some reason, it is necessary that makeinfo is called with "--footnote-style separate".

[sage-devel] Re: sphinx, texinfo and emacs

this is now https://trac.sagemath.org/ticket/21734 help is much appreciated -- 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] Re: sphinx, texinfo and emacs

after patching and doing ./sage -docbuild reference texinfo I get many *.texi files, and in each directory a makefile. After installing makeinfo (sudo apt-get install info), and doing make, I get very nice looking info files, and at least the top one seems to work very well. Even in the

Re: [sage-devel] sphinx, texinfo and emacs

Am Donnerstag, 20. Oktober 2016 13:05:59 UTC+2 schrieb Johan S. R. Nielsen: > > > Yes, but there are no links. Or do you have them? > > True, they are not links. It would be nice if they were, though > personally I like that what is printed is the actual module name that I > should type in

[sage-devel] Re: sphinx, texinfo and emacs

as a first step to answering (2), I just applied the patch below, and it seems to build the reference in texinfo format. diff --git a/src/sage_setup/docbuild/__init__.py b/src/sage_setup/docbuild/__init__.py index 0bd52a6..9ddf7d4 100644 --- a/src/sage_setup/docbuild/__init__.py +++

Re: [sage-devel] sphinx, texinfo and emacs

> > At least, on my machine it prints the exact same information. > > Best, > Johan > > 'Martin R' via sage-devel writes: > > > As you may know, using https://github.com/sagemath/sage-shell-mode, > working > > with sage in emacs is a very enjoyable pastime.

[sage-devel] sphinx, texinfo and emacs

As you may know, using https://github.com/sagemath/sage-shell-mode, working with sage in emacs is a very enjoyable pastime. In particular, typing at the sage prompt sage: sage.combinat.posets? opens a new frame and displays the documentation of sage.combinat.posets there. However, to my

[sage-devel] Re: git-trac push

no idea why, but now it works (I deleted the branch and checked it out again :-) Martin Am Dienstag, 18. Oktober 2016 08:56:21 UTC+2 schrieb Martin R: > > git-trac doesn't like me - what have I done wrong? > > martin@Martin-Laptop:~/sage-develop$ git-trac push 21594 > Pushing to Trac #21594...

[sage-devel] git-trac push

git-trac doesn't like me - what have I done wrong? martin@Martin-Laptop:~/sage-develop$ git-trac push 21594 Pushing to Trac #21594... Guessed remote branch: u/mantepse/growth_diagrams Traceback (most recent call last): File "/home/martin/git-trac-command/bin/git-trac", line 18, in

Re: [sage-devel] About exceptions

wouldn't it make sense to catch "everything reasonable"? I could imagine that for some reason at some point it is decided that the method you call raises a slightly different error. Would that be bad? Martin -- You received this message because you are subscribed to the Google Groups

Re: [sage-devel] Re: openblas segfault?

Thanks, now (and for the next few hours :-) trying... Am Montag, 26. September 2016 21:06:17 UTC+2 schrieb Michael Orlitzky: > > On 09/26/2016 03:03 PM, 'Martin R' via sage-devel wrote: > > > > Is there a quick fix? > > > > To get something usable, try >

Re: [sage-devel] Re: openblas segfault?

I just tried make after saying "export TARGET=P2". Doing so, openblas starts to build but fails after a while saying ar: sgemm_kernel.o: No such file or directory ../Makefile.tail:40: recipe for target 'libs' failed make[4]: *** [libs] Error 1 make[4]: Leaving directory

Re: [sage-devel] Re: openblas segfault?

I forgot: martin@Martin-Laptop:~/sage-develop$ lscpu Architecture: x86_64 CPU op-mode(s):32-bit, 64-bit Byte Order:Little Endian CPU(s):4 On-line CPU(s) list: 0-3 Thread(s) pro Kern:1 Kern(e) pro Socket:4 Socket(s): 1

Re: [sage-devel] Re: openblas segfault?

On my computer, 7.4.beta6 doesn't seem to compile openblas successfully either. After make distclean and make I get an error (log attached). real 135m22.614s user 407m51.656s sys 21m22.276s *** Error building Sage. The following

<    1   2   3   4   5   6   >