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.
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
>
>
> 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 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.
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 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 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
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 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.
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
> > 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
(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
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
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
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: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 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 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 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 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 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: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 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 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 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 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 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 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 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
>
>
> 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
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
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.
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 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 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 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
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
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 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
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
40 matches
Mail list logo
