Simon King wrote:
> That makes sense to me.
> Thus I now think, z.is_prime() should roughly work like this:
> def is_prime(self):
> ...
What about keeping the is_prime() *method* unchanged (except perhaps for
adding an optional warning in the default implementation for field
elements), and r
Dima Pasechnik wrote:
> is_prime() should be restricted to rings in which one can have
> non-trivial prime elements
Well, that's what I'm doubting. If the goal is that the global
is_prime() function doesn't do anything surprising for people who would
have integers in mind, then it may be better
Simon King wrote:
> The reason he gave: In Mathematica, matrices can be defined with a
> graphical tool. Hence, one can input some entries, use arrow keys to
> switch from entry to entry, and can insert (and delete?) rows or
> columns on the fly.
>
> I think it would be nice for SageMath to have s
Thierry wrote:
> sudo iptables -A OUTPUT -j ACCEPT -o lo
> sudo iptables -A OUTPUT -j ACCEPT -o 127.0.0.1
> sudo iptables -A OUTPUT -j DROP
>
> But i guess this is not what you want.
I don't know the details, but it looks like nowadays there
are ways to do something a little more fine-grained:
Matthias Koeppe wrote:
> This is discussed in https://trac.sagemath.org/ticket/16993
...and https://trac.sagemath.org/ticket/16268 (needs review!).
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
John Cremona wrote:
> This is simpler than writing numerator and denominator as a rational
> times a primitive integral polynomial, though that is probably what
> users would prefer.
And (at least in my limited experience), for rational fractions over
general fraction fields (things like ℚ(x)(y),
Vincent Delecroix wrote:
> That does not prevent us to normalize for let say: __repr__() ,
> numerator(), denominator(). Is there any reasonable rule to choose
> when to and when not to normalize? For QQ itself, GMP does normalize
> all the time.
Just to be certain that we are talking about the sa
Travis Scrimshaw wrote:
> In terms of surprise, the fast == is clearly worse,
It is not that clear to me! (What I think I'd expect if I didn't know
Sage would be for == to compare the representation of the objects, not
their mathematical semantics, even when that semantics is unambiguous.)
--
Kwankyu Lee wrote:
> I guess, one principle in Sage is to use the full name unless an
> abbreviated form is already firmly rooted in our culture
I consider ceil() about as standard as, say, acos()...
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-de
John Cremona wrote:
> I hope it is not being suggested that we have to add tangent() as an
> alias to tan(), logoarithm() as an alias to log(), etc etc etc
I made the comparison with acos() because ceil() clearly is the usual
notation for me (I didn't know of any language or library calling it
c
Travis Scrimshaw wrote:
> A casual user will almost certainly do
>
> 1 / x^k
>
> and then try to do a method on Laurent polynomials (say, iterate over
> such element). The rational functions code does not have many of the
> methods and features that Laurent polynomials have.
Yes, but is that rea
Travis Scrimshaw wrote:
>> I agree that having x^-1 and 1/x being different is confusing. I will
>> update the branch at #25524 to make them identically return a
>> rational fraction.
>
> I think this is even worse than the confusion.
I agree with that.
>> Though, close to what Nils talked about
Hello everyone,
Please allow me to advertise a couple of tickets currently waiting to be
reviewed that deal with fraction field elements, and in particular
rational fractions in several variables:
https://trac.sagemath.org/ticket/25290
https://trac.sagemath.org/ticket/23909
https://trac.sagemat
Erik Bray wrote:
> Personally I'm hesitant to touch that just because I don't want to go
> deleting *anyone*'s branches that aren't my own.
FWIW, I've been deleting my old branches as well as some old public
branches I had worked on for years now, and I don't think anyone ever
complained.
--
M
Gabriel Frieden wrote:
> I'm trying to run sage from TeXmacs, and I followed the instructions
> here: https://wiki.sagemath.org/TeXmacs. When I click on Insert -->
> Session --> SAGE, I get the message "Busy..." where it should give the
> version information, above the input line with "Sage]." I ca
martin.vgag...@gmx.net wrote:
> Is there anything like this around already?
sage.structure.sequence provides something similar for lists (and is
indeed very useful), but I don't think it has a counterpart for
dictionaries.
--
Marc
--
You received this message because you are subscribed to th
Marc Mezzarobba wrote:
> sage.structure.sequence provides something similar for lists (and is
> indeed very useful), but I don't think it has a counterpart for
> dictionaries.
Oops, I read too fast: of course, the behaviour of sequences is
analogous to coercing the *values* to a
Thierry wrote:
>> parent(A) is parent(B)
>> but
>> type(A) is not type(B)
>
> Here is an example:
>
> sage: A = cos(x)
> sage: B = units.charge.coulomb
> sage: parent(A) is parent(B)
> True
> sage: type(A) is not type(B)
> True
More examples:
sage: parent(-infinity) is parent(infinity)
True
sag
Hi,
The following example from q_analogues.py happens to work for a number
of questionable reasons:
sage: q_binomial(6,1,I)
1 + I
I'm working on a patch that breaks (or fixes, depending how you look at
it) one of the behaviors it relies on, and I'd like advice on how to
handle the situati
Clemens Heuberger wrote:
> Are there other options? What are your recommendations?
Assuming the two modules are part of the same package, I would add a
separate REFERENCES section somewhere in the package and make both
docstrings point to that section.
--
Marc
--
You received this message be
Hi,
What is the recommended way to implement a parent that needs a fast
element constructor but otherwise can be expected not to be queried too
often once the coercion maps involving it are set up ? (I would like
MyParent(obj) to have as little overhead as possible, not just
coercions.)
I can
Volker Braun wrote:
> My advice would be to implement the parent in Python and benchnmark
> it. If you are doing something in _element_constructor_ that would
> benefit greatly by Cython then you can just move that part to Cython.
Apparently my question was unclear. Of course, it is good advice as
Jeroen Demeyer wrote:
> However, I wonder why you insist on using
> parent._element_constructor_(). You could for example have a fast
> ElementClass.__init__() or a fast non-method function
> construct_foo_element().
Yes, that's my question, more or less: for example, QQ is an instance of
a Pytho
Jeroen Demeyer wrote:
> You are missing something:
Indeed! Thanks for pointing it out. That was sloppy grepping of mine.
> * finite fields are Python
> (src/sage/rings/finite_rings/finite_field_*.py)
So in this case, apparently,
(i) the Python parent classes derive from an abstract Cython cla
Jeroen Demeyer wrote:
>> Element.__call__ calls it, it is a Cython call.
> There is no Element.__call__.
I meant Parent.__call__, sorry.
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving e
Jeroen Demeyer wrote:
> On 2015-02-11 18:18, Marc Mezzarobba wrote:
>> Jeroen Demeyer wrote:
>>>> Element.__call__ calls it, it is a Cython call.
>>> There is no Element.__call__.
>>
>> I meant Parent.__call__, sorry.
> If Parent is a Python object
Hi,
Here's what I get when trying to comment on #17194:
Oops…
Trac detected an internal error:
OSError: [Errno 2] No such file or directory: '/tmp/tmpfeh2TI'
There was an internal error in Trac. It is recommended that you notify
your local Trac administrator with the information needed to reprod
Volker Braun wrote:
> fixed, at least for now.
Thanks!
--
Marc
--
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
Jeroen Demeyer wrote:
> Sage shouldn't support Debian. Debian should support Sage.
On a perhaps related note, Sage used to be about "building the car",
didn't it¹? I find it ironic how hard sage makes it for other projects
to rely on it in the way it itself relies on tons of third-party
package
Eric Gourgoulhon wrote:
> It seems that callable symbolic expressions, as implemented in
> src/sage/symbolic/callable.py,
> are not included in the reference manual: there is no mention of
> sage/symbolic/callable in
> src/doc/en/reference/calculus/index.rst
> and they do not appear when asked for
Eric Gourgoulhon wrote:
> Then clearly the ticket #17876 is irrelevant.
Not necessarily: I have no idea when (or if) I will be able to finish
going through all missing modules, or even when I will have time to
bring the existing part to a state where it can be reviewed without
waiting for the r
Vincent Delecroix wrote:
> I already added sage/misc/sage_input.py in #17748 and Nathan added
> combinat/permutations_cython.pyx in #17848. So it is highly probable
> that your branch conflicts with the current and/or next beta
Yes, I noticed. No problem, your sphinx-ifications are probably much
Simon King wrote:
> I guess a single ticket whose purpose is to add and fix all
> documentation to the manual would be a nightmare to maintain. Wouldn't
> it be easier to have one ticket for each module that is missing in the
> documentation?
Yes, it would! And I'm not planning to submit it all in
Simon King wrote:
> According to the documentation, one is allowed to treat __richcmp__
> separate from __cmp__. Hence, it is legal to have separate behaviour
> for <,<= etc and for cmp(,).
>
> Is that possibility used in Sage somewhere?
Yes, see src/sage/rings/real_mpfi.pyx.
--
Marc
--
You r
Marc Mezzarobba wrote:
> There are *tons* of modules missing from the reference manual, some
> obsolete, some still in pre-sphinx style or with rst syntax errors,
> some whose user documentation in fact appears in another module, and
> many apparently just forgotten.
>
> A few w
Bruno Grenet wrote:
> My questions: Is my understanding correct? If not, what are supposed
> these arguments to be for? And if I understand correctly, is the
> behavior I mention a bug?
I'd say you are right, and the reason for the bug is that ETuple changed
after Polydict was written. Compare 5c
Francois Bissey wrote:
> Those are files generated by cython - they should be in .gitignore.
They were removed from .gitignore in #17918 because current version of
sage no longer put them in src/sage. You can delete them once and for
all with git clean, and they should not come back.
--
Marc
William Stein wrote:
> sage: a = RIF(1/5)
> sage: a == a
> False
> sage: a is a
> True
That's how interval arithmetic usually works! Quoting from the
documentation of real_mpfi:
| Comparison operations (``==``, ``!=``, ``<``, ``<=``, ``>``, ``>=``)
| return ``True`` if every value in the first i
Marc Mezzarobba wrote:
> There are *tons* of modules missing from the reference manual, some
> obsolete, some still in pre-sphinx style or with rst syntax errors,
> some whose user documentation in fact appears in another module, and
> many apparently just forgotten.
>
> A few w
Volker Braun wrote:
> Which of the big M's has multiple
> and subtly-different ways to determine the size of a container?
Maple. ;-)
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving email
The sage trac server has tons of years-old open tickets about
(i) the notebook;
(ii) interacts;
(iii) Solaris and AIX ports.
I suspect a number of them should be closed as duplicate/invalid/
wontfix; it would be nice if people with better knowledge of these areas
could have a look.
--
Ma
kcrisman wrote:
> Occasionally people do; I occasionally cull (i) or transfer
> them/report
> upstream to the github sagenb site, for instance. It's just that
> people have other things to work on; in that sense, "triage" is
> happening continuously.
Sure. I mentioned these specific areas because
Jeroen Demeyer wrote:
> src/sage/combinat/partitions_c.cc
partitions_c could probably be replaced by the implementation in arb if
people want to drop it. But having two implementations can be a good
thing too...
--
Marc
--
You received this message because you are subscribed to the Google Gr
Jeroen Demeyer wrote:
>> partitions_c could probably be replaced by the implementation in arb
>
> Why arb (which deals with floating point)?
Because arb has the best (fastest and most rigorous among the "fast"
ones) implementation as far as I know. As for why Fredrik put it in arb,
I guess that'
Currently, evaluating a polynomial ring element on a symbolic expression
returns a result in Horner form:
sage: pol = QQ['x'](range(10))
sage: pol(x)
9*x + 8)*x + 7)*x + 6)*x + 5)*x + 4)*x + 3)*x + 2)*x + 1)*x
This behavior is of course a side effect of the default generic
evaluation al
Jan Groenewald wrote:
> I a computer lab environment, with identical desktop images (PPA,
> Ubuntu 14.04, 64bit) all except one user can launch the notebook fine.
>
> For some reason, that user is importing the system-wide twisted and
> not the sage twisted.
A wild guess: does the user have .pth
Marc Mezzarobba wrote:
> Currently, evaluating a polynomial ring element on a symbolic
> expression returns a result in Horner form:
>
> sage: pol = QQ['x'](range(10))
> sage: pol(x)
> 9*x + 8)*x + 7)*x + 6)*x + 5)*x + 4)*x + 3)*x + 2)*x + 1)*x
http://tr
Jan Groenewald wrote:
> So, that should be fixed. Would you mind explaining to me what that
> was?
I don't know exactly, I only had a similar problem some time ago...
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from t
Vincent Delecroix wrote:
> The cache is in a custom field `__an_element` whose name will be
> changed in #14982 for `_cache_an_element` because in one case it has
> to be reset.
By the way, I would be really grateful if someone could review that
ticket, which aims at fixing a coercion issue that
Hi,
Fredrik Johansson's "Arb" library hasn't been an optional package for a
full year yet, but Volker already suggested fast-tracking it to standard
a while ago[1], and the (few) replies to his message were positive.
Doing it now would make the development of the sage bindings a bit
easier. Do
Vincent Delecroix wrote:
> As I already mentioned on tickets, the semantic of equality is a bit
> different for intervals and balls. This is annoying since they
> basically represent the same objects (=intervals with diadic bounds).
> This is my only objection for having it standard right now.
If
Jori Mäntysalo wrote:
> OK. I'll close this path, as it seems that my view belongs to
> minority.
I for one agree with you.
More precisely, I do find the sage source code easy to navigate, making
it easy to learn about Sage's capabilities *if* you know how to grep
through it and make sense of w
Hi,
Tangentially related: wouldn't it be better to also remove the "AUTHORS"
sections from docstrings?
--
Marc
--
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
John Cremona wrote:
> Just because Sage is open source does not mean that contributors
> should not get credit for their work.
Of course. But from what I've seen, lots of AUTHORS sections are awfully
out of date, while the git history is a few keystrokes away...
--
Marc
--
You received this m
John Cremona wrote:
> ...not to a user who types
>
> sage: X.fancy_function?
>
> though. Credit needs to be easily and obviously accessible or it will
> not get noticed.
My impression is that no (fine-grained) credit at all is better than
what we have now, and that credits generated from the g
William Stein wrote:
> If somebody explicitly puts their name in the AUTHORS block when they
> are writing the code in the first place, then we should respect that
> and continue to acknowledge them.
I agree with that part. It would be wrong to remove the AUTHORS blocks
without putting correspond
Simon King wrote:
> it is also supposed to say *who* did *what* ("what" meaning the
> purpose/intention of the change)
Commit messages too, and I'd argue they are the right place to do
that...
(Incidentally, I'm not sure git blame would be the right tool if we did
want to auto-generate author i
Dima Pasechnik wrote:
>> The graph clearly shows that there was a critical point between 2012
>> and 2014. I am curious what were major changes of circumstances
>> around then.
>>
> OpenDreamKit grant, obviously.
And the switch to git, I assume. For me at least, the "new" development
workflow has
William Stein wrote:
> The 3 people who expressed interest in being on the Sage dev prize
> committee are me, John Cremona, and Karl-Dieter Crisman.
Didn't Samuel Lelièvre also volunteer?
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
Hi everyone,
Some external packages that cimport cython modules from sage no
longer build with sage 9.7.beta8. It looks like this is due to
some recent change in Sage, as is reportedly works with sage 9.6.
Two examples:
~/co/sage:develop$ ./sage -pip install sage-flatsurf
Collecting sage-flatsur
Matthias Koeppe wrote:
> See
>
https://trac.sagemath.org/wiki/ReleaseTours/sage-9.7#sagesage.ringssage.libs...arenowPEP420namespacepackages
> and https://trac.sagemath.org/ticket/34221
Thanks a lot!
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-dev
be more natural to use issues for, well, issues (that is,
bug reports, as opposed to bug *fixes* or enhancements) and pull
requests for proposed changes?
--
Marc Mezzarobba
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscrib
en the contributions were not
developed on github but simply ended up in a repository mirrored on
github.
--
Marc Mezzarobba
--
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 i
Matthias Koeppe wrote:
> Yes, of course, and that's what I am documenting
> at https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
Sorry, apparently I misunderstood your proposal.
I would suggest the following changes then:
"Instead of opening a Trac ticket"
--> "To report a bug,
osed change.
--
Marc Mezzarobba
--
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 view this discussion on
Matthias Koeppe wrote:
> OK, good point, and I agree. I'll work that into the wiki page.
Thanks!
--
Marc
--
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-de
Dima Pasechnik wrote:
> I've conducted few experiments with a tool to import trac sites to
> github: https://github.com/svigerske/trac-to-github, which in
> particular allows to import trac tickets as github issues; a result of
> running it on few tickets
> may be inspected
> here:
> https://github
Dima Pasechnik wrote:
> this script goes for a simpler route - it writes GitHub logins (or
> original trac logins for the cases where there is no match) of users
> who commented, etc. into
> comments text. This does not need authorisation from users, but it's
> arguably less nice looking.
Not just
David Ayotte wrote:
> I have a question: given a trac ticket number, is there a way of
> recover the "Merge In" field of the ticket with the command line? I'd
> like to automatically add this info to the list.
In case they differ, do you want the contents of this field as it
appears on trac, or th
at
sagemath.org?
> --grep="^Trac #25848" --pretty='%H') --exclude='*beta*'
> --exclude='*rc*' --candidates=0
> fatal: cannot describe '4c9486b75fb02b14a21278bb69e44998c5045ccd'
--
Marc Mezzarobba
--
You received this message because y
Samuel Lelièvre wrote:
> a. The company operating GitHub can block access to GitHub,
> block account creation, or terminate accounts for individuals,
> companies or countries without prior notice on discriminatory
> grounds, see links below.
>
> b. Relying on free software tools for essential infr
Matthias Koeppe wrote:
> This is great question, thanks for the pointer to this GitLab.com URL.
> I've updated
>
https://github.com/sagemath/sage/wiki/Github-vs-Gitlab-vs-trac#in-favor-of-gitlab
> based on it.
Additionally, here in France at least, many universities and research
institutes already
William Stein wrote:
> Perhaps this is a bad criteria, e.g.,
> it excludes our webmaster (Harald Schilly), since he's done a lot to
> support Sage, but I don't think he's contributed code to the library
> -- at least I didn't find him in Dima's list from GitHub.
Looks like he has:
~/co/sage:devel
Emmanuel Charpentier wrote:
> +1 for Github
>
> Also wishing for contingency plan for re-migrating to self-hosted
> Gitlab.
Same here.
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving em
Vincent Delecroix wrote:
> Though these are specifications for SR and does
> not apply to the entire library. It is not clear to me what global
> specification we could have for bool(algebraic expression).
Something like "bool(x) iff x is not trivially zero" would make sense to
me, where "not triv
John H Palmieri wrote:
> You would think that this would be a solved problem: others in the
> open source community must have be in the practice of backing up their
> GitHub info.
The following tools seem fairly complete:
- https://github-backup.branchable.com/ (but I'm getting timeouts with
it),
Nils Bruin wrote:
> Speaking of backups ... do we backup the sage-devel, sage-support news
> groups?
They are on gmane, and presumably some sage developers have more or less
complete archives on their own computers...
> In fact, they are sometimes referred to on trac, via
> super-opaque URLs.
I
they see fit, and let new conventions emerge.
--
Marc Mezzarobba
--
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.
Thank you all for your work!
A minor point: the PR template still says "we are not accepting pull
requests yet".
--
Marc
--
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 e
Marc Mezzarobba wrote:
> A minor point: the PR template still says "we are not accepting pull
> requests yet".
Another one (more of a warning to other users actually): apparently
subscriptions to issues have not been migrated; you need to
re-subscribe to issues you are interest
Marc Mezzarobba wrote:
> Another one (more of a warning to other users actually): apparently
> subscriptions to issues have not been migrated; you need to
> re-subscribe to issues you are interested in.
Maybe related: search patterns of the form mentions:someone (including
the defau
Marc Mezzarobba wrote:
> Maybe related: search patterns of the form mentions:someone (including
> the default filter 'Everything mentioning you') seem to only return
> issues created after the migration.
...However, involves:@me seems to work.
--
Marc
--
You received this
Hi,
At https://github.com/sagemath/sage/pull/35848 I'm trying to make sage
build with flint3. It does build on my laptop, but autoreconf seems to
behave differently locally and on the CI VMs, and I have no idea why.
It would be great if someone with more knowledge of autotools and/or
our CI infras
Michael Jung wrote:
> Ah, interesting. Do you have some literature/references for me?
Among the standard references, Chapter 5 of *Modern Computer Algebra* by
von zur Gathen & Gerhard discusses the basic evaluation-interpolation
algorithm for computing the determinant of polynomial matrices in s
Nathan Dunfield wrote:
> -1: I don't really care what RealField.__repr__ returns, but cast a
> token no vote to object to the logical next move of breaking backwards
> compatibility by changing the meaning of RealField and/or RR. I see
> the need for a "genuine real field", but it seems a lot simp
The most recent Docker image (excluding develop/latest) at
https://hub.docker.com/r/sagemath/sagemath/tags
corresponds to Sage 9.2.beta3. Is that normal?
Thanks,
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this
Dima Pasechnik wrote:
> hopefully everything needed to fix docker builds will be merged in the
> coming beta.
Ok, thank you!
--
Marc
--
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 i
sage-de...@lists.sourceforge.net is still receiving new messages--99%
spam, but not 100%, see:
https://sourceforge.net/p/sage/mailman/sage-devel/
Does anyone have the necessary permissions to shut it down?
--
Marc
--
You received this message because you are subscribed to the Google Groups
"
Nisoli Isaia wrote:
> I was planning in doing a Cython implementation of Forward automatic
> differentiation and
> Taylor arithmetics as in
> https://press.princeton.edu/titles/9488.html
> to use to implement a library for Sage with rigorous quadrature and
> integration of ODE.
This is very inter
Nisoli Isaia wrote:
> P.=CBF[]
> x._sin_series(4)
Indeed, I remembered wrong. Only a few of these arb functions are
accessible from sage at this point. It is trivial to add more, though.
The relevant files are
src/sage/libs/arb/acb_poly.pxd
src/sage/rings/polynomial/polynomial_complex_arb.pyx
Nisoli Isaia wrote:
> I've seen that you wrote a sage interface for sollya, which
> seems to take already take care of Taylor models.
Indeed, though the Taylor models in Sollya may be a bit limited, and (if
I understood right, but I'm really no expert here) have some performance
issues.
> Is So
Hi,
Maybe a stupid question, but: does Sage really need to build all
these static libraries? Why?
456M./local/lib/libgiac.a
144M./local/lib/libec.a
120M./local/lib/libppl_c.a
107M./local/lib/libpari.a
69M ./local/lib/libppl.a
48M ./local/lib/libsymmetrica.a
31M ./local
Something like object creation, memory allocation, basic arithmetic, or
cython calls seems to have become a lot slower recently.
Overall, my Python code using sage runs about 10% slower with 9.0.beta6
than with 8.9. The slowdown seems to be spread evenly across many
different functions.
But he
Vincent Delecroix wrote:
> @Marc: could you perform some C profiling (it might work directly
> inside Sage via %crun [2]).
Yes, I'll try to investigate a bit more, but I first wanted to ask if it
was a known issue.
--
Marc
--
You received this message because you are subscribed to the Google
Vincent Delecroix wrote:
> Then I guess the reason of the slowdown comes from the change in
> the integer types in Python 3 and the way we handle the conversion
> from Python integers to Sage integers
This may be part of it, but I don't think it explains everything:
sage: a = 1
sage: %timeit a+a
Some profiling data (via linux-perf) for
sage: def f():
: for i in [x]range(1):
: a+a
Py2:
Samples: 26K of event 'cycles', Event count (approx.): 17630706503
Children Self Command Shared ObjectSymbol
+ 77,85%47,79% python2 libpython2.7.so.1.0
Marc Mezzarobba wrote:
> Some profiling data (via linux-perf) for
>
> sage: def f():
> : for i in [x]range(1):
> : a+a
where a = Integer(1).
If a is made local to the function, the very expensive lookups
disappear, and we still see calls to PyLong_
Marc Mezzarobba wrote:
>> sage: def f():
>> : for i in [x]range(1):
>> : a+a
>
> where a = Integer(1).
>
> If a is made local to the function, the very expensive lookups
> disappear, and we still see calls to PyLong_FromLong taking
[re-posting a reply from a week ago that apparently did not go through
because gmane was moving]
Nils Bruin wrote:
> This model has the advantage that (sqrt(1+t)^2 -1)/t == 1 returns
> true, as one would expect mathematically.
Do you mean it has the advantage that cos(sin(tan(t^2)) -
tan(sin(t^
[re-posting a reply from a week ago that apparently did not go through
because of the gmane move]
David Roe wrote:
>> So one thing I thought of that could be a problem is this:
>>
>> ZZ['x'] --> ZZ['x,y']['x']
>>
>> or more generally anytime there are repeated variable names.
>> Actually, in this
101 - 200 of 221 matches
Mail list logo
