[sage-devel] Re: creation of tmp files names is not lexicographic anymore

On Wednesday, July 2, 2014 7:43:05 AM UTC-7, Sébastien Labbé wrote: > > The following would be make everybody happy and I am sure it is not too > much administration : > > tmp-001_ZuuV0L.png > tmp-002_ij0dqf.png > tmp-003_yNciio.png > > I don't particularly mind it, I just don't think it's a very

[sage-devel] Re: Do ticket titles matter? Can I rename a ticket if I didn't open it?

On Friday, July 4, 2014 12:05:53 PM UTC-7, Andrey Novoseltsev wrote: > > So - does anyone else care about ticket titles or it is a complete > bikeshedding and I should just go mind silently my own tickets? > Changing a title (that was likely put there deliberately) without consulting the origina

Re: [sage-devel] Re: FiniteDimensionalAlgebra does not check associative

On Monday, July 7, 2014 10:19:33 AM UTC-7, 张秦川 wrote: > > Thank you,Peter. > I have another stupid question that does not related to this topic, I > think it difficult to write a matrix as a list of list in Sage. See the documentation, accessible via "Matrix?". There are other ways of specifyin

[sage-devel] Re: trouble installing 5.11

On Wednesday, July 9, 2014 10:56:44 AM UTC-7, robert@gmail.com wrote: > > I'm trying to help develop some code that a group is currently working on > using sage 5.11, and so I need to get a copy of that version of sage on my > laptop. There is no longer a binary file posted and so I need to

[sage-devel] Re: Solving rational inequality should give simplified result

On Monday, July 1, 2013 8:33:47 AM UTC-7, kcrisman wrote: > > > I feel like this might have something to do with the fact we're using the > binary ECL interface, maybe? > Nope. It may have to do with our interface in general, or with the options we set/packages we load. All of the following g

[sage-devel] Re: Solving rational inequality should give simplified result

On Thursday, July 10, 2014 11:46:58 AM UTC-7, Nils Bruin wrote: > > So next thing is probably to try the usual: see if the maxima console > behaves the same if you paste in all of sage's maxima init code. If not, we > have a real riddle. If so, you could try to pare the init

[sage-devel] Re: Solving rational inequality should give simplified result

On Friday, July 11, 2014 2:01:33 AM UTC-7, Robert Pollak wrote: > > The following does not work, it still gives the "!= 0" terms: > > maxima.eval("domain : real;") > solve(abs((x-1)/(x-5)) <= 1/3, x) > sage: maxima_calculus("domain: real") real sage: solve(abs((x-1)/(x-5)) <= 1/3, x) #0: solve_rat

Re: [sage-devel] On scientific computing, Python and Julia

On Thursday, July 17, 2014 10:35:32 PM UTC-7, Robert Bradshaw wrote: > I'm not sure multimethods alone are enough to solve issues with Sage's > type system (e.g. coercion, where the result of a+b may happen in a > completely new domain) but they could certainly help. > Indeed. If you want mult

Re: [sage-devel] On scientific computing, Python and Julia

On Friday, July 18, 2014 7:26:00 AM UTC-7, William wrote: > > > Magma uses "multiple dispatch" extensively to deal with what our coercion > model code addresses, and it's definitely a step back in my experience. > > I agree that in scenarios for which coercion was designed, it works better than

Re: [sage-devel] On scientific computing, Python and Julia

On Friday, July 18, 2014 12:59:37 PM UTC-7, Robert Bradshaw wrote: > > Yes, but here T must explicitly implement to multiple dispatch. One > can't take an existing object and "add a method" based on the type of > the second argument. > Do you mean that a.bar(b) a.bar(c) would dispatch to diff

Re: [sage-devel] On scientific computing, Python and Julia

On Saturday, July 19, 2014 5:43:57 AM UTC-7, defeo wrote: > However, Julia multimethods are backed up by a powerful coercion > system, so I do not understand the "step back" criticism. > > That comment wasn't made with respect to Julia, because that would be comparing the coercion facilities of

[sage-devel] Re: weird integral behavior

On Saturday, July 19, 2014 9:25:42 AM UTC-7, Anne Schilling wrote: > > Sage can solve this numerically: > > sage: g = lambda x : (1+e^(2*pi*I*x)).abs() > sage: numerical_integral(g,0,1) > (1.2732395447351625, 1.4155343563970746e-14) > sage: n(4/pi) > 1.27323954473516 > > but not symbolically:

Re: [sage-devel] On scientific computing, Python and Julia

On Friday, July 18, 2014 4:01:10 PM UTC-7, Stefan Karpinski wrote: > If Julia has shown anything, it's that you *can* have ubiquitous multiple > dispatch in a dynamic language and have it be very fast – it is commonly a > zero-cost abstraction in Julia. > I find this an interesting claim. Do yo

Re: [sage-devel] On scientific computing, Python and Julia

On Monday, July 21, 2014 1:51:37 PM UTC-7, Stefan Karpinski wrote: > I hope that all makes some sense. I'm not sure if doing this kind of code > specialization in Sage is realistic, but type inference on Python code is > certainly possible. As you've pointed out, there is no obvious way to make

[sage-devel] Re: Comparison between str and sage.rings.integer.Integer depends on whether doctest called directly or via Makefile

On Tuesday, July 22, 2014 9:57:13 AM UTC-7, Clemens Heuberger wrote: > > Does that simply mean that cmp(str, sage.rings.integer.Integer) is random? > My guess is that it would be. However, I have not found a type on my system that compares as less than str and I haven't found a type that has id(

[sage-devel] Re: Comparison between str and sage.rings.integer.Integer depends on whether doctest called directly or via Makefile

On Tuesday, July 22, 2014 11:51:29 AM UTC-7, Clemens Heuberger wrote: > > > May I ask on which system? > Fedora 19 x86_64. I tried your makefile trick and I got consistent results, so I haven't been able to nudge sage or python into the comparison behaviour you described (for any type, really).

Re: [sage-devel] Re: hiding doctest in documentation

On Thursday, July 31, 2014 7:43:27 AM UTC-7, Daniel Krenn wrote: > > Am 2014-07-31 um 15:55 schrieb Volker Braun: > > On Thursday, July 31, 2014 9:16:50 AM UTC-4, Daniel Krenn wrote: > > > > Does this mean it is guaranteed that in doctests dicts are always > shown > > with their keys s

Re: [sage-devel] Re: hiding doctest in documentation

On Thursday, July 31, 2014 2:23:03 PM UTC-7, Travis Scrimshaw wrote: > >I disagree with sorting the output of dicts. I ended up finding a very > subtle bug dealing with dictionary output that I would have had a much > harder time figuring out with the automatic sorting. Just do > ``sorted(d.

[sage-devel] Re: "Background" documentation

On Friday, August 8, 2014 1:48:20 AM UTC-7, Clemens Heuberger wrote: > > > Is there any canonical place for such background documentation, possibly > within > the sage source tree? > If your work is interesting then you'll probably be doing computations with it that warrant publication. That c

[sage-devel] problem with polynomial.__iter__

There's a very inconvenient mismatch of choice in polynomials at the moment: sage: R.=QQ[] sage: f=x+2*y+z sage: list(f) [(1, x), (2, y), (1, z)] As you can see, polynomials are iterable and produce (coefficient, monomial) pairs. The nasty thing is: that looks like the appropriate input for a d

[sage-devel] Re: Equality, hashing and polynomial rings

On Tuesday, August 19, 2014 12:13:07 PM UTC-7, Simon King wrote: > > I think this would make sense---of course with bidirectional coercions, > as mentioned in my previous mail. > Bidirectional coercion implies memory leak: The strong references to the codomains on the coercion maps will keep

Re: [sage-devel] Re: problem with polynomial.__iter__

On Thursday, August 28, 2014 1:56:31 PM UTC-7, Volker Braun wrote: > > iteritems() is gone in Python 3... > It is, but the functionality is still provided by .items() . So the discussion of what the semantics in sage should be, is still relevant. On Thursday, August 28, 2014 9:26:34 PM UTC+1, Ni

Re: [sage-devel] Re: problem with polynomial.__iter__

On Friday, August 29, 2014 3:30:08 AM UTC-7, Volker Braun wrote: > > I agree, of course.. iterators are still present ;-) What I'm saying is: > We should call such a method iter() and not iteritems() to be > forward-compatible. > I'm not so sure of that particular name! "iterating" over an elem

[sage-devel] Re: Tracking Citations; How?

On Sunday, September 7, 2014 9:24:48 AM UTC-7, Volker Braun wrote: > > If you want to cite inside a decision tree then you can't do that with a > decorator. Instead of *also* having a function call syntax, we should then > *only* have function call syntax. Nothing good ever came out of having two

[sage-devel] Re: Tracking Citations; How?

On Tuesday, September 9, 2014 5:48:59 AM UTC-7, Volker Braun wrote: > > But that doesn't work at the C level, you either compile something in or > not. So you can't apply it to the (presumably) speed-critical c(p)def > functions, only to plain Python functions > True > where overhead wasn't muc

[sage-devel] Re: Tracking Citations; How?

On Tuesday, September 9, 2014 8:55:04 AM UTC-7, Volker Braun wrote: > > On Tuesday, September 9, 2014 4:44:33 PM UTC+1, Nils Bruin wrote: >> >> In python, looking up a global flag is going to be relatively slow, >> because, if addressed by its proper name, it i

Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices

On Wednesday, September 10, 2014 8:36:47 AM UTC-7, Viviane Pons wrote: > > It is not bluff Nathann. And it's no bluff either to say that many many > valuable people would just stop using Sage if it stopped handling 1-based > permutations. Sage is a mathematical software and it makes sense that it

Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices

On Wednesday, September 10, 2014 10:38:50 AM UTC-7, Nils Bruin wrote: > > sage: Permutation([0,1,2]) > aw shoot. The problem is there already, because we're defining permutations by *ordered list of images* rather than as a composition of cycles. That means the base actually is i

Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices

On Wednesday, September 10, 2014 11:51:55 AM UTC-7, Martin R wrote: > > I think that's what PermutationGroup and PermutationGroupElement do. No: sage: PermutationGroupElement((2,3,4)).parent() Symmetric group of order 4! as a permutation group sage: PermutationGroupElement([1,2,3]).parent() Symme

Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices

On Wednesday, September 10, 2014 10:54:06 AM UTC-7, Nils Bruin wrote: > > On Wednesday, September 10, 2014 10:38:50 AM UTC-7, Nils Bruin wrote: >> >> sage: Permutation([0,1,2]) >> > In fact, one CAN see from this list whether the permutation is 0-based or 1-based, s

[sage-devel] Re: pb with display hook

On Saturday, September 20, 2014 4:03:11 AM UTC-7, Volker Braun wrote: > > Incidentally, this works after http://trac.sagemath.org/16746 where I > refactored our displayhook (and fixed a handful of bugs). Needs review > *hint* *hint* > > sage: cython(""" > : cdef class A: > : def __it

Re: [sage-devel] Re: equal FractionFieldElement_1poly_field have different hashes

On Monday, September 22, 2014 11:37:13 PM UTC-7, Clemens Heuberger wrote: > > the problem is that the labels of a state could be any hashable Sage > object. > Thus preprocessing this single case of Frac(QQ[x]) would be quite ugly > IMHO and > would not address the underlying problem. > The Fr

[sage-devel] Re: problems with hypergeometric and maxima_calculus.hgfpoly

On Friday, September 26, 2014 6:55:39 AM UTC-7, Dima Pasechnik wrote: > > > IMHO it would be great to have this in mpmath rather than a Sage > workaround. > (AFAIK, hypergeometric_U is vulnerable to the very same problem, so this > would mean the workaround would either be needed in several plac

Re: [sage-devel] Re: Diverging PARI from upstream (#16997)

On Friday, September 26, 2014 1:40:58 PM UTC-7, Snark wrote: > > > My point is that it's pretty bad for at least two reasons : > - for a long-term support perspective, that means more work following > upstream ; > - for a public relationship perspective with respect to upstream, > modifying thi

[sage-devel] Re: Defining Polynomial Rings with same variable name

On Monday, September 29, 2014 7:44:35 AM UTC-7, Volker Braun wrote: > > We talked about this once, afair it is the same in Magma. > Except that in magma the print name of variables has no semantic value and can be changed at any point. > Really, there is no reason for forbidding it > Well, th

[sage-devel] Buildbot link on "needs work" tickets.

Dear buildboteers, The new buildbot interface is wonderful. However, on #17065 we ran into an issue that "needs work" tickets do not display the buildbot link. That's inconvenient in the following scenario: 1. Author gets a ticket to a reasonable state and sets ticket to "needs review" 2. Bui

Re: [sage-devel] Buildbot link on "needs work" tickets.

On Monday, October 6, 2014 8:50:19 PM UTC-7, Robert Bradshaw wrote: > > > Do you have an example ticket where it's not working? > > Yes, as originally mentioned: http://trac.sagemath.org/ticket/17065 which is still "needs work" presently. As you can see, no buildbot link is provided. There is a

[sage-devel] Re: Coercion proposal: compatible parents

On Tuesday, October 7, 2014 7:03:54 AM UTC-7, Jeroen Demeyer wrote: > > Hello, > > Consider the following Sage session: > > sage: a = RR(-1) > sage: b = 1.0001 > sage: a + b > 0.000 > sage: a._add_(b) > 1.03397576569128e-24 > > Here, the coercion model makes

[sage-devel] Re: Coercion proposal: compatible parents

On Tuesday, October 7, 2014 10:03:54 AM UTC-7, Volker Braun wrote: > > p-adics are even more weird, they coerce in the wrong direction. And, to > patch up that mistake, have a precision in the parent and another precision > in the element: > I'd say in p-adics elements simply carry around their

Re: [sage-devel] Re: Coercion proposal: compatible parents

On Tuesday, October 7, 2014 1:33:19 PM UTC-7, Jeroen Demeyer wrote: > > > > The ramifications for coercion discovery are also quite big: > No, you're understanding it wrong. The parent of the result of any > computation would be the same as now. The result of adding 2 RealNumbers > with differin

Re: [sage-devel] Re: NumberField comparison?!?

On Thursday, October 23, 2014 12:26:53 PM UTC-7, David Roe wrote: > > I disagree, since this approach will yield a < b and b < a both False most > of the time. Moreover, it will only work if K is either totally real or > CM. We should have two codepaths, one for testing equality (which is fast

[sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems

On Saturday, October 25, 2014 7:35:06 PM UTC-7, Robert Dodier wrote: > > Is there a tl;dr somewhere which says what is the problem that Mma got > wrong? and I gather there is an incorrect integral too? > Here's an integral maxima gets wrong with abs_integrate loaded: integrate(integrate(abs(e

[sage-devel] Re: __cmp__ vs. __eq__ in element class

On Sunday, October 26, 2014 2:08:27 PM UTC-7, Volker Braun wrote: > > Python 3 only uses __eq__, __lt__, . Python also provides > functools.partial_ordering to synthesizing the remaining methods just from > __eq__ and __lt__. We either use that or write a similar decorator to also > deal wit

[sage-devel] Re: __cmp__ vs. __eq__ in element class

On Monday, October 27, 2014 5:03:00 AM UTC-7, Volker Braun wrote: > > On the command line we could bind == to _isomorphic_, but use _identical_ > in library code. Then we would have intuitive comparison and could still > work with associative containers. > I don't think this would be easy to do

[sage-devel] Re: __cmp__ vs. __eq__ in element class

On Monday, October 27, 2014 10:57:58 AM UTC-7, Volker Braun wrote: > > On Monday, October 27, 2014 5:32:12 PM UTC, Nils Bruin wrote: >> >> I don't think this would be easy to do with the current preparser. >> > > As you said, we'll need to lo

Re: [sage-devel] Re: __cmp__ vs. __eq__ in element class

On Monday, October 27, 2014 1:13:29 PM UTC-7, Robert Bradshaw wrote: > Currently, the only place preparsing modifies valid code is for > literals, which is surprising enough but at least easy to explain. > There is one more: the "^" -> "**" substitution. Without it I think many mathematicians

Re: [sage-devel] Re: __cmp__ vs. __eq__ in element class

On Monday, October 27, 2014 2:33:34 PM UTC-7, Volker Braun wrote: > > The you can just as well get rid of @cached_method, that of course also > solves the problem. > Note quite, thanks to http://trac.sagemath.org/ticket/16316 , which basically implements the scheme Robert proposes and uses that

[sage-devel] Re: Slowness in comparing symbolic expressions

On Tuesday, November 4, 2014 10:54:51 AM UTC-8, rjf wrote: > > > Sage apparently does not call Maxima for this, since > is(equal(0,exp(512*(x+1; takes 0.05ms, even if one > provides the irrelevant declare(x,real). > > Indeed, sage doesn't call Maxima with *that* statement because it wo

[sage-devel] Re: Slowness in comparing symbolic expressions

On Tuesday, November 4, 2014 11:59:18 AM UTC-8, rjf wrote: > > For Sage, I think > a better approach if you are going to use Maxima, might be to something > like .. > > is(simplify(1-exp(256*(x+1)) = 0) > > where "simplify" is some particular simplification program, e.g. ratsimp, > fullra

[sage-devel] Re: Slowness in comparing symbolic expressions

n be done about it, but you can track progress at https://sourceforge.net/p/maxima/bugs/2836/ Cheers, Nils -- 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: [Cython] New function (pointer) syntax.

On Thursday, November 6, 2014 10:57:23 AM UTC-8, Robert Bradshaw wrote: > > > cdef float -> float F > cdef (float -> float, float, float) -> float G > cdef (char*) -> (float -> float, float, float) -> float H > Is there any precedent for an infix operator in type declarations? I fin

Re: [sage-devel] Re: Slowness in comparing symbolic expressions

On Friday, November 7, 2014 1:43:13 PM UTC-8, Thierry (sage-googlesucks@xxx) wrote: > > > Incidentally I observe that Sympy has the same behavior, so we can't > > just nick their factoring algorithm -- maybe some other package we can > > try the same example to see if any of them handle it quick

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

On Thursday, November 20, 2014 6:06:53 PM UTC-8, William wrote: > > Can somebody help me count the votes? I made pass through this long > and complicated thread, and here's what I seem to have got. > I'm -1 to an "enforcable" code of conduct. In extreme cases (which haven't happened) a list ad

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

On Saturday, November 22, 2014 10:39:37 AM UTC-8, William wrote: > > I will start a new thread on sage-devel with a clear title "VOTE: code > of conduct", copy of the proposed code, and [ ] Yes/ [ ] No option, > and a time limit. Good job going for the edge case on the time limit:-) Does your M

[sage-devel] Re: IMHO having "sage-abuse" publicly readable is a bad idea

On Wednesday, November 26, 2014 11:01:14 AM UTC-8, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: > > While I am all for openly sharing ideas and code, it is unreasonable > to expect everything to be open. Since there is going to be a way of > reporting someone for bad behavior, I think there is

Re: [sage-devel] Re: coeffs() & coefficients()

On Thursday, November 27, 2014 2:23:09 AM UTC-8, Bruno Grenet wrote: > > While I agree that the current names can be confusing, we have to be > careful not to make something even more confusing. As mentioned earlier > by John, f.coefficients() is "correlated" with f.exponents() and I think > it

[sage-devel] Re: possible issue with DiGraph in interval fields

On Monday, December 1, 2014 9:46:04 AM UTC-8, Ben Hutz wrote: > > D={} > for t in G: > D.update({t:[F(t)]}) > The keys here aren't necessarily a problem yet, provided "preperiodic" is careful. However, the values here are computed from an imprecise t and you're hoping that their values wil

[sage-devel] Re: Slow Poset creation and UniqueRepresentation

On Monday, December 1, 2014 10:44:44 AM UTC-8, Simon King wrote: > > Is it clear why their not freed, even though UniqueRepresentation only > puts a *weak* reference to them (it uses a weak value dictionary)? > I don't think it's a memory *leaking* issue this time. My impression is that they're

[sage-devel] Re: Slow Poset creation and UniqueRepresentation

On Monday, December 1, 2014 12:49:27 PM UTC-8, Simon King wrote: > > > Hmm. Sounds like a mess. But I do think one should have a general > mechanism ("UniqueRepresentationOptional" or so) with which one can > choose by an optional argument whether caching and comparison by > identity should be u

[sage-devel] Re: ExpressionNice

On Wednesday, August 17, 2016 at 3:25:31 PM UTC-7, Bill Page wrote: > > > It turns out that a solution is now "hidden away" in plain sight: > > https://trac.sagemath.org/ticket/18640 > > http://sagemanifolds.obspm.fr/doc/18640/reference/manifolds/sage/manifolds/utilities.html > > > And also not

Re: [sage-devel] Re: ExpressionNice

On Thursday, August 18, 2016 at 5:32:09 AM UTC-7, Bill Page wrote: > > I think that there was no claim that it was unambiguous and therefore > it implies that some ambiguity would be tolerated. But this has > already been argued ad infinitum and apparently that has resulted in > the current stal

Re: [sage-devel] Re: ExpressionNice

On Friday, August 19, 2016 at 9:45:12 AM UTC-7, Bill Page wrote: > > On the contrary after reading the code for ExpressionNice carefully it > is clear that it does not do post-processing as such class ExpressionNice(Expression): def _repr_(self): d = self._pare

[sage-devel] Re: TypeError: is not hashable and does not implement _cache_key()

On Friday, August 19, 2016 at 11:20:44 AM UTC-7, Joseph Hundley wrote: > > Context: I am playing around with implementing abstract algebraic groups > which are recovered from based root data. > So, one should eventually be able to say > b = BasedRootDatum( suitable input ) > g = AbstractAlgebraic

[sage-devel] Re: TypeError: is not hashable and does not implement _cache_key()

On Friday, August 19, 2016 at 1:43:30 PM UTC-7, Joseph Hundley wrote: > > There are two reasons I was planning to have AbstractAlgebraicGroup be > UniqueRepresentation > (1) The passage in this tutorial > > which > r

Re: [sage-devel] Re: ExpressionNice

On Saturday, August 20, 2016 at 6:13:16 AM UTC-7, Eric Gourgoulhon wrote: > > > >> I'd be hesitant to go any further. Using leibnitz notation in general >> requires temporary variables, e.g. >> >> D[0,1](f)(x+y,x-y) = diff(f(t1,t2),t1,t2) |_[t1=x+y,t2=x-y] >> >> I don't think the RHS is more rea

[sage-devel] Re: Iterators and KeyboardInterrupt

On Monday, August 22, 2016 at 12:42:26 AM UTC-7, Salvatore Stella wrote: > > At the moment the init function of :class:`ClusterAlgebra` calls > :meth:`reset_exploring_iterator` that creates an instance of :meth:`seeds` > and > stores it in an internal var ``_sd_iter``. Are you really getting

[sage-devel] Re: Iterators and KeyboardInterrupt

On Monday, August 22, 2016 at 10:53:23 AM UTC-7, Volker Braun wrote: > IMHO iterators must not have global state, which is really just a > corollary to "global variables are bad". In particular, iterating twice > simultaneously should work. With the exception of input iterators of > course, but

[sage-devel] Re: Error building sage source "error: need equal sizes for long and void*"

On Wednesday, August 31, 2016 at 12:38:51 PM UTC-7, Simon Brandhorst wrote: > > So far I am using precompiled binaries. They work. Now I am thinking on > writing my own branch/contributing to sage so I followed the instructions on > > http://doc.sagemath.org/html/en/developer/walk_through.html > >

[sage-devel] Re: What is "do_system"?

On Thursday, September 8, 2016 at 12:52:47 PM UTC-7, Simon King wrote: > > Hi! > > Trying to profile some code with %crun, I get lots of hits in the > function do_system. However, a function of that name does not appear in > the code. So, what does do_system do, where is it from, and what is >

[sage-devel] Installing sage as a kernel in the system-wide jupyter

I've found the following quite convenient and I wonder what the best place is to document this better and/or make it more robust: sage.repl.ipython_kernel.install.JUPYTER_PATH=os.environ["HOME"]+"/.ipython" sage.repl.ipython_kernel.install.SageKernelSpec.update() It installs the sage kernel into

[sage-devel] Re: sage -br rebuilds things that were not changed

On Saturday, September 10, 2016 at 9:14:08 AM UTC-7, leif wrote: > > For new branches, I think it's best to base them on the last *stable* > release (i.e., check out master before creating the new branch), unless > you really need fixes from later betas, or it's clear (or likely) that > you'd ge

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

On Tuesday, September 20, 2016 at 4:03:27 PM UTC-7, John H Palmieri wrote: > > As discussed in another thread [1]_ on sage-devel recently, I propose > changing our policy toward references: > > - all references should be put into a master bibliography file > There is one significant drawback to t

Re: [sage-devel] Re: Finite fields coercion bug

On Thursday, October 13, 2016 at 12:16:36 PM UTC-7, John Cremona wrote: > > Kwankyu's point is also a good one. It really is not acceptable (from > a user's point of view) to ask if there any coercions, be told there > are none, and then be prevented from defining one! > It's a necessity for s

[sage-devel] Re: symbolic series precision vs order term exponent

On Saturday, October 29, 2016 at 12:55:51 AM UTC-7, Ralf Stephan wrote: > > Hello, > > TLDR: > Proposal is to support the precision as argument to ex.series() instead of > the order > term exponent. Visible changes only expected with Laurent series. > I think we support these properties (on both

[sage-devel] Re: actions Zmod and QQ

On Sunday, October 30, 2016 at 6:16:37 AM UTC-7, vdelecroix wrote: > > I think that the behavior of these operations should be similar. Do > you think that > A) the above is fine (with explanation please) > B) we should raise an error in the first example > C) the second example should wo

[sage-devel] Re: Bug: Sage says Maxima was unable to solve this BVP but it's not true!

On Sunday, October 30, 2016 at 9:04:37 AM UTC-7, M. Fernandez wrote: > > I hope that's the right place to post the bug. > Yes, that works. > Use Maxima's interface to solve the problem > >1. >> >>maxima('depends(y,x)') >>maxima('eq: x^2*diff(y,x,2)-x*diff(y,x,1)+y=0') >>ma

[sage-devel] Re: Symbolic expressions assumptions and simplify in parallel

On Tuesday, November 1, 2016 at 1:55:00 PM UTC-4, Fedor Sumkin wrote: > > Hi all, > > Faced with a quite sad sage bug which arises with interval based > assumptions and full_simplify()/simplify() in called in parallel. > > Maxima is not threadsafe at all, and the sage design uses a single (li

[sage-devel] Re: Symbolic expressions assumptions and simplify in parallel

On Tuesday, November 1, 2016 at 1:55:00 PM UTC-4, Fedor Sumkin wrote: > > Hi all, > > Faced with a quite sad sage bug which arises with interval based > assumptions and full_simplify()/simplify() in called in parallel. > > Here is a gist : > https://gist.github.com/sumkincpp/a5472ce6fcec4d05eba

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

On Thursday, November 3, 2016 at 1:37:25 PM UTC-4, Dima Pasechnik wrote: > > > > On Thursday, November 3, 2016 at 1:06:05 PM UTC, Bill Hart wrote: >> >> >> >> On Friday, 28 October 2016 18:44:09 UTC+2, Dima Pasechnik wrote: >>> >>> 5 variables and degree 100 is really, really huge. Especially over

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

On Sunday, November 6, 2016 at 3:12:38 PM UTC-8, Salvatore Stella wrote: > > {{{ > if n == 2 and m == 0: > self.greedy_element = MethodType(greedy_element, self, self.__class__) > }}} > > This has at least one drawback: the documentation produced by Sphinx looks > weird because these metho

[sage-devel] Re: Errors from importing abs

On Monday, November 14, 2016 at 12:49:17 PM UTC-8, Paul Masson wrote: > > Doesn't the explicit alias to abs_symbolic put abs into the global name > space as a symbolic function? Why does an import of abs create more > problems than the alias? Is this a general Python problem or something > speci

[sage-devel] Re: Errors from importing abs

On Monday, November 14, 2016 at 10:49:56 PM UTC-8, Ralf Stephan wrote: > > > so it seems the Python abs can be overridden. > Yes, abs is not a keyword. It's just a name that's by default bound to __builtin__.abs . However, given that python's "abs" gives access to a protocol that allows custom

[sage-devel] Re: "Tri bool"

On Tuesday, November 15, 2016 at 2:59:06 AM UTC-8, Simon King wrote: > > But I don't see why "too much discussion" should be enough reason to kill > a PEP. After all, it isn't bike shedding but a non-trivial extension > with potentially useful applications. > Guido gives other reasons why he re

[sage-devel] Re: Cross-type comparisons

On Monday, December 5, 2016 at 12:35:47 AM UTC-8, Marc Mezzarobba wrote: > > 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. > > Is there already a replacement for cmp() in Sage (i.e., something that > all

[sage-devel] Re: Re: Cross-type comparisons

On Monday, December 5, 2016 at 9:15:50 AM UTC-8, Marc Mezzarobba wrote: > > > I'm not sure I follow you: doesn't what cmp() does (if I understand > right: use the internal order when possible, otherwise sort by type and > refine by id) do the job? But then, of course, this behavior cannot be > i

Re: [sage-devel] Updates or hints on "latex Function Prevent Simplification"?

On Saturday, December 10, 2016 at 12:31:20 PM UTC-8, Qian Hong wrote: > > Thanks David, > > On Sun, Dec 11, 2016 at 7:02 AM, David Roe > wrote: > > The issue is with the simplification of the expression, rather than the > > latex function. The following currently works: > > > > sage: latex(x

[sage-devel] Re: maxima_calculus.load("blah.mac") throws, load("blah.mac'") in sage --maxima works

This works: sage: maxima_calculus.load('to_poly_solve') \"/usr/local/sage/sage-git/local/share/maxima/5.35.1/share/to_poly_solve/to_poly_solve.mac\" whereas this does not: sage: maxima_calculus.load('to_poly_solve.mac') TypeError: ECL says: In function PATHNAME, the value of the only argument is

[sage-devel] Re: maxima_calculus.load("blah.mac") throws, load("blah.mac'") in sage --maxima works

On Thursday, January 12, 2017 at 7:35:03 PM UTC-8, Robert Dodier wrote: > > On 2017-01-12, Dima Pasechnik > wrote: > > > maxima_calculus.load("blah.mac") throws a TypeError: > > ECL says: THROW: The catch MACSYMA-QUIT is undefined. > > I think the problem here is that maxima_calculus.load("/pat

[sage-devel] Re: maxima_calculus.load("blah.mac") throws, load("blah.mac'") in sage --maxima works

On Friday, January 13, 2017 at 11:01:15 AM UTC-8, Dima Pasechnik wrote: > > There is also a problem parsing ''' (thanks, google-groups, for editing it > for us :-)) as ' " (or " ', depending on the context). > At least it did hit me... > cut/paste works fine for me, so I think the only confusing

[sage-devel] Re: Polynomial ring extension inconsistencies

On Friday, January 13, 2017 at 6:14:29 PM UTC-8, Stefan wrote: > > What I'd like: extend R with a few extra variables. I also have a matrix > over R that I'd like to interpret as a matrix over > R-with-a-few-extra-variables. > What I get: only the ring S has the method extend_variables. Neither R

Re: [sage-devel] Detected access to protected memory, also kwown as 'bus or segmentation fault'.

This indeed seems to be a problem in maxima itself. With domain : complex; limit( (1/(c*n^6))^(log(n)/log(2/3)), n, inf); in maxima, the same problem arises. Without "domain : complex" there is no problem, so it's an unfortunate interaction somewhere. -- You received this message because you a

[sage-devel] Re: how to check zip, map, range, print for Python3

On Thursday, January 26, 2017 at 12:02:07 PM UTC-8, Frédéric Chapoton wrote: > > > Please, tell me how to change the zip behaviour in the code. Or just > change the branch if you know how. > > If I understand correctly, part of your question is "how do I get zip to behave line Py3 in the doctest

[sage-devel] Re: Possible bug in Maxima related to variable names in long expressions

I think it's a bug in maxima that is dependent on the ordering of the variables. You can trigger it in maxima with exactly the same formulas, e.g.: s : 2*(cos(1/2*x)*cos(y) + sin(1/2*x)^2 - 1)*(cos(z)*sin(y) + cos(y)*sin(z))*((cos(1/2*x)*cos(z) - cos(y)*cos(z) + sin(y)*sin(z))*sin(1/2*x)/(cos(

Re: [sage-devel] Too many Maximas!

On Tuesday, February 7, 2017 at 8:47:40 AM UTC-8, William wrote: > > > Basic question: is there any reason whatsoever for us to even have a > pexpect interface to maxima anymore? Nils Bruin (and others) put a > massive amount of effort into a C library version (using ecl) ov

Re: [sage-devel] Too many Maximas!

On Tuesday, February 7, 2017 at 2:12:30 PM UTC-8, William wrote: > > On Tue, Feb 7, 2017 at 5:08 PM, Nils Bruin > > wrote: > > On Tuesday, February 7, 2017 at 8:47:40 AM UTC-8, William wrote: > >> > >> > >> Basic question: is there any reason w

Re: [sage-devel] ComplexField dilog precision bug

On Sunday, February 12, 2017 at 10:59:06 AM UTC-8, Matthias Goerner wrote: > > Careful: you are changing the default precision before calling dilog. That > might mask the problem with pari's dilog. Indeed, the dilog is just implemented as self._parent(self._pari_().dilog()) and: sage: U=Comp

Re: [sage-devel] ComplexField dilog precision bug

On Sunday, February 12, 2017 at 2:11:29 PM UTC-8, John Cremona wrote: > > About 8 years ago I spent a long time making sure that precision was > handled correctly in converting between Sage and pari. Since then the > interface has totally changed and possibly these recent changes are at > fault

Re: [sage-devel] integration algorithms

On Sunday, February 26, 2017 at 8:17:05 AM UTC-8, Michael Orlitzky wrote: > > > sage: f = function('f')(x) Please consider to stop using such assignments. It propagates a confusion between the *function* f and the *expression* f(x). The distinction is significant in sage and generally brushed

Function calling syntax (was Re: [sage-devel] integration algorithms)

(split from original thread because this is a separate topic) On Monday, February 27, 2017 at 5:38:17 AM UTC-8, Michael Orlitzky wrote: > > I tried the thing that makes more semantic sense, > > sage: f = function('f',x) > > and it told me to > > DeprecationWarning... Use function('f')(x) in

Re: Function calling syntax (was Re: [sage-devel] integration algorithms)

On Monday, February 27, 2017 at 5:56:44 PM UTC-8, Michael Orlitzky wrote: > > But it fills my heart with > joy that I can fix things by doing > > sage: f(x) = f(x) > sage: f > x |--> f(x) > > But only after you've declared f to be a function. If you want to do it in one line, you'd ha

<    4   5   6   7   8   9   10   11   12   13   >