On Jan 4, 7:08 am, kcrisman wrote:
> Let's hope Sage continues to yield 100-fold fruit
> from what we put into it!
Ah, that explains the memory management practices :-).
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send
On Jan 4, 4:08 am, John Cremona wrote:
> A disadvantage is that one loses all the beauty of a workable
> worksheet which can be instructive to look at even if one does not
> want to run the code.
Perhaps old-fashioned, but since a notebook is ultimately rendered as
an HTML page, you can your your
On Jan 4, 8:17 pm, Dima Pasechnik wrote:
> > The abs() method is defined in sage.structure.element.RingElement. If
>
> but why? not all rings have any meaningful abs()..
>
> > that method makes sense for your specific class of ring elements,
> > implement a method __abs__.
Perhaps more importantl
On Jan 4, 10:19 pm, Nicholas Kirchner wrote:
> The instructions at "Walking Through the Development Process" do not seem
> quite suitable for patching the app, which resides in
> SAGE_ROOT/devel/ext-main/sage/ext/mac-app. What's the preferred way to
> create a patch for a Trac ticket on the Mac a
On Jan 5, 1:27 am, Volker Braun wrote:
> Also, x.__abs__() is just the Python magic method for abs(x). The function
> call syntax abs(x) will always call __abs__ and return an AttributeError if
> it is not defined. So all we have is an x.abs() method that behaves exactly
> like abs(x), for better
In sage/covariant_functorial_construction.py, line 359 we still have
an uncached
def is_subcategory(self, C):
"""
.. todo:: doctests + explain why this method is needed
"""
if C is self:
return True
return any(X.is_subcategory(C) for X in
sel
On Jan 8, 2:12 am, Simon King wrote:
> I don't know what a "rider patch" is, but go ahead. Briefly looking at
> the discussion on #13400, it seems that this ticket should be split in
> several independent small tickets anyway.
I just figured it could be included in a somewhat related ticket, but
On Jan 8, 3:28 am, Volker Braun wrote:
> The notebook stuff hurts us twice in import times: First, many modules have
> their path added to sys.path making it longer. Second, the notebook stuff
> is actually imported in a plain commandline Sage session. And the modules
> are pretty slow, for exampl
On Jan 9, 8:34 am, Volker Braun wrote:
> I say we don't do anything special. Ccache will use the default ~/.ccache
> or CCACHE_DIR if set. Why muck around with it if there is a perfectly fine
> configuration system in place already?
>
> [vbraun@volker-desktop ~]$ du -sh ~/.ccache/
> 44G /home/vbra
On Jan 9, 12:57 pm, Simon King wrote:
> Hi all,
>
> what do I need to do to use ccache?
See "man ccache". However, some comments on gotchas to get that
working properly with sage would be welcome.
Would something like
ln -s ccache $SAGE_ROOT/local/bin/gcc
ln -s ccache $SAGE_ROOT/local/bin/g++
l
On Jan 9, 2:46 pm, Robert Bradshaw
wrote:
> Disk space is (relatively) cheap. I think anyone who builds Sage from
> source is likely to build it again, i.e. be a (potential) developer.
Not *all* disk space is cheap, though. If I install and build a piece
of software on a disk I have designated fo
On Jan 9, 2:46 pm, Robert Bradshaw
wrote:
> I think anyone who builds Sage from
> source is likely to build it again, i.e. be a (potential) developer.
But you shouldn't measure this per person. Given sage's finicky
configuration, the most trustworthy deployment on multiple computers
is to just co
On Jan 9, 5:00 pm, Robert Bradshaw wrote:
> That defeats the purpose of sharing ccache across Sage builds.
That won't yield a benefit anyway. Quoting from the manpage:
"""
For both modes, the following information is included in the hash:
· the extension used by the compiler for a file with p
On Jan 10, 12:21 am, Jeroen Demeyer wrote:
> jdemeyer@sage:~$ ccache -s
> cache directory /home/jdemeyer/.ccache
> cache hit (direct) 5889666
> cache hit (preprocessed) 980843
> cache miss547099
> called for link
On Jan 10, 1:50 am, Volker Braun wrote:
> I don't
> think anybody is proposing to make ccache a standard spkg, for starters it
> does not help for the one-time Sage build. Just don't use ccache if it
> doesn't fit in your or your organization's infrastructure.
I agree with that. If it's an option
On Jan 10, 12:55 pm, Johannes wrote:
> hey list,
>
> If you look at the code, there is a function called _new_c() which is
> used in the multiplication algorithm.
See
http://trac.sagemath.org/sage_trac/ticket/8294
Looks like a little more is broken than just __copy__.
Normally, _mutability get
On Jan 10, 3:20 pm, Johannes wrote:
> But in the _copy_() method _mutability is set to a value.
Yes, that's the line that led me to the fixed ticket #8294.
A thing to keep in mind is that the designers of 2x2 matrices might
have been willing to give up some features (such a immutability) in
favor
On Jan 10, 7:44 pm, P Purkayastha wrote:
> We are thinking about people using 256G or even 500G+ hard disks and
> desktops. But what about people who are developing on notebooks with
> only SSDs?
If you only have one disk the question isn't where the cache should be
but if there should be one at
On Jan 11, 5:27 am, David Loeffler wrote:
> I'm keen to keep Matrix_integer_2x2 as a subclass of Matrix. I'd have said
> that doing it any other way is likely to cause lots of obscure bugs (since
> developers will quite naturally assume that Matrix_xxx is a subclass of
> Matrix for any value of xx
sage/matrix$ grep _mutability *.pxd
matrix0.pxd:cdef sage.structure.mutability.Mutability _mutability
matrix0.pxd:cdef check_mutability(self)
matrix0.pxd:cdef check_bounds_and_mutability(self, Py_ssize_t i,
Py_ssize_t j)
matrix0.pxd:cdef check_row_bounds_and_mutability(self, Py_ssiz
First try on:
http://trac.sagemath.org/sage_trac/ticket/13949
at least tests in sage/matrix pass ...
This project nearly seemed painful due to the required changes to
pickling, but then it turned out that pickling isn't implemented for
matrices anyway, so no outdated pickles should exist.
I hav
On Jan 13, 10:01 am, Marco Streng wrote:
> Polynomials in Sage have a well-defined degree, and that means that
> the leading coefficient cannot be (numerically) zero, the degree of
> 0.0 is ambiguous unless we decide that 0.0 is just 0, in which case we
> may as well print it as such.
That's good
On Jan 13, 2:33 pm, Charles Bouillaguet
wrote:
> Well, I would prefer this thing to print "0.0", just as a gentle reminder
> that the result may not be accurate…
Well, the zero polynomial really is something different from the
constant 0.0. Printing 0 reminds you that really no term is present
he
With 5.6 almost out the door, it is perhaps time to prepare some
infrastructure maintenance tickets in line for inclusion in 5.7. In
particular, these tickets spring to mind:
http://trac.sagemath.org/sage_trac/ticket/12215
http://trac.sagemath.org/sage_trac/ticket/12313
http://trac.sagemath.org/sa
On Jan 23, 9:41 am, Raniere Silva wrote:
> Hi,
> I'm loading some matrix to do a benchmark and got a error when load some
> matrix (one of then can be found
> athttp://www.cise.ufl.edu/research/sparse/MM/LPnetlib/lp_qap12.tar.gz). A
> minimal
> example and the log of error are below
>
> sage
On Jan 23, 2:43 pm, Simon King wrote:
> Since MyClass inherits from UniqueRepresentation, comparison should be
> by identity. But I thought that == would rely on __eq__ (which *is*
> provided by UniqueRepresentation). Are the 2 microseconds really the
> to-be-expected overhead of calling UniqueRep
On Jan 24, 11:29 am, Travis Scrimshaw wrote:
> > And now the catch: In a Cython class, you can not directly implement
> > __eq__, but you *must* implement __richcmp__ instead.
>
> That seems strange to me...
That's just how Cpython chose to implement those routines. Instead of
putting a whole bun
On Jan 29, 10:44 am, Volker Braun wrote:
> The first three digits ("0.00") of your result are correct, this is the
> expected output.
Well ... I'm not so sure about THAT expectation, but the gist of it:
sage: (2*pi).n()
6.28318530717959
sage: sin(6.283)
-0.000185307178525578
sage: sin(6.284)
0.0
Looks like a known problem:
http://trac.sagemath.org/sage_trac/ticket/13054
The routine in question tries to find a better defining polynomial for
a given field. With
R.=QQ['y']
poly=y^4 - 4294967296*y^2 + 54265257667816538374400
it executes:
degree = poly.degree()
pari_poly = pari(pol
On Jan 31, 6:49 am, "Nicolas M. Thiery"
wrote:
> Shall we ask the Cython devs to implement the __classcall__ protocol?
> Then we could merge the factory function and the class in Cython
> classes as is done by UniqueRepresentation.
I guess that could be quite doable for "python" style classes th
On Feb 2, 12:11 am, Simon King wrote:
> By this, you mean whether there is an easy way to either make the intuitive
> syntax
> @cached_method
> def truc(...):
> ...
> trac = truc
> work, or warn the user? No idea yet.
In order to convert this syntax
def _uncached(..):
On Feb 2, 11:24 am, Simon King wrote:
> But I think it would be both easier and cleaner to separate the creation
> of the class from the creation of method aliases:
>
> sage: class Foo(object):
> : @cached_method
> : def truc(self, x):
> : print "calling truc"
>
On Feb 2, 2:25 pm, Simon King wrote:
> OK, but I still don't see why this would be a problem. After all, f.truc
> *is* f.trac.
OK, I tried reading the code and I decided that I don't understand
what it IS doing. You wrote it so you might know better :-).
Anyway, my first stab at such code would b
I think the problem is in CachedMethodCallerNoArgs.__get__, which is
the function responsible for retrieving the cached function instance
from the class or its instance. See line 1807 for sage/misc/
cachefunc.pyx:
try:
return
(inst.__cached_methods).__getitem__(self.__name__)
On Feb 3, 1:37 am, Nils Bruin wrote:
> See line 1807 for sage/misc/cachefunc.pyx:
Actually, I'm not so sure that code ever gets executed in our example.
I certainly didn't get any results from putting "raise" or "print"
commands there. On class level, there&#x
On Feb 4, 2:28 am, Simon King wrote:
> Of course, one could add some
> try:
> return getattr(inst, self._cachedmethod._cachedfunc.__name__)
> except AttributeError:
> pass
> to the __get__ methods in sage/misc/cachefunc.pyx. It would speed up the
> access to aliases of a c
Plain old coercions are cached on the codomain. Since our generic,
global objects like ZZ and QQ tend to coerce universally *into* other
rings, this tends to mean that the morphisms, which hold strong
references to domain and codomain, are hanging off the more temporary
objects, i.e., ZZ and QQ are
On Feb 4, 1:53 pm, Simon King wrote:
> But is a weak reference to the domain of a map really enough?
I don't think so. Consider
K=QQ(z)
P=place(K,z-1)
KP. = Completion(K,P,precision = 10)
i.e., KP is the Laurent series ring of rational functions in z,
expanded around z=1 (i.e., laurent serie
On Feb 4, 3:31 pm, Robert Bradshaw
wrote:
> This is a bit of a tangent, but perhaps _convert_from_hash could be a
> weak-ref dict.
It is a "MonoDict" (weak key ref dict looked up by id) after #12313
> Binary operations can be used for actions more complicated than
> coercion-to-a-common-parent f
On Feb 4, 5:23 pm, Nils Bruin wrote:
> Note: the time-critical thing for us is to access the reference of a
> weakref. We currently do that via a normal method lookup, but using
>
> PyWeakref_GetObject
>
> would be WAY faster. Question: If we have a KeyedRef object (which
&g
On Feb 4, 10:01 pm, Simon King wrote:
> Note that in some cases the _element_constructor of a complicated ring
> would try to convert the input into ZZ before converting it into self.
Ouch. by generic conversion?
> So, in order to strictly avoid it, we would need to carefully clean all
> of Sag
On Feb 4, 10:01 pm, Simon King wrote:
> ... Here, you do not have any odd ring which
> happens to coerce into KP
That's why I thought it wouldn't be too much of a problem: Coercions
aren't supposed to exist between any odd pair of rings. If there is a
coercion then there is a special relation bet
On Feb 4, 10:57 pm, Robert Bradshaw
wrote:
> Currently the cdef _call_ assumes the argument is in the domain
> (sometimes giving incorrect results or segfaulting if it's not, for
> performance reasons), whereas __call__ coerces its argument into the
> domain if it is not already there. I think thi
On Feb 4, 10:57 pm, Simon King wrote:
> There is a base class of maps, and the first
> thing I'd try is to use the weakref there!
Some notes for this I found upon initial inspection:
- coercion discovery is littered with references to mor.domain() and
mor._domain, so these maps are really assume
On Feb 5, 12:34 am, Robert Bradshaw
wrote:
> By default, such morphisms would be kept alive by their codomains,
> which are typically more complicated structures that often have direct
> references back to the domains as well (e.g. R[x] -> R). Embeddings
> (e.g. K -> CC) would be kept alive by th
On Feb 6, 12:05 pm, Simon King wrote:
> There is the idea to always keep the last N created parents alive by a
> strong reference. Couldn't this easily be done, by appending "self" to a
> list (and removing the first entry, when the list is too long), while
Yes, except you want to do it circularl
On Feb 8, 7:40 pm, Kannappan Sampath wrote:
> No, I wanted to clear the screen. I brought in Octave for want of an
> anology and to say the fact that what works when I start Octave myself does
> not work when I start it from Sage (the Ctrl + L). And, unfortunately,
> "clear" does not clear the scr
The following came up on #14084 but it relates much more to the kinds
of things happening on #13370.
Since parents are unique in sage, so if you ask for a parent to be
constructed, you really don't know what you get back. It might be a
freshly produced one, it might be one that is currently also
r
On Feb 10, 12:17 pm, Charles Bouillaguet
wrote:
> Why doesn't the first call to R in IntegralDomains() decide wether this is
> true or not ?
Since in this case it just boils down to exactly the same check that
is necessary for `R in Fields()`, that's definitely an option.
However, in general dec
The process of transplanting a discussion from a trac ticket (#14084
in this case) to sage-devel is a bit painful. Simon seems to agree
that the discussion belongs here, so I'll copy his latest comments
here and reply. I think their context is clear but if in doubt: look
on the ticket.
> Also note
On Feb 11, 3:16 am, Simon King wrote:
> It [method inheritance] is affected. There actually is an example in my
> thematic tutorial on
> coercion and categories (for elements, but it is the same for parents).
I find that worrying in the light of unique parents. It means that
when I construct a
On Feb 11, 11:35 am, "Nicolas M. Thiery"
wrote:
> By design, the category of an object in Sage describes:
>
> (a) It's "operations" (additive structure, multiplicative
> structure). This conditions what the morphisms are in the category.
>
> (b) The properties of the operations that Sage is a
On Feb 11, 3:10 pm, Nils Bruin wrote:
Sorry! typo. The example should read:
> sage: QA.is_field()
> False
> sage: QB.is_field()
> True
> sage: QB in Fields()
> True
of course, QB is a field so QB.is_field() should return True. My
apologies.
--
You received this messa
On Feb 11, 11:30 pm, Robert Bradshaw
wrote:
> I don't think we should have a separate ZZ whose category is
> EuclideanDomains another one whose category is Rings, another one
> whose category is AbelianGroups, and another one whose category is
> Sets. Perhaps this is a special case, as this is a n
On Feb 14, 7:27 am, Ben Hutz wrote:
> I seem to be getting a weird result when I use .subs over QQbar:
>
> R.=PolynomialRing(QQbar,3)
> Y=(x^4*y + 2*c*x^2*y^3 - x*y^4 + (c^2 + c)*y^5)/(x^2*y - x*y^2 +c*y^3)
> fm=[x^2 + c*y^2, y^2]
> W1=Y.subs({x:fm[0],y:fm[1]})
The rest of the results are as they
On Feb 14, 7:27 am, Ben Hutz wrote:
> R.=PolynomialRing(QQbar,3)
> Y=(x^4*y + 2*c*x^2*y^3 - x*y^4 + (c^2 + c)*y^5)/(x^2*y - x*y^2 +c*y^3)
In addition, this doesn't simplify, whereas over QQ sage recognizes
the denominator divides the numerator (you still get a fraction field
element, though). Tha
Hi Simon,
Probably good to make this difference. Some comments below.
On Feb 17, 7:48 am, Simon King wrote:
> - Have a class CachedRepresentation. If your class inherits from it, then
> calling your class with equal arguments returns identical instances,
> and pickling is automatically provi
On Feb 17, 9:56 am, Simon King wrote:
> You see, the class of a unique instance is like a good red wine in a
> bottle: The bottle remains the same, but the wine may improve in the
> course of time...
a bottle shared by many. And improvement is a matter of taste. If you
got a bottle because you t
On Feb 17, 11:10 am, Simon King wrote:
> Yes. But the C code generated by Cython is *much* longer than what you get
> from
> cdef long hash_by_id(PyObject *o):
> return o
>
> So, if you assign the latter to tp_hash, it is faster. I could be
> mistaken, but I think *this* makes the diff
On Feb 17, 12:27 pm, Simon King wrote:
> Question: Do we *want* that subclasses can override it? After all, if
> they are sub-class of UniqueRepresentation, then they are supposed to
> show the unique representation behaviour---which includes that
> comparison is by identity.
I think we shouldn't
On Feb 17, 1:09 pm, Nils Bruin wrote:
> """
> User-defined classes have __cmp__() and __hash__() methods by default;
> with them, all objects compare unequal (except with themselves) and
> x.__hash__() returns id(x).
> """
The Python documentation is p
On Feb 17, 3:25 pm, Simon King wrote:
> So, it would work. Note, however, that your suggestion is intrusive as
> well. It would be impossible to use a different hash in a sub-class:
> sage: cython("""
> : from sage.misc.fast_methods import provide_hash_by_id
> : cdef class Foo:
> .
On Feb 17, 3:25 pm, Simon King wrote:
> However, subclasses forget everything about the hash:
> sage: class Bar(Foo):
> : pass
> :
> sage: b = Bar()
> sage: hash(b) == id(b)
> False
> sage: hash(b) == id(b) >> 4
> True
OK, I think I've found the problem. I think cytho
On Feb 17, 10:35 pm, Nils Bruin wrote:
> Indeed, we have
>
> sage: MyHash.__dict__["__hash__"](h)
> 0
> sage: print MyHash.__hash__(h)
> 0
> sage: h.__hash__()
> 0
Incidentally, this suggests that hash(a) does the following:
1] see if type(a).tp_hash is set.
On Feb 17, 10:35 pm, Nils Bruin wrote:
> The only reason I can think of for inheritance not to pick up on the
> changed tp_hash field is that PyType_Ready gets called on the data
> structure formed for MyHash before we get a chance to change the
> tp_hash field.
Indeed, PyType
Simon ran into the following snag:
* To provide a hash function on a python extension class, one needs
to assign a function pointer of type
long (PyObject *). One can do exactly that using a "cdef" in
cython
* Cython only accepts "def __hash__(self):" to define this hash
function. This function
On Feb 17, 11:47 pm, Jeroen Demeyer wrote:
> How about cpdef, does that work? It might give you the best of both worlds.
Could be, but cython does need to take special action: It needs to
recognize a cdef of the right signature is available and plug that
straight into the slot (such as tp_hash) r
On Feb 18, 10:21 am, Robert Bradshaw wrote:
> What cruft?
Cruft only in the eye of the beholder, or in this case in view of the
domain of application. It seems
a few refcounting and argument packing/unpacking things are
unavoidable. Simon was running into a case where he essentially was
trying to
On Feb 18, 11:26 am, Robert Bradshaw
wrote:
> That's because you're calling id as a Python function, not because of
> __hash__. Try
>
> def __hash__(self):
> return self;
That is extremely cool! Thanks. (The previous post crossed your reply)
--
You received this message because you are subs
On Feb 19, 12:58 am, Simon King wrote:
> Here I am not sure: Must hash be compatible with cmp or with rich
> comparison?
Neither :-). It's up to the class writer to decide if they want
something usable :-)
> Hence, should I overload __cmp__ as well?
If you look at the C-API rules, inheritance
On Feb 19, 9:38 am, Simon King wrote:
> sage: cython("""
> class Bla:
> def __hash__(self):
> return 2
> def __cmp__(self, other):
> print "cmp"
> return 0
> def __richcmp__(self, other, m):
> print "calling richcmp"
> if m==2:
> retu
On Feb 24, 11:57 am, JMH wrote:
> Also, if you do not think that I should modify the standard "sage-env"
> script, how can I "register" my library in a different way?
> Before I source my "setup" shell script (bash), I need all Sage related
> variables to be set, so the end of the standard "sage-
On Feb 26, 4:15 pm, JMH wrote:
> Hi,
> in general, the package that I want to use comes with a shell script which
> modifies environment variables that are needed. So I need a mechanism to
> "source" that shell script (and that script needs to modify at least
> "PATH", "LD_LIBRARY_PATH" and "PYTHO
On Feb 26, 11:32 pm, Simon King wrote:
> Hi!
>
> The patchbot's startup_time plugin complains about #14159. In order to
> see what is happening, I studied the output of sage -startuptime, and
> got a surprise.
I don't think the list printed is complete. It seems to be just a top
50. It probably m
On Feb 27, 9:39 am, Timo Kluck wrote:
> The issue is that we're upgrading boost, and apparently, its random number
> generator has slightly changed. Therefore, we have some failing doctests
> for random_set.
Do we really want to test our random number generators for
deterministic behaviour? If so
On Feb 27, 12:06 pm, Simon King wrote:
> On 2013-02-27, mmarco wrote:
>
> > Isn't the result supposed to be over the rationals? Or am i missing
> > something?
>
> And:
>
> sage: S.category()
> Category of sets
The __init__ is not calling super().__init__ (or whatever the
appropriate spelling
On Mar 1, 6:17 am, Jan Groenewald wrote:
> This problem is inside the ECL call (maxima_ecal) in maxima_lib.py. I tried
> not sending the stdout to dev null, and in the same place setting
> debugmode=true, but then got dropped in a shell whose syntax I don't know
> at all.
That's the ECL debugger
On Mar 6, 10:05 am, Ivan Andrus wrote:
> Would it be possible to print the warning only if the session is interactive.
> Then you wouldn't have to change doctests and wouldn't have to see the
> warning when running scripts.
Any time you change the behaviour between interactive and non-
interac
On Mar 12, 5:23 am, Jan Groenewald wrote:
> Hi
>
> Is this the intended behaviour, for A==B to say False instead of returning
> the expression?
>
> sage: A=matrix([(x+1)*(x-1)]); B=matrix([x^2-1]);
> sage: A==B
> *False*
> sage: A.simplify_rational()==B
> *True*
What surprises me is that equality
On Mar 17, 10:29 am, Volker Braun wrote:
> On the contrary, the error message that you get right now is 100% spot on.
It does show that cached_function changes the interface behaviour,
though, which is a little less than desirable:
sage: @cached_function
: def t(a):
: if not isin
On Mar 19, 9:51 am, Nathann Cohen wrote:
> And I hate cached
> functions and UniqueRepresentation (for instance in Posets) because it
> means that some algorithms that do not require any big memory
> (1) create one poset
> (2) test something
> (3) forget about it
> (repeat many many times)) can ta
On Mar 19, 9:10 pm, Robert Bradshaw
wrote:
> Sounds good. What if we called this foo.uncached(args) instead (which
> is more verbose but much clearer, and tab completion shouldn't make
> that too bad...) I could make cached methods work as well.
Do we actually have a use-case?
--
You received t
On Mar 20, 7:18 am, leif wrote:
> And calling foo.f() will break if someone decides to no longer cache the
> function or method, or to rename the attribute.
[...]
> my_foo=get_uncached_function(foo)
I've seen that last argument before and I don't quite understand why
introducing a function m
I will soon be giving an informal talk where I need to play some
custom synthesized sounds. I ended up using pyalsaaudio (http://
sourceforge.net/projects/pyalsaaudio/files/) to play sounds, which
obviously only has a desirable effect if you're running your notebook
locally. The standard "ossaudiod
On Mar 21, 9:05 am, Benjamin Jones wrote:
> It seems to me that the ambiguity arises from the original statement,
Systems like magma (and I assume gap as well) solve this by having a
"GSet" type. If you have S3 acting on the GSet V={1,2,3} then, one can
construct the powerset W of V as a GSet as
On Mar 20, 10:01 am, leif wrote:
> Abstraction. Although it's (currently) not foo._f nor foo.__f, I
> wouldn't say f is part of a cached function's public interface, but
> rather an implementation detail.
Fair enough. So why not make "foo.f" part of the public interface?
Python properties (and t
On Mar 5, 11:34 am, Andrey Novoseltsev wrote:
> Hello,
>
> debug() in a new cell after 1/0 does not work for me with "IndexError:
> string index out of range" message. This is using Sage 5.7 or
> 5.8.beta2, while 5.5 shows the interact William has added a while ago.
> Is this a regression (due to
http://trac.sagemath.org/sage_trac/ticket/14338 ready for review
--
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 t
It seems to be that the lines in inspect.findsource were introduced by
this change:
http://hg.python.org/cpython/rev/527c40add91d/
I'm pretty sure this is something that needs to be fixed in python, so
it's now
http://bugs.python.org/issue17526
--
You received this message because you are subs
On Mar 26, 10:04 am, "Nicolas M. Thiery"
wrote:
> It's more geared toward sets endowed with an action of a semigroup,
> but the category part should scale to groups.
+1. I'm pretty sure that whatever the user interface is going to be,
something along these lines will have to go underneath to buil
We can reach inside IPython and put another formatter in place for
"type" and "classobj" objects:
sage: type(1)
sage.rings.integer.Integer
sage: import IPython
sage: self=sys.displayhook.shell.display_formatter.formatters[u'text/
plain']
sage: T=[k for k,v in self.type_printers.items() if v is
IPy
On Mar 29, 8:10 pm, Jeroen Demeyer wrote:
> This could be related to http://trac.sagemath.org/sage_trac/ticket/13447
The "Exception KeyError: (The ring pointer -0x1f5282c,) in
'sage.libs.singular.ring.singular_ring_delete' ignored" messages
almost certainly are.
--
You received this message bec
On Mar 30, 10:14 am, Eric Gourgoulhon wrote:
> Hello,
>
> I've noticed this strange behavior (bug ?) on the following elementary
> computation:
>
> sage: a = matrix([[sqrt(x),0,0,0], [0, 1, 0, 0], [0, 0, 1, 0], [0, 0, 0,
> 1]])
> sage: det(a)
> ...
> TypeError: no conversion of this rational to i
I guess someone should fix this at some point:
http://trac.sagemath.org/sage_trac/ticket/14403
--
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
On #14214 we observed something that is a little disturbing:
- On a pure python class (inheriting from object), repeated attribute
lookup seems to be independent of MRO depth (i.e., it probably gets
cached somewhere).
- On a cython derived python class (i.e., "cdef class ...(object):
pass") th
Yay! with a little digging around I think I know what feature cython-
derived classes are missing that pure python classes do have: It's the
Py_TPFLAGS_VALID_VERSION_TAG feature, which gets used in the "method"
cache. in _PyType_Lookup (python source: typeobject.c)
Evidence obtained with the follo
Is this a bug?
$ mkdir a
$ ln -s a b
$ touch b/t
$ ls a
t
What touch b/t did was open b for writing to put a link to the freshly
allocated file underlying t. The fact that opening a symbolic link
means opening the thing to which the link is pointing is essential to
the nature of symbolic links. N
Good news! The change for including the Py_TPFLAGS_HAVE_VERSION_TAG
for cython types by default is trivial and will likely make it into
cython 0.19. See:
https://groups.google.com/group/cython-users/browse_thread/thread/5110f344ea2e6e86?hl=en
To see what kind of effect we can expect in sage I che
Sometimes one ends up with implementing really small access routines,
just to do a lookup for something. In cython you might even want to do
that with some "cdef" methods. For general accessibility, you might
consider slapping a "cpdef" on rather than a "cdef". That may come at
a serious price, bec
On Apr 9, 1:18 pm, Tom Boothby wrote:
> This shouldn't really come as a surprise. From the Cython documentation,
>
> "This is about 20 times slower, but still about 10 times faster than
> the original Python-only integration code. This shows how large the
> speed-ups can easily be when whole loop
501 - 600 of 1748 matches
Mail list logo
