I thought a bit more, and now I think Simon's viewpoint is arguably more
consistent than mine, and my worries are groundless because we have method
exponents().
Cheers.
Kwankyu
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an emai
On Sep 24, 11:14 am, Simon King wrote:
> Question: Should Sage's save/dumps and load/loads use the trick above
> to pickle functions that can't be pickled otherwise?
I still think the answer should be "by default no", but at the same
time I think the ability to pickle code is incredibly useful whe
On Sat, Sep 24, 2011 at 2:40 PM, Simon King wrote:
> PS:
>
> On 24 Sep., 23:22, Simon King wrote:
>> > Or would it already be faster to keep Finder (which is cdef'd) as it
>> > is, and call Finder.which_root as a method?
>>
>> I tried, and the total computation time *doubles* if I replace a call
PS:
On 24 Sep., 23:22, Simon King wrote:
> > Or would it already be faster to keep Finder (which is cdef'd) as it
> > is, and call Finder.which_root as a method?
>
> I tried, and the total computation time *doubles* if I replace a call
> to f1(...) by Finder.which_root(...)
Sorry, I stand correc
Hi Robert,
On 24 Sep., 23:09, Simon King wrote:
> Or would it already be faster to keep Finder (which is cdef'd) as it
> is, and call Finder.which_root as a method?
I tried, and the total computation time *doubles* if I replace a call
to f1(...) by Finder.which_root(...), even though Finder is c
Hi Robert,
On 24 Sep., 22:14, Robert Bradshaw
wrote:
> When you do
>
> f1 = Finder.which_root # creates an *object* f1
> f1(...)
>
> you're not taking advantage of the fact that which_root is a cpdef
> function. This is probably where the bulk of your time is going.
How would one take
On Sep 24, 1:02 pm, Simon King wrote:
> Yes, that's not good. Unless it is possible to keep an old marshal
> version around even after upgrading python?
It's not the version of marshal, it's the underlying data. CPython
VM's bytecode can change between versions. For improving the language
impleme
On Sat, Sep 24, 2011 at 10:26 AM, leif wrote:
> On 24 Sep., 18:25, "D. S. McNeil" wrote:
>> Leif wrote:
>> > Any reasonable compiler does constant folding and loop-invariant code
>> > motion; even Python's byte-code compiler should do that.
>>
>> Almost none is done. Only the most trivial cases
Hi Nils,
On 24 Sep., 21:04, Nils Bruin wrote:
> Very interesting! Look at the big caveat, though: "marshal's format
> (any python bytecode for that matter) may not be compatable between
> major python versions."
Yes, that's not good. Unless it is possible to keep an old marshal
version around ev
On Sep 24, 12:04 pm, Nils Bruin wrote:
> Does it properly recreate a function that resulted from a closure?
It doesn't but with a little extra work it can. There is a bit of
trouble that closures require "cell" objects which one cannot create
normally. However, they're created by closures, so we
On Sep 24, 11:14 am, Simon King wrote:
> It shows that there are ways to pickle a code object, using the
> marshal and the types modules:
> Question: Should Sage's save/dumps and load/loads use the trick above
> to pickle functions that can't be pickled otherwise?
Very interesting! Look at the bi
I forgot to say that for me Sage builds on MacOSX 10.6.8 just fine (I
set SAGE64=yes, perhaps this is not even needed any more)
Dima
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
Fo
>Library not loaded: /usr/local/lib/libfreetype.6.dylib
Sage normally does not use any stuff from /usr/local/
and it is not safe to have some random stuff there when building it.
What happens is that instead of using
$SAGE_ROOT/local/lib/libfreetype.6.dylib
it tries to load the one in /usr/loca
Hi!
If I am not mistaken, loads and dumps are no Python built-ins, but
defined in Sage. However, they share one shortcoming with Python: It
is not possible to pickle a function defined in an interactive
session.
{{{
sage: def g(x):
: if x>0:
: return x+1
: return x-1
.
On 24 Sep., 18:25, "D. S. McNeil" wrote:
> Leif wrote:
> > Any reasonable compiler does constant folding and loop-invariant code
> > motion; even Python's byte-code compiler should do that.
>
> Almost none is done. Only the most trivial cases are handled. [...]
OMG. That's why I said "reasonable
On 24 Sep., 18:05, leif wrote:
> $ ldd /tmp/Sage/sage-4.7.2.alpha2/local/lib/libgd.so
> linux-vdso.so.1 => (0x7fff92fff000)
> libfontconfig.so.1 => /usr/lib/libfontconfig.so.1
> (0x7f6867599000)
> libfreetype.so.6 => /tmp/Sage/sage-4.7.2.alpha2/local/lib/
> libfree
Hi Doug!
On 24 Sep., 18:25, "D. S. McNeil" wrote:
> "NO Sage preparsing is applied to spyx files, e.g., 1/3 will result in
> 0 in a spyx file instead of the rational number 1/3."
Thank you, I didn't know about it (to my excuse: I have never used
spyx files before, and I thought the "s" refers to
Leif wrote:
> Any reasonable compiler does constant folding and loop-invariant code
> motion; even Python's byte-code compiler should do that.
Almost none is done. Only the most trivial cases are handled. For
example, addition:
sage: preparser(False)
sage: type(2)
sage: def f():
:
On 24 Sep., 17:32, leif wrote:
> This smells like a bug in the gd spkg, not linking gd to *Sage's*
> libfreetype.
>
> Will investigate...
Hmmm, this is a bit strange. Despite that we *don't* add '-L
$SAGE_LOCAL/lib' to LDFLAGS (unless $SAGE64=yes, which you could try),
we configure gd with '--wit
Hi Simon,
In your point of view that a polynomial ring is always a graded ring, what I
want is perhaps this: even though you work with a polynomial ring with
non-default grading, the methods degree(), degrees(), total_degree() for the
default grading should still be available to the user becaus
On 23 Sep., 23:26, Rob Gross wrote:
> Hi,
>
> I'm trying to compile 4.7.1. The compile on Mac OS 10.6.8 proceeds
> without errors, though I get an error building documentation similar
> to the error below. When I try to run sage, though, I get the error
>
> ImportError: dlopen(/Users/gross/sage-
Hi Leif,
On 24 Sep., 16:28, leif wrote:
> A smarter compiler would [have] remove[d] *the whole loop*, since the
> loop body is completely dead code (for 2/3 rather than 2.0/3, because
> abs(...)<0 will never hold).
Since we talk about a spyx-file (not pyx), the Sage preparser is
applied to 2/3,
On 23 Sep., 10:19, javier wrote:
> On 23 sep, 06:57, "D. S. McNeil" wrote:
>
> > I think replacing 2/3 with 2./3 in
>
> > if abs(varia-root)<2/3:
>
> > will help a little.. :^) By itself, that cuts the time down to 19s for me.
>
> Slightly better, save yourself doing the same com
Hi Kwankyu,
On 24 Sep., 13:36, Kwankyu Lee wrote:
> I think one should not take it for granted a polynomial ring is a graded
> ring.
No. Of course it is granted!
> Of course, you can view a polynomial ring as a graded ring. But one
> work with a polynomial ring, perhaps more often, not as a gra
Hi Simon,
I think one should not take it for granted a polynomial ring is a graded
ring. Of course, you can view a polynomial ring as a graded ring. But one
work with a polynomial ring, perhaps more often, not as a graded ring.
With a polynomial in a polynomial ring not as a graded ring, you h
25 matches
Mail list logo
