Hi!
My impression is that relatively often questions on sage-support are
about people accidentally mixing symbolics and polynomials. For
example
sage: z = var('z')
sage: R = QQ[z]
and then believing that z is the generator of R.
I think it would avoid trouble if one would print a big warn
+1
On Wed, Dec 15, 2010 at 00:55, Simon King wrote:
> On 15 Dez., 01:55, Robert Bradshaw
> wrote:
>> I would strongly object to removing the ability to iterate over
>> infinite sets, sometimes it's very useful to iterate until something
>> is found, or to grab a certain number of elements.
>
> +
On 15 Dez., 01:55, Robert Bradshaw
wrote:
> I would strongly object to removing the ability to iterate over
> infinite sets, sometimes it's very useful to iterate until something
> is found, or to grab a certain number of elements.
+1
--
To post to this group, send an email to sage-devel@google
Great news! Keep up the good work.
Since my Windows installation is under Parallels/Boot Camp on OS X
from my employer, I decided not to take the chance to bork the
installation, since I understand little of how Puppy Linux would co-
boot with Windows. But I think it would be great if some peopl
On Tue, Dec 14, 2010 at 3:09 PM, Rob Beezer wrote:
> Symptom: The following code would appear to run forever, since the
> rationals define an iterator that never quits.
>
> QQ.list()
>
> I discovered this when I presumed that
>
> (QQ^2).list()
>
> would raise an error. It doesn't. So I patched
Hello,
i have improved the live CD (Sage 4.6) with the feedback I got. There
were the following changes:
1) Included JRE (Java), so 3d plotting works out of the box
2) Made boot option pfix=nocopy default, this means that it doesn't
load completly to RAM by default. This behaves nice and I was ab
Symptom: The following code would appear to run forever, since the
rationals define an iterator that never quits.
QQ.list()
I discovered this when I presumed that
(QQ^2).list()
would raise an error. It doesn't. So I patched the free module code
so the iterator producing module elements would
After months of threats, I finally have a toolchain of conversion
software working acceptably and have begun adding actual Sage content
to open source textbooks. At
http://wiki.sagemath.org/devel/LatexToWorksheet
you will find:
1. In the Examples section, the first chapter of my linear algebra
Can somebody please review:
http://trac.sagemath.org/sage_trac/ticket/103611
It is a plain upgrade of the source package (both original version and
new version need no patches). The updated package fixes known
interactions between setuptools and distribute (which makes installing
the PyCUDA/PyOpenC
Hello,
I'm the creator of the patch and reporter of the trac ticket. I'd just
like to mention that the patch I uploaded is only a quick hack to make
sage pass the test file I had written (which is also uploaded to the
trac ticket). I have little experience with sage on the whole, and
less with the
On 14 Dez., 14:02, Minh Nguyen wrote:
> At ticket #10458 [1] is a patch that allows the doctesting framework
> to deal with doctest lines that begin with ":". Such a line is
> exactly what you would get if you work with IPython. By default
> IPython prints out ":" for line continuation, as
Hello,
I am going to improve the functionality of nef partitions and fix some
issues in the current implementation
(sage.geometry.lattice_polytope.NEFPartition), which was written
before I understood what are nef partitions and included into Sage
before mandatory refereeing. Worst issues:
- it is
It seems that #sage is already registered, though nobody has said
anything there since July of this year. I talked to the owner of the
channel - he is a member of the USENIX Special Interest Group for
Sysadmins ( http://sage.org/ ) and says that other users of that
organization sometimes use #sage
Yep. It's just something that hasn't been implemented yet.
David
On Tue, Dec 14, 2010 at 07:18, Dan Drake wrote:
> diagonal_matrix() does not seem smart enough to deal with 1-dimensional
> numpy arrays:
>
> sage: s
> array([ 7.10977223, 2.10977223])
>
> Both values are numpy floats:
>
> sage: [
actually, this idea won't fly on OSX, IMHO.
Using a non-Xcode compiler on OSX looks next to impossible.
On Dec 14, 10:56 pm, kcrisman wrote:
> Will a newer gcc work on older processors? I assume so, even with
> building gcc with an older gcc. I would be happy to test a sample
> proof-of-concept
Will a newer gcc work on older processors? I assume so, even with
building gcc with an older gcc. I would be happy to test a sample
proof-of-concept tarball on OS X PPC. If you get it to me before the
end of next week, at least.
- kcrisman
--
To post to this group, send an email to sage-devel
certainly, I can relicense whatever was under v3 to v2, if needed.
Dima
On Dec 14, 10:00 pm, Keshav Kini wrote:
> Hi Minh,
>
> On Dec 14, 9:07 pm, Minh Nguyen wrote:
>
>
>
>
>
> > [...]
> > Your patch adds the following source files to the Sage library:
>
> > * STABIL.c
> > * STABIL.h
>
> > both
Hi Minh,
On Dec 14, 9:07 pm, Minh Nguyen wrote:
> [...]
> Your patch adds the following source files to the Sage library:
>
> * STABIL.c
> * STABIL.h
>
> both of which are explicitly licensed under the terms of GPLv3. A
> policy of the Sage project is to include only code licensed under the
> ter
Hi Keshav,
On Tue, Dec 14, 2010 at 5:17 PM, Keshav Kini wrote:
> Hello,
>
> I have put together a patch which adds a module "sage.graphs.wlrefine"
> and implements the Weisfeiler-Leman algorithm for coherent partition /
> graph refinement, using an algorithm by Dmitrii Pasechnik and Luitpold
> Ba
Hi William,
could you perhaps take care of this?
On Dec 14, 5:43 pm, Keshav Kini wrote:
> After some consultation with a freenode oper, it seems that there is a
> rather humongous backlog of group registration forms that have been
> filled and are waiting for processing ("thousands"), but if a so
Hi folks,
At ticket #10458 [1] is a patch that allows the doctesting framework
to deal with doctest lines that begin with ":". Such a line is
exactly what you would get if you work with IPython. By default
IPython prints out ":" for line continuation, as compared to the
Python shell which
diagonal_matrix() does not seem smart enough to deal with 1-dimensional
numpy arrays:
sage: s
array([ 7.10977223, 2.10977223])
Both values are numpy floats:
sage: [parent(_) for _ in s]
[, ]
But diagonal_matrix() can't make sense of s:
sage: diagonal_matrix(s)
Traceback (most recent call last
/Slightly/ related thread: (Shipping C, C++, Fortran libraries with
bdists):
http://groups.google.com/group/sage-devel/t/47ab4370e253306e
("Add 'gcc' libraries to Sage binaries (< 0.5% bloat)", from February)
-Leif
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsu
On 14 Dez., 09:21, leif wrote:
> Hmmm, couldn't resist, but ...
>
> ...
> libtool: link: ranlib .libs/libsupc++convenience.a
> rm: cannot remove `libsupc++convenience.la': No such file or directory
> libtool: link: ( cd ".libs" && rm "libsupc++convenience.la" && ln -s
> "../libsupc++convenience.la
After some consultation with a freenode oper, it seems that there is a
rather humongous backlog of group registration forms that have been
filled and are waiting for processing ("thousands"), but if a software
project needs their group registration processed in order to regain
control of a channel,
There's actually a freenode policy which recommends against using
"primary channels" (ones that start with # and not ##) unless they're
associated with a "primary group", which is basically a software
project registered with freenode and with known contact persons. Has
anyone tried applying for "sa
On 14 Dez., 08:09, Keshav Kini wrote:
> The #sage-devel IRC channel is not currently registered in anyone's
> name on the freenode network (was it ever?), which means that nobody
> can obtain operator privileges in it unless everyone leaves, the
> channel thus gets purged, and then someone joins i
On 14 Dez., 09:42, Jeroen Demeyer wrote:
> On 2010-12-14 05:59, David Kirkby wrote:
>
> > Cons:
> > * It would make Sage 1.6 MB larger
> > * It would slow builds on any system where the Sage gcc was used in
> > preference to a system one.
>
> Building gcc takes a huge amount of time. I guess
On 2010-12-14 05:59, David Kirkby wrote:
> Cons:
> * It would make Sage 1.6 MB larger
> * It would slow builds on any system where the Sage gcc was used in
> preference to a system one.
Building gcc takes a huge amount of time. I guess it could easily
double the total build-from-scratch time fo
On 14 Dez., 06:30, leif wrote:
> An absolutely great idea.
>
> One problem remains: If we ship a more recent GCC, we still need to
> build GMP/MPIR, perhaps also MPFR and MPC, with the system's C
> compiler, preferably some GCC version, at least for bootstrapping our
> compiler.
>
> (Btw., I faile
30 matches
Mail list logo
