On 13-May-09, at 10:53 PM, Nicolas M. Thiery wrote:
>
> On Tue, May 12, 2009 at 05:40:46PM -0700, Nick Alexander wrote:
>>> - C-C C-j seems to get confused by tabs in the input, and triggers
>>> automatic completion:
>>
>> As far as I'm concerned, tabs in input are always wrong. Python even
>>
On Tue, May 12, 2009 at 05:40:46PM -0700, Nick Alexander wrote:
> > - C-C C-j seems to get confused by tabs in the input, and triggers
> > automatic completion:
>
> As far as I'm concerned, tabs in input are always wrong. Python even
> has an error (TabError) for this, no? This is wontfix f
On May 13, 9:46 am, Brian Granger wrote:
Hi Brian,
> I just pinged the pythonmac-sig group about why and when a framework
> build is actually needed. A while back I created an spkg for qt/pyqt
> and I remember that I needed to do a framework build to get it to
> work. My recollection is tha
On May 13, 2:37 pm, mark mcclure wrote:
> On May 12, 3:27 am, mabshoff wrote:
Hi,
> > I have build a 3.4.2 binary with various fixes and posted it at
> > http://sage.math.washington.edu/home/mabshoff/OSX64/
> > Please give it a spin if you care about 64 bit OSX.
>
> Seems to work OK on my
In 2d plots, dots and oblique lines are nicely antialiased
but seem to be consistently misplaced by about 1 pixel.
Is this a problem with sage, matplotlib, aag, ...?
See the example below, where the dots are about 1 pixel to the left of
where they should be,
and the diagonal lines are likewise o
Hi,
I created a ticket #6036 for this bug.
Kwankyu
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at
Hi,
I traced this bug, and found that
sage: B=QQ[x]
sage: print B({0:1,1:2})
sage: print B({(0,):1,(1,):2})
2*x + 1
2*x + 1
sage: B=GF(5)[x]
sage: print B({0:1,1:2})
sage: print B({(0,):1,(1,):2})
2*x + 1
Traceback (most recent call last):
File "", line 1, in
File "/home/kwankyu/.sage/sage_
On May 12, 3:27 am, mabshoff wrote:
> I have build a 3.4.2 binary with various fixes and posted it at
> http://sage.math.washington.edu/home/mabshoff/OSX64/
> Please give it a spin if you care about 64 bit OSX.
Seems to work OK on my Mac Pro, although I hardly put it to
the test. Are there a
2009/5/13 Robert Bradshaw :
>
> On May 13, 2009, at 8:53 AM, John Cremona wrote:
>
>> Is there any reason why this line:
>>
>> print sum([1,2,3],10)
>>
>> in a .pyx file should not compile? I get the error "Call with wrong
>> number of arguments (expected 3, got 2)" with an arrow pointing to the
On May 13, 2009, at 11:23 AM, Carl Witty wrote:
> On Wed, May 13, 2009 at 11:02 AM, Robert Bradshaw
> wrote:
>>
>> I recently noticed that complex interval fields have a very different
>> notion of equality than real interval fields. For RIF, a != b if a is
>> *definitely* not equal to b, but CI
This is a nicely written paper by some scientific computing person
about using Cython. See below. Also, this link is better than the
one given by the author below, since he messed up the file name.
http://sage.math.washington.edu/home/wstein/tmp/simula_pdf_file.pdf
-- Forwarded messa
On Wed, May 13, 2009 at 11:02 AM, Robert Bradshaw
wrote:
>
> I recently noticed that complex interval fields have a very different
> notion of equality than real interval fields. For RIF, a != b if a is
> *definitely* not equal to b, but CIF just compares endpoints. I think
> we should change CIF
On May 13, 2009, at 8:53 AM, John Cremona wrote:
> Is there any reason why this line:
>
> print sum([1,2,3],10)
>
> in a .pyx file should not compile? I get the error "Call with wrong
> number of arguments (expected 3, got 2)" with an arrow pointing to the
> work "sum".
>
> This is driving me ma
I recently noticed that complex interval fields have a very different
notion of equality than real interval fields. For RIF, a != b if a is
*definitely* not equal to b, but CIF just compares endpoints. I think
we should change CIF's behavior to be more like RIF, does anyone have
any object
> I apologize for the way I presented this. No offense was intended for
> anybody. I won't follow up in sage-flame, because it was never my
> intention to start a flame (I don't think this discussion has turned
> into a flame yet, neither by me or others, but I can see it has the
> potential to be
I just pinged the pythonmac-sig group about why and when a framework
build is actually needed. A while back I created an spkg for qt/pyqt
and I remember that I needed to do a framework build to get it to
work. My recollection is that if you want Python to be able to do
anything with the native M
> Well, I think what we should do is merge as much of SPD into Sage as
> possible to lessen the maintainance burden. One thing I could see here
> is to define SAGE_EXECUTABLE and you would just set it to spd in your
> code.
I think this is a good idea. I think if SPD is kept separate, it will
en
>> The build bits do not exist in ipython, but I think ipython should
>> have some good web notebook.
>
> Sure, competition is good for business. I just don't think this code
> is currently a priority for them and judging from the current
> discussion about getting 0.10 out the door I don't see an
Is there any reason why this line:
print sum([1,2,3],10)
in a .pyx file should not compile? I get the error "Call with wrong
number of arguments (expected 3, got 2)" with an arrow pointing to the
work "sum".
This is driving me mad -- a very similar line in another .pyx file was fine!
John
-
On May 13, 5:25 am, Mickael Gastineau wrote:
Hi Mickael,
> The fedora says that isn't compatible but the FSF says that it is
> compatible with GPL :
> seehttp://www.fsf.org/licensing/licenses/ (section CeCILL version
> 2)
> orhttp://www.gnu.org/licenses/license-list.html#SoftwareLicenses
No,
The fedora says that isn't compatible but the FSF says that it is
compatible with GPL :
see http://www.fsf.org/licensing/licenses/ (section CeCILL version
2)
or http://www.gnu.org/licenses/license-list.html#SoftwareLicenses
and the FAQ of the cecill says that the "CeCILL is nevertheless
compati
On May 13, 1:42 am, Mickael Gastineau wrote:
> Dear all,
Hi Mickael,
> You may have heard about the protocol called "Symbolic Computation
> Software Composability Protocol", abbreviated SCSCP, developped under
> the SCIEnce project (http://www.symbolic-computation.org/).
>
> I have made a C l
Dear David,
> I think the polynomial ring model should translate well
> to the non-commutative free algebras. In addition to
> access, specifying a (non-commutative) monomial
> ordering would be desirable. Generalizing these
> orderings is the only challenge in the generalization
> from f
Dear William,
> > Or my student's :). That was my intention ! The obvious question is now the
> > naming convention. It seems to me that we should stick as close as possible
> > to
> > polynomials:
> >
> > sage: ring = ZZ['x1,x2']
> > sage: x1 = ring.gens()[0] # why x1 is not defin
Hi Florent,
I think the polynomial ring model should translate well
to the non-commutative free algebras. In addition to
access, specifying a (non-commutative) monomial
ordering would be desirable. Generalizing these
orderings is the only challenge in the generalization
from free commutative al
Dear all,
You may have heard about the protocol called "Symbolic Computation
Software Composability Protocol", abbreviated SCSCP, developped under
the SCIEnce project (http://www.symbolic-computation.org/).
I have made a C library for SCSCP. The library aims to provide a
simplest API to create c
26 matches
Mail list logo
