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

On Tuesday, February 28, 2017 at 8:26:22 AM UTC-8, Jeroen Demeyer wrote: > > (4) __pari__(): consistent with Python (__int__, __str__) and NumPy > (__array__). However, creating such names possibly goes against the > Python documentation [2]. > > This would leave with me the strong expectation t

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

On Wednesday, March 1, 2017 at 2:59:07 AM UTC-8, Jeroen Demeyer wrote: > > > No, you are misunderstanding. There is absolutely nothing Sage-specific > about _pari_. In fact, I started this discussion because we would like > to split up the PARI interface as a different package, independent from

[sage-devel] Re: Name symbolic expressions

On Sunday, March 19, 2017 at 12:54:34 AM UTC-7, Aidan wrote: > > > I wrote some code > I would > like to contribute, but I don't know the most appropriate place to put it. > > It works like this right now > > > sage: g(x,y)

Re: [sage-devel] Re: An "easy looking" computation in AA that sage can't do

On Monday, March 20, 2017 at 5:49:24 AM UTC-7, Jeroen Demeyer wrote: > > I believe that this is simply https://trac.sagemath.org/ticket/15600 > > The variable d lies in a number field of degree 32, which is rather big > to call polredbest() on. > If the sage implementation ends up doing this the

Re: [sage-devel] Re: An "easy looking" computation in AA that sage can't do

On Monday, March 20, 2017 at 3:03:05 PM UTC-7, Dima Pasechnik wrote: > > > surely you can do this, but it seems to be harder to certify if a number > is zero or not. > Exactly. That's the idea of Allan's approach: rather than tracking these questions in characteristic 0, you do it in a finite fi

[sage-devel] Re: Jupyter notebook: typeset formulas in pdf-export

On Wednesday, March 22, 2017 at 4:32:10 AM UTC-7, Daniel Krenn wrote: > > In a Jupyter notebook, when I do > File --> Download as --> PDF via LaTeX > then typeset formulas (displayed via show(...) command) are not typeset > anymore, but displayed as their plain text output in the pdf. > > Is

Re: [sage-devel] sage.misc.package considered harmful

On Tuesday, April 4, 2017 at 1:00:31 PM UTC-7, François wrote: > > (2) while being just one use, is probably not replaceable. > Not in this form at the very least. > How can one get the appropriate information in sage-on-gentoo? If we compare the mechanisms that work in the different scenarios

Re: [sage-devel] sage.misc.package considered harmful

On Tuesday, April 4, 2017 at 2:24:52 PM UTC-7, François wrote: > > Let’s be clear, I could ship a list of possible > optional packages supported in sage-on-gentoo > but any checking of package availability would > have to go through the the distribution package > manager. > > Or through the sa

Re: [sage-devel] sage.misc.package considered harmful

On Tuesday, April 4, 2017 at 4:01:50 PM UTC-7, François wrote: > > > With the current system you could install and then remove > some essential files manually and the doctesting framework > would still try to use it. It is installed according to the > packaging system after all. runtime testing

Re: [sage-devel] As of Sage 8.0, lcm is from sage.arith.functions but gcd is not

On Friday, April 7, 2017 at 9:18:47 AM UTC-7, Travis Scrimshaw wrote: > > 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 > spec

Re: [sage-devel] As of Sage 8.0, lcm is from sage.arith.functions but gcd is not

On Friday, April 7, 2017 at 11:14:01 AM UTC-7, Jeroen Demeyer wrote: > > On 2017-04-07 19:23, Nils Bruin wrote: > > Importing > > infrastructure has changed significantly between Py2 and Py3\ > > Really? What has changed? > > I was mainly looking at https

[sage-devel] Re: python3 : help needed

Thank you! I can confirm that, after a distclean, building your branch with `SAGE_PYTHON3=yes` gets me to the same point as you describe. The first few issues are fairly simple. I've pushed some coarse fixes for them to trac u/nbruin/py3_compat (based on your ugly_python3). I consider these mor

[sage-devel] Re: python3 : help needed

incidentally, it would be nice if we could equiv local/bin/ipython with the proper sage-python23 as well. Having a functional shell with an interactive debugger is a much nicer way to debug "import sage.all". -- You received this message because you are subscribed to the Google Groups "sage-de

[sage-devel] Re: python3 : help needed

On Thursday, May 25, 2017 at 4:36:49 PM UTC-7, Nils Bruin wrote: > > > TypeError: __str__ returned non-string (type bytes) > > which happens in the Parent stuff for "rings/infinity.py" somewhere. The > problem is clear: we end up with some byte string from what should

[sage-devel] Re: python3 : help needed

On Thursday, May 25, 2017 at 5:07:22 PM UTC-7, John H Palmieri wrote: > > > > On Thursday, May 25, 2017 at 4:40:01 PM UTC-7, Nils Bruin wrote: >> >> incidentally, it would be nice if we could equiv local/bin/ipython with >> the proper sage-python23 as well. Hav

Re: [sage-devel] python3 : help needed

On Thursday, May 25, 2017 at 6:40:18 PM UTC-7, François wrote: > > I am a bit surprised you can do that. I have just sent a PR to pynac > a couple of days ago to have it build with python3. > https://github.com/pynac/pynac/pull/248 > I have a feeling you still a python2 pynac. > > François > >

[sage-devel] Re: python3 : help needed

On Friday, May 26, 2017 at 7:52:57 AM UTC-7, John H Palmieri wrote: > > If you build Sage's IPython package with SAGE_PYTHON3=yes, then it will > install a script local/bin/ipython3. (Note then that if the sage-location > script runs, its function make_scripts_relative will break > local/bin/ipy

Re: [sage-devel] Re: python3 : help needed

On Monday, May 29, 2017 at 2:08:37 AM UTC-6, vdelecroix wrote: > > Note that __hex__ is not used anymore in py3 (calling `hex(obj)` goes > through `obj.__index__()`). What I proposed in cypari2 [1] is to use > Cython macros for py2/py3 changes. That solved all py2/py3 issues we had. > > Ah. So a

[sage-devel] Re: why is assume() so slow?

On Friday, June 2, 2017 at 6:33:12 AM UTC-6, Stan wrote: > > I asked this question before on ask.sagemath ( > https://ask.sagemath.org/question/37744/why-is-assume-so-slow/) but > haven't found an answer yet, so perhaps someone here has an idea. > > Basically, declaring assumptions using `assume

Re: [sage-devel] Sage Python 3 proposal

On Friday, June 2, 2017 at 2:54:22 AM UTC-6, Ralf Stephan wrote: > > No. See > https://stackoverflow.com/questions/44322187/binary-using-both-python-c-api-version-2-and-3 > > But then we need to either build libraries libpynac2 and libpynac3 or put libpynac somewhere in local/lib/python*. Do we k

[sage-devel] Re: Bug in a "simple" integration

On Saturday, June 3, 2017 at 10:07:03 AM UTC-7, Ognjen Dragoljevic wrote: > > The following integral should be 1/3 but Sage gives 1/2. > integrate(integrate(integrate(1,x2,max(x0,x1),1),x1,0,1),x0,0,1) > > It seems that Sage immediately evaluates max(x0,x1) to x0 which is > incorrect. > "max" hasn

[sage-devel] the overhead of sorting in .roots()

How attached are people to creating deterministic output where none is warranted? Currently, there is a "sort" routine in f.roots which creates a 60% overhead: sage: C=ComplexField(100) sage: %timeit f.roots(multiplicities=False) 1000 loops, best of 3: 703 µs per loop sage: %timeit [C(a) for a

Re: [sage-devel] the overhead of sorting in .roots()

On Monday, June 12, 2017 at 10:44:57 AM UTC-7, Daniel Krenn wrote: > > > If not sorted, should the output data structure be a Python set instead > of a list? > Conceptually it's a set, but for efficiency reasons it shouldn't be a Python set. The extraneous hashing and equality testing is a waste

Re: [sage-devel] the overhead of sorting in .roots()

It's currently apparently not an error to hash p-adics, but they aren't really, because elements with distinct hash can compare equal: sage: Qp=pAdicField(3) sage: a=Qp(1000) sage: b=a+O(Qp(3)^4) sage: hash(a) == hash(b) False sage: a==b True As a result, p-adics will not behave properly when ha

Re: [sage-devel] the overhead of sorting in .roots()

On Monday, June 12, 2017 at 4:01:19 PM UTC-7, William wrote: > > > What is your definition of "hashable"? I always thought of hashable > as basically > synonymous with "immutable", except for issues of efficiency. Aren't > floating points > numbers at least immutable, even if there are var

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

On Tuesday, June 27, 2017 at 3:34:46 PM UTC+2, Travis Scrimshaw wrote: > > > Although not tall categories are defined over the exact base ring of the > algebra, but recall that sometimes instead they are given over a category > like Rings or Fields(). > If I recall correctly, you should expect

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

On Monday, July 3, 2017 at 10:37:27 PM UTC+2, Kwankyu Lee wrote: > > > I am thinking of feature branches that are fully implemented but not > expected to be merged to sage soon because it is too special, too big, > needs more work to start normal review process, etc, or the author simply > does

[sage-devel] Re: Question on git merge

On Wednesday, July 12, 2017 at 8:46:00 AM UTC+2, Simon King wrote: > > Actually I still miss the old sage development workflow with mercurial. > > Are you sure? It led to some precious losses of code: https://trac.sagemath.org/ticket/13447#comment:84 -- You received this message because you a

Re: [sage-devel] Re: [sage-packaging] Re: Brainstorming about Sage dependencies from system packages

Does sage need a purpose-built pari/gp? Ideally, configuring sage to use an external pari/gp would mean that sage just compiles/links using externally provided header files and libpari.so (and perhaps know where the gp executable is provided). When sage is being rebuilt, it could take the modif

[sage-devel] Re: Possible Cython bug

On Thursday, August 3, 2017 at 7:58:50 PM UTC+2, Travis Scrimshaw wrote: > > Hey all, >I think I have come across a possible Cython bug, but I am not sure. I > am using 8.1beta0. Here is as small of a working example as I can currently > get. > > sage: %%cython > : def foo(F, int i): > ..

[sage-devel] Re: SIGSEGV in Maxima

On Saturday, August 12, 2017 at 4:50:28 PM UTC-7, rjf wrote: > > seems to me that asking for the "sign" of b^(1/3) in the complex domain > is nonsense. There are 3 cube roots. Let q be one of them; it doesn't > matter which. > then - (1+sqrt(3)*i)*q/2are the other two. Yes, two. because th

[sage-devel] Re: Homomorphisms between multivariate polynomial rings and nested univariate polynomial rings

On Thursday, October 1, 2015 at 8:15:39 AM UTC-7, len...@ackermans.info wrote: > > In my code I often encounter elements of polynomial rings of polynomial > rings. Since some functions only work on multivariate polynomial rings I > need to create a homomorphism, but I'm unable to do this. What i

Re: [sage-devel] Re: Casting to suptype and equality

On Thursday, October 1, 2015 at 8:14:12 AM UTC-7, Travis Scrimshaw wrote: > > Simon, >Do you know off-hand if is it safe to dynamically add in a class to the > MRO of a subclass of UniqueRepresentation? > > Without further information this is not safe: UniqueRepresentation objects are incredi

Re: [sage-devel] Re: Casting to suptype and equality

On Wednesday, September 30, 2015 at 8:42:05 AM UTC-7, Nathann Cohen wrote: > > We might also want to remove this dependency of posets on > UniqueRepresentation. Despite creating this equality problem, > UniqueRepresentation also causes a memory problem by caching *all* > created posets in memory

[sage-devel] Re: Homomorphisms between multivariate polynomial rings and nested univariate polynomial rings

On Thursday, October 1, 2015 at 11:57:45 AM UTC-7, Travis Scrimshaw wrote: > > Hey, >You need to make sure the order of the variables agrees: > > sage: A = QQ['t'] > sage: B = A['x','y'] > sage: C = QQ['t', 'x','y'] > sage: C.coerce(B.0) > x > That's a bug in sage. It's completely canonical in

Re: [sage-devel] Elements of finitely presented groups: hash function

On Friday, October 2, 2015 at 5:02:43 AM UTC-7, vdelecroix wrote: > > important ingredient: there is no normal form in general! This is an > undecidable problem... there is no algorithm that takes as input a > presentation and outputs whether this group has more than one element. > > Though, the

[sage-devel] Re: Element.__hash__ stopgap

On Friday, October 2, 2015 at 2:18:47 AM UTC-7, Simon King wrote: > > And on second thought: Always returning 0 may actually speed things > *up*! There will be more hash collisions. But determining the string > representation to determine the hash can be very slow. > I think you are underestima

[sage-devel] Re: The end of stopgaps

On Friday, October 9, 2015 at 1:29:14 AM UTC-7, kcrisman wrote: > > I think just before a stable release is probably the *best* time to add a > stopgap, since it's unlikely it will be fixed in the last rc :) > Indeed, making an invasive change in an rc which probably causes widespread and hard t

[sage-devel] Ping for review: Element.__hash__ rework

As far as doctests go, we have now figured out how to successfully remove the problematic "hash(str(a))" implementation on sage Element. The ticket just needs some trivial doctest additions to make a beancounting patchbot plugin happy. The changes on the ticket are pretty straightforward, but th

Re: [sage-devel] I > 0 is true

On Friday, October 16, 2015 at 2:22:41 PM UTC-7, John Cremona wrote: > > Obviously, any mathematician would expect the mathematically sensible > answer of "undefined". And yes, I do know why that is not what > happens in python. > Wrong, that IS what happens in python Python 2.7.10 (default,

Re: [sage-devel] mutable rows of immutable matrix?

On Friday, October 23, 2015 at 6:20:19 AM UTC-7, Nathann Cohen wrote: > > I do not see why matrix.row(0) should return a *copy* of the row when > the matrix is immutable. > It depends on the implementation. I think most matrices allocate their element store as a contiguous block. Hence the vect

[sage-devel] Re: Definition of multifactorial #5415

On Saturday, October 31, 2015 at 8:31:59 AM UTC-7, prateek sharma wrote: > > From the given code for > sage:5.multifactorial(3) > 5 > But the result should be 10. > There has been work on this: http://trac.sagemath.org/ticket/5415 but it looks like momentum was lost. There seems to be some disa

[sage-devel] Re: Definition of multifactorial #5415

On Sunday, November 1, 2015 at 7:22:37 AM UTC-8, prateek sharma wrote: > > I have submitted a patch to the issue #5415. > Please review. > Nothing appears on the ticket. Did you follow the instructions in http://doc.sagemath.org/html/en/developer/ to set up a trac account and submit your change

[sage-devel] Re: Manifold equality and UniqueRepresentation

On Wednesday, November 4, 2015 at 2:10:51 PM UTC-8, Eric Gourgoulhon wrote: > > Hi sage-dev, > > There is an ongoing discussion at #18529 > about defining __eq__ for > manifolds and whether one should > use UniqueRepresentation (which implements equality by

[sage-devel] Re: Manifold equality and UniqueRepresentation

On Thursday, November 5, 2015 at 7:22:10 AM UTC-8, Travis Scrimshaw wrote: > >So I'm somewhat inclined to use EqualityById and let the pickling be > broken (and redefining _test_pickling to do nothing (i.e., passes) with a > docstring warning that it is intentionally broken). I'm starting to

[sage-devel] Re: Manifold equality and UniqueRepresentation

On Thursday, November 5, 2015 at 10:42:47 AM UTC-8, Eric Gourgoulhon wrote: > > > So we see that the objects used as keys are charts, vector frames and > manifolds. > I think that's a very strong reason to go with equality-by-id and *not* unique representation: You really don't want to risk tha

[sage-devel] Re: Manifold equality and UniqueRepresentation

On Thursday, November 5, 2015 at 2:35:57 PM UTC-8, Eric Gourgoulhon wrote: > > Yes charts are immutable: a chart is defined by two parameters, which are > passed to the constructor: its domain (a manifold) and its coordinates (a > list of symbolic variables). These two parameters do not change du

[sage-devel] Re: Manifold equality and UniqueRepresentation

On Thursday, November 5, 2015 at 2:30:08 AM UTC-8, Simon King wrote: > Certainly, if "A is B" then "A==B" will be True. Actually I am not sure > if A.__eq__ would be invoked at all if you compare to identical objects > (i.e., I don't know what Python does). > This is famous in Python: sage:

[sage-devel] Re: Manifold equality and UniqueRepresentation

On Friday, November 6, 2015 at 2:58:24 AM UTC-8, Eric Gourgoulhon wrote: > > > However, your example with NAN in the reply to Simon shows that dictionary > lookup shortcuts equality testing on identical keys. If I understand > correctly, this means that even if we had a slow __eq__ for charts, a

Re: [sage-devel] random seed is not renewed for parallel functions

On Friday, November 13, 2015 at 1:18:07 PM UTC-8, Dima Pasechnik wrote: > > how one would then run a randomised algorithm in parallel? (e.g. testing > property with random input) > In such a case one certainly need something orthogonal to this. > Something like this? @parallel > def f(a): >

Re: [sage-devel] random seed is not renewed for parallel functions

On Friday, November 13, 2015 at 1:53:25 PM UTC-8, Nils Bruin wrote: > > I would think this is the kind of thing that is worth documenting > somewhere. > Particularly because the behaviour depends on the underlying parallellization mechanism: @parallel(p_iter="multipro

Re: [sage-devel] random seed is not renewed for parallel functions

On Saturday, November 14, 2015 at 2:52:15 AM UTC-8, Thierry (sage-googlesucks@xxx) wrote: > > Why not simply get a fresh seed ? > > sage: @parallel > : def f(a): > : sage.misc.randstate.set_random_seed() > : return a+random() > If os.urandom works then that's a good option

[sage-devel] Which path to edit for .../site-packages/

I noticed that for non-sage code that is imported from site-packages, the current editor code does not get us the right file: here it does the right substitution (because it's part of sage!) sage: sage.misc.sageinspect.sage_getfile(edit) '/usr/local/sage/sage-git/local/lib/python2.7/site-package

[sage-devel] Re: install_package('whatever')

On Tuesday, November 24, 2015 at 1:43:03 PM UTC-8, Volker Braun wrote: > > The real question is: Why are we still shipping the old SageNB as default > notebook? It does have usability issues, in particular no way to extend it > with non-Sage stuff. E.g. the IPython notebook has a built-in termina

[sage-devel] Re: install_package('whatever')

On Tuesday, November 24, 2015 at 4:49:53 PM UTC-8, Nils Bruin wrote: > > On another computer I got something different (and that's an up-to-date > fedora 22!): > > XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so: > /usr/lib64/firefox/libxul.so: undefined symbol

[sage-devel] Re: install_package('whatever')

On Wednesday, November 25, 2015 at 2:23:27 AM UTC-8, Volker Braun wrote: > > LD_LIBRARY_PATH strikes again... > What can we do about it, though? I think the relevant module is "webbrowser". It has rather complicated logic and is therefore rather hard to convince to run a command through "sage-na

[sage-devel] Re: domain:complex

On Thursday, December 3, 2015 at 8:24:29 AM UTC-8, Dima Pasechnik wrote: > > as a 1st step, a way for the user to set up Maxima domain is badly needed. > It does not look like a good idea to hardcode domain once and for all. > Though setting the domain is trivial: sage: maxima_calculus("domain: r

Re: [sage-devel] Re: Definition of multifactorial #5415

On Tuesday, December 8, 2015 at 5:56:36 AM UTC-8, prateek sharma wrote: > > Can you please summarize me what I basically need to do? > > Read this: http://doc.sagemath.org/html/en/developer/ and follow the workflow there to push a branch incorporating your changes to trac.sagemath.org. The sag

Re: [sage-devel] Re: Definition of multifactorial #5415

On Wednesday, December 9, 2015 at 5:13:58 AM UTC-8, prateek sharma wrote: > > Can you tell me how can I create a branch .When I do git-trac-checkout 5415 > It says "Newly created local branch: t/5415/problems_with_multifactorial_" > Doesn't the system just tell you that you have now succeeded in c

Re: [sage-devel] Re: Definition of multifactorial #5415

On Wednesday, December 9, 2015 at 10:21:17 AM UTC-8, prateek sharma wrote: > > No . The system just says "Newly created local branch..." and processing > keeps on going. > I have to forcefully stop the programme. > It works for me (it does take some time to finish, however. I don't know what it

Re: [sage-devel] Re: Definition of multifactorial #5415

On Thursday, December 10, 2015 at 2:25:45 PM UTC-8, prateek sharma wrote: > > I had pushed my branch on trac but I am unable to see any commit on > trac.Can anybody tell me why? > Your branch shows up red. That means that an automatic merge of your branch with the reference branch (the "develop"

Re: [sage-devel] Re: Definition of multifactorial #5415

On Saturday, December 12, 2015 at 10:30:29 PM UTC-8, prateek sharma wrote: > > How can I change doctest to check my changes made.? > Continue reading the developer guide. http://doc.sagemath.org/html/en/developer/coding_basics.html in particular http://doc.sagemath.org/html/en/developer/codi

[sage-devel] Re: bug report using assume

On Tuesday, December 15, 2015 at 2:06:44 PM UTC-8, vdelecroix wrote: > > Now if I restart a new Sage session and start with a failing maxima > command then the behavior is different > > sage: var('k', 'n') > sage: sum(binomial(n-k,k), k, 0, n) > Traceback (most recent call last): > ... > > Va

[sage-devel] Re: bug report using assume

On Wednesday, December 16, 2015 at 9:41:03 AM UTC-8, Robert Dodier wrote: > > If you can make a bug report > about it, it would be helpful. It might have been reported already, I > didn't > look for it. > > This is now: https://sourceforge.net/p/maxima/bugs/3058/ -- You received this message

Re: [sage-devel] Re: Jupyter notebook by default?

On Sunday, December 20, 2015 at 2:12:57 PM UTC-10, William wrote: > > It will be much easier for our users to actually *use* a converter if > we delay changing the defaults until after such a converter is > written. > ++1 (OK, I guess that's an error in most language). It's going to be a rela

Re: [sage-devel] Re: Jupyter notebook by default?

On Sunday, December 20, 2015 at 10:40:23 PM UTC-10, Volker Braun wrote: > > On Monday, December 21, 2015 at 5:16:44 AM UTC+1, Nils Bruin wrote: >> >> different notebook. We could possibly alleviate the problem of lack of >> information by somehow guessing if this is

[sage-devel] Re: Possible bug: Equality of divisor classes in Jacobians of hyperelliptic curves

On Sunday, December 27, 2015 at 9:19:31 AM UTC-8, Daniel Lännström wrote: > > # BUT THIS FAILS > assert J2(0) == J1(0) > Equality of elements of point sests of different jacobians is indeed inconsistent, but with something else than what you note: sage: J1(x,1)+J2(x,1) (x^2, y + 6) Apparently

Re: [sage-devel] Updating Sagemath's README on Github [help] [newbie]

On Thursday, January 7, 2016 at 10:19:59 AM UTC-8, Karan Desai wrote: > > I forked the repository and converted the README.txt to README.md in a > separate branch created from master. > It's nice to have a README that renders a little nicer under special circumstances, but this should not come

Re: [sage-devel] Re: Notebooks from admin viewpoint

On Sunday, January 10, 2016 at 2:21:34 AM UTC-8, Volker Braun wrote: > > I would argue the opposite, making local accounts is exactly what you > usually do to let users run their own programs (i.e. execute arbitrary > code). > I would agree with that. However, one would also expect that a note

[sage-devel] Re: plateform specific implantation

On Friday, January 15, 2016 at 3:36:24 PM UTC-8, Travis Scrimshaw wrote: > > In the interest of speed, to avoid calls to `sys,platform`, I would make > foo a (module level) @lazy_attribute or @cached_function. IMO a full class > is a lot more than you need. > > According to https://docs.python.or

Re: [sage-devel] GF(16,'x') when we do not care about the 'x'

On Wednesday, January 20, 2016 at 1:04:49 PM UTC-8, John Cremona wrote: > > > Is there any reason to not make GF(16) behave as GF(16,'x') does, > > unless specified otherwise? I do not see the point of requesting the > > user to provide a character if (s)he does not care. > > > > +1 for having a d

Re: [sage-devel] GF(16,'x') when we do not care about the 'x'

On Wednesday, January 20, 2016 at 1:49:12 PM UTC-8, Nathann Cohen wrote: > > If conflicts can come from the choice of a variable name, I'd say that > the problem is not the variable's name but the code that relies on it. > Conflicts do not arise from variable names (or at least not the conflicts

Re: [sage-devel] GF(16,'x') when we do not care about the 'x'

On Wednesday, January 20, 2016 at 3:22:54 PM UTC-8, Dima Pasechnik wrote: > > > to me, two fields that are specified by the same irreducible polynomial > over the same prime subfield ought to be identical. > it'd be much better design, not wedding them to named generators at all. > > That's not c

[sage-devel] Re: gamma function enhancement proposal

On Wednesday, January 20, 2016 at 9:25:59 PM UTC-8, Buck Evan wrote: > > I've written up a proposal in this google document, and set it to be > globally readable, commentable. > > > https://docs.google.com/document/d/1zEzIz0TCgC1aEKCQmHQkI5EVLlRnwsvrZOnAAClUcdM/edit# > > > I have the next couple o

Re: [sage-devel] Re: gamma function enhancement proposal

On Thursday, January 21, 2016 at 12:18:18 AM UTC-8, Buck Evan wrote: > > > In terms of numerics though, it would be beneficial to get sage to > simplify to the regularized function before computation. I can't see how > this can happen under the above scheme. > You could consider the incomplete g

[sage-devel] Re: Matrix unicode output

On Sunday, January 24, 2016 at 1:46:34 PM UTC-8, Volker Braun wrote: > > Yes you can set it up the way you want, this is about what a sane DEFAULT > is. And the best machine parseable output is, like the best output for the > visually impared, not the best output for the majority of our potential

[sage-devel] Re: Output of Matrix.plot() depends on whether the Matrix is sparse of dense

On Friday, February 5, 2016 at 6:43:38 AM UTC-8, Nathann Cohen wrote: > > Let me add to that: > > sage: Matrix(whatever=58) > [] > Yes, this is a more universal problem in the UI: it's quite common that unknown keywords just get pass through, usually because they might be of use for a

Re: [sage-devel] How are number field elements sorted?

On Friday, February 5, 2016 at 4:05:22 AM UTC-8, John Cremona wrote: > > Understood. I thought that a total order was implemented for number > field elements, but looking in the code I could not even find the > relevant _cmp_ function! > It's there, but indeed it doesn't implement a total orde

Re: [sage-devel] Re: Output of Matrix.plot() depends on whether the Matrix is sparse of dense

On Friday, February 5, 2016 at 9:08:45 AM UTC-8, Nathann Cohen wrote: > > > Yes, this is a more universal problem in the UI: > > I object. It is a *very* simple mistake that has a *very* simple solution: > > Any function that takes **kwargs as argument must: > 1) Remove from kwargs a

Re: [sage-devel] Re: Output of Matrix.plot() depends on whether the Matrix is sparse of dense

On Friday, February 5, 2016 at 10:20:22 AM UTC-8, Volker Braun wrote: > > Passing the keywords down individually also incurs some overhead, plus we > are talking about fairly small dicts. Its unlikely to be of a performance > concern IMHO > > As Travis noted, Python *always* makes a shallow copy

Re: [sage-devel] Re: Output of Matrix.plot() depends on whether the Matrix is sparse of dense

On Friday, February 5, 2016 at 10:23:17 AM UTC-8, Nathann Cohen wrote: > > > I suppose you meant to add a third rule > > 3) In any branch where a **kwargs -taking function does not call > another > > function it forwards the **kwargs argument to, it must raise an error if > any > > unrecog

Re: [sage-devel] Re: Output of Matrix.plot() depends on whether the Matrix is sparse of dense

On Friday, February 5, 2016 at 12:46:54 PM UTC-8, Nathann Cohen wrote: > > > Well, the call syntax for polynomials and symbolic expressions really > > benefits from arbitrary keywords. > > Yeah, I guess there is nothing wrong with > "an_expression.subs(whatever=4)" returning nothing even though

Re: [sage-nt] Re: [sage-devel] How are number field elements sorted?

On Saturday, February 6, 2016 at 8:20:29 AM UTC-8, John Cremona wrote: > > Thanks for the replies and suggestions. I am not sure what is the > best thing to do. I can see three different needs here: > > (1) Any deterministic total order for python sorting to be possible > and consistent. I t

[sage-devel] Re: Coverage and shared doctests...

On Thursday, February 11, 2016 at 5:42:26 AM UTC-8, fhivert wrote: > > Hi, > > Background: during my work on #13580 "Parallel map reduce on > SearchForest", I > hit a bug in the implementation of semaphore on MacOS. So I need some code > which on MacOS reproduce the behavior of BoundedSema

[sage-devel] Is upgrading to common parent for "^" a good idea?

A question for coercion experts: Currently we have: sage: cm=get_coercion_model() sage: cm.explain(ZZ,QQ['t'],operator.pow) Coercion on left operand via Composite map: From: Integer Ring To: Univariate Polynomial Ring in t over Rational Field Defn: Natural morphism:

[sage-devel] Re: subs deprecation -- what the heck?!

On Tuesday, March 1, 2016 at 8:15:56 AM UTC-8, William wrote: > > -1 to telling users that a syntax is deprecated and will be removed, but > planning to never remove it. > > +1 to executing the removal. We can't let a lottery like this: sage: var('foo,bar') (foo, bar) sage: f=foo+bar sage: f(1)

Re: [sage-devel] Re: subs deprecation -- what the heck?!

On Tuesday, March 1, 2016 at 5:23:36 PM UTC-8, kcrisman wrote: > > If I recall correctly, Jason Grout's example for this is > > x+y-y > > which becomes x but in principle had two variables, so how do you know > which one is "right"? > Hm, I'm not sure that's a problem here. Indeed if both are de

Re: [sage-devel] Re: subs deprecation -- what the heck?!

On Friday, March 4, 2016 at 10:52:58 AM UTC-8, Michael Orlitzky wrote: > > But, proposing that we get rid of symbolic expressions in piecewise > functions is stronger than the proposal to get rid of unnamed arguments. > This works, and accounts for just about every use of piecewise() you'll > fi

[sage-devel] Re: I think my students hate me

On Friday, March 4, 2016 at 9:59:21 AM UTC-8, john_perry_usm wrote: > > I teach a class where students learn some "advanced" math topics using > Sage. Naturally, talking about Sage is part of that. I gave a test today, > with the following T/F question that I *thought* would be easy: > > Sage is

[sage-devel] Re: output results depending on platform

On Monday, March 7, 2016 at 4:22:04 PM UTC-8, João Pedro Cruz wrote: > > Hello, > > I would like to output results with the following code: > if MEGUA_PLATFORM=='sagews': > fullpath = os.path.join(self.working_dir, > self.unique_name()+'.tex') > salvus.file(fullpath

[sage-devel] Re: LaTeX names of symbolic functions lost after simplification

On Sunday, March 13, 2016 at 8:08:51 AM UTC-7, Eric Gourgoulhon wrote: > > > Is this a known issue? Shall I open a ticket for it? > > I think it's known, but difficult to solve. Consider this: sage: f1=function('f') sage: f2=function('f') sage: f3=function('f',latex_name='F') sage: f1(x).operator(

[sage-devel] Re: LaTeX names of symbolic functions lost after simplification

On Sunday, March 13, 2016 at 3:32:10 PM UTC-7, Eric Gourgoulhon wrote: > > Thanks for these detailed explanations. > I understand that the fix requires some significant work on symbolic > functions. > This would be quite nice however, since most symbolic computations require > simplification at

[sage-devel] Re: memory leak

On Wednesday, March 23, 2016 at 9:17:58 AM UTC-7, vdelecroix wrote: > > Hello, > > Some friend just sent an e-mail to me mentioning a memory leak. Here is > a minimal example > > sage: x = polygen(ZZ) > sage: K = NumberField(x**3 - 2, 'cbrt2', embedding=RR(1.2599)) > sage: w = K.gen() > sage:

Re: [sage-devel] Re: memory leak

On Wednesday, March 23, 2016 at 12:08:29 PM UTC-7, vdelecroix wrote: > > > I am not sure about the Python analysis (though it might be some other > problem). > > I observed the same thing. It looks like we're looking at two different memory leaks in the same example: 1) A plain old malloc-type

Re: [sage-devel] Re: memory leak

For the python-level leak, I think it's down to this: x = polygen(ZZ) v = x # or 1/3 or RR(3) but not, say 3 pre={id(c) for c in gc.get_objects()} for _ in range(2): test = sage.rings.polynomial.polynomial_element.Polynomial.__call__(x,v) It ends up letting a lot of 1-element tuples of the

[sage-devel] Re: Huge virtual memory usage

On Monday, March 28, 2016 at 12:35:41 AM UTC-7, Volker Braun wrote: > > Presumably this is due to #19883 > > There isn't really any problem here, though. If you implement your own > version of malloc then, in some implementations, you'll need about as much > virtual memory as ram to do the accoun

Re: [sage-devel] Re: Bug? indefinite_integral does not accept sage.symbolic.function

On Saturday, April 9, 2016 at 9:17:27 AM UTC-7, David Roe wrote: > > > Is there any ambiguity? g is a function of one variable and we're > specifying the variable of integration. Is there a reason that we > shouldn't allow indefinite_integral(g, x) to work? > David > > In you just use integral,

[sage-devel] Re: Integration of function and it's simplified version yields different results

On Monday, April 11, 2016 at 7:31:53 AM UTC-7, rjf wrote: [large dialogue with Dima] > > So I stay with my criticism of Sage -- you are always talking about > python this-and-that, but the large bodies of code that (apparently) > you depend upon and that (apparently) don't do exactly what you >

Re: [sage-devel] Re: how we develop sage

On Monday, April 11, 2016 at 10:46:59 AM UTC-7, Volker Braun wrote: > > On Monday, April 11, 2016 at 2:57:16 PM UTC+2, Erik Bray wrote: >> >> Sage, unfortunately, hasn't made many pacts in this regard > > > Sage does have a very clear way of making symbols available on the > commandline, namely vi

[sage-devel] Univariate polynomial ring conversion

Univariate polynomial rings seem to convert into each other by basically just converting coefficient vectors. Unfortunately, this leads to results that are at odds with sage's concept that conversions are done by looking at variable names: sage: S.=ZZ[] sage: R.=S[] sage: ZZ['b']['a'](a^2+b) a

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