On 2013-02-19 20:54, David Roe wrote:
> I'm fairly sure the problem is that the defining polynomial for the
> relative extension is not monic. One solution would be to use an
> equivalent monic polynomial and keep track of a simple transformation
> allowing one to translate between the internal re
I'm fairly sure the problem is that the defining polynomial for the
relative extension is not monic. One solution would be to use an
equivalent monic polynomial and keep track of a simple transformation
allowing one to translate between the internal representation of elements
on the one hand and p
Dear All,
> * A parallel build (using the usual MAKE="make -jN") can speed up the
> docbuilding time. Note that the speed-up factor is closer to N/2 than to
> N because two passes are needed now.
This is not quite true. I don't have precise timing. Put most of the time of
the first pass is
On Tue, 19 Feb 2013 at 12:13PM +0100, Jeroen Demeyer wrote:
> * A parallel build (using the usual MAKE="make -jN") can speed up the
> docbuilding time. Note that the speed-up factor is closer to N/2 than to
> N because two passes are needed now.
I'll take O(N) over O(1) any day!
...and with many
Hi Nils,
On 2013-02-19, Nils Bruin wrote:
> __richcmp__ is not a special method for python classes. You need to
> implement __eq__ etc for those. I'd hope (and this example
> corroborates it) that cython decided to use the same semantics for non-
> cdef classes. Your example wouldn't change if yo
Hi all,
Adrien Poteaux reported this bug
(http://trac.sagemath.org/sage_trac/ticket/14146) to me. When you create a
number field (possibly on top of another number field), what are the
restrictions on the defining polynomial ? Currently, strange PARI error occur,
that are quite cryptic. Appare
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
Hi Nils,
On 2013-02-19, Nils Bruin wrote:
> On Feb 19, 12:58 am, Simon King wrote:
>
>> Here I am not sure: Must hash be compatible with cmp or with rich
>> comparison?
>> Hence, should I overload __cmp__ as well?
>
> If you look at the C-API rules, inheritance of tp_compare,
> tp_richcompare an
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 Tuesday, February 19, 2013 8:15:43 AM UTC-5, Volker Braun wrote:
>
> On Tuesday, February 19, 2013 11:19:05 AM UTC, David Roe wrote:
>
>> Sounds fantastic! For those of us running with only one core, will these
>> two processes increase the buildtime by a factor of two?
>>
>
> Not quite sinc
This link was posted earlier by Robert Dodier on the Maxima list, and
interesting food for thought. I don't necessarily agree with everything on
here (such as the git emphasis! since most of our new developers are
mathematicians, not programmers, by trade), but I think most folks here
would ag
On Tuesday, February 19, 2013 12:13:25 PM UTC+1, Jeroen Demeyer wrote:
>
> Sage-5.8.beta0 will contain a new driver for the building of the
> documentation. This has consequences for all Sage developers:
>
> * The documentation is built in two passes, similar to how you usually
> need to run (l
On Tuesday, February 19, 2013 11:19:05 AM UTC, David Roe wrote:
> Sounds fantastic! For those of us running with only one core, will these
> two processes increase the buildtime by a factor of two?
>
Not quite since no html is generated on the first pass. Though I doubt that
there are many sin
Sounds fantastic! For those of us running with only one core, will these
two processes increase the buildtime by a factor of two? Or is there a
single process option similar to the old system?
David
On Tue, Feb 19, 2013 at 4:13 AM, Jeroen Demeyer wrote:
> Sage-5.8.beta0 will contain a new driv
Sage-5.8.beta0 will contain a new driver for the building of the
documentation. This has consequences for all Sage developers:
* The documentation is built in two passes, similar to how you usually
need to run (la)tex twice to get all references correct.
* Links are possible from other documents
Hi all,
On 2013-02-17, Simon King wrote:
> OK. That's indeed an argument to make it possible to override
> stuff---users are supposed to know what they do.
I just posted a new patch version at #14054. It is more pythonic in the
sense that it allows for overloading hash and rich comparison.
One
I'll give it a look
Cheers,
J
On Tuesday, February 19, 2013 12:40:16 AM UTC, Keshav Kini wrote:
>
> Hi,
>
> If there are any Spanish speaking Sage devs who have a little time,
> could you please review this Spanish translation of the sagenb UI?
>
> https://github.com/sagemath/sagenb/pull/133
17 matches
Mail list logo
