[sage-devel] Re: matrix multiplication weird coercion

This may help: sage: sage.matrix.action.MatrixMatrixAction(N.parent(),T.parent()).codomain() Full MatrixSpace of 2 by 2 dense matrices over Ring of integers modulo 1 sage: A=matrix(GF(25,'a'),[[1,1],[0,3]]) sage: sage.matrix.action.MatrixMatrixAction(N.parent(),A.parent()).codomain() sage: G=N.par

[sage-devel] Re: cpdef (a little) harmful

On Apr 9, 4:11 pm, Robert Bradshaw wrote: > To let x.foo() call different functions depending on whether your in > Cython or Python, or even worse whether x is fully typed, would be > even more surprising. Does cython overload on type signature? I don't have a particular problem with the semantic

[sage-devel] Re: matrix multiplication weird coercion

The problem may be this: sage: S=Rationals() sage: R=GF(7) sage: from sage.categories.pushout import * sage: pushout(R,S) Ring of integers modulo 1 sage: R_tower = construction_tower(R) sage: S_tower = construction_tower(S) sage: R_tower [(None, Finite Field of size 7), (QuotientFunctor, Integer R

[sage-devel] Re: matrix multiplication weird coercion

On Apr 10, 2:19 am, Jean-Pierre Flori wrote: > I've just built 5.8 + #8335 and this is indeed fixed, are you sure you > rebuilt the Sage library after applying the patches? Yes, I see. That patch changes the unique "rank = 7" to "rank = 4.5" in the relevant file, so that should do the trick. Did

[sage-devel] Re: new optional (or experimental) package CSDP?

On Apr 10, 8:52 pm, Dima Pasechnik wrote: > 2) yes to CSDP becoming an experimental package. Doing that requires no different work from preparing it to be an optional package, so why not do that first? Once that's done I would expect it'll be pretty smooth sailing into optional status. -- You r

[sage-devel] Re: \usepackage{times} in our latex output

On Apr 14, 5:58 am, Nathann Cohen wrote: > I am playing with Latex through Sage these days, and notice that our > default output is a bit ugly The default font seems to be a bitmap, and > we could have a much better result if we only added \usepackage{times} in > our default header. This is m

[sage-devel] Re: 1 == Set([0]) works, 0 == Set([1]) does not

On Apr 25, 2:18 am, Volker Braun wrote: > Actually, I am very confused about why a Set is a Parent and not the > Element of a universal set parent. We want sets to be quickly > constructable, non ? Do we really need Set to be extremely fast? We already have python sets for that. I would expect t

[sage-devel] Re: Sage 5.9's doctesting framework

On Apr 26, 10:38 am, Simon King wrote: > I think it would be really bad if one had to run two separate tests, one > only non-optional and the other only optional. Not in the least because it would be quite natural to write tests with as many lines as possible *not* marked with #optional and then

[sage-devel] Re: Sage 5.9's doctesting framework

On Apr 26, 10:55 am, William Stein wrote: > That's *not* the correct interpretation.  In fact, either all tests in a > docstring are run or no tests in that docstring are run.     I guess "test" > is defined in the documentation output by "sage -t". OK, that's good to know. That makes a doctest (

[sage-devel] Re: Sage 5.9's doctesting framework

On Apr 26, 12:28 pm, William Stein wrote: > No, that's not at all a problem, and not what I was addressing.  Your > question was: "Not in the least because it would be quite natural to write > tests with as many lines as possible *not* marked with #optional".  The > lines *not* marked with optiona

[sage-devel] Re: Reasons for upgrading

On Apr 30, 3:52 am, Martin Albrecht wrote: > Definitely (A) for me (ATLAS insists on tuning on my box) I had that problem too. I then lifted the required files out of atlas and put them in a directory and now I just point SAGE_ATLAS_LIB at it. Then full installation isn't so bad. If I were to ge

[sage-devel] Re: can't escape sage after error in attached file (IPython experts?)

On May 1, 9:45 am, Marco Streng wrote: > And how to fix this? I have three ideas that all have a downside: > * Catching the error will destroy a valuable traceback (which I removed > above). Or is there a way to preserve that traceback and have it printed > somehow? Apparently the traceback is th

[sage-devel] Re: Mutability

On May 2, 8:32 am, Simon King wrote: > What do people think? > [ ] @invariant and @mutabor is fine Having the decorators is not particularly damaging. I wouldn't like the overhead, but getting rid of them in favour of more efficient solutions is an easy transformation. "invariant" has the wrong

[sage-devel] Re: can't escape sage after error in attached file (IPython experts?)

On May 3, 12:36 pm, Volker Braun wrote: > I also changed attach so the file is reloaded from the idle loop, so you > don't have to actually press any key in your Sage command line to > re-evaluate as long as you are sitting at the command prompt. Isn't that sensitive to race conditions? I imagine

[sage-devel] Re: can't escape sage after error in attached file (IPython experts?)

On May 3, 2:53 pm, Volker Braun wrote: > Pretty unlikely since timestamps are only checked every 100ms.  Of course > the real solution is to use inotify and trigger on the close following the > write. Though thats a different ticket. So perhaps then just avoid introducing a race condition (even i

[sage-devel] Re: can't escape sage after error in attached file (IPython experts?)

On May 3, 4:50 pm, Volker Braun wrote: > IMNSHO the benefits of not having to switch windows outweight the so far > academic possibility of a partial read. There's another potential problem: Python doesn't prohibit multiple threads. It's quite possible to split off a thread that continues computa

[sage-devel] Re: Coefficients of power series

On May 7, 2:10 pm, David Roe wrote: > For consistency with multivariate polynomials, the coefficient method on > univariate polynomials (and power series) only returns the nonzero > coefficients. Note that (x^2+1).coeffs() and list(x^2+1) do provide the desired behaviour, so at least there's a wo

[sage-devel] Re: Cython and Python signal

On May 11, 2:15 pm, Thierry wrote: > Hi, > > it was reported > inhttp://ask.sagemath.org/question/2567/kill-the-thread-in-a-long-compu... > that cython seems not to handle Python signals correctly. It-it a > feature or should-it be reported ? I think it's a feature. There's a lot of code that re

[sage-devel] Re: Cython and Python signal

On May 11, 9:44 pm, William Stein wrote: > By the way, the alarm function in Sage uses Python's "signal.alarm", > whose source code is this: > > static PyObject * > signal_alarm(PyObject *self, PyObject *args) > { >     int t; >     if (!PyArg_ParseTuple(args, "i:alarm", &t)) >         return NULL

[sage-devel] Re: All variables vanish

On May 12, 5:29 am, man...@gmx.net wrote: > This happens reproducibly. plot( ) evaluates to nothing (no output, etc) > and afterwards, the workspace seems to be emptied of everything that was > defined. That means that the sage worker process servicing your plot crashed and died. The notebook unfor

[sage-devel] Re: Cython and Python signal

tation timed out because alarm was set for 10 seconds so somehow the SIGALRM gets reacted on properly by ECL (which has its own signal handler) and somehow the condition arrives in its proper state in Python as well, so that Python gets a turn at running the registered signal handlers. Cheers,

[sage-devel] Re: Cython and Python signal

On May 12, 6:50 pm, leif wrote: > With Sage 5.10.beta1, (the custom SIGALRM handler gets called as > expected and) I get a traceback, but only after much more than 10 > seconds -- I'd say exactly *after* maxima_eval() returned [normally], > which is (almost) the same behaviour as with factor() usi

[sage-devel] Re: Orderings and dictionaries

On May 14, 3:42 am, Jernej Azarija wrote: > This is what the guys on #python (IRC) told me to consider > > >>> d1 = {-1: 0, -2: 0}>>> d2 = {-2: 0, -1: 0}>>> d1{-2: 0, -1: 0}>>> d2{-1: > >>> 0, -2: 0}>>> d1 == d2True>>> d1.keys()[-2, -1]>>> d2.keys()[-1, -2]>>> That is an extremely sneaky example

[sage-devel] Dig through stack for printing an object?

On http://trac.sagemath.org/sage_trac/ticket/14579 I noticed that sage is doing something very fancy to produce a short "repr" of a large matrix: It doesn't print the entries (I knew that), but it even goes delving in the stack to see if it can find a name to which the matrix might possibly be boun

[sage-devel] Re: Dig through stack for printing an object?

Oh, and sage_getvariablename doesn't quite live up to its advertised API either: sage: L=["hi"] sage: _T=L[0] sage: sage.misc.sageinspect.sage_getvariablename(L[0],omit_underscore_names=True) '_T' -- You received this message because you are subscribed to the Google Groups "sage-devel" group. T

[sage-devel] Re: Dig through stack for printing an object?

On May 14, 10:02 am, Volker Braun wrote: > I have no opinion on whether or not to do that on each _repr_ call. It > doesn't do anything for me, but I don't see what the point of flooding the > terminal even faster is. Not all "repr"s end up on a terminal, though. They can end up in exception mess

[sage-devel] Re: Dig through stack for printing an object?

On May 14, 11:35 am, Volker Braun wrote: > Don't do that. Exceptions should be short and to the point. And not do any > string processing. Don't convert passed values to strings unless you don't > care about performance. I agree, but it does happen. And as you see, matrix.__repr__ takes the whole

[sage-devel] Re: Dig through stack for printing an object?

On May 14, 2:13 pm, Simon King wrote: > There is a lazy object specially designed for attribute errors. See > sage.structure.misc.AttributeErrorMessage. Cool. Doesn't the coercion framework end up trying all kinds of things that may generate errors which get caught? Aren't those also different er

[sage-devel] Re: F(0)^0

On May 14, 3:34 pm, Mike OS wrote: > F. := GF(5) > F(0)^0 ... >   File "integer_mod.pyx", line 2381, in > sage.rings.finite_rings.integer_mod.IntegerMod_int.__pow__ > (sage/rings/finite_rings/integer_mod.c:20136) > ArithmeticError: 0^0 is undefined. I'm pretty sure that's not the error you got

[sage-devel] Re: Dig through stack for printing an object?

On May 14, 2:52 pm, Nils Bruin wrote: > On May 14, 2:13 pm, Simon King wrote: > > > There is a lazy object specially designed for attribute errors. See > > sage.structure.misc.AttributeErrorMessage. We already have a tool for delaying string assembly and it indeed makes a diff

[sage-devel] Re: Dig through stack for printing an object?

On May 14, 10:01 pm, Simon King wrote: > Indeed, when I created the AttributeErrorMessage, it was suggested on > trac to use LazyString instead. It turns out that a special purpose > cythoned AttributeErrorMessage is faster, but I agree that in the > general case (when it makes no sense to have a

[sage-devel] Re: SQRT of negative number is negative? Or positive? Or what?

On May 15, 3:25 am, man...@gmx.net wrote: > It does not work because "abs( )" returns an "Expression" which > will cause find_local_minimum to cause errors. The problem here is that 1.0+I*1.0 is a symbolic expression rather than a complex number (which one would you want? python complex? CDF? some

[sage-devel] Re: SQRT of negative number is negative? Or positive? Or what?

On May 15, 8:58 am, Nils Bruin wrote: > sage: zeta.simplify_radical() > -1 Sorry, that was supposed to be sage: (zeta^3).simplify_radical() -1 my apologies. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe fro

[sage-devel] Re: Overriding non-data descriptors

On May 17, 6:58 am, Simon King wrote: > However, the possibility to override non-data descriptors seems to be > restricted to classes that do not inherit from object, and this is the > reason for my post: > >  sage: class Bla(object): >  :     @property >  :     def _domain(self): >  :

[sage-devel] Re: glpk_graph_backend.pxd and include paths -- how does it work

On May 17, 1:04 pm, Julien Puydt wrote: > jpuydt@newton:~/sage-5.10.beta3/devel/sage/sage/numerical/backends$ grep > *pxd -e glpk.h > glpk_backend.pxd:cdef extern from "../../../local/include/glpk.h": > glpk_graph_backend.pxd:cdef extern from "../../../local/include/glpk.h": Since it's a "cdef e

[sage-devel] Cython classes with a __dict__

I don't dare posting this on cython-users because it's a horrible hack, but it does make a cython class have a dictionary that gets recognized by python as one to look up attributes in: The main problem is to convince Cython to compute the offset of a slot in a type structure.I ended up importing

[sage-devel] Re: Cython classes with a __dict__

On May 19, 12:15 am, Robert Bradshaw wrote: > Note that adding a __dict__ also massively slows down any cpdef function > calls. Which could be mitigated if cython would grow a pragma that allows cpdef calls being generated with "__pyx_skip_dispatch=1" (giving them the semantics of "cdef method t

[sage-devel] Re: Help needed with a memory leak

On Wednesday, July 3, 2013 2:32:14 PM UTC+2, Nathann Cohen wrote: > > Hell everybody !!! > > There is a very ugly memory leak in Sage's graphs, and I have no idea of > how it should be hunted. It is (unfortunately) very easy to produce : > > sage: get_memory_usage() > 956.87890625 > sage

[sage-devel] Re: parallel for loop with minimal forking

On Sunday, July 7, 2013 9:20:11 AM UTC+2, Maarten Derickx wrote: > > This indeed seems like a good addition. I'm not aware yet of a place in > sage where something like this is done. > > I would chose a different name though, something like "bundled_parallel", > because naming this one unordere

[sage-devel] Re: UTF-8 and old terminals (new startup banner)

On Monday, July 8, 2013 4:05:29 AM UTC+2, Volker Braun wrote: > > Frédéric Chapoton has written a patch at http://trac.sagemath.org/14733that > will beautify the Sage startup banner using some UTF-8 characters to > draw the box. This will display incorrectly in terminals that do not > support UT

Re: [sage-devel] Re: UTF-8 and old terminals (new startup banner)

On Monday, July 8, 2013 11:33:18 AM UTC+2, Jean-Pierre Flori wrote: > > IIRC the new GAP banner uses UTF-8. > You're right. With (to me) the same jarring effect, so I don't like it. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscrib

[sage-devel] Re: Products of permutations use nonstandard order of operation

On Saturday, July 13, 2013 1:43:09 AM UTC+2, darijgrinberg wrote: > There is a further issue lurking in the background here. It *is* possible > to make Sage use the standard convention (first \psi, then \pi), namely by > setting a global variable (see > http://trac.sagemath.org/sage_trac/ticket

[sage-devel] Re: Bug in evaluation of Maxima numbers? Or where? Or not a bug at all?

On Monday, July 22, 2013 6:36:04 PM UTC+2, Jesus Torrado wrote: > > So the "b" as an exponential sign is treated as a variable, producing some > funny behaviour: > > sage: maxima("2*bfloat(2e-4)").sage() > 4.0*b - 4 > sage: 2*maxima("bfloat(2e-4)").sage() > 4.0*b - 8 > That's inde

[sage-devel] Re: Dig through stack for printing an object?

This is now http://trac.sagemath.org/ticket/15036 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, s

[sage-devel] Re: Will Sage Cell Server later become part of standard Sage binary so no extra install steps needed?

On Thursday, August 22, 2013 11:53:07 AM UTC-7, jason wrote: > I think the best way to distribute a runnable cell server is as a > virtual machine image. At least then it is sandboxed into a virtual > machine where someone has seriously considered the security implications. > +1 The inheren

[sage-devel] usage of "verbose" in cython code

I noticed that in the sage library (for instance in matrix_rational_dense) the following use of "verbose" is around a lot: t = verbose('Computing echelon form of %s x %s matrix over QQ using p-adic nullspace algorithm.'%( self.nrows(), self.ncols())) Observe that: - The rou

[sage-devel] Re: usage of "verbose" in cython code

On Thursday, August 22, 2013 2:36:49 PM UTC-7, Simon King wrote: > > > We have lazy_string and lazy_format. Note that #14585 suggest a cython > version of them. > > Yes, I'm aware of those :-) and that should alleviate costs somewhat. However, a call verbose(lazy_string("computing %s x %s ...",

[sage-devel] Re: Problems with ATLAS 3.10.1 shared libraries

On Saturday, August 24, 2013 5:35:47 AM UTC-7, Jeroen Demeyer wrote: > > In http://trac.sagemath.org/ticket/15045, we noticed a problem with the > ATLAS build process involving shared libraries. It's a problem which > doesn't occur often, it happens essentially randomly (but mostly/only on > AMD

Re: [sage-devel] Re: usage of "verbose" in cython code

On Saturday, August 24, 2013 6:03:52 AM UTC-7, David Loeffler wrote: > > There is a second problem, also, with the use of "verbose" in Cython > code in the sage library. When "verbose" is called, the code for the > verbosity mechanism decides whether to print the message based on the > name of t

[sage-devel] Re: Can we require that the user has a recent enumitem LaTeX package?

On Wednesday, August 28, 2013 5:57:11 AM UTC-7, Simon King wrote: > > Hi! > > At #9107, we are facing a problem building the pdf documentation of > Sage. Namely, by dealing with "nested classes" in a proper way, the > documentation will provide lists that are more deeply nested than what > they

[sage-devel] Re: Hashing elements from the same ring

On Thursday, August 29, 2013 8:52:02 AM UTC-7, Simon King wrote: > > Hi Stefan, > > On 2013-08-29, Stefan > wrote: > > Actually, this is not quite true. reduce() is, by default, called > > automatically for elements of exact rings at creation time. It will > > correctly get rid of common factor

[sage-devel] Re: Pickling limitations

On Wednesday, September 4, 2013 4:29:30 PM UTC-7, Volker Braun wrote: > One possibility that I'd like to bring up is to write our own pickler. > Since we have our own framework for creating unique objects, we don't > *really* need the pickler to unpickle identical objects to identical > object

[sage-devel] Re: Pickling limitations

On Saturday, September 7, 2013 9:38:04 AM UTC-7, Volker Braun wrote: > Is that really true? That is basically my question. What would go wrong? > If one can only break cyclic references in specific orders then the whole > thing is probably not going to work as we can't predict how a user will >

[sage-devel] Re: Pickling limitations

On Sunday, September 8, 2013 7:15:50 AM UTC-7, Volker Braun wrote: > I agree that you can't use the "object id as unique identifier" pattern. > AFAIK the graph theory code in Sage does not work like that, but uses > integers to enumerate nodes. If you really want unique GraphNodes then the >

[sage-devel] Re: Pickling limitations

On Wednesday, September 4, 2013 4:29:30 PM UTC-7, Volker Braun wrote: > > Having spent a day to look closer at pickling issues, there seem to be > some dangerous issues. In particular, Python currently has a bug where you > can create pickles that unpickle incorrectly without raising any except

[sage-devel] Some questions about CachedRepresentation

These questions are probably most appropriate for Simon, but they're about sage general stuff, so I'm posting it here. I note that CachedRepresentation is presently an old-style class, because it's declared by class CachedRepresentation: Shouldn't that be class CachedRepresentation(object):

[sage-devel] Re: Some questions about CachedRepresentation

On Tuesday, September 10, 2013 6:43:34 AM UTC-7, Simon King wrote: > > > I am puzzled: I believe that CachedRepresentation *IS* a new-style class, > "new-style class" being defined as a type inheriting from ): > OK, never mind. Indeed, it's a cython file, not a python file. > > I don't thin

[sage-devel] Re: Some questions about CachedRepresentation

On Tuesday, September 10, 2013 8:50:11 AM UTC-7, Nils Bruin wrote: > > > If other objects in the pickle would always trigger the creation of > certain entries in the dict, we could even end up with an inconsistent > state, because those other objects might be relying on t

[sage-devel] Re: sage.bla.foo() does not always work in lazy_imported modules

On Thursday, September 12, 2013 10:35:10 PM UTC-7, Dima Pasechnik wrote: > > With Sage 5.12.beta4, I see > > sage: delsarte_bound_additive_hamming_space(11,3,4,d_star=9) > Have you tried sage: delsarte_bound_additive_hamming_space? instead? It causes an unhandled SIGSEGV for me. -- You re

[sage-devel] Re: How can we improve 3d graphics in sage?

On Saturday, September 14, 2013 3:07:45 AM UTC-7, Eric Gourgoulhon wrote: What about using Blender ? It is a mature free > and open-source 3d/4d graphics software of professional level. Moreover, it > has a Python > API

[sage-devel] Pickling of CategoryObject instances

The problems arising on #15149 arise from the fact that if objects occur as keys in dictionaries, then their hashes might be required prior to `setstate` being called on them during unpickling. If we trace where the failing `hash` comes from, we find it's CategoryObject.__hash__(self):

[sage-devel] Re: Pickling of CategoryObject instances

On Saturday, September 14, 2013 7:00:22 PM UTC-7, Nils Bruin wrote: > > so in a way, it's CategoryObject that breaks the unpickling: If > CategoryObject introduces a custom hash, it should also ensure that (at > least by default), pickling ensures that it gets unpacked approp

[sage-devel] Re: Pickling of CategoryObject instances

t be documented, but ideally we'd find some solution so that pickling doesn't break, or at least that there is a well-documented and low-cost way of making it work again. On Saturday, September 14, 2013 7:00:22 PM UTC-7, Nils Bruin wrote: > > The problems arising on #15149 arise

[sage-devel] Re: Pickling of CategoryObject instances

On Tuesday, September 17, 2013 2:15:14 AM UTC-7, Simon King wrote: > And it is a good guess that two Sage objects evaluate equal only if their > string representations are equal (but not "if and only if"). > > Some problems, though: The string representation is not always available > when we ne

[sage-devel] Re: Pickling of CategoryObject instances

On Tuesday, September 17, 2013 2:15:14 AM UTC-7, Simon King wrote: > > And, worst: The string > representation can be customized after object creation, and so the hash > value depends on whether the hash was first called before or after > renaming. > We can fix that, assuming that `rename` is n

[sage-devel] Re: Pickling of CategoryObject instances

see http://trac.sagemath.org/ticket/15207 for a very preliminary draft of something that might help implementing better pickling procedures. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails

[sage-devel] Re: Are Laurent polynomials really this broken? (or is it me?)

I think the error is elsewhere: sage: P.=LaurentPolynomialRing(ZZ,2) sage: p=2*u**-1*v**-1+u*v sage: [ type(c) for (exp,c) in p.dict().iteritems()] [sage.rings.rational.Rational, sage.rings.rational.Rational] The coefficients are returned as rationals, not integers. Indeed: sage: type(P(1).coef

[sage-devel] Re: Are Laurent polynomials really this broken? (or is it me?)

On Thursday, September 19, 2013 1:34:02 AM UTC-7, Andrew Mathas wrote: > Everything is correct except, I think, the last line: x^-1 it NOT defined > so this should be returning an error rather than coercing into the field of > fractions. > If you're mainly interested in laurent polynomials

[sage-devel] Re: Are Laurent polynomials really this broken? (or is it me?)

On Thursday, September 19, 2013 10:10:26 AM UTC-7, Travis Scrimshaw wrote: > > Let me also make explicit the question: Given ZZ[t, t^-1], do we want 1 / > (2*t) to be in the fraction field or in QQ[t, t^-1]? > > I'm leaning towards the latter since it is a "smaller/more simple" ring > (and I real

Re: [sage-devel] broken prompts in Emacs shell-mode

On Friday, September 20, 2013 11:12:37 AM UTC-7, William wrote: > > If the problem is the same, you could ask on the ipython list... > (since sage's command line is ipython). > > William > > It is. I don't think IPython's prompt configuration looks at the > environment TERM at all. It's fully

Re: [sage-devel] Inverse of discrete functions

On Wednesday, September 25, 2013 9:59:46 AM UTC-7, Tom wrote: > > For iso/automorphisms of graphs, I often wish that dictionaries were > both callable and invertible. In general, yes, I think > DiscreteFunction and DiscreteBijection classes would be very useful. > Does https://pypi.python.org/

Re: [sage-devel] Re: We need a new color?

On Monday, September 30, 2013 11:08:02 AM UTC-7, Tom wrote: > > > For the more pragmatic, you can fairly accurately predict when that > url will come live, and just sleep 'til then. > > That's not very robust in the face of future changes. Randomized retry with exponential backoff (perhaps cappe

[sage-devel] Re: motivation: here's one reason your contributions to Sage matter...

On Monday, September 30, 2013 12:26:51 PM UTC-7, telugujoshi wrote: > > Just thought of a name for Sage user group - uSage. > Nice play on words. Also the similarity to "U-pick" orchards seems an appropriate allusion to what using sage in the less polished areas often feels like. Perhaps for th

[sage-devel] Re: Is this a bug or is it intended?

Your example looks suspicious because you're calling _unset_embeddings and then install an embedding. That's explicitly warned against in the documentation. What you're finding is that QQbar.convert_map_from(F) returns a broken map. That happens also if you don't try to register an embedding at

[sage-devel] Re: Is this a bug or is it intended?

On Wednesday, October 2, 2013 1:07:21 PM UTC-7, mmarco wrote: > > I get it, thanks. > Actually, all the errors around failed conversions seem a little rough: sage: M=matrix([[1,2],[3,4]]) sage: QQ(M) TypeError: rational_reconstruction() takes exactly one argument (0 given) sage: QQ.convert_map_

[sage-devel] Re: Mutability

See: http://trac.sagemath.org/ticket/13949 It's not just a technical issue: matrices used to have a 'mutability' instance stored on an attribute, to encode a simple boolean. That increases memory footprint and reduces performance significantly. Just storing the boolean straight away should be

[sage-devel] Re: Mutability

On Monday, October 7, 2013 9:40:20 AM UTC-7, Volker Braun wrote: > > On Monday, October 7, 2013 5:05:52 PM UTC+1, Nils Bruin wrote: >> >> I think this holds uniformly, i.e., the class can go, being an >> inappropriate abstraction. I think in all cases a simple boolean (b

[sage-devel] Re: Mutability

On Monday, October 7, 2013 11:35:47 AM UTC-7, Volker Braun wrote: > > I think you are missing the point that it is supposed to be a mixin class. > Ah, right. Perhaps it could be used like that, and it looks like it was before pyrexification. Presently it's just not used at all, and its last use w

Re: [sage-devel] imag(CC(infinity)) is 0?

On Monday, October 7, 2013 3:37:22 PM UTC-7, Peter Bruin wrote: > > > I think a case could be made for having two versions of the current RR: > one like the current one (more like a model of the extended real line) and > one where overflow or division by zero raises an exception instead of > r

[sage-devel] Crash on fedora 17 for sage-git

I tried to get with the times and build sage via the "git" route. It seems I mostly got a functioning "sage 5.12rc1". There is one problem, however: I'm getting SIGSEGV whenever I ask for "?" on the command line. The segfault occurs somewhere in ncurses: #0 0x0031d060f080 in waitpid() #1

[sage-devel] Re: Crash on fedora 17 for sage-git

Some further info that may be helpful: $ ldd /usr/local/sage/sage-git/local/lib/python2.7/lib-dynload/_curses.so linux-vdso.so.1 => (0x7fff5a884000) libncursesw.so.5 => /lib64/libncursesw.so.5 (0x7f83e3d43000) libtinfo.so.5 => /usr/local/sage/sage-git/local/lib/libtinfo.so.5

[sage-devel] Re: Crash on fedora 17 for sage-git

On Thursday, October 10, 2013 2:21:43 AM UTC-7, Jean-Pierre Flori wrote: > > > > On Thursday, October 10, 2013 11:19:01 AM UTC+2, Jean-Pierre Flori wrote: >> >> I guess http://trac.sagemath.org/ticket/15080 takes care of this? >>> >>> >>> Yes, that works! I did "sage -i " and that solved the prob

[sage-devel] Transitivity of coercion discovery

On #14711 we ran into an existing difference with how coercions that are "embeddings" are handled in coercion discovery: class pA(Parent): pass class pB(Parent): pass class pC(Parent): pass A=pA(); B=pB(); C=pC() BtoA=Hom(B,A)(lambda x: A(x)) AtoC=Hom(A,C)(lambda x: C(x)) A.register_coercion(Bt

[sage-devel] Re: Transitivity of coercion discovery

On Tuesday, October 15, 2013 12:10:15 AM UTC-7, Simon King wrote: > Ultimately, the coercion system is asking the involved parents which > coercions they know of. There is no other location that would store > coercions. > That's how we implement it. If that's insufficient then we fail to prope

[sage-devel] how to run doctests?

In the process of trying to referee #12601 I tried to run `make ptest` to check the doctests. Everything builds OK, except some unrelated documentation: ... Building reference manual, first pass. ... [matrices ] no targets are out of date. Traceback (most recent call last): File "/usr/local/sa

Re: [sage-devel] Transitivity of coercion discovery

On Monday, October 14, 2013 9:38:02 PM UTC-7, Robert Bradshaw wrote: > > This is definitely a bug, This is now http://trac.sagemath.org/ticket/15303 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receivi

Re: [sage-devel] Re: Transitivity of coercion discovery

On Thursday, October 17, 2013 3:33:33 PM UTC-7, Robert Bradshaw wrote: > As long as the coercion graph is constructed lazily, I don't know that > it's possible to respect the digraph model. For example, if we have X > -> Y -> Z, the mere creation of Y induces a coercion from X to Z that > migh

Re: [sage-devel] Should the Sage manual mention SageMathCloud?

On Thursday, October 17, 2013 3:46:59 PM UTC-7, William wrote: > there are likely well over a > million people taking collage math classes (for which Mathematica is > useful) right now. Brilliant. I think that is the perfect term for assignment submissions mainly created by cut and paste.

[sage-devel] Re: [sage-combinat-devel] Re: Usage of the term Composition

On Sunday, October 20, 2013 5:49:07 PM UTC-7, Anne Schilling wrote: > > > > With regard to `Composition`, I do not have any strong feelings. I do > not see anything wrong with having both `IntegerComposition` and > `Partition` in the name-space. On the other hand, since no one > > has noticed a

Re: [sage-devel] Re: Transitivity of coercion discovery

On Thursday, October 17, 2013 3:33:33 PM UTC-7, Robert Bradshaw wrote: > As long as the coercion graph is constructed lazily, I don't know that > it's possible to respect the digraph model. For example, if we have X > -> Y -> Z, the mere creation of Y induces a coercion from X to Z that > might

Re: [sage-devel] Re: Transitivity of coercion discovery

It seems that `_coerce_map_from_` implementations should indeed be written quite carefully. An example is CC._coerce_map_from_ where you see the backtracking happens programmatically: def _coerce_map_from_(self, S): RR = self._real_field() if RR.has_coerce_map_from(S):

Re: [sage-devel] Re: Transitivity of coercion discovery

On Friday, October 25, 2013 12:57:33 PM UTC-7, Nils Bruin wrote: > > Comparing that with the example in the documentation ( > http://www.sagemath.org/doc/reference/coercion/): > >def _coerce_map_from_(self, S): >if S is ZZ: >return True >

[sage-devel] Re: Embedded number fields

On Saturday, November 2, 2013 10:34:10 AM UTC-7, vdelecroix wrote: > > I am working with number fields that I consider as subfields of RR. RR doesn't coerce into AA (it really doesn't!), so specifying an embedding of your numberfield in RR is not going to help in finding a coercion into AA. You

[sage-devel] Changing branch on a trac ticket

It seems that the current "branch" field in trac serves two purposes: (a) It's a pointer to code-in-development that people who are collaborating can refer to (b) It serves as the official "to-be-merged" code once the ticket has a positive review For purpose (a), having lots of little commits,

[sage-devel] Re: Changing branch on a trac ticket

On Sunday, November 3, 2013 6:51:48 PM UTC-8, P Purkayastha wrote: > If you check out the branch locally, you can run a > > git diff > > to see the cumulative changes. > That's good to know. However, when trying to figure out the history of code, it's usually not so much the question what h

Re: [sage-devel] Re: Changing branch on a trac ticket

On Monday, November 4, 2013 10:33:24 AM UTC-8, David Roe wrote: > > I agree with Volker: any plan which involves rewriting the history of your > branch to make it "nicer" is a very bad idea. Once you push changes to > trac, you really should not go back and rewrite your commits. Even if you >

[sage-devel] Re: Changing branch on a trac ticket

On Tuesday, November 5, 2013 6:32:49 AM UTC-8, Simon King wrote: > > To say it clearly: In the scenario above, you *have* to rebase, with or > without a change of history, and the rebase (if I understand correctly) > is the same effort with or without a change of history. > > Hence, saying that

Re: [sage-devel] Re: Creating the (Z/5Z)^2 group in Sage : Hell among groups, parent/elements, Cartesian Products ...

On Friday, November 8, 2013 12:09:24 AM UTC-8, Nathann Cohen wrote: > By the way, why would "G = AdditiveAbelianGroup([7,23])" > 1) expect input from Z/161 > 2) give its output as pairs 7x23 ? > That must be an oversight (and hence a reportable bug). This is just too confusing: sage: G1=Additi

Re: [sage-devel] Re: Creating the (Z/5Z)^2 group in Sage : Hell among groups, parent/elements, Cartesian Products ...

On Friday, November 8, 2013 3:25:10 PM UTC-8, Travis Scrimshaw wrote: > > I think it would be better to make these UniqueRepresentations by sorting > the list of integer inputs, that way things like > >> >> sage: G1 is G2 >> False >> sage: G1 == G2 >> False >> >> would make sense. >> > > Sorry, I

[sage-devel] another memory leak?

I think sage's memory management is making progress: examples of getting obvious leaking are getting more convoluted. I ran into the following one. With the code import gc def t(N,start=0): P=PolynomialRing(QQ,name='x') x=P.gen(0) L=[NumberField(x^2+1,name="a%d"%start)] for i in

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