On Mar 15, 2010, at 8:47 PM, Dan Drake wrote:
On Mon, 15 Mar 2010 at 09:14PM -0600, Jason Grout wrote:
What about this: we make a PPA of the binary and just direct everyone
to that. That way, there is a one-step, distribution-supported avenue
for getting an up-to-date Sage. At least, this migh
On Mon, 15 Mar 2010 at 09:14PM -0600, Jason Grout wrote:
> What about this: we make a PPA of the binary and just direct everyone
> to that. That way, there is a one-step, distribution-supported avenue
> for getting an up-to-date Sage. At least, this might be a very easy
> stop-gap measure, if some
On Tue, 16 Mar 2010 at 01:32PM +1100, Minh Nguyen wrote:
> Sounds good to me. Could you open a ticket and share your tips on
> proper ways to deprecate a function?
http://trac.sagemath.org/sage_trac/ticket/8546
That ticket contains what I know, which is not necessarily the
"official" correct way!
On 03/14/2010 04:03 PM, Scott wrote:
I am trying to code loglog and semilog plot tools, however I cannot
find the place to manipulate the ticklabels.
sage.plot.list_plot is my template. Where are the tick labels set in
list_plot?
I want to change the tick labels from [1 ,2,3] to [1e1,1e2,1e3]
On 03/13/2010 06:48 PM, Tim Abbott wrote:
I don't like the current situation any more than you do, but the Ubuntu
archive maintainers' policy isn't unreasonable, even if it is frustrating.
What about this: we make a PPA of the binary and just direct everyone to
that. That way, there is a one
Hi Dan,
On Tue, Mar 16, 2010 at 1:28 PM, Dan Drake wrote:
> Perhaps there should be a section in the
> developer's guide briefly describing the correct way to do this, and how
> to change doctests appropriately?
Sounds good to me. Could you open a ticket and share your tips on
proper ways to
Hello,
Today I wanted to put the proper deprecation stuff into a function which
should be deprecated, and I had to grep through source code to find the
proper way to do it. Perhaps there should be a section in the
developer's guide briefly describing the correct way to do this, and how
to change d
The problem is fixed, and there is a patch awaiting review at #8539.
Robert-- Thanks again for helping me figure this out. It would be an
easy review, if you still feel generous :)
--
Robert L. Miller
http://www.rlmiller.org/
--
To post to this group, send an email to sage-devel@googlegroups.c
On Mar 15, 2010, at 4:27 PM, Robert Miller wrote:
On Mon, Mar 15, 2010 at 3:59 PM, Robert Miller
wrote:
On Mon, Mar 15, 2010 at 3:47 PM, Robert Miller
wrote:
Thanks for the tip, I'll keep digging!
I believe the problem is in M._mod_int(p):
Is this a problem with __new__ versus __cinit_
On Mon, Mar 15, 2010 at 3:59 PM, Robert Miller wrote:
> On Mon, Mar 15, 2010 at 3:47 PM, Robert Miller wrote:
>> Thanks for the tip, I'll keep digging!
>
> I believe the problem is in M._mod_int(p):
Is this a problem with __new__ versus __cinit__? In _mod_int, the
result is constructed like this
On Mon, Mar 15, 2010 at 3:47 PM, Robert Miller wrote:
> Thanks for the tip, I'll keep digging!
I believe the problem is in M._mod_int(p):
sage: M = Matrix(ZZ, 300, 300, sparse=True)
sage: M
300 x 300 sparse matrix over Integer Ring (type 'print M.str()' to see
all of the entries)
sage: M.parent(
On Mon, Mar 15, 2010 at 3:38 PM, Robert Bradshaw
wrote:
> Here's the problem:
>
> sage: M.parent()
> Full MatrixSpace of 5376 by 16128 dense matrices over Integer Ring
Thanks for the tip, I'll keep digging!
--
Robert L. Miller
http://www.rlmiller.org/
--
To post to this group, send an email
On Mar 15, 2010, at 3:13 PM, Robert Miller wrote:
Hello,
It seems that a certain sparse matrix over the Integers takes
"forever" to multiply by 1:
(this is in Sage-4.3.4.alpha1)
sage: z,M = load('http://sage.math.washington.edu/home/rlmill/bad_matrix.sobj')
Attempting to load remote file:
htt
On Mon, Mar 15, 2010 at 3:13 PM, Robert Miller wrote:
> Hello,
>
> It seems that a certain sparse matrix over the Integers takes
> "forever" to multiply by 1:
PS - this comes from
http://trac.sagemath.org/sage_trac/ticket/8539
--
To post to this group, send an email to sage-devel@googlegroups.
Hello,
It seems that a certain sparse matrix over the Integers takes
"forever" to multiply by 1:
(this is in Sage-4.3.4.alpha1)
sage: z,M = load('http://sage.math.washington.edu/home/rlmill/bad_matrix.sobj')
Attempting to load remote file:
http://sage.math.washington.edu/home/rlmill/bad_matrix.s
Gonzalo,
On Mon, Mar 15, 2010 at 1:17 PM, Gonzalo Tornaria
wrote:
> On Mon, Mar 15, 2010 at 3:57 PM, Brian Granger
> wrote:
> > Thanks for describing this better, it helps me to understand what the
> > current _sig_on/_sig_off does. Because of the licensing issues, I am
> > not looking at the c
William,
Fantasic, thanks for trying this!
Cheers,
Brian
On Mon, Mar 15, 2010 at 2:02 PM, William Stein wrote:
> On Mon, Mar 15, 2010 at 12:57 PM, Brian Granger
> wrote:
> > Gonzalo,
> > On Sun, Mar 14, 2010 at 9:21 PM, Brian Granger
> > wrote:
> >>
> >> > Gonzalo,
> >> > Thanks for startin
On Mon, Mar 15, 2010 at 12:57 PM, Brian Granger wrote:
> Gonzalo,
> On Sun, Mar 14, 2010 at 9:21 PM, Brian Granger
> wrote:
>>
>> > Gonzalo,
>> > Thanks for starting this discussion. I am willing to help with this
>> > effort
>> > as I definitely need this capability. Part of the challenge will
On Mon, Mar 15, 2010 at 3:57 PM, Brian Granger wrote:
> Thanks for describing this better, it helps me to understand what the
> current _sig_on/_sig_off does. Because of the licensing issues, I am
> not looking at the code in Sage until it has been officially re-licensed.
> Once that has been do
Gonzalo,
On Sun, Mar 14, 2010 at 9:21 PM, Brian Granger
wrote:
> > Gonzalo,
> > Thanks for starting this discussion. I am willing to help with this
> effort
> > as I definitely need this capability. Part of the challenge will be
> > figuring out how to do this on Windows.
>
> Not necessarily.
On Mar 14, 2010, at 8:18 PM, Gonzalo Tornaria wrote:
On Sat, Mar 13, 2010 at 7:22 PM, Robert Bradshaw
wrote:
On Mar 13, 2010, at 4:04 PM, Gonzalo Tornaria wrote:
What are the options for supporting this (either the
decorator/function attribute or the with-clause)?
We can support both. We co
Dan Drake wrote:
If spaces are the concern, using quotes whenever you reference the
variable is the fix: "$SAGE_ROOT/whatever". There are lots of places in
Sage scripts where we should be using quotes to make sure paths with
spaces work properly -- see, for example,
http://trac.sagemath.org/sage
On Mon, 15 Mar 2010 at 01:11AM -0700, Dima Pasechnik wrote:
> Could anyone tell me the the advantage of
>
> ${gapver:=$SAGE_ROOT/spkg/standard/newest_version gap}
> GAP0=`$gapver`
>
> over
>
> GAP0=`$SAGE_ROOT/spkg/standard/newest_version gap`
>
> (it was there, but commented out and repl
On Mar 15, 1:12 am, Rado wrote:
> I have the following simplehttp://www.math.uiuc.edu/~rkirov2/files/escher.py
You can start by cythonizing the first function, something like:
cdef float a1
...
cpdef float intersect_lines(float x, ):
...
return (b1*c2 ...
h
--
To post to this group, s
Bedankt!
On Mar 15, 5:51 pm, Willem Jan Palenstijn wrote:
> On Mon, Mar 15, 2010 at 01:11:22AM -0700, Dima Pasechnik wrote:
> > Could anyone tell me the the advantage of
>
> > ${gapver:=$SAGE_ROOT/spkg/standard/newest_version gap}
> > GAP0=`$gapver`
>
> The meaning of ':=' there is to only s
On Mon, Mar 15, 2010 at 01:11:22AM -0700, Dima Pasechnik wrote:
> Could anyone tell me the the advantage of
>
> ${gapver:=$SAGE_ROOT/spkg/standard/newest_version gap}
> GAP0=`$gapver`
The meaning of ':=' there is to only set $gapver to $SAGE_ROOT/spkg/ if
$gapver was unset or null previo
Could anyone tell me the the advantage of
${gapver:=$SAGE_ROOT/spkg/standard/newest_version gap}
GAP0=`$gapver`
over
GAP0=`$SAGE_ROOT/spkg/standard/newest_version gap`
(it was there, but commented out and replaced by the former)
The "${gapver:=..." does not work on Solaris, so I need a k
27 matches
Mail list logo
