That would be awesome! In fact, within emacs (sage-mode) I also get all
the underscored methods, which I don't like at all. I should ask about
that...
Am Mittwoch, 13. April 2016 23:12:37 UTC+2 schrieb mmarco:
>
> That's a valid point. Maybe there is a middle option that could combine
> the b
Hi Martin,
On 2016-04-13, 'Martin R' via sage-devel wrote:
> A thought: it might in fact be a feature that tab completion *does* show
> methods which only work with optional packages. I usually try
> tab-completion first. I won't mind at all hitting an error message "Please
> install the opt
Hi Jeroen,
On 2016-04-14, Jeroen Demeyer wrote:
> On 2016-04-14 00:00, Simon King wrote:
>> If I understand correctly, such a decorator would not work in Cython code.
>
> Why not? Cython supports decorators.
I occasionally got errors telling me that Cython does not support
arbitrary decorators.
Hi Nils,
On 2016-04-14, Nils Bruin wrote:
> What can we do to make this more consistent?
Deprecate polynomial rings whose coefficient ring is a polynomial ring?
Convert it to multivariate rings on the fly?
Or more seriously:
First of all, the construction
sage: ZZ['x']['x']
Univariate Polyn
On 2016-04-14 08:58, Nils Bruin wrote:
Univariate polynomial rings seem to convert into each other by basically
just converting coefficient vectors. Unfortunately, this leads to
results that are at odds with sage's concept that conversions are done
by looking at variable names:
sage: S.=ZZ[]
sag
On Tue, Apr 12, 2016 at 4:11 PM, kcrisman wrote:
> This has been an interesting thread. In the end, I think that some (or a
> lot) of Sage's attractiveness to end users goes away if it becomes a bunch
> of possibly-updated packages that might or might not work with a current
> version of Sage. I
On Tue, Apr 12, 2016 at 7:33 PM, William Stein wrote:
> On Tue, Apr 12, 2016 at 7:11 AM, kcrisman wrote:
>> This has been an interesting thread. In the end, I think that some (or a
>> lot) of Sage's attractiveness to end users goes away if it becomes a bunch
>> of possibly-updated packages that
On Tue, Apr 12, 2016 at 9:58 PM, William Stein wrote:
> On Tue, Apr 12, 2016 at 12:50 PM, kcrisman wrote:
>> You are right, as I apparently
>> didn't make clear, that it would be even better to have people more easily
>> able to have separate packages that are quite narrow - and I think that a
>>
On Wed, Apr 13, 2016 at 9:46 AM, Jeroen Demeyer wrote:
> On 2016-04-05 20:44, William Stein wrote:
>>
>> I am recommending to absolutely everybody I talk with about Sage
>> development that we switch from our current massive monolithic
>> centralized approach toward standard open source practices.
A really important point (which so far hasn't been addressed) is how to
deal with breakages of affiliated packages. I see two ways:
1. If I make a change to some core package, it is my responsibility to
ensure that no affiliated package breaks.
2. It is the responsibility of the affiliated pa
>
>
> I think these are some thoughtful comments, but I also think this is
>
Thanks.
> partly missing the point. This discussion isn't (necessarily) about
> how Sage is packaged and presented for the average user. One can
> certainly put together a metapackage containing all the bells and
On Thu, Apr 14, 2016 at 3:21 PM, Jeroen Demeyer wrote:
> A really important point (which so far hasn't been addressed) is how to deal
> with breakages of affiliated packages. I see two ways:
These are good questions.
> 1. If I make a change to some core package, it is my responsibility to
> ensu
On Thu, Apr 14, 2016 at 3:26 PM, kcrisman wrote:
>>
>> I think these are some thoughtful comments, but I also think this is
>
>
> Thanks.
>
>>
>> partly missing the point. This discussion isn't (necessarily) about
>> how Sage is packaged and presented for the average user. One can
>> certainly p
On 14 April 2016 at 15:51, Erik Bray wrote:
> I disagree that Sage is all that special. Or at least, I don't
> believe there's any need for it to be, whether or not it is currently.
>
If the past is any indication, you will find some cultural resistance about
this point in the Sage community. S
On 04/14/2016 09:21 AM, Jeroen Demeyer wrote:
> A really important point (which so far hasn't been addressed) is how to
> deal with breakages of affiliated packages. I see two ways:
>
> 1. If I make a change to some core package, it is my responsibility to
> ensure that no affiliated package bre
On Thursday, April 14, 2016 at 1:47:01 AM UTC-7, Simon King wrote:
>
> Or more seriously:
> First of all, the construction
> sage: ZZ['x']['x']
> Univariate Polynomial Ring in x over Univariate Polynomial Ring in x
> over Integer Ring
> where there is a name clash should result in an error
On Thursday, April 14, 2016 at 1:52:37 AM UTC-7, Jeroen Demeyer wrote:
>
> I like it exactly the way it is. If you explicitly ask for a polynomial
> over a polynomial, this is the expected answer.
>
It is at odds with the behaviour for multivariate polynomials, though.
The other surprising par
On 2016-04-14 15:46, Erik Bray wrote:
If truly nobody can maintain an affiliated package
anymore it might die. And that's a problem since it might mean loss of
functionality for users
A logical conclusion from the above that it's a simply a bad idea to
split up Sage into separate packages unle
On 2016-04-14 17:21, Nils Bruin wrote:
On Thursday, April 14, 2016 at 1:52:37 AM UTC-7, Jeroen Demeyer wrote:
I like it exactly the way it is. If you explicitly ask for a polynomial
over a polynomial, this is the expected answer.
It is at odds with the behaviour for multivariate polynom
On Thu, Apr 14, 2016 at 5:25 PM, Jeroen Demeyer wrote:
> On 2016-04-14 15:46, Erik Bray wrote:
>>
>> If truly nobody can maintain an affiliated package
>> anymore it might die. And that's a problem since it might mean loss of
>> functionality for users
>
>
> A logical conclusion from the above tha
On 2016-04-14 17:38, Erik Bray wrote:
Sage already has the problem of large
chunks of code that are effectively unmaintained and create a
maintenance burden on anyone serious about maintaining sage. Their
interfaces whither, and become inconsistent with the rest of the
package. It's dead weight
On Thursday, April 14, 2016 at 8:28:22 AM UTC-7, Jeroen Demeyer wrote:
>
>
> True, but a polynomial with polynomial coefficients is a very different
> thing than a multi-variate polynomial. Therefore, it's perfectly fine if
> they behave differently.
>
OK. I misremembered. I thought towers of m
On Thursday, April 14, 2016, Francesco Biscani wrote:
> On 14 April 2016 at 15:51, Erik Bray > wrote:
>
>> I disagree that Sage is all that special. Or at least, I don't
>> believe there's any need for it to be, whether or not it is currently.
>>
>
> If the past is any indication, you will find
On 2016-04-14 20:35, William Stein wrote:
However I'm only now starting to complain loudly and
repeatedly just because I'm seeing such a huge wasted opportunity.
Instead of complaining, why don't you put together a more concrete and
technical proposal of what you actually want? Because this th
On Thu, Apr 14, 2016 at 12:23 PM, Jeroen Demeyer wrote:
> On 2016-04-14 20:35, William Stein wrote:
>>
>> However I'm only now starting to complain loudly and
>> repeatedly just because I'm seeing such a huge wasted opportunity.
>
>
> Instead of complaining, why don't you put together a more concr
On 14/04/16 16:32, William Stein wrote:
On Thu, Apr 14, 2016 at 12:23 PM, Jeroen Demeyer wrote:
On 2016-04-14 20:35, William Stein wrote:
However I'm only now starting to complain loudly and
repeatedly just because I'm seeing such a huge wasted opportunity.
Instead of complaining, why don'
On Thu, Apr 14, 2016 at 12:41 PM, Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
> On 14/04/16 16:32, William Stein wrote:
>>
>> On Thu, Apr 14, 2016 at 12:23 PM, Jeroen Demeyer
>> wrote:
>>>
>>> On 2016-04-14 20:35, William Stein wrote:
However I'm only now starting to compla
As a postscript, see http://trac.sagemath.org/ticket/11590#comment:19 where
it looks like at least this issue has been fixed upstream! Thanks, Robert.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiv
(Disclaimer: I haven't yet read this entire thread when writing my
response.)
Chris -- who wrote abelfunctions -- is a Univ of Wash grad student I
> know. I recently ran into him and he told me that he had spent years
> writing this package as a standard Python package depending on sympy
> (m
> > These packages are nearly impossible to found from the sagemath website!
>
> Chris -- who wrote abelfunctions -- is a Univ of Wash grad student I
> know. I recently ran into him and he told me that he had spent years
>
This is a good point; we could use more infrastructure for supporting
On 2016-04-07, Dmitry Sokolov wrote:
> var('t')
> f=sin(t)*atan2(2*sin(t),1-2*cos(t))
> version()
> print "numeric integral: ", numerical_integral(f,0,pi)[0]
> print "symbolic integral: ", integrate(f,(t,0,pi))
>
>
>|t|'SageMath Version 6.10, Release Date: 2015-12-18'|numeric integral:
>2.35619
On Thursday, April 14, 2016 at 8:35:29 PM UTC+2, William wrote:
>
> apply normal software development practices!!
You mean like in the Linux kernel? A project which, by the way, is a)
extremely anal about having a stable API (=posix) and b) very clear about
what is not going to be stable.
I felt like writing this up:
https://gist.github.com/cswiercz/c632d920565a2da519b73bd2b79d7920
Please suggest improvements and corrections.
--
Chris
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receivi
On Wed, Apr 13, 2016 at 10:56:48AM -0700, mmarco wrote:
>I was thinking of something much deeper, something like:
>@optional('eggs')
>def spam():
>"""
> docstring with the corresponding doctests
>"""
>blah
>And then, several things happen:
> 1. The
On Friday, April 15, 2016 at 6:54:44 AM UTC+9, kcrisman wrote:
>
>
> > These packages are nearly impossible to found from the sagemath website!
>>
>> Chris -- who wrote abelfunctions -- is a Univ of Wash grad student I
>> know. I recently ran into him and he told me that he had spent years
>>
On Friday, April 15, 2016 at 8:46:44 AM UTC+9, Chris Swierczewski wrote:
>
> I felt like writing this up:
>
> https://gist.github.com/cswiercz/c632d920565a2da519b73bd2b79d7920
>
> Please suggest improvements and corrections.
>
Sorry. I didn't see your post before I wrote mine :-) That is a nice s
On Thu, Apr 14, 2016 at 6:38 PM, Kwankyu Lee wrote:
>
>
> On Friday, April 15, 2016 at 6:54:44 AM UTC+9, kcrisman wrote:
>>
>>
>>> > These packages are nearly impossible to found from the sagemath
>>> > website!
>>>
>>> Chris -- who wrote abelfunctions -- is a Univ of Wash grad student I
>>> know.
>
>
> Chris started with something here:
>
> https://gist.github.com/cswiercz/c632d920565a2da519b73bd2b79d7920
>
>
Honestly, this could be of great use also for something intended
'immediately' for the Sage library too, very nicely put together thus far.
> Rather than a section of the s
On 2016-04-14 21:32, William Stein wrote:
So I wonder if you think
that, say, elliptic curves should be a separate package too?
I'm not lowering the fact/opinion ratio further...
I would at least help to understand what exactly it is that you are
proposing. You keep using the words "normal s
Hi Nicolas,
On 2016-04-14, Nicolas M. Thiery wrote:
> So now we have (at least) the following proposals:
>
> 1. a decorator applying to the full docstring
> 2. a markup applying to everything below in the docstring (e.g. .. OPTIONAL::
> gap)
> 3. a markup applying to a single block of code
> 4.
40 matches
Mail list logo
