To respond to the OP: I'm all for getting rid of these functions.
"Nicolas M. Thiery" writes:
> Also, the idiom ``is_Field(P)`` would be best replaced by ``P in Fields()``.
As a beginner I might wonder, "Why is it `5/1 in ZZ` but `ZZ in
Fields()`? Why not `5/1 in ZZ()` or `ZZ in Fields`?"
These
On Tue, 27 Mar 2012 18:15:17 R. Andrew Ohana wrote:
> This is now at http://trac.sagemath.org/sage_trac/ticket/12763, and
> need review :).
>
Done. Thanks for the quick fix.
Francois
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an e
This is now at http://trac.sagemath.org/sage_trac/ticket/12763, and
need review :).
On Tue, Mar 27, 2012 at 18:08, François Bissey
wrote:
> On Tue, 27 Mar 2012 18:06:31 R. Andrew Ohana wrote:
>> Sorry, this is my bad, did you open a ticket for this issue?
>>
> Not, I am glad you seem to have an i
On Tue, 27 Mar 2012 18:06:31 R. Andrew Ohana wrote:
> Sorry, this is my bad, did you open a ticket for this issue?
>
Not, I am glad you seem to have an idea of what's going on.
If you open one I'll happilly review it.
Francois
--
To post to this group, send an email to sage-devel@googlegroups.c
Sorry, this is my bad, did you open a ticket for this issue?
On Tue, Mar 27, 2012 at 17:34, François Bissey
wrote:
> Hi,
>
> Something I noticed with sage-on-gentoo but would also affect
> anyone installing sage as root to make it available on the system.
> In http://trac.sagemath.org/sage_trac/t
On 2012-03-27, David Loeffler wrote:
> --=_Part_1845_21496564.1332870376547
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tuesday, 27 March 2012 17:03:12 UTC+1, Dima Pasechnik wrote:
>>
>> On 2012-03-27, leif wrote:
>> > On 27 Mrz., 17:29, leif wrote:
>> >> On 27 Mrz., 15:39, Volker
Hi,
Something I noticed with sage-on-gentoo but would also affect
anyone installing sage as root to make it available on the system.
In http://trac.sagemath.org/sage_trac/ticket/12644
the installation of ellcurves has been altered and I am not sure
how to fix it.
In elliptic_curves-0.3 we have t
On Tue, Mar 27, 2012 at 10:29:12AM -0700, Starx wrote:
> ...
+1 on reducing the number of is_... functions.
> As for the other 150, some of them do the following:
>
> def is_Name(x)
>return isinstance(x, Name_something)
>
> I didn't check but I suspect that there is a factory called Name wh
On 03/27/2012 02:10 PM, Jeroen Demeyer wrote:
On 2012-03-27 20:05, Stephen Montgomery-Smith wrote:
Actually the error appeared with beta9. The error seems to have
disappeared with beta10.
Are you *sure* it was beta9 and not an earlier version? There was a
change in Linbox in sage-5.0.beta8 wh
> On Tue, Mar 27, 2012 at 6:10 PM, John H Palmieri
> wrote:
> > This topic has been brought up here before as side notes in various
> threads,
> > but I'd like to discuss it more officially:
> >
> > Should we remove MoinMoin as a standard package?
>
[X] Yes
[ ] No
> If "yes", I'm assuming we
On Tue, Mar 27, 2012 at 10:10 AM, John H Palmieri
wrote:
> This topic has been brought up here before as side notes in various threads,
> but I'd like to discuss it more officially:
>
> Should we remove MoinMoin as a standard package?
>
> [X] Yes
> [ ] No
>
> If "yes", I'm assuming we should make
On Tue, Mar 27, 2012 at 6:10 PM, John H Palmieri wrote:
> This topic has been brought up here before as side notes in various threads,
> but I'd like to discuss it more officially:
>
> Should we remove MoinMoin as a standard package?
>
[X] Yes
> [ ] No
>
> If "yes", I'm assuming we should make it
On Tuesday, 27 March 2012 19:10:50 UTC+2, John H Palmieri wrote:
>
> This topic has been brought up here before as side notes in various
> threads, but I'd like to discuss it more officially:
>
> Should we remove MoinMoin as a standard package?
>
> [x ] Yes
> [ ] No
>
> If "yes", I'm assuming we
On 2012-03-27 20:05, Stephen Montgomery-Smith wrote:
> Actually the error appeared with beta9. The error seems to have
> disappeared with beta10.
Are you *sure* it was beta9 and not an earlier version? There was a
change in Linbox in sage-5.0.beta8 which might have fixed your problem,
but not in
On 03/27/12 13:10, John H Palmieri wrote:
> This topic has been brought up here before as side notes in various
> threads, but I'd like to discuss it more officially:
>
> Should we remove MoinMoin as a standard package?
>
[X] Yes
[X] Get rid of altogether
--
To post to this group, send an emai
Le mardi 27 mars, John H Palmieri a écrit:
> Should we remove MoinMoin as a standard package?
Yes.
> Or does anyone support getting rid of it altogether?
Get rid of it altogether.
Snark on #sagemath
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from thi
> How much are these functions used in the Sage library?
Not counting definitions, imports, or doctests, "is_[A-Z]" matches 807
times in the source. So I would definitely be writing a script to
remove whatever we decide to remove, and then make sure it builds and
tests, and read through the diff
On Tuesday, March 27, 2012 10:34:12 AM UTC-7, leif wrote:
>
> On 27 Mrz., 19:19, Jason Grout wrote:
> > On 3/27/12 12:10 PM, John H Palmieri wrote:
> >
> > > This topic has been brought up here before as side notes in various
> > > threads, but I'd like to discuss it more officially:
> >
>
On 03/27/2012 10:58 AM, Jeroen Demeyer wrote:
On 2012-03-27 17:52, Stephen Montgomery-Smith wrote:
I am attempting to compile sage-5.0.beta10. I see there is a new patch
in linbox for commentator.C. But it is not working for me.
Could you at least say why it's not working? How does it fail?
How much are these functions used in the Sage library? I would be
supportive of removing them all if possible
David
On Tue, Mar 27, 2012 at 18:29, Starx wrote:
> This discussion stems from:
>
> http://groups.google.com/group/sage-devel/browse_thread/thread/979bdce4e002cd05/e8061b2ff21a4cdf?
On Tuesday, 27 March 2012 17:03:12 UTC+1, Dima Pasechnik wrote:
>
> On 2012-03-27, leif wrote:
> > On 27 Mrz., 17:29, leif wrote:
> >> On 27 Mrz., 15:39, Volker Braun wrote:
> >>
> >> > The current state is that we build static atlas with and without
> threads,
> >> > and the shared library wit
On 27 Mrz., 19:19, Jason Grout wrote:
> On 3/27/12 12:10 PM, John H Palmieri wrote:
>
> > This topic has been brought up here before as side notes in various
> > threads, but I'd like to discuss it more officially:
>
> > Should we remove MoinMoin as a standard package?
>
> > [ ] Yes
> > [ ] No
>
>
Actually I think deleting the is_functions deserves it's own thread,
so ignore my last message and see:
http://groups.google.com/group/sage-devel/browse_thread/thread/e8c2470e270f616b
-Jim
On Tue, Mar 27, 2012 at 10:06 AM, Starx wrote:
> There are 260 functions defined in Sage of the form def is
This discussion stems from:
http://groups.google.com/group/sage-devel/browse_thread/thread/979bdce4e002cd05/e8061b2ff21a4cdf?lnk=gst&q=is_AlgebraElement#e8061b2ff21a4cdf
I decided it deserves it's own thread.
The is_functions (is_Integer, is_AlgebraElement, ect) are depreciated
and have been for 4
On 3/27/12 12:10 PM, John H Palmieri wrote:
This topic has been brought up here before as side notes in various
threads, but I'd like to discuss it more officially:
Should we remove MoinMoin as a standard package?
[ ] Yes
[ ] No
Yes
If "yes", I'm assuming we should make it an optional pack
This topic has been brought up here before as side notes in various
threads, but I'd like to discuss it more officially:
Should we remove MoinMoin as a standard package?
[ ] Yes
[ ] No
If "yes", I'm assuming we should make it an optional package instead. Or
does anyone support getting rid of i
There are 260 functions defined in Sage of the form def is_Name(x)
where Name starts with a capitol letter (my script didn't count the
cdef functions so there might actually be more). Of those 110 of them
simply return isinstance(x, Name) and I think those 110 can definitely
be deleted. Deleting
Hi!
The latest version of my group cohomology spkg is 2.1.2. However, the
current "officially Sage-approved" version is 2.0, which is more than
a year old -- hence, if you do install_package("p_group_cohomology"),
you would get version 2.0, not 2.1.2.
Problem: With recent versions of Sage (since
On 03/27/2012 11:03 AM, leif wrote:
On 27 Mrz., 17:52, Stephen Montgomery-Smith
wrote:
I am attempting to compile sage-5.0.beta10. I see there is a new patch
in linbox for commentator.C. But it is not working for me.
The attached patch did work for me, and I was wondering if it would be a
pro
On Mar 27, 12:03 pm, leif wrote:
> On 27 Mrz., 17:52, Stephen Montgomery-Smith
> wrote:
>
> > I am attempting to compile sage-5.0.beta10. I see there is a new patch
> > in linbox for commentator.C. But it is not working for me.
>
> > The attached patch did work for me, and I was wondering if
On 2012-03-27, leif wrote:
> On 27 Mrz., 17:29, leif wrote:
>> On 27 Mrz., 15:39, Volker Braun wrote:
>>
>> > The current state is that we build static atlas with and without threads,
>> > and the shared library without threads only. And our module_list.py links
>> > with the single-threaded atl
On 27 Mrz., 17:52, Stephen Montgomery-Smith
wrote:
> I am attempting to compile sage-5.0.beta10. I see there is a new patch
> in linbox for commentator.C. But it is not working for me.
>
> The attached patch did work for me, and I was wondering if it would be a
> problem for anyone else if this
On 2012-03-27 17:52, Stephen Montgomery-Smith wrote:
> I am attempting to compile sage-5.0.beta10. I see there is a new patch
> in linbox for commentator.C. But it is not working for me.
Could you at least say why it's not working? How does it fail?
--
To post to this group, send an email to s
On 27 Mrz., 17:51, Volker Braun wrote:
> If thats the case then its by mistake; The spkg-install file calls "make
> shared cshared" and not "make ptshared cptshared" to build the shared
> libraries. Incidentally, which distribution is that? You are not using the
> gentoo ebuild, are you?
It's Ubu
I am attempting to compile sage-5.0.beta10. I see there is a new patch
in linbox for commentator.C. But it is not working for me.
The attached patch did work for me, and I was wondering if it would be a
problem for anyone else if this patch was used instead. This is a
replacement for linbox
If thats the case then its by mistake; The spkg-install file calls "make
shared cshared" and not "make ptshared cptshared" to build the shared
libraries. Incidentally, which distribution is that? You are not using the
gentoo ebuild, are you?
On Tuesday, March 27, 2012 4:41:56 PM UTC+1, leif
On 27 Mrz., 17:29, leif wrote:
> On 27 Mrz., 15:39, Volker Braun wrote:
>
> > The current state is that we build static atlas with and without threads,
> > and the shared library without threads only. And our module_list.py links
> > with the single-threaded atlas shared library only. So Sage wil
On 27 Mrz., 15:39, Volker Braun wrote:
> The current state is that we build static atlas with and without threads,
> and the shared library without threads only. And our module_list.py links
> with the single-threaded atlas shared library only. So Sage will use the
> single-threaded version if you
> More importantly, what happens if coercion etc. fails? Will Sage then
> potentially make false mathematical statements, or raise an
> exception / return "unknown" or "undecidable" etc.
No. It catches the ValueErrors and TypeErrors, and returns False (so
ZZ['x'].gen() is not in QQ).
David
--
On 27 Mrz., 10:14, Simon King wrote:
> Hi Keshav,
>
> On 2012-03-26, Keshav Kini wrote:
>
> > Simon King writes:
> >> sage: is_Integer(int(5))
> >> False
> >> sage: is_Integer(5/1)
> >> False
> >> sage: int(5) in ZZ
> >> True
> >> sage: 5/1 in ZZ
> >> True
>
> > Huh. It seems lik
I do agree that we should use a parallel blas whenever possible, I just
wanted to give the rationale why atlas defaults to single-threaded ;-)
On Tuesday, March 27, 2012 2:48:15 PM UTC+1, William wrote:
>
> On Tue, Mar 27, 2012 at 2:39 PM, Volker Braun
> wrote:
> > The current state is that w
Yes, the sylvester matrix is not the most efficient, but in this small
example seemed like the easiest way to convey my point.
So this is really a matter of context and is expected behavior?
If so, that means the trac ticket I filed: Ticket #12752 is not
actually a defect, but is really an enhanc
On 2012-03-27, Volker Braun wrote:
> The current state is that we build static atlas with and without threads,
> and the shared library without threads only. And our module_list.py links
> with the single-threaded atlas shared library only. So Sage will use the
> single-threaded version if you
On Tue, Mar 27, 2012 at 2:39 PM, Volker Braun wrote:
> The current state is that we build static atlas with and without threads,
> and the shared library without threads only. And our module_list.py links
> with the single-threaded atlas shared library only. So Sage will use the
> single-threaded
The current state is that we build static atlas with and without threads,
and the shared library without threads only. And our module_list.py links
with the single-threaded atlas shared library only. So Sage will use the
single-threaded version if you build atlas yourself.
If you use the os-pro
On Tue, Mar 27, 2012 at 12:39 PM, Volker Braun wrote:
> When I rewrote the atlas spkg I enabled multithreaded atlas libraries. That
> is, we configure atlas to allow threading. Whether or not atlas actually
> builds threaded libraries depends on os and configure checks for ptthreads.
Does it work
On Tue, Mar 27, 2012 at 1:52 PM, Jason Grout
wrote:
> On 3/27/12 7:47 AM, Burcin Erocal wrote:
>>
>> This happened to me as well. I could still change the options even
>> though I don't use a gmail address. I fixed your membership options
>> nevertheless.
>
>
> How did you change your options? Is
On Tue, 27 Mar 2012 07:52:10 -0500
Jason Grout wrote:
> On 3/27/12 7:47 AM, Burcin Erocal wrote:
> > This happened to me as well. I could still change the options even
> > though I don't use a gmail address. I fixed your membership options
> > nevertheless.
>
> How did you change your options?
On 3/27/12 7:47 AM, Burcin Erocal wrote:
This happened to me as well. I could still change the options even
though I don't use a gmail address. I fixed your membership options
nevertheless.
How did you change your options? Is there a way to email commands to
google groups?
Thanks,
Jason
On Tue, 27 Mar 2012 07:36:40 -0500
Jason Grout wrote:
> On 3/27/12 4:13 AM, William Stein wrote:
> > On Tue, Mar 27, 2012 at 10:12 AM, Ivan
> > Andrus wrote:
> >> FWIW, when I subscribed to this list I apparently signed up for
> >> the "no email" option (though I would never have done such a thi
Done
On Tuesday, March 27, 2012 1:36:40 PM UTC+1, jason wrote:
>
> Can someone change my email options to deliver email?
>
--
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
For more opt
On 3/27/12 4:13 AM, William Stein wrote:
On Tue, Mar 27, 2012 at 10:12 AM, Ivan Andrus wrote:
FWIW, when I subscribed to this list I apparently signed up for the "no email"
option (though I would never have done such a thing consciously). So if you are wondering
why you didn't get any email t
When I rewrote the atlas spkg I enabled multithreaded atlas libraries. That
is, we configure atlas to allow threading. Whether or not atlas actually
builds threaded libraries depends on os and configure checks for ptthreads.
>
--
To post to this group, send an email to sage-devel@googlegroups
On Tue, Mar 27, 2012 at 10:12 AM, Ivan Andrus wrote:
> FWIW, when I subscribed to this list I apparently signed up for the "no
> email" option (though I would never have done such a thing consciously). So
> if you are wondering why you didn't get any email that may be why.
>
The same happened t
FWIW, when I subscribed to this list I apparently signed up for the "no email"
option (though I would never have done such a thing consciously). So if you are
wondering why you didn't get any email that may be why.
-Ivan
On Mar 26, 2012, at 7:30 PM, Jason Grout wrote:
> I'll just remind people
I proposed a standard MPC (multi-precision complex numbers) package at
#12515, which is a dependency of GCC (#12369). It got positive_review,
but further testing revealed problems compiling MPC on systems with an
old glibc. I discovered this was due to the -D_FORTIFY_SOURCE=2 flag.
There is a new
Hi Keshav,
On 2012-03-26, Keshav Kini wrote:
> Simon King writes:
>> sage: is_Integer(int(5))
>> False
>> sage: is_Integer(5/1)
>> False
>> sage: int(5) in ZZ
>> True
>> sage: 5/1 in ZZ
>> True
>
> Huh. It seems like this is the opposite of what you'd expect, doesn't
> it? "objec
Blocker ticket #12742 needs review. It adds matplotlib as dependency of
cvxopt. cvxopt's sage-check will fail without matplotlib installed.
Please review this one-line patch:
http://trac.sagemath.org/sage_trac/ticket/12742
--
To post to this group, send an email to sage-devel@googlegroups.com
58 matches
Mail list logo
