Try for example ZZ.random_element? in the notebook. Reading is hard, as
the output of one example is very long. Is there something to do for this?
--
Jori Mäntysalo
> > Oh dear. abs_integrate is something I now dread to think about; it is
> so
> > very useful, and yet so very buggy with the Sage flags - see
> > http://trac.sagemath.org/ticket/12731 :-(
>
> Hmm, what are the flags that cause trouble? My guess is that the
> abs_integrate code was written
>
>> Well, reading this thread made me think that. Because I don't see how we
>> enforce all those "other pieces" working nicely together, so some would
>> (perhaps quite quickly) drop by the wayside. You are right, as I
>> apparently didn't make clear, that it would be even better to have p
Let me share some more thoughts on the interplay between modularization and
the review process. I'm afraid I'm going to be long... TL;DR:
modularization is good to keep Sage going forward.
Our review process discourages patchbombs, and for a reason. For one, no
one wants to review patchbombs. B
On Tuesday, April 12, 2016 at 10:12:19 PM UTC+1, Robert Dodier wrote:
>
> On 2016-04-12, kcrisman > wrote:
>
> > Oh dear. abs_integrate is something I now dread to think about; it is
> so
> > very useful, and yet so very buggy with the Sage flags - see
> > http://trac.sagemath.org/ticket/127
On Tue, Apr 12, 2016 at 09:14:44PM +0200, Nicolas M. Thiery wrote:
> On the other hand I am frustrated with the tone of sage-devel these
> days. I would really appreciate if e-mails would acknowledge others
> efforts; something like "thanks for the suggestion and for
> investigating how to implemen
On Tue, Apr 12, 2016 at 02:03:15AM -0700, mmarco wrote:
>I agree with Volker here. If the problem is that writing a
># optional blah
> at the end of each line that starts with
>sage:
> maybe limited to a certain portion of your file, that sounds like the
>kind of thing
On Tue, Apr 12, 2016 at 12:50 PM, kcrisman wrote:
> It doesn't mean that the normal visible
>> public API of Sage changes
>> at all. Why do you think otherwise?
>>
>
> Well, reading this thread made me think that. Because I don't see how we
> enforce all those "other pieces" working nicely to
On 2016-04-12, kcrisman wrote:
> Oh dear. abs_integrate is something I now dread to think about; it is so
> very useful, and yet so very buggy with the Sage flags - see
> http://trac.sagemath.org/ticket/12731 :-(
Hmm, what are the flags that cause trouble? My guess is that the
abs_integrate
On 04/12/2016 03:58 PM, William Stein wrote:
>
> It's all my fault originally, but I think I've learned something about
> software engineering during the last few years... and I think we're
> doing it wrong.
>
Don't be too hard on yourself. The fact that every function in Sage is
documented, tes
On Tuesday, April 12, 2016, Volker Braun wrote:
> On Tuesday, April 12, 2016 at 9:59:40 PM UTC+2, William wrote:
>>
>> We might also be able to make it available
>> outside Sage, and it could suddenly be of huge value to the Python
>> world.
>
>
> In other words: If we change our mission to "the
On Tuesday, April 12, 2016 at 9:59:40 PM UTC+2, William wrote:
>
> We might also be able to make it available
> outside Sage, and it could suddenly be of huge value to the Python
> world.
In other words: If we change our mission to "the most useful collection of
libraries" then we should split
On Tue, Apr 12, 2016 at 12:50 PM, kcrisman wrote:
>> It doesn't mean that the normal visible
>> public API of Sage changes
>> at all. Why do you think otherwise?
>
>
> Well, reading this thread made me think that. Because I don't see how we
> enforce all those "other pieces" working nicely tog
>
> It doesn't mean that the normal visible
> public API of Sage changes
> at all. Why do you think otherwise?
>
Well, reading this thread made me think that. Because I don't see how we
enforce all those "other pieces" working nicely together, so some would
(perhaps quite quickly) drop by
On Tuesday, April 12, 2016 at 2:50:01 PM UTC-4, Robert Dodier wrote:
>
> On 2016-04-09, Sergey V Kozlukov >
> wrote:
>
> > (%i1) f(r,phi) := signum(r^2 - 4);
> >2
> > (%o1) f(r, phi) := signum(r - 4)
> > (%i2) integrate(int
On 2016-04-07, Dmitry Sokolov wrote:
> When I run following code on cloud.sagemath.com I get two different results
> for numerical and symbolic integration, I guess it is a bug.
>
> var('t')
> f=sin(t)*atan2(2*sin(t),1-2*cos(t))
> version()
> print "numeric integral: ", numerical_integral(f,0,pi
On 2016-04-09, Sergey V Kozlukov wrote:
> (%i1) f(r,phi) := signum(r^2 - 4);
>2
> (%o1) f(r, phi) := signum(r - 4)
> (%i2) integrate(integrate(r*f(r,phi), r, 0, 3), phi, 0, 2*%pi);
> (%o2) - 9 %pi
>
On Monday, April 11, 2016 at 11:43:46 PM UTC+1, Volker Braun wrote:
>
> IMHO thats terrible; When you copy&paste an example it should either work
> or say very clear why it is optional.
>
I disagree. I remember that when my students saw sage documentation for the
first time they did not understan
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 might or might not work with a current
> version of Sage. I
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 always found the "with(plots)" syntax (or whatever it
On Tuesday, April 12, 2016 at 8:37:53 AM UTC+1, Jeroen Demeyer wrote:
>
> On 2016-04-12 00:04, Nicolas M. Thiery wrote:
> > Dear Sage developers,
> >
> > It's quite common that optional doctests come in batch, typically when
> > documenting a method that is only available when a cert
(1) Sage developers could be better informed of what are they are going to
affect if sage, as an "author tool", send usage statistics about each
"sage-lib" related function:
- Author should put sage in "send usage statistics mode"
- The same author would be warned if any of those functions star
On Tue, Apr 12, 2016 at 11:19 AM, Erik Bray wrote:
> On Mon, Apr 11, 2016 at 7:36 PM, Volker Braun wrote:
>> On Monday, April 11, 2016 at 3:00:12 PM UTC+2, Erik Bray wrote:
>>>
>>> It's no doubt very time consuming to check every merged pull request
>>
>>
>> Thats a great idea and scales really w
On Tue, 12 Apr 2016, Thierry wrote:
TESTS:
sage: M = ModularForms(1, 12)
i.e. missing a colon: should be TESTS::.
egrep -R '^ +TESTS:$' src/sage -A 2 | egrep 'sage:' | cut -f 1 -d - | sort -u
Be careful that it should be a multiline test, since the following are
allow
Hi,
On Tue, Apr 12, 2016 at 09:02:53AM +0300, Jori Mäntysalo wrote:
> For example src/sage/modular/modform/ambient.py contains function
> _compute_hecke_matrix_prime_power with docstring
>
> TESTS:
>
> sage: M = ModularForms(1, 12)
>
> i.e. missing a colon: should be TESTS::
On Mon, Apr 11, 2016 at 8:29 PM, Nils Bruin wrote:
> On Monday, April 11, 2016 at 10:46:59 AM UTC-7, Volker Braun wrote:
>>
>> On Monday, April 11, 2016 at 2:57:16 PM UTC+2, Erik Bray wrote:
>>>
>>> Sage, unfortunately, hasn't made many pacts in this regard
>>
>>
>> Sage does have a very clear way
On Mon, Apr 11, 2016 at 7:36 PM, Volker Braun wrote:
> On Monday, April 11, 2016 at 3:00:12 PM UTC+2, Erik Bray wrote:
>>
>> It's no doubt very time consuming to check every merged pull request
>
>
> Thats a great idea and scales really well when the project merges 5 branches
> a day. It will also
I agree with Volker here. If the problem is that writing a
# optional blah
at the end of each line that starts with
sage:
maybe limited to a certain portion of your file, that sounds like the
kind of thing you could easily do with some simple plugin for your
favourite text editor. Or
On 2016-04-12 08:02, Jori Mäntysalo wrote:
Will this test be run with ./sage -t?
More generally, such questions can easily be answered by the running the
doctests with the --verbose option.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To u
On 2016-04-12 00:04, Nicolas M. Thiery wrote:
Dear Sage developers,
It's quite common that optional doctests come in batch, typically when
documenting a method that is only available when a certain feature or
package is available.
Let me add something here: often, not *every* test req
On 2016-04-12 00:04, Nicolas M. Thiery wrote:
Dear Sage developers,
It's quite common that optional doctests come in batch, typically when
documenting a method that is only available when a certain feature or
package is available. Having to mark each and every test line with
`# optional
On 2016-04-12 08:02, Jori Mäntysalo wrote:
For example src/sage/modular/modform/ambient.py contains function
_compute_hecke_matrix_prime_power with docstring
TESTS:
sage: M = ModularForms(1, 12)
i.e. missing a colon: should be TESTS::.
Will this test be run with ./sage -
32 matches
Mail list logo
