On Mar 12, 11:36 am, Julien PUYDT wrote:
> Help, comments and ideas are welcome.
Are the changes at
"Rewrite ATLAS spkg-install"
http://trac.sagemath.org/sage_trac/ticket/10226
helpful or relevant with the ATLAS install/build?
Rob
--
To post to this group, send an email to sage-devel@google
On Mar 12, 7:23 am, Volker Braun wrote:
> On Saturday, March 12, 2011 1:49:40 PM UTC, Dr. David Kirkby wrote:
>
> > There have been several instances of where doctests have been found to be
> > wrong,
>
> There have been several instances where stated results in published papers
> have been found
As I've mentioned on a related thread, I think that increasing the quality
of doctests is a valuable goal, but that we shouldn't add more impediments
to getting code accepted into Sage. In particular, I'm strongly against
requiring such justifications for each doctest before code can get a
positiv
Hi,
the title is a little pun : the ARM support isn't really broken since it
was never there anyway in the first place.
I took sage-4.6.2's sources and tried to build it on my ARM netbook ; it
tooks two days as usual, and three spkg are still problematic (by
alphabetical order) :
- atlas (h
On Mar 12, 6:23 am, Volker Braun wrote:
> In the long run I feel that it is more productive to have code released to
> expose it to a larger audience so that they can use it with examples they
> are familiar. Release early, and release often :-)
+1
I wrote the doctest below last night for a comm
On 03/12/11 02:23 PM, Volker Braun wrote:
On Saturday, March 12, 2011 1:49:40 PM UTC, Dr. David Kirkby wrote:
There have been several instances of where doctests have been found to be
wrong,
There have been several instances where stated results in published papers
have been found to be wron
On Saturday, March 12, 2011 1:49:40 PM UTC, Dr. David Kirkby wrote:
>
> There have been several instances of where doctests have been found to be
> wrong,
>
There have been several instances where stated results in published papers
have been found to be wrong :-)
Just because you quote some pa
I agree that thats the only valid question here: is f(x=2,y=3) substitution
or evaluation? The call syntax suggests evaluation, but keywords allow you
to only substitute some variables. I'm tempted to say that since its not
obvious we shouldn't have the function at all, that is, don't allow keyw
On 03/12/11 09:56 AM, Jeroen Demeyer wrote:
On 2011-03-12 09:56, David Kirkby wrote:
I propose that when a doctest is written, there should be a comment in
the code, substantiating why the "Expected" result is correct. That
might take the form of at least all of the following, with hopefully
not
Cool, thanks!
--
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 options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
On 2011-03-12 09:56, David Kirkby wrote:
> I propose that when a doctest is written, there should be a comment in
> the code, substantiating why the "Expected" result is correct. That
> might take the form of at least all of the following, with hopefully
> not too many of #7.
I agree that your ide
On 12 March 2011 08:56, David Kirkby wrote:
> I propose that when a doctest is written, there should be a comment in
> the code, substantiating why the "Expected" result is correct. That
> might take the form of at least all of the following, with hopefully
> not too many of #7.
Oops, I mean not
It concerns me that in many cases the "doctests" in Sage are not
really testing the validity of the implementation in Sage, but testing
the reproducibility of that implementation. Whether the "Expected"
result is actually correct is not always tested.
I propose that when a doctest is written, ther
13 matches
Mail list logo