I noticed a failed doctest report by a patchbot:
http://patchbot.sagemath.org/log/15432/Ubuntu/12.10/x86_64/3.5.0-17-generic/pi/2013-11-17%2018:44:09%20-0800
which I could reproduce on my own computer with 5.13b2 by pulling the
branch and doing sage -b.
However, after issuing `make` the doctest
I think the patchbot may have some trouble with patches correcting
whitespace. On:
http://trac.sagemath.org/ticket/15367
the patchbot complained (correctly) about whitespace. I'm pretty sure I
corrected it with the latest commit, but the last run of the patchbot
(triggered by the commit) repor
On Monday, November 18, 2013 2:54:16 PM UTC-8, Nils Bruin wrote:
>
> I think the patchbot may have some trouble with patches correcting
> whitespace.
>
Actually, looking at the output of the whitespace plugin, I noticed the
whitespace report is *per patch*, where a patch is extrac
On Tuesday, November 19, 2013 11:57:35 AM UTC-8, mmarco wrote:
>
> I didn't add any dictionary on my code. Maybe it is a problem with using
> an auxiliar polynomial ring as an atribute?
>
In any situation where the hash depends on `__repr__` and `__repr__`
requires attributes that are set only
On Tuesday, November 19, 2013 6:54:10 AM UTC-8, mmarco wrote:
>
> I added a few methods and atributes to the Laurent polynomial ring
> classes, but didn't change the structure of the way they are constructed,
> so i don't understand why, at unpickling, the ._n atribute disappears now.
>
See http
On Tuesday, November 19, 2013 5:50:01 PM UTC-8, Volker Braun wrote:
>
> Also, it is perfectly legal to feed values that are not constant across
> sessions into the hash. E.g. id(self.parent()).
>
That by itself wouldn't make it invalid to cache and pickle hash values. It
would just mean the has
On Tuesday, November 19, 2013 7:05:02 PM UTC-8, Volker Braun wrote:
> Creating an object with the wrong hash is invalid in my book. Once you
> start comparing it with an object that was just created (not unpickled)
> you'll run into problems.
>
Hm, just to be explicit about it, because it's som
On Friday, November 22, 2013 7:52:12 AM UTC-8, William wrote:
> Is the pickling issue a bug in Sage?
>
I'd say so. It's a subtle one:
loads(dumps(cremona_curves(37).next().gens(descent_second_limit=10)))
tends to work but loading the saved pickle from a file does not. Executing
V=loads(dumps(
On Saturday, November 23, 2013 6:07:58 AM UTC-8, Nathann Cohen wrote:
>
> Hmm... A 'tried' list. It seems the easiest to implement indeed. I
> think that this is what I will end up implementing, but I still wish
> there was an easier way .. :-/
>
It's not the easiest to document, though. I
On Saturday, November 23, 2013 9:28:26 AM UTC-8, Nathann Cohen wrote:
>
> Hell !!
>
> > It's not the easiest to document, though.
>
> Really ? I was thinking of :
>
> - ``tried`` -- Internal use. Keep your fingers off.
>
Well, whether that's sufficient is between you and the reviewer
On Saturday, November 23, 2013 10:56:10 AM UTC-8, Nathann Cohen wrote:
> Well, splitting sounds nice indeed but what exactly do you point at ? You
> can't swear that a TD will be built without ever requiring a MOLS to be
> built at some recursion step.
>
Right. In your steps 3), probably your
On Thursday, December 5, 2013 11:00:07 AM UTC-8, kcrisman wrote:
>
> I'm not a pickling or memory leak expert, but some of you are. Earn some
> Stackoverflow rep.
>
>
> http://stackoverflow.com/questions/20294628/using-pythons-pickle-in-sage-results-in-high-memory-usage
>
Possible answer:
On Thursday, December 5, 2013 7:43:47 PM UTC-8, Robert Campbell wrote:
>
> Nathann,
> A simple recursively defined pure Python generator for the binary reverse
> Gray code
> is below. The elements of the code are represented as lists whose elements
> are 0s
> and 1s.
>
>
It will be very hard t
On Friday, December 6, 2013 7:51:35 AM UTC-8, kcrisman wrote:
>
> Just for the record, this wasn't my question :) but hopefully the user
> accepts it, thanks for this (which in retrospect I should have diagnosed as
> well, as I have used load/save but thought they were the same as the
> "usua
On Friday, December 6, 2013 6:52:26 AM UTC-8, Tom wrote:
>
> Well too darned bad, 'cause I'm gonna share the magic formula I just
> found anyway:
>
> [((i&-i)-1).popcount() for i in srange(1,2^n)]
>
> from http://aggregate.org/MAGIC/
>
Hm, I can imagine that counting ones may not be the faste
On Friday, December 6, 2013 6:39:53 AM UTC-8, Tom wrote:
>
> (i.valuation(2) for i in srange(1,2^n))
>
> does the job -- though this can certainly be implemented better.
>
Yes, I think in sage it should be spelled
(i.trailing_zero_bits() for i in srange(1,2^n))
The GMP implementation that is u
On Sunday, December 15, 2013 2:48:21 PM UTC-8, Volker Braun wrote:
>
> This is from http://trac.sagemath.org/15517, ecm doesn't find a factor.
> But there is one with 17 digits, so should be just fine? Does anybody have
> a suggestion on what to do if ecm quits without finding a factor? When is
On Sunday, December 15, 2013 3:16:48 PM UTC-8, Volker Braun wrote:
>
> I know that ECM is probabilistic, the question is: what is the
> probability? Maybe there is a choice of parameters where the probability is
> better than about 10^(-4), because that happens fairly quickly if you run
> it in
On Tuesday, December 17, 2013 12:43:54 PM UTC-8, Michael Orlitzky wrote:
>
> It's the same as starting a new ticket/branch. When you get to the point
> where you would modify the sage library, download the mercurial patch
> and apply it.
This step, including the committing in git, can be don
On Thursday, August 15, 2013 1:16:19 AM UTC-7, Jeroen Demeyer wrote:
>
> On 08/15/2013 04:38 AM, kcrisman wrote:
> > In the past, Trac somehow "knew" (presumably someone did this behind the
> > scenes) to move open tickets from Sage-5.x to Sage-5.(x+1) etc.
> >
> > With the new Trac, Jeroen (
On Wednesday, December 18, 2013 9:58:15 AM UTC-8, vdelecroix wrote:
>
> Users of polynomials should worry about the coefficient ring. What do
> someone should expect of
>
> sage: (6*x^2 - 12).factor()
>
> The answers are different in ZZ[x], QQ[x] and RR[x]. For a symbolic
> polynomial there
On Wednesday, December 18, 2013 11:04:22 PM UTC-10, maldun wrote:
>
> What I mean is that we should only allow expressions of meromorphic
> functions in the symbolic field, i.e. we would only allow variables,
> trigonometric functions and so on.
> SR should be then a superset where everything els
On Friday, December 20, 2013 2:58:51 AM UTC-10, maldun wrote:
>
> Another more careful approach would be to start at the field of rational
> functions and extend it step by step with algebraic and transcendental
> functions, till we reach a field which is maximal under the available
> symbolic e
I'm finding that "sandpiles.py" often fails for me for varous reasons while
doing `make ptest`. Testing the file individually or via `sage -tp
src/sage/sandpiles` (i.e., just the relevant directory) seems fine.
The errors I have received up to now are "Timed out (2 times)"
---
File "src/sage/sa
On Friday, December 27, 2013 10:16:06 AM UTC-8, Nils Bruin wrote:
>
> I'm finding that "sandpiles.py" often fails for me for varous reasons
> while doing `make ptest`. Testing the file individually or via `sage -tp
> src/sage/sandpiles` (i.e., just the relevant directo
On Saturday, December 28, 2013 6:43:49 PM UTC-8, Volker Braun wrote:
>
> I can't reproduce it on my ssd, but might be timing related. Can you
> trigger it when you run as
>
> strace -s 1024 -ff -o tmpdir/log sage -tp2 tt*.py
>
> If there is a temp file conflict then we can figure it out from the
On Sunday, December 29, 2013 1:30:33 AM UTC-8, Nils Bruin wrote:
> The strace log directory sits in:
>
> http://sage.math.washington.edu/home/nbruin/strace.tgz
>
More specifically, I think the python process experiencing the error is
31307 and the singular process it is communica
On Sunday, December 29, 2013 11:08:53 AM UTC-8, Nils Bruin wrote:
>
> I don't see why 31307 and 31305 decide to do different things.
>
In fact, it may be the following: Singular at some point does this write:
read(0, "print(sage698);\n", 1024) = 16
OK, I think the following clearly indicates the sync problem we're running
into. This is a tiny example of a program that prompt for input and then
returns (fixed) output.
$cat hiho.c
#include
#include
int main(int argc, char** argv) {
char *line[1000];
size_t len = 0;
ssize_t readl
On Sunday, December 29, 2013 10:50:31 PM UTC-8, Volker Braun wrote:
>
> This is similar to http://trac.sagemath.org/15440, the problem boils down
> to: The expect pattern must(!) trigger at a place where all input has been
> eaten. Including newline/spaces. If not then there is still input coming
On Monday, December 30, 2013 9:09:38 AM UTC-8, Volker Braun wrote:
>
> That is exactly what I am talking about: The pexpect pattern must match at
> a point where the subprocess has stopped processing and is just waiting for
> further input. But if you match for a prompt, say, and then the subproc
On Monday, December 30, 2013 12:35:37 PM UTC-8, R. Andrew Ohana wrote:
> Moreover, I don't think we have to force the switch, it should be
> perfectly possible to support both python 2 and python 3 for a period of
> time.
>
What's the benefit of that? The sage process itself will be running on
On Tuesday, December 31, 2013 8:23:35 PM UTC-8, Volker Braun wrote:
>
> I also agree that it would be much better if the pexpect interfaces would
> have been written against non-echoing tty. Of course that'll only work if
> the subprocess doesn't turn echoing back on. The downside is of course th
On Wednesday, January 1, 2014 3:32:05 PM UTC-8, Simon King wrote:
>
> A conversion map is (by definition) a partial map, that in some cases
> happens to be an actual map (not just partial), in other cases happens
> to even be a morphism, and in the best case is a coerce map.
>
Given how few pr
On Wednesday, January 1, 2014 4:17:28 PM UTC-8, Peter Bruin wrote:
>
> I would like to add that in my opinion the first line of this example,
>
> sage: f = GF(11).convert_map_from(GF(7))
>
> should not be assumed to work at all, and it would be preferable to raise
> an error rather than returning
On Thursday, January 2, 2014 2:42:13 AM UTC-8, Peter Bruin wrote:
>
> Except that currently (if A is the codomain) A.__call__() looks for a
> conversion and calls it, where the default conversion consists of calling
> A._element_constructor_(), so just letting the conversion f be the callable
>
On Thursday, January 2, 2014 8:55:37 AM UTC-8, John Cremona wrote:
> If someone could point me to a place which explains how to install and
> use ccache, that would be helpful, since I may not get away with using
> MAKE='make -j 60' for ever (and even then it takes a couple of minutes
> to swit
On Thursday, January 2, 2014 9:29:59 AM UTC-8, John Cremona wrote:
>
> Thanks -- just installed it. But surely I have to do something to get
> Sage to use it?
>
> Not necessarily. If you're using the system gcc then installing ccache on
your system probably also takes care of putting the approp
On Thursday, January 2, 2014 10:39:13 AM UTC-8, Robert Bradshaw wrote:
>
> So I would propose that every *commit* that goes into Sage needs to be
> positively reviewed.
In which case we'd want a lot more history discarding/rewriting to happen
before a commit gets positive review. Wouldn't we b
On Saturday, January 4, 2014 11:29:33 AM UTC-8, vdelecroix wrote:
>
> I do not see how we can make the coercion numpy int/Sage Integer works
> if numpy is not loaded at startup time...
It seems more an issue of *ensuring* that coercion does *not* work, because
we're communicating with a non-sage
It's an odd confluence of circumstances that makes numpy.float64 behave
this way. The code that causes the problem is this:
sage/structure/coerce.pyx:965 (cpdef canonical_coercion)
elif y_numeric:
try:
sage_parent = py_scalar_parent(type(y))
if
On Monday, January 6, 2014 12:46:19 PM UTC-8, Zimmermann Paul wrote:
> What about getting rid of real literals?
>
I think they exist mainly to let
RealField(200)(1e-20)
work in the first place: The parser needs to generate code to instantiate
the constant 1e-20 somewhere and that constant sho
On Friday, January 10, 2014 2:02:52 AM UTC-8, Stefan wrote:
> On a git ticket, click on the name of the branch (which should be green if
>> it applies cleanly) and you'll get a diff of the changes that would occur
>> if the ticket were merged into the current development branch. This view
>>
On Saturday, January 11, 2014 6:26:59 AM UTC-8, Volker Braun wrote:
> Would it be possible to move real literals to their own parent? Arithmetic
> operations with other parents should always cast the literal to the other
> parent first, and arithmetic operations within the real literals would en
On Monday, January 13, 2014 4:32:10 PM UTC-8, Gregory Bard wrote:
>
> Hi everyone. I might be confused but I think I've found something not
> quite right.
>
> The following code:
>
> ###
> a(x) = x^2 - 5*x + 6
> b(x) = x^2 - 8*x + 15
>
For polynomial arithmetic, you're
On Friday, January 17, 2014 7:14:58 AM UTC-8, Nathann Cohen wrote:
>
> Well, that's what would happen if 2.0 was the latest version able to
> open those pickles, and that the guy never updated his version of Sage
> until today.
That's not how bitrot tends to work. The more likely scenario is th
On Sunday, January 12, 2014 11:01:50 PM UTC-8, Anne Schilling wrote:
>
> I agree with Travis that we should just remove the jar, given that the old
> k-Schurs were deprecated for over a year!
>
The period of deprecation is actually irrelevant for whether a pickle
should be unpickleable. The rele
Oh boy, the pickle as it is is always going to be horribly broken anyway:
si4 = unpickle_newobj(pg_Partition_class, ())
unpickle_build(si4, {'_hash':11648069979105038r, '_list':[]})
It looks like it's putting a cache dictionary on the Partition_class object
that has a hash value in it! That mean
On Sunday, January 19, 2014 1:37:07 AM UTC-8, Bernhard Spinnler wrote:
>
> It's a pity that there doesn't seem to be an easy fix for this.
There is, as diagnosed above. It's just so trivial that the administrative
burden of applying it to sage becomes significant by comparison, and
dealing with
On Sunday, January 19, 2014 9:58:08 AM UTC-8, Nils Bruin wrote:
>
> There is, as diagnosed above. It's just so trivial that the administrative
> burden of applying it to sage becomes significant by comparison, and
> dealing with admin is never attractive. There is now
>
Oops
On Saturday, January 18, 2014 7:46:07 PM UTC-8, ref...@uncg.edu wrote:
>
> Before I begin, I'd like to thank you in advance for any help you may give.
>
> I'm trying to learn cython, and I'd like to use the RealNumber class. I'd
> like to take a RealNumber as input, and compute the square of the
On Wednesday, January 22, 2014 3:49:01 AM UTC-8, Ralf Stephan wrote:
>
> While the ring type hierarchy does not reflect that polynomials are power
> series, you can have a power series without bigoh which is pratically a
> polynomial but, being a power series, has much less member functions
> av
On Tuesday, January 21, 2014 1:47:47 PM UTC-8, Simon King wrote:
>
> I don't understand what is the problem with the Python class. Please
> enlighten me!
>
I don't either, but I'll share some of my observations from the traceback.
The libsingular init calls as a first thing
MPolynomialRing_gene
On Wednesday, January 22, 2014 12:32:44 PM UTC-8, Nils Bruin wrote:
>
> It would be good to identify why this isn't giving problems on a cdef
> class. The code that triggers the problem sits in
> sage.categories.algebras.Algebras.ParentMethods.__init_extra__ so the ease
>
On Wednesday, January 22, 2014 8:43:36 PM UTC-8, Nils Bruin wrote:
>
>
> It surprises me that the MPolynomialRing_generic instance does have an
> __init_extra__ attribute. Where does that come from? does it get supplied
> by some custom get somewhere?
On Wednesday, January 22, 2014 11:10:24 PM UTC-8, Nils Bruin wrote:
>
> sage.structure.parent.Parent.__getattr__ claims to look on Parent and on
> self._category.parent_class for attributes.
>
Moreover, it makes me wonder why we even bother with dynamic classes:
sage: [C.__getattri
On Thursday, January 23, 2014 2:25:36 AM UTC-8, Simon King wrote:
> And that's a general problem:
> - I suppose generally one wishes to call __init__ of the base classes
> quite soon in a class' own __init__, so that useful attributes are
> correctly initialised.
> - However, we want that
Hi all,
In http://trac.sagemath.org/ticket/15104, I am finding that by far the most
expensive part of taking the transpose of a (non-square) matrix is getting
your hands on the parent (at least for matrices over (smallish) finite
fields) It would be nice if we can speed this up:
As an example,
On Tuesday, February 4, 2014 9:47:49 AM UTC-8, Simon King wrote:
> Do I understand correctly that #15104 is where you *found* the problem,
> while *fixing* it will be somewhere else? If you open a new ticket, please
> put me on Cc. I am sure the creation of transposed matrices can be
> accelera
On Thursday, February 6, 2014 8:56:09 AM UTC-8, William wrote:
>
> When we do eventually switch to Python 3, I want to modify the preparse to
> allow
> use of print as statement still
That may be challenging. How should the following be parsed (and which are
syntax errors)?
print (1,2,3)
On Friday, February 14, 2014 7:57:09 AM UTC-8, Jan Groenewald wrote:
> Also Octave, Scilab, or Freemat as various levels of free/Free
> alternatives in differing ways compatible with Matlab. Octave is in Sage.
>
It is, but the sage-octave interface has a slight problem on exit:
sage: octave(1)
On Friday, March 7, 2014 8:33:50 AM UTC-8, Nicolas M. Thiéry wrote:
>
> - R in FiniteSets():
> Does Sage already know that R is a finite set?
>
> - R.is_finite():
> Is R finite? Answering may require a lengthy calculation; A
> NotImplementedError would be a valid "answer".
>
Shouldn't
On Wednesday, March 12, 2014 6:41:07 AM UTC-7, Eric Gourgoulhon wrote:
>
> The issue here is that CommutativeRing.__init__ requires the argument
> "base_ring" and in the present context, I don't know what to put here: the
> ring C^oo(N) does not depend upon any other ring. Shall I put self, i.e.
On Thursday, March 13, 2014 9:38:35 PM UTC-7, Robert Bradshaw wrote:
>
> This isn't about
> correctness or performance or sufficient testing, it's a question of
> aesthetics, right?
There are performance issues actually, but probably ones that can be dealt
with as long as we make sure that the
On Sunday, March 9, 2014 8:09:58 AM UTC-7, n...@vorpus.org wrote:
>
> Greetings, Sage Ones,
>
> Some of you may have already seen this, but I've started working on a
> draft PEP for adding a dedicated operator for matrix multiplication to
> Python
>
I've seen many examples of complicated matrix
k.maximal_order()
sage: R=O.quo(35,names="rr")
sage: R.is_finite()
NotImplementedError
sage: R.characteristic()
NotImplementedError
Cheers,
Nils
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop rec
On Tuesday, April 1, 2014 7:27:26 AM UTC-7, Ben Hutz wrote:
>
> Actually, it seems that _coerce_map_from works just fine allowing you to
> send an integer into the power series ring. What is broken is recognizing
> that the powerseries element is an integer even though T(1)==1 returns true.
>
Tha
On Saturday, April 5, 2014 7:41:47 PM UTC-7, Andrew Juell wrote:
>
> Running sage locally under Ubuntu to avoid any esoteric problems in the
> cloud, I discovered another issue...while I could iterate over Posets(7)
> and (8) and count their linear extensions with little trouble, attempting
> to
The following paradigm happens for
"sage.combinat.posets.posets.FinitePoset" and their "linear_extensions",
but it's such an easy mistake to make that I'd almost consider it a flaw in
our design:
class A(Parent,UniqueRepresentation):
@cached_method
def BfromA(self):
ret
On Sunday, April 6, 2014 12:23:56 PM UTC-7, Nathann Cohen wrote:
>
> > As you can see for n=6, all the 318
> sage.graphs.linearextensions.LinearExtensions instances are still in
> memory. I suspect it's something like this:
> > - The "linear_extension" method is cached. This means that the pose
On Sunday, April 6, 2014 1:35:17 PM UTC-7, Nathann Cohen wrote:
>
> No, I meant... Can't we add some parameter to cached_method, so that
> it could not be applied to an object which inherits from
> UniqueRepresentation (if this is the problem) ?
>
> something like
>
> def cached_method(self, fu
It came up on sage-support that some element constructor documentation is
rather hard to find:
https://groups.google.com/forum/#!topic/sage-support/FIqaVz1tgyk
and since solving this issue is a development problem, I'm reposting here.
In short, given
R.=QQ[]
how to find that R([1,2,3]) create
On Thursday, April 10, 2014 9:38:36 AM UTC-7, Ben Hutz wrote:
>
> Well I'm getting closer. When loads is called on a list containing 2
> (distinct) points the first loads does fine, the second point __setstate__
> is called with just the dict instead of (parent,dict). If it is say, 2
> distinct
On Wednesday, April 23, 2014 3:15:25 PM UTC-7, Volker Braun wrote:
>
> Also, I think that caches should age out eventually. This would also
> mitigate a lot of possible memleaks. Downside is of course that you might
> have to recompute intermediate results, but that is still better than being
>
On Saturday, April 26, 2014 3:22:30 AM UTC-7, Volker Braun wrote:
> And @cached_method returning a UniqueRepresentation is never good, its at
> best double caching (even if the memory leak were fixed elsewhere).
>
That is not true in the full generality in which you state it. For instance
on a
On Sunday, April 27, 2014 3:32:46 PM UTC-7, Dima Pasechnik wrote:
>
> In the first case one gets a transitive group on 8 points, and in the
> second case on 4 points.
>
> Is this a bug?
>
The really (only?) useful answer is to get the Galois group as a
permutation group on the roots of the ori
On Wednesday, April 30, 2014 2:13:20 AM UTC-7, Jean-Pierre Flori wrote:
> Good question...
> We had a look around last week to gather info about what other libs do and
> IIRC, at least for flint, what happens is that start at top degree monomial
> you substract the largest multiple of the modulu
On Wednesday, April 30, 2014 1:07:55 AM UTC-7, John Cremona wrote:
> NO! If f1 and f2 define the same extension field then will
> not be prime, e.g. f1=x^2-2 and f2=x^2-8 over QQ.
>
you probably mean f1=x^2-2 and f2=y^2-8 in QQ[x,y] . =<1> is
also not prime but that doesn't have much to do
On Friday, May 9, 2014 12:35:30 PM UTC-7, jason wrote:
Mike Hansen and I had a conversation about this at one point, and I
> think we concluded that instead of looking at the base ring in the case
> of SR, we should instead look at the specific matrix and decide if it
> was "exact" or an approx
On Tuesday, May 13, 2014 11:27:02 AM UTC-7, kro...@uni-math.gwdg.de wrote:
>
> 1. Does sage provide a concept for user-configurable (separately for each
> package or other context) optional (parameter) testing like in GAP
> or Singular? Purpose: debugging/bug hunting.
>
If you're interested in
On Wednesday, May 14, 2014 3:54:36 AM UTC-7, Nathann Cohen wrote:
>
> I have a function named "a" which takes an integer as input. Unfortunately
> when 'n' is a prime power, a(n) returns a very large matrix (but quick to
> compute). Thus, I would love to cache only the answers of a(n) when n is
On Thursday, May 15, 2014 12:11:31 AM UTC-7, Nathann Cohen wrote:
>
> I would accept the argument of "speed issue", but of course you cannot use
> that one AND defend the "key" parameter, which has an easier workaround
> than my problem here and a higher cost. So it is both or none, see ? :-P
>
c_code.co_filename (which of course belongs to the
wrapper, not the wrapped object). It seems to me that we should have an
obj._sage_src_file_ to accompany the obj._sage_src_lines_ protocol , or
extend the tuple returned by obj._sage_src_lines_ to also include the file
name (as a third entry
On Friday, May 16, 2014 2:02:41 PM UTC-7, Nils Bruin wrote:
>
> sage: sage_getsource(hyperbolic_triangle) in
> open(sage_getfile(hyperbolic_triangle),'r').read()
> False
>
This is now http://trac.sagemath.org/ticket/16363 with a preliminary
solution.
In the proces
On Tuesday, May 20, 2014 1:10:05 PM UTC-7, Nils Bruin wrote:
>
> This is now http://trac.sagemath.org/ticket/16363 with a preliminary
> solution.
>
Sorry, that should be http://trac.sagemath.org/ticket/16382 . Needs review
(and some trivial doctest fixes).
--
You received
Hi Simon!
On Sunday, May 25, 2014 5:15:08 AM UTC-7, Simon King wrote:
So, it is a tiny amount of memory (~25 byte per round), but I guess it
> should be fixed anyway.
>
I see a little more memory (~42 bytes). From such a small amount you can
already guess no python objects get leaked, and ind
On Wednesday, May 28, 2014 7:23:20 AM UTC-7, Volker Braun wrote:
>
> Non-underscore attributes implement a mutable interface.
>
I wasn't aware of that convention. Is it documented somewhere, with
rationale?
I've indeed seen "constant" instance attributes accessed via accessors and
was aware of t
On Wednesday, May 28, 2014 10:51:10 AM UTC-7, vdelecroix wrote:
> For me, it would makes sense on parents directly
> {{{
> sage: Permutations().known_maps_to(Partitions())
> [...]
> }}}
> And in the methods known_maps_to and known_maps_from there should be
> pointer on how to feed the databa
On Monday, June 9, 2014 1:44:41 PM UTC-7, Erik Massop wrote:
>
> On Mon, 09 Jun 2014 16:48:09 +0200
> leif > wrote:
>
> > Volker Braun wrote:
> > > On Monday, June 9, 2014 12:54:56 AM UTC+1, vdelecroix wrote:
> > >
> > > sage: {3, AA(3)}
> > > {3, 3}
> > >
> > >
> > > IMHO you shou
On Monday, June 9, 2014 2:19:32 PM UTC-7, William wrote:
> I wanted to understand what you just claimed, so in Magma [1] I typed
> this:
>
> 5 eq GF(7)!5
>
> but it output "true".So clearly I completely misunderstood your
> claim. Can you be more precise?
>
Sorry, you didn't misunde
On Monday, June 9, 2014 3:50:06 PM UTC-7, Volker Braun wrote:
>
> This seems like it would be a good solution in Sage, namely provide
> associative containers that participate in coercion and ensure that all
> elements have the same type. E.g.
>
> sage: s = SageSet([3, 8]); s # universe = ZZ
On Wednesday, June 11, 2014 10:15:23 AM UTC-7, leif wrote:
>
> > Not that bad if x != 1 throws an exception.
>
> Yep, I'd prefer such behaviour as well.
>
It isn't for explicit equality checks, but the wide use of @cachedmethod
means that many objects that are passed as arguments (so that's almo
On Thursday, June 12, 2014 12:48:37 AM UTC-7, Marc Mezzarobba wrote:
>
> Sure. But why not have
>
> sage: bool(sin(x)^2+cos(x)^2==1)
> True
>
> return False as well, and let the user test that
>
> (rhs-lhs).simplify_full() == 0
>
That would probably be even desirable if you want to make SR mo
On Thursday, June 12, 2014 7:05:12 PM UTC-7, Nils Bruin wrote:
>
> And since the arguments get processed already in order to get hashed, it
> would probably be quite doable to process them such that SageElement
> instances get replaced by (elt.parent(), elt), or perhaps better: i
On Wednesday, June 18, 2014 2:37:21 AM UTC-4, Gregory Bard wrote:
>
> This has been brought up many times before, but I'd like to bring up
> the possibility of adding two commands to Sage: cuberoot(x) and
> nthroot(x, n)
>
+1 for nthroot. Once we have that, I don't think we need cuberoot. The
func
On Thursday, June 19, 2014 2:38:11 AM UTC-4, vdelecroix wrote:
>
> Note that there is already a method "nth_root" on several elements
> (ZZ, finite fields, etc). So I would rather go for "real_nth_root"
> which makes things clearer.
>
Perhaps we can then just get away with a "nth_root" symbolic
On Friday, June 13, 2014 6:28:17 PM UTC-4, Bruno Grenet wrote:
>
> Dear all,
>
> I am new to Sage development and I'd like some help or advice for the
> following task:
>
> There is right now no specific algorithm for computing roots of Sparse
> Polynomials in Sage. Such algorithms exist, at lea
On Saturday, June 21, 2014 9:06:39 PM UTC-7, 张秦川 wrote:
>
> I use Sage 6.1.1 which I build from source code on my x86 Ubuntu14.04
>
The x86 is the key here. The flint announcement mentions that this bug only
affects 64 bit platforms.
--
You received this message because you are subscribed to
On Tuesday, July 1, 2014 9:21:09 AM UTC-7, Sébastien Labbé wrote:
> Now (since at least one year, but I don't know which version exactly), tmp
> files are created with some hashed value in the end and the left and right
> arrow do not correspond to the order of creation of the files anymore. Two
On Tuesday, July 1, 2014 3:42:15 PM UTC-7, Sébastien Labbé wrote:
>
>
>>
>> If you're creating filenames via a predictable pattern, you're
>> vulnerable to a denial of service, since an adversary might try and predict
>> which file you're going to try and create next and do that before you.
>>
701 - 800 of 1748 matches
Mail list logo
