[sage-devel] Re: Naming Conventions for Dirac Delta, Heaviside Theta and Unit Step

[Tim Lahey]

On Jun 24, 2009, at 1:57 AM, Maurizio wrote:


 I agree. We could do something like plotting all the deltas with a
 stem plot and then superimposing the rest of the plot

 Maurizio


It might give the wrong impression.


 On 24 Giu, 04:21, David Roe r...@math.harvard.edu wrote:
 One way would be to have a vertical ray that doesn't change the  
 scaling of
 the rest of the graph (just goes to the top of the viewing  
 window).  Not
 precisely accurate, but better than nothing.
 David

If you put arrows on the top, it might give the right impression.

However, I'd like plotting Dirac deltas to be optional. So, if you're  
plotting
something with Dirac deltas and other functions, you don't need to  
sift through
and remove the deltas before plotting.

Cheers,

Tim.

---
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo
http://www.linkedin.com/in/timlahey


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: A bug or mis-use ?

[William Stein]

On Wed, Jun 24, 2009 at 4:18 AM, Dr. David
Kirkbydavid.kir...@onetel.net wrote:

 Mike Hansen wrote:
 On Tue, Jun 23, 2009 at 6:23 PM, Dr. David
 Kirkbydavid.kir...@onetel.net wrote:
 exp(-x^i).integral(x,0,1)  returns

 Traceback (click to the left for traceback)
 ...
 Is %i an integer?

 Ouch! Any Sage comments?

Thanks for testing this.  It is good to know about, and I would think
it is definitely a bug in Maxima.


 This is just coming from Maxima:

 (%i3) integrate(exp(-x^(%i)),x,0,1);
 Is %i an integer?

 --Mike

 So it does appear a bit inconsistent, where i is reconised as sqrt(-1)
 at one time, and not at another.

A large amount of the symbolic functionality that uses Maxima has
issues like this, but unfortunately there is basically nothing we can
do about it, except continue with projects to rewrite the parts of
Sage that call Maxima so that they don't call Maxima.  So this class
of bugs should be very good motivation to continue to work on
implementing symbolic integration ourselves (and/or further improving
sympy!).

By the way, evidently one can no longer convert I=sqrt(-1) to sympy:

sage: (x+sqrt(2))._sympy_()
x + 2**(1/2)
sage: (x+I)._sympy_()
SympifyError: SympifyError: I is NOT a valid SymPy expression


Anyway, I see two trac tickets to report above, and I hope somebody
reports them, since I have to write a talk right now.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: #6343: Adds SageObject.check() generic testing framework

[Nicolas M. Thiery]

On Wed, Jun 24, 2009 at 12:01:58AM -0400, David Roe wrote:
 On Tue, Jun 23, 2009 at 7:08 PM, Nicolas M. Thiery nicolas.thi...@u-psud.fr 
 wrote:

 On Tue, Jun 23, 2009 at 10:29:34AM +0200, Franco Saliola wrote:
   I'm also in favor of _test_X to avoid cluttering up the tab
   completion. Another option to increase visibility would be to have a
   test object, e.g.
  
   sage: foo.test.associativity()
   True
 
  +1. I think it merges the two concerns together nicely (visibility and
  avoiding clutter).
 
 Thanks for the feedback! I agree that the syntax looks good.
 
 But, err, guys, are you telling *me* that you want an attribute here
 instead of a method? Or should this be:
 
 I'm fine with it as a lazy attribute.

Taking a good note of that :-)

 
foo.test().associativity?
 
 I also like the clean aspect of separating the test object. But one of
 the main point of doing this would be to stick more closely to the
 testunit framework. But then that would call for:
 
foo.test().test_associativity()
 
 which is not that nice anymore.
 
 Some other questions:
 
  - what syntax do you want to run all tests?
 
foo.check()
 
foo.test().run()
 
foo.test()   /   foo.test.associativity()
 
 
 foo.test().  The __call__ method on the test object runs the tests (would this
 work with a lazy attribute?  Yes, right?)

No problem. Well, I actually would just use a property rather than a
lazy_attribute, since there is no reason to cache the test object.

Do we have a consensus on this? 

  - Do we want to have the .test object appear for every sage object?
   i.e. 1.test (William was not that happy about this)

 What are some objects other than parents that would be making use of this?

I already have at least Categories and cartan types. There certainly
will be further objects which are in categories that do not derive
from Sets (at SD15, I discussed the design of some of those around
chain complexes). In general any Sage object which is not an element
is a good candidate (elements might not need that since one could
expect that they would be tested via their parents).

 Other concerns:
 
  - This adds yet another layer of complexity. The user has to learn
   that to implement foo.test.associativity, he should actually add a
   method _test_associativity in the class of foo (or some
   superclass). We want our users and developers to use and write lots
   of tests, so we have to keep it simple, s*d.
 
 No, the user just needs to write some_elements().  Or, if they wanted more
 control over how associativity was tested, they could write 
 _test_associativity
 (), but they wouldn't need to. 

Sorry, I meant: if a user/developer wants to add a new test_bla
functionality, he has to find out that he should implement _test_bla
in ...

   - I just don't have the time to implement this *now* (I probably
   could do the renaming .check - ._check and .test_bla to
   ._test_bla). Sorry, I have been advertising this feature for more
   than 3 months, and it would have been easier to reserve time for
   this earlier in the process ...
 
 Yeah, I know how that feels.  Sorry to contribute to that in the category
 review.  I'm working on it now.

Thanks! 
Nicolas
--
Nicolas M. Thiéry Isil nthi...@users.sf.net
http://Nicolas.Thiery.name/

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: #6343: Adds SageObject.check() generic testing framework

[William Stein]

On Wed, Jun 24, 2009 at 8:33 AM, Nicolas M.
Thierynicolas.thi...@u-psud.fr wrote:

 On Wed, Jun 24, 2009 at 12:01:58AM -0400, David Roe wrote:
 On Tue, Jun 23, 2009 at 7:08 PM, Nicolas M. Thiery 
 nicolas.thi...@u-psud.fr wrote:

     On Tue, Jun 23, 2009 at 10:29:34AM +0200, Franco Saliola wrote:
       I'm also in favor of _test_X to avoid cluttering up the tab
       completion. Another option to increase visibility would be to have a
       test object, e.g.
      
       sage: foo.test.associativity()
       True
     
      +1. I think it merges the two concerns together nicely (visibility and
      avoiding clutter).

     Thanks for the feedback! I agree that the syntax looks good.

     But, err, guys, are you telling *me* that you want an attribute here
     instead of a method? Or should this be:

 I'm fine with it as a lazy attribute.

 Taking a good note of that :-)


            foo.test().associativity?

     I also like the clean aspect of separating the test object. But one of
     the main point of doing this would be to stick more closely to the
     testunit framework. But then that would call for:

            foo.test().test_associativity()

     which is not that nice anymore.

     Some other questions:

      - what syntax do you want to run all tests?

            foo.check()

            foo.test().run()

            foo.test()   /   foo.test.associativity()


 foo.test().  The __call__ method on the test object runs the tests (would 
 this
 work with a lazy attribute?  Yes, right?)

 No problem. Well, I actually would just use a property rather than a
 lazy_attribute, since there is no reason to cache the test object.

 Do we have a consensus on this?

I am still opposed to adding a non-underscore method to SageObject.

I did like Robert Bradshaw's other suggestion to do something like the
following.

sage: Test(foo).associativity()

sage: Test?
[[descript testing framework]]

I.e., just create a Sage class Test, which gives access to the test
functionality, documents it, can even do something useful on objects
foo that aren't necessarily SageObjects at all, etc.

Test(obj) returns something that provides all kinds of functionality
and methods for testing said object.  This can call certain _ methods
on obj.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: #6343: Adds SageObject.check() generic testing framework

[Nicolas M. Thiery]

On Wed, Jun 24, 2009 at 08:49:20AM +0200, William Stein wrote:
 
 On Wed, Jun 24, 2009 at 8:33 AM, Nicolas M.
 Thierynicolas.thi...@u-psud.fr wrote:
 
  On Wed, Jun 24, 2009 at 12:01:58AM -0400, David Roe wrote:
  On Tue, Jun 23, 2009 at 7:08 PM, Nicolas M. Thiery 
  nicolas.thi...@u-psud.fr wrote:
 
      On Tue, Jun 23, 2009 at 10:29:34AM +0200, Franco Saliola wrote:
        I'm also in favor of _test_X to avoid cluttering up the tab
        completion. Another option to increase visibility would be to have 
  a
        test object, e.g.
       
        sage: foo.test.associativity()
        True
      
       +1. I think it merges the two concerns together nicely (visibility 
  and
       avoiding clutter).
 
      Thanks for the feedback! I agree that the syntax looks good.
 
      But, err, guys, are you telling *me* that you want an attribute here
      instead of a method? Or should this be:
 
  I'm fine with it as a lazy attribute.
 
  Taking a good note of that :-)
 
 
             foo.test().associativity?
 
      I also like the clean aspect of separating the test object. But one of
      the main point of doing this would be to stick more closely to the
      testunit framework. But then that would call for:
 
             foo.test().test_associativity()
 
      which is not that nice anymore.
 
      Some other questions:
 
       - what syntax do you want to run all tests?
 
             foo.check()
 
             foo.test().run()
 
             foo.test()   /   foo.test.associativity()
 
 
  foo.test().  The __call__ method on the test object runs the tests (would 
  this
  work with a lazy attribute?  Yes, right?)
 
  No problem. Well, I actually would just use a property rather than a
  lazy_attribute, since there is no reason to cache the test object.
 
  Do we have a consensus on this?
 
 I am still opposed to adding a non-underscore method to SageObject.
 
 I did like Robert Bradshaw's other suggestion to do something like the
 following.
 
 sage: Test(foo).associativity()
 
 sage: Test?
 [[descript testing framework]]
 
 I.e., just create a Sage class Test, which gives access to the test
 functionality, documents it, can even do something useful on objects
 foo that aren't necessarily SageObjects at all, etc.
 
 Test(obj) returns something that provides all kinds of functionality
 and methods for testing said object.  This can call certain _ methods
 on obj.

That would be fine for me too. The only thing I really care for is for
the actual test methods (._test...) to be attached to foo, and derived
from its classes.

What syntax would you suggest to run all tests?

One thing I am not very keen on is that to get the list of available
tests, one need to do:

sage: t = Test(foo)
sage: t.asstab

But I guess I can live with that (in practice, I myself will be using 
t._test_asstab)

Best,
Nicolas
--
Nicolas M. Thiéry Isil nthi...@users.sf.net
http://Nicolas.Thiery.name/

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: #6343: Adds SageObject.check() generic testing framework

[William Stein]

On Wed, Jun 24, 2009 at 9:18 AM, Nicolas M.
Thierynicolas.thi...@u-psud.fr wrote:

 On Wed, Jun 24, 2009 at 08:49:20AM +0200, William Stein wrote:

 On Wed, Jun 24, 2009 at 8:33 AM, Nicolas M.
 Thierynicolas.thi...@u-psud.fr wrote:
 
  On Wed, Jun 24, 2009 at 12:01:58AM -0400, David Roe wrote:
  On Tue, Jun 23, 2009 at 7:08 PM, Nicolas M. Thiery 
  nicolas.thi...@u-psud.fr wrote:
 
      On Tue, Jun 23, 2009 at 10:29:34AM +0200, Franco Saliola wrote:
        I'm also in favor of _test_X to avoid cluttering up the tab
        completion. Another option to increase visibility would be to 
  have a
        test object, e.g.
       
        sage: foo.test.associativity()
        True
      
       +1. I think it merges the two concerns together nicely (visibility 
  and
       avoiding clutter).
 
      Thanks for the feedback! I agree that the syntax looks good.
 
      But, err, guys, are you telling *me* that you want an attribute here
      instead of a method? Or should this be:
 
  I'm fine with it as a lazy attribute.
 
  Taking a good note of that :-)
 
 
             foo.test().associativity?
 
      I also like the clean aspect of separating the test object. But one of
      the main point of doing this would be to stick more closely to the
      testunit framework. But then that would call for:
 
             foo.test().test_associativity()
 
      which is not that nice anymore.
 
      Some other questions:
 
       - what syntax do you want to run all tests?
 
             foo.check()
 
             foo.test().run()
 
             foo.test()   /   foo.test.associativity()
 
 
  foo.test().  The __call__ method on the test object runs the tests (would 
  this
  work with a lazy attribute?  Yes, right?)
 
  No problem. Well, I actually would just use a property rather than a
  lazy_attribute, since there is no reason to cache the test object.
 
  Do we have a consensus on this?

 I am still opposed to adding a non-underscore method to SageObject.

 I did like Robert Bradshaw's other suggestion to do something like the
 following.

 sage: Test(foo).associativity()

 sage: Test?
 [[descript testing framework]]

 I.e., just create a Sage class Test, which gives access to the test
 functionality, documents it, can even do something useful on objects
 foo that aren't necessarily SageObjects at all, etc.

 Test(obj) returns something that provides all kinds of functionality
 and methods for testing said object.  This can call certain _ methods
 on obj.

 That would be fine for me too. The only thing I really care for is for
 the actual test methods (._test...) to be attached to foo, and derived
 from its classes.

 What syntax would you suggest to run all tests?

 One thing I am not very keen on is that to get the list of available
 tests, one need to do:

        sage: t = Test(foo)
        sage: t.asstab

 But I guess I can live with that (in practice, I myself will be using 
 t._test_asstab)

Yeah -- it seems that we have a consensus!

 - William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Sage 4.1.alpha0

[Robert Miller]

This is the first release of the new cycle, and I've agreed to step in
and co-chair the release with Tom. The source tarball and sage.math
binary are available:

http://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0.tar
http://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0-sage.math-only-x86_64-Linux.tar.gz

This is the first development release in which the new merge tools
were used by people other than the authors. Several doctests fail on
sage.math:

sage -t  devel/sage-main/sage/graphs/graph.py # 25 doctests
failed
sage -t  devel/sage-main/sage/databases/database.py # 20
doctests failed
sage -t  devel/sage-main/sage/geometry/polyhedra.py # 1
doctests failed

These are all due to the removal of graph_isom.pyx, and I will be
posting a patch to fix this shortly, at #6394. I think that there was
no way to avoid these failures, since the only way to expose them was
to remove the code, rebuild entirely from scratch, and then run the
tests.

This release does not include any tickets involving spkg's. I will
make this the main focus of alpha1, which should drop before Friday.

Each of the following tickets were rejected by the merge scripts, but
unfortunately the failures are not available at this time (this is due
to human error on my part). If you are involved with one of them, you
are encouraged to try applying the patches to 4.1.alpha0 and see why/
if they failed. Tom and I will eventually do this, but it would be
helpful for people involved in the ticket to get things started:

6196
5481
6276
4712
5517
5991
6164
6200
5902
6269

Other easy ways to save release managers time, resulting in more
frequent releases and shorter wait times to get your code merged:

* Please include the trac number in each commit message if possible.
* Please make sure Author and Reviewer fields are set, when changing
the ticket status to positive review. Since these are used in
generating release notes, please use full names.
* Please adhere to the trac_-description.patch filename format
when creating patch files.

Cheers,

Robert Miller (and Tom Boothby)

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 4.1.alpha0

[John Cremona]

2009/6/24 Robert Miller rlmills...@gmail.com:



6196 mpmath support
5481 devel/doc/output/* should be filtered from the list of files to doctest
6276 atlas-3.8.3.p2 dumps core on Solaris 10 with gcc 4.4.0
4712 Make the doctest timeouts in Sage easily adjustable
5517 cvxopt-0.9.p7: build failure due to missing perl modules
5991 Add a standard constructor for dynamic classes
6164 Phan's Mini-AES for educational purposes
6200 Use mpmath to compute constants
5902 Try SAGE_ROOT as base of argument to sage -t
6269 Coloring odds and ends

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 4.1.alpha0

[William Stein]

On Wed, Jun 24, 2009 at 2:04 PM, Robert Millerrlmills...@gmail.com wrote:

 This is the first release of the new cycle, and I've agreed to step in
 and co-chair the release with Tom. The source tarball and sage.math
 binary are available:

 http://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0.tar
 http://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0-sage.math-only-x86_64-Linux.tar.gz

 This is the first development release in which the new merge tools
 were used by people other than the authors. Several doctests fail on
 sage.math:

        sage -t  devel/sage-main/sage/graphs/graph.py # 25 doctests
 failed
        sage -t  devel/sage-main/sage/databases/database.py # 20
 doctests failed
        sage -t  devel/sage-main/sage/geometry/polyhedra.py # 1
 doctests failed

 These are all due to the removal of graph_isom.pyx, and I will be
 posting a patch to fix this shortly, at #6394. I think that there was
 no way to avoid these failures, since the only way to expose them was
 to remove the code, rebuild entirely from scratch, and then run the
 tests.

 This release does not include any tickets involving spkg's. I will
 make this the main focus of alpha1, which should drop before Friday.

 Each of the following tickets were rejected by the merge scripts, but
 unfortunately the failures are not available at this time (this is due
 to human error on my part). If you are involved with one of them, you
 are encouraged to try applying the patches to 4.1.alpha0 and see why/
 if they failed. Tom and I will eventually do this, but it would be
 helpful for people involved in the ticket to get things started:

 6196
 5481
 6276
 4712
 5517
 5991
 6164
 6200
 5902
 6269

 Other easy ways to save release managers time, resulting in more
 frequent releases and shorter wait times to get your code merged:

 * Please include the trac number in each commit message if possible.
 * Please make sure Author and Reviewer fields are set, when changing
 the ticket status to positive review. Since these are used in
 generating release notes, please use full names.
 * Please adhere to the trac_-description.patch filename format
 when creating patch files.

 Cheers,

 Robert Miller (and Tom Boothby)

Thanks.  I've started builds going on the build farm and two OS X boxes...

William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 4.1.alpha0

[kcrisman]

The source tarball and sage.math
 binary are available:

 http://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0.tarhttp://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0-s...

If you are involved with one of them, you
 are encouraged to try applying the patches to 4.1.alpha0 and see why/
 if they failed. Tom and I will eventually do this, but it would be
 helpful for people involved in the ticket to get things started:

Is there an -upgrade location to go to?

Thanks,
- kcrisman
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage on Wikipedia

[William Stein]

On Wed, Jun 24, 2009 at 3:15 AM, Dr. David
Kirkbydavid.kir...@onetel.net wrote:

 I think we should really make some effort to improve our page on Wikipedia.

 Comparing the Sage and Mathematica pages on Wikipedia shows the
 Mathematica one is much nicer. Would it not be sensible to put some
 effort into promoting Sage there? If it looks like the program is more
 complete, one has a greater chance of getting people using it and
 attracting more developers.

 As you know, I'm interested in porting sage to Solaris, as I'm a Solaris
 user and want to use it there. Hence I'm not a Sage user. Looking on the
 Mathematica Wikipedia entry, there is one person who definitely (and
 admits) he works for WRI and another I suspect does, as his edits to the
  Mathematica page always promote it, and his edits to the Sage page
 always demotes it. (When I asked, he declines to answer).

 What of the following could we say Sage supports? Can someone give me a
 yes/no or brief comment by each of these.

 --
 Some features of Mathematica include:

     * Libraries of elementary and special mathematical functions

yes

     * 2D and 3D data and function visualization tools

yes

     * Matrix and data manipulation tools including support for sparse
 arrays

yes

     * Solvers for systems of equations, ODEs, PDEs, DAEs, DDEs and
 recurrence relations

no clue

     * Numeric and symbolic tools for discrete and continuous calculus

yes.  I don't know what discrete calculus means.

     * Multivariate statistics libraries

yes (R and scipy)

     * Constrained and unconstrained local and global optimization

no clue

     * A programming language supporting procedural, functional and
 object oriented constructs

Yes -- python.

     * A toolkit for adding user interfaces to calculations and applications

yes -- @interact

     * Tools for image processing [5]

yes, in pylab, plus also there is the Python Imagining Library.  (PIL)

     * Tools for visualizing and analysing graphs

yes

     * Data mining tools such as cluster analysis, sequence alignment
 and pattern matching

maybe.  not sure.

     * Libraries of number theory functions

yes.

     * Continuous and discrete integral transforms

no clue

     * Import and export filters for data, images, video, sound, CAD,
 GIS, document and biomedical formats

don't know.  probably python has most of that.

     * A collection of databases of mathematical, scientific, and
 socio-economic information (see below)

nope, and little interest since people just write pythons scripts to
import such data when they need it...

     * Support for complex number, arbitrary precision and symbolic
 computation for all functions

all functions?  yeah right.

     * Notebook interface for review and re-use of previous inputs and
 outputs including graphics and text annotations

yes

     * Technical word processing including formula editing and automated
 report generating

yes, except I don't know what automated report generating.

     * Tools for connecting to SQL, Java, .NET, C++, FORTRAN and http
 based systems

Yes.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage on Wikipedia

[kcrisman]

      * Solvers for systems of equations, ODEs, PDEs, DAEs, DDEs and
  recurrence relations

 no clue


perhaps desolve and friends?

      * Numeric and symbolic tools for discrete and continuous calculus

 yes.  I don't know what discrete calculus means.

Probably this means difference equations.

      * Constrained and unconstrained local and global optimization

 no clue

would that include cvxopt? other similar tools?

      * Continuous and discrete integral transforms

 no clue


maybe this means Fourier, Laplace, Mellin (cont.) and discrete Fourier
(disc.)?

HIH,
- kcrisman
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage on Wikipedia

[John Cremona]

I think Sage does have at least one mathematical database (in fact
more than one...) !

John

2009/6/24 kcrisman kcris...@gmail.com:

  * Solvers for systems of equations, ODEs, PDEs, DAEs, DDEs and
  recurrence relations

 no clue


 perhaps desolve and friends?

  * Numeric and symbolic tools for discrete and continuous calculus

 yes.  I don't know what discrete calculus means.

 Probably this means difference equations.

  * Constrained and unconstrained local and global optimization

 no clue

 would that include cvxopt? other similar tools?

  * Continuous and discrete integral transforms

 no clue


 maybe this means Fourier, Laplace, Mellin (cont.) and discrete Fourier
 (disc.)?

 HIH,
 - kcrisman
 


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: typesetting partial derivatives

[Golam Mortuza Hossain]

Hi

On Tue, Jun 23, 2009 at 9:00 PM, Burcin Erocalbur...@erocal.org wrote:
 If there are no objections to the above definition of hybrid approach,
 the options for default printing are:

 1) Mathematica style
 2) Maple style
 3) hybrid

 I still vote for 1, MMA style. To state the reasons again, it's
 consistent, and concise.

Burcin, I am giving you my vote also, for implementing MMA
style typesetting as the default one for partial derivatives.  Please
have those {'} and {''} and may be even {'''} notations.

So I would urge you to go ahead with the implementation.

It wouldn't be difficult to add other choices later as options
to users (some of the codes are already there).

Cheers,
Golam

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: typesetting partial derivatives

[Jason Grout]

Burcin Erocal wrote:
 On Tue, 16 Jun 2009 19:42:46 -0300
 Golam Mortuza Hossain gmhoss...@gmail.com wrote:
 
 Hi,


 On Tue, Jun 16, 2009 at 2:20 PM, kcrismankcris...@gmail.com wrote:
 So the conclusion is that we will go with the Mathematica style
 notation.
 Does that also apply to Golam's earlier comment

   (a) If we all agree that there is no ambiguity when the particular
argument is a symbolic variable or symbolic function then
we should typeset them as those found in text-books.
Ex:
(1)  D[0,0,0] (f)(x,y)=  \frac{\partial^3}{\partial
 x^3} f (x,y)
(2)  D[0] (f)(g(x,y), h(z)) =  \frac{\partial}{\partial
 g(x,y)} f(g(x,y), h(y))

 so that we will no longer see nicely typeset partial derivatives
 even in case (a)(1) (or even Leibniz notation at all?), or is it
 only in the case (b) when the argument is an expression?
  Thanks for the clarification.
 As Burcin pointed  out that even MMA uses different Tex-ing scheme
 for some situations such as  F'[x] for D[F[x],x]. So strictly
 speaking even MMA uses hybrid approach.
 
 I don't think what MMA does can really be called a hybrid approach. It
 just represents first and second derivatives of single argument
 functions with F' and F'', instead of F^{(1)} and F^{(2)} respectively.
 
 John Palmieri wrote in a different thread:
 I don't like the D[1] notation at all.  By the way, when we have a
 function f of two variables, should we automatically assume that the
 mixed partials are equal? Does this affect our choice of notation?
 
 I guess we assume that they commute:
 
 sage: var('x,y,z')
 (x, y, z)
 sage: t = f(x,y)
 sage: diff(t,x,y)
 D[0, 1](f)(x, y)
 sage: diff(t,y)
 D[1](f)(x, y)
 sage: diff(t,y,x)
 D[0, 1](f)(x, y)
 
 
 I guess, we should aim for doing better than MMA/Maple.
 
 What would the hybrid approach be in this case? Use Maple convention,
 but use MMA style F^{(4, 0} instead of D[1,1,1,1]F[x+y,y] or F^{(3,1)}
 instead of D[1,1,1,2]F[x+y,y]?
 
 
 I would like to settle this vote and get rid of the D[...] notation as
 soon as possible, but William's count of 4 votes for MMA notation to 2
 votes for Maple notation doesn't look decisive. At least I can't
 believe there were so few responses. :)
 
 Can people who care about this please comment and vote?
 
 If there are no objections to the above definition of hybrid approach,
 the options for default printing are:
 
 1) Mathematica style
 2) Maple style
 3) hybrid
 
 For all cases, we would need to provide a function that takes the names
 of the arguments of the given symbolic function as a parameter and
 typesets the expression in textbook style
 
 
 I still vote for 1, MMA style. To state the reasons again, it's
 consistent, and concise.


+1 for the MMA style.

Jason


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 4.1.alpha0

[Jason Grout]

Robert Miller wrote:
 
 Other easy ways to save release managers time, resulting in more
 frequent releases and shorter wait times to get your code merged:
 
 * Please include the trac number in each commit message if possible.

Surely this could be scripted?  Just prepend a Trac #:  to the 
commit message when the patch is merged?  You could even do Trac #, 
patch x: 



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 4.1.alpha0

[William Stein]

On Wed, Jun 24, 2009 at 5:13 PM, Jason Groutjason-s...@creativetrax.com wrote:

 Robert Miller wrote:

 Other easy ways to save release managers time, resulting in more
 frequent releases and shorter wait times to get your code merged:

 * Please include the trac number in each commit message if possible.

 Surely this could be scripted?  Just prepend a Trac #:  to the
 commit message when the patch is merged?  You could even do Trac #,
 patch x: 


I still think it is a very good idea to include the trac number in
each commit message.
It makes it vastly easier on people when reading through the hg history later.

I personally *always* include the trac ticket in my commit messages.
Often I do hg ci, then realize I haven't made a ticket for what I'm
doing, so I make one, get the number, then finish the commit.  It's a
good idea to help make the development of Sage more collaborative (by
letting others know what you're really working on), and also make it
easier for people to trace through what happened.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 4.1.alpha0

[Tom Boothby]

 Each of the following tickets were rejected by the merge scripts, but
 unfortunately the failures are not available at this time (this is due
 to human error on my part). If you are involved with one of them, you
 are encouraged to try applying the patches to 4.1.alpha0 and see why/
 if they failed. Tom and I will eventually do this, but it would be
 helpful for people involved in the ticket to get things started:

 6196
 5481
 6276
 4712
 5517
 5991
 6164
 6200
 5902
 6269

Don't look at these too carefully -- I know for a fact that at least a
couple of these failing is my fault.  I'm going to re-test and post
detailed info to each ticket, starting in about an hour.

Thanks for all your help, Robert!

   --tom

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 4.1.alpha0

[John Cremona]

2009/6/24 Robert Miller rlmills...@gmail.com:

 This is the first release of the new cycle, and I've agreed to step in
 and co-chair the release with Tom. The source tarball and sage.math
 binary are available:

 http://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0.tar
 http://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0-sage.math-only-x86_64-Linux.tar.gz

 This is the first development release in which the new merge tools
 were used by people other than the authors. Several doctests fail on
 sage.math:

sage -t  devel/sage-main/sage/graphs/graph.py # 25 doctests
 failed
sage -t  devel/sage-main/sage/databases/database.py # 20
 doctests failed
sage -t  devel/sage-main/sage/geometry/polyhedra.py # 1
 doctests failed

I get these but no other failures on either 32-bit Suse or 64-bit Ubuntu.

John


 These are all due to the removal of graph_isom.pyx, and I will be
 posting a patch to fix this shortly, at #6394. I think that there was
 no way to avoid these failures, since the only way to expose them was
 to remove the code, rebuild entirely from scratch, and then run the
 tests.

 This release does not include any tickets involving spkg's. I will
 make this the main focus of alpha1, which should drop before Friday.

 Each of the following tickets were rejected by the merge scripts, but
 unfortunately the failures are not available at this time (this is due
 to human error on my part). If you are involved with one of them, you
 are encouraged to try applying the patches to 4.1.alpha0 and see why/
 if they failed. Tom and I will eventually do this, but it would be
 helpful for people involved in the ticket to get things started:

 6196
 5481
 6276
 4712
 5517
 5991
 6164
 6200
 5902
 6269

 Other easy ways to save release managers time, resulting in more
 frequent releases and shorter wait times to get your code merged:

 * Please include the trac number in each commit message if possible.
 * Please make sure Author and Reviewer fields are set, when changing
 the ticket status to positive review. Since these are used in
 generating release notes, please use full names.
 * Please adhere to the trac_-description.patch filename format
 when creating patch files.

 Cheers,

 Robert Miller (and Tom Boothby)

 


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: #6343: Adds SageObject.check() generic testing framework

[Nick Alexander]

 Test(obj) returns something that provides all kinds of functionality
 and methods for testing said object.  This can call certain _ methods
 on obj.

+1 to this, -1 to lazy attributes, properties, etc.

Nick

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] temp files being left in /tmp

[John Cremona]

I am accumulating a large number of small text files in /tmp, for example

j...@host-57-44%cat /tmp/fileqibSwS
cpu MHz : 2800.113
cpu MHz : 2800.113
cpu MHz : 2800.113
cpu MHz : 2800.113

and

j...@host-57-44%cat filekswTqv
make[2]: Entering directory
`/home/jec/sage-4.0/spkg/build/atlas-3.8.3.p1/ATLAS-build'
gcc 
-I/home/jec/sage-4.0/spkg/build/atlas-3.8.3.p1/ATLAS-build/../src//CONFIG/include
 -g -w -o xspew
/home/jec/sage-4.0/spkg/build/atlas-3.8.3.p1/ATLAS-build/../src//CONFIG/src/SpewMakeInc.c
atlconf_misc.o \

atlconf_misc.o: In function `CmndResults':
/home/jec/sage-4.0/spkg/build/atlas-3.8.3.p1/ATLAS-build/../src//CONFIG/src/atlconf_misc.c:306:
warning: the use of `tmpnam' is dangerous, better use `mkstemp'
make[2]: Leaving directory
`/home/jec/sage-4.0/spkg/build/atlas-3.8.3.p1/ATLAS-build'


These are clearly being created by building (not running) Sage.  Where
are they coming from?

John

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage on Wikipedia

[Robert Bradshaw]

On Jun 23, 2009, at 6:15 PM, Dr. David Kirkby wrote:

 I think we should really make some effort to improve our page on  
 Wikipedia.

I'll second this. Wikipedia is the highest source of traffic for  
Cython after google and people typing in cython.org directly (despite  
an only average page)--I wouldn't be surprised if it accounts for a  
significant proportion of potential and actual sage hits as well.


 Comparing the Sage and Mathematica pages on Wikipedia shows the
 Mathematica one is much nicer. Would it not be sensible to put some
 effort into promoting Sage there? If it looks like the program is more
 complete, one has a greater chance of getting people using it and
 attracting more developers.

 As you know, I'm interested in porting sage to Solaris, as I'm a  
 Solaris
 user and want to use it there. Hence I'm not a Sage user. Looking  
 on the
 Mathematica Wikipedia entry, there is one person who definitely (and
 admits) he works for WRI and another I suspect does, as his edits  
 to the
   Mathematica page always promote it, and his edits to the Sage page
 always demotes it. (When I asked, he declines to answer).

 What of the following could we say Sage supports? Can someone give  
 me a
 yes/no or brief comment by each of these.

 --
 Some features of Mathematica include:

  * Libraries of elementary and special mathematical functions
  * 2D and 3D data and function visualization tools
  * Matrix and data manipulation tools including support for sparse
 arrays
  * Solvers for systems of equations, ODEs, PDEs, DAEs, DDEs and
 recurrence relations
  * Numeric and symbolic tools for discrete and continuous calculus
  * Multivariate statistics libraries
  * Constrained and unconstrained local and global optimization
  * A programming language supporting procedural, functional and
 object oriented constructs
  * A toolkit for adding user interfaces to calculations and  
 applications
  * Tools for image processing [5]
  * Tools for visualizing and analysing graphs
  * Data mining tools such as cluster analysis, sequence alignment
 and pattern matching
  * Libraries of number theory functions
  * Continuous and discrete integral transforms
  * Import and export filters for data, images, video, sound, CAD,
 GIS, document and biomedical formats
  * A collection of databases of mathematical, scientific, and
 socio-economic information (see below)
  * Support for complex number, arbitrary precision and symbolic
 computation for all functions
  * Notebook interface for review and re-use of previous inputs and
 outputs including graphics and text annotations
  * Technical word processing including formula editing and  
 automated
 report generating
  * Tools for connecting to SQL, Java, .NET, C++, FORTRAN and http
 based systems

 


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: typesetting partial derivatives

[Nick Alexander]

 +1 for the MMA style.


I am +1 for mathematica style, but can someone explain why

In[5]:= D[F[x+2*y], x, x]

Out[5]= F''[x + 2 y]

Why is x somehow considered special and y not?

Nick

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: #6343: Adds SageObject.check() generic testing framework

[Robert Bradshaw]

On Jun 24, 2009, at 12:52 AM, William Stein wrote:


 But, err, guys, are you telling *me* that you want an  
 attribute here
 instead of a method? Or should this be:

One new attribute in tab completion is fine. A dozen, not so much. I  
still like the approach below better though.

 I am still opposed to adding a non-underscore method to SageObject.

 I did like Robert Bradshaw's other suggestion to do something  
 like the
 following.

 sage: Test(foo).associativity()

 sage: Test?
 [[descript testing framework]]

 I.e., just create a Sage class Test, which gives access to the  
 test
 functionality, documents it, can even do something useful on objects
 foo that aren't necessarily SageObjects at all, etc.

 Test(obj) returns something that provides all kinds of functionality
 and methods for testing said object.  This can call certain _  
 methods
 on obj.

 That would be fine for me too. The only thing I really care for is  
 for
 the actual test methods (._test...) to be attached to foo, and  
 derived
 from its classes.

 What syntax would you suggest to run all tests?

 One thing I am not very keen on is that to get the list of available
 tests, one need to do:

sage: t = Test(foo)
sage: t.asstab

 But I guess I can live with that (in practice, I myself will be  
 using t._test_asstab)

That also seems to read a bit funny. Why not a global tester object,  
so one could do.

tester.test_associativity(foo)

(OK, the test there is a bit redundant, maybe test.associativity(foo)  
or tester.is_associative(foo))

- Robert


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: #6343: Adds SageObject.check() generic testing framework

[William Stein]

On Wed, Jun 24, 2009 at 6:30 PM, Robert
Bradshawrober...@math.washington.edu wrote:

 On Jun 24, 2009, at 12:52 AM, William Stein wrote:


     But, err, guys, are you telling *me* that you want an
 attribute here
     instead of a method? Or should this be:

 One new attribute in tab completion is fine. A dozen, not so much. I
 still like the approach below better though.

 I am still opposed to adding a non-underscore method to SageObject.

 I did like Robert Bradshaw's other suggestion to do something
 like the
 following.

 sage: Test(foo).associativity()

 sage: Test?
 [[descript testing framework]]

 I.e., just create a Sage class Test, which gives access to the
 test
 functionality, documents it, can even do something useful on objects
 foo that aren't necessarily SageObjects at all, etc.

 Test(obj) returns something that provides all kinds of functionality
 and methods for testing said object.  This can call certain _
 methods
 on obj.

 That would be fine for me too. The only thing I really care for is
 for
 the actual test methods (._test...) to be attached to foo, and
 derived
 from its classes.

 What syntax would you suggest to run all tests?

 One thing I am not very keen on is that to get the list of available
 tests, one need to do:

        sage: t = Test(foo)
        sage: t.asstab

 But I guess I can live with that (in practice, I myself will be
 using t._test_asstab)

 That also seems to read a bit funny. Why not a global tester object,
 so one could do.

 tester.test_associativity(foo)

 (OK, the test there is a bit redundant, maybe test.associativity(foo)
 or tester.is_associative(foo))

I also like the idea of a global tester object.Though, an advantage of
t = Test(foo) is that it is way more flexible.  I.e.,

   sage: t = Tester(some_arithmetic_thing)
   sage: t.tab --- various arithmetic type tests
   sage: type(t)
   some sort of arithmetic tester

   sage: t = Tester(a_web_server)
   sage: t.tab --- various network type tests
   sage: type(t)
   some sort of web framework tester

   sage: t = Tester(an_element)
   sage: type(t)
   some sort of element tester

Of course the tester objects could all fit into a class hierarchy eventually.

William


 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: patch naming scheme on trac

[Robert Bradshaw]

On Jun 23, 2009, at 4:24 PM, Nicolas M. Thiery wrote:

 Indeed.  The current trac naming convention really strongly  
 encouraged
 you to do the right thing, which is to always open a trac ticket  
 for
 whatever you're working on.

 Definitely. That also why I 100% support having the ticket number in
 the patch name.

+1

 I think the following is a counterexample to The trac_ prefix does
 not bring any useful information.

 I still think it's not really, and it is just making the name longer,
 but I don't really care either.

I don't see the use for it either, but it's not a huge issue for me.


 Starting the patch name with the ticket number defeats tab
   completion when sorting through a large number of patches,
   typically in a mercurial queue. It is a life saver for me to be
   able to do hg qpop categories-fratab

 This could perhaps be solved via technical methods, e.g., some
 improvement to how the tab completion works.

 If it was only within Sage, yes. But doing this in all shells and file
 browsers that our developers are using does not quite seem like an
 option to me.

 I am not saying our convention is optimal; I was just pointing at it
 for the record. Actually, for most case, it is indeed too verbose, and
 we often shorten the description part. But I really do want to insist
 on having the description *first*.

I really like having the ticket number first, it makes it easy to see  
(given an ordered list of patches) what patches belong as part of a  
single ticket. E.g.

6201-heegner.patch
6201-referee-fixes.patch
...

I do think every patch should at least include the ticket number and  
*some* kind of descriptive word/phrase.

- Robert

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: typesetting partial derivatives

[John Cremona]

2009/6/24 Nick Alexander ncalexan...@gmail.com:

 +1 for the MMA style.


 I am +1 for mathematica style, but can someone explain why

 In[5]:= D[F[x+2*y], x, x]

 Out[5]= F''[x + 2 y]

 Why is x somehow considered special and y not?

F is a function of one variable.  F'' is its second derivative.  It's
nothing to do with x and y being special.

John


 Nick

 


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: patch naming scheme on trac

[Craig Citro]

 I used to include a commit message when I did not use MQs.  With MQs I
 make the patch using sage -hg export qtip  blah.patch and do not
 get prompted for a commit message.  Thelast one I did then ended up
 with [mq]: intpts where the commit message would be, so perhaps that
 is the commit message provided by MQ.

 I expect there is a way to change that default?


Hi John -- I think you just use the '-e' option to either qnew or
qrefresh -- I remember it as e for editor. I learned about it here:

http://wiki.sagemath.org/MercurialQueues

-cc

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage on Wikipedia

[Harald Schilly]

On Jun 24, 6:16 pm, Robert Bradshaw rober...@math.washington.edu
wrote:
 I'll second this. Wikipedia is the highest source of traffic for  
 Cython after google and people typing in cython.org directly (despite  
 an only average page)--I wouldn't be surprised if it accounts for a  
 significant proportion of potential and actual sage hits as well.

I can give you some numbers, but in general you are right. Don't
forget, there are also other wikipedia language editions that give a
fair amount of traffic, especially french.

Besides wikipedia, there is also knol, google's version of an
wikipedia for experts. This means, that an article is always
associated with an author and there are no independent topics. Last
time when I improved Sage's wikipedia page, I also started this:
http://knol.google.com/k/harald-schilly/sage
It's very general, but improvements are welcome. Anybody is invited to
suggest some improvements or more directly, I can also add others
(with a google account) to become editors.

H
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: patch naming scheme on trac

[Craig Citro]

 I think the following is a counterexample to The trac_ prefix does
 not bring any useful information.

 I still think it's not really, and it is just making the name longer,
 but I don't really care either.

 I don't see the use for it either, but it's not a huge issue for me.


I want to weigh in with a +1 on letting patches start with trac_. I
use it so that patches in a directory on my machine are grouped
together -- it's much easier to see them and move them around that
way, because then trac_* picks them up. I also use a system similar to
John Cremona, it seems -- patches named random_thing.patch are
half-finished things, and trac_-descr.patch are ready to get
uploaded. (So I can't just use *.patch -- it'll pick up both kinds of
patches.)

Of course, I'm also +10 on having the ticket number and a short
description, as everyone else commented, but that seems to be
unanimous on this thread.

-cc

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: typesetting partial derivatives

[Nick Alexander]

On 24-Jun-09, at 9:42 AM, John Cremona wrote:


 2009/6/24 Nick Alexander ncalexan...@gmail.com:

 +1 for the MMA style.


 I am +1 for mathematica style, but can someone explain why

 In[5]:= D[F[x+2*y], x, x]

 Out[5]= F''[x + 2 y]

 Why is x somehow considered special and y not?

 F is a function of one variable.  F'' is its second derivative.  It's
 nothing to do with x and y being special.

I missed that.

Thanks,
Nick

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage on Wikipedia

[Dr. David Kirkby]

Dr. David Kirkby wrote:
 I think we should really make some effort to improve our page on Wikipedia.


OK, based on some input from others, and what I found with Google, I 
have revised the 'Features* section somewhat (and only the Features to 
date).

The current page is here (this might include edits by others. I would 
not be surprised if the two Wolfram Research employees go over it soon.)

http://en.wikipedia.org/wiki/Sage_(mathematics_software)

What I wrote is here:
http://en.wikipedia.org/w/index.php?title=Sage_(mathematics_software)oldid=298394689

The previous page is here, which was last edited by Cloudruns who I 
believe works for WRI, but he has never admitted it.

http://en.wikipedia.org/w/index.php?title=Sage_(mathematics_software)oldid=295406997

The differences between the previous page (edited by Cloudruns) and the 
one I wrote is

http://en.wikipedia.org/w/index.php?title=Sage_(mathematics_software)diff=298394689oldid=295406997

Someone wrote the 'Description' does not cite any references. It might 
be better to delete that altogether, as it is basically covered in the 
section above it.


It is still nowhere near as nice as the Mathematica page
http://en.wikipedia.org/wiki/Mathematica
but hopefully a bit better than it was. Others please comment or edit 
it. It might be better if William does not, as it could be considered a 
conflict of interet. (Not that that stops the WRI guys!)

Looking at the Mathematica page, the only real reference to most of 
functionality is the Mathematica documentation. We should make sure the 
documentation of Sage covers the areas I have put, as otherwise they 
might be deleted.

One question, does the 'secure' notebook use HTTPS ? I assume it does, 
but did not write that in case it is not true.


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: patch naming scheme on trac

[Tom Boothby]

On Wed, Jun 24, 2009 at 10:20 AM, Craig Citrocraigci...@gmail.com wrote:

 I think the following is a counterexample to The trac_ prefix does
 not bring any useful information.

 I still think it's not really, and it is just making the name longer,
 but I don't really care either.

 I don't see the use for it either, but it's not a huge issue for me.


 I want to weigh in with a +1 on letting patches start with trac_. I
 use it so that patches in a directory on my machine are grouped
 together -- it's much easier to see them and move them around that
 way, because then trac_* picks them up. I also use a system similar to
 John Cremona, it seems -- patches named random_thing.patch are
 half-finished things, and trac_-descr.patch are ready to get
 uploaded. (So I can't just use *.patch -- it'll pick up both kinds of
 patches.)

Put 'em in a folder, then -- trac/* will pick 'em up.  Having tickets
start with a repo name would vastly improve the automerge experience.

+1 to repo_num_desc.patch


 Of course, I'm also +10 on having the ticket number and a short
 description, as everyone else commented, but that seems to be
 unanimous on this thread.

 -cc

 


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage on Wikipedia

[William Stein]

2009/6/24 Dr. David Kirkby david.kir...@onetel.net:

 Dr. David Kirkby wrote:
 I think we should really make some effort to improve our page on Wikipedia.


 OK, based on some input from others, and what I found with Google, I
 have revised the 'Features* section somewhat (and only the Features to
 date).

 The current page is here (this might include edits by others. I would
 not be surprised if the two Wolfram Research employees go over it soon.)

 http://en.wikipedia.org/wiki/Sage_(mathematics_software)

 What I wrote is here:
 http://en.wikipedia.org/w/index.php?title=Sage_(mathematics_software)oldid=298394689

 The previous page is here, which was last edited by Cloudruns who I
 believe works for WRI, but he has never admitted it.

 http://en.wikipedia.org/w/index.php?title=Sage_(mathematics_software)oldid=295406997

 The differences between the previous page (edited by Cloudruns) and the
 one I wrote is

 http://en.wikipedia.org/w/index.php?title=Sage_(mathematics_software)diff=298394689oldid=295406997

 Someone wrote the 'Description' does not cite any references. It might
 be better to delete that altogether, as it is basically covered in the
 section above it.


 It is still nowhere near as nice as the Mathematica page
 http://en.wikipedia.org/wiki/Mathematica
 but hopefully a bit better than it was. Others please comment or edit

I think it looks very nice.  thanks!!

 it. It might be better if William does not, as it could be considered a
 conflict of interet. (Not that that stops the WRI guys!)

 Looking at the Mathematica page, the only real reference to most of
 functionality is the Mathematica documentation. We should make sure the
 documentation of Sage covers the areas I have put, as otherwise they
 might be deleted.

 One question, does the 'secure' notebook use HTTPS ? I assume it does,
 but did not write that in case it is not true.


Yes, it does.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: patch naming scheme on trac

[Tom Boothby]

On Wed, Jun 24, 2009 at 11:07 AM, Nick Alexanderncalexan...@gmail.com wrote:

 Put 'em in a folder, then -- trac/* will pick 'em up.  Having tickets
 start with a repo name would vastly improve the automerge experience.

 +1 to repo_num_desc.patch

 Can repo be optional and default to devel/sage?  There's lots our
 tools can do that doesn't require having a redundant 'sage' or 'sage-
 main' or 'devel' at the front.  This was a feature never added to -
 merge, that's all.

Yeah, that's fine by me.


 Nick

 


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 4.1.alpha0

[Tom Boothby]

On Wed, Jun 24, 2009 at 8:31 AM, Tom Boothbytomas.boot...@gmail.com wrote:
 Each of the following tickets were rejected by the merge scripts, but
 unfortunately the failures are not available at this time (this is due
 to human error on my part). If you are involved with one of them, you
 are encouraged to try applying the patches to 4.1.alpha0 and see why/
 if they failed. Tom and I will eventually do this, but it would be
 helpful for people involved in the ticket to get things started:

 6196
 5481
 6276
 4712
 5517
 5991
 6164
 6200
 5902
 6269

 Don't look at these too carefully -- I know for a fact that at least a
 couple of these failing is my fault.  I'm going to re-test and post
 detailed info to each ticket, starting in about an hour.

Robert's list of failures was too long -- I didn't actually apply most
of that list.  The following actually failed:

6196
5991
6164
6200
6269

I'm generating reports on these right now and posting them to tickets
as they come.

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 4.1.alpha0

[Tom Boothby]

 6196
 5991
 6164
 6200
 6269

 I'm generating reports on these right now and posting them to tickets
 as they come.


Ah -- and 6269 almost certainly failed because I applied both patches
on the ticket, not because the second patch was actually bad.

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage on Wikipedia

[kcrisman]

A related page to look at would be 
http://en.wikipedia.org/wiki/Comparison_of_computer_algebra_systems
Note that Mma is declared there to be ubiquitous while Maple only
notes its libraries' sources are viewable.  Our friends at Axiom even
link from there to a video!

- kcrisman
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: patch naming scheme on trac

[John Cremona]

2009/6/24 Tom Boothby tomas.boot...@gmail.com:

 On Wed, Jun 24, 2009 at 11:07 AM, Nick Alexanderncalexan...@gmail.com wrote:

 Put 'em in a folder, then -- trac/* will pick 'em up.  Having tickets
 start with a repo name would vastly improve the automerge experience.

I put mine in a folder called patches/

And maybe I'm not the only one who doesn't even know what the repo name  is!

John


 +1 to repo_num_desc.patch

 Can repo be optional and default to devel/sage?  There's lots our
 tools can do that doesn't require having a redundant 'sage' or 'sage-
 main' or 'devel' at the front.  This was a feature never added to -
 merge, that's all.

 Yeah, that's fine by me.


 Nick

 


 


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: #6343: Adds SageObject.check() generic testing framework

[Nicolas M. Thiery]

On Wed, Jun 24, 2009 at 09:52:51AM +0200, William Stein wrote:
 
  One thing I am not very keen on is that to get the list of available
  tests, one need to do:
 
         sage: t = Test(foo)
         sage: t.asstab
 
  But I guess I can live with that (in practice, I myself will be using 
  t._test_asstab)
 
 Yeah -- it seems that we have a consensus!

Ok. There just remains:

  What syntax would you suggest to run all tests?

Test(foo).all()?
Test(foo).run()?
...?

Best,
Nicolas
--
Nicolas M. Thiéry Isil nthi...@users.sf.net
http://Nicolas.Thiery.name/

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: #6343: Adds SageObject.check() generic testing framework

[William Stein]

On Wed, Jun 24, 2009 at 6:09 PM, Nicolas M.
Thierynicolas.thi...@u-psud.fr wrote:

 On Wed, Jun 24, 2009 at 09:52:51AM +0200, William Stein wrote:
 
  One thing I am not very keen on is that to get the list of available
  tests, one need to do:
 
         sage: t = Test(foo)
         sage: t.asstab
 
  But I guess I can live with that (in practice, I myself will be using 
  t._test_asstab)

 Yeah -- it seems that we have a consensus!

 Ok. There just remains:

  What syntax would you suggest to run all tests?

 Test(foo).all()?
 Test(foo).run()?
 ...?

I prefer run().

William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: patch naming scheme on trac

[Robert Miller]

  I think the following is a counterexample to The trac_ prefix does
  not bring any useful information.

  I still think it's not really, and it is just making the name longer,
  but I don't really care either.

 I don't see the use for it either, but it's not a huge issue for me.

I should explain my workflow, as I'm probably not the only person
doing this (e.g. Craig). When I'm managing releases is one thing, but
in daily practice, I always download patches to my home directory.
Think about it. Open a terminal, wget a patch, and this is what
happens. It's the easiest thing to do, and if everything starts with
trac_, then they're all in the same place. And it's only five
characters. Every once in a while, when I'm cleaning things out, it's
easier to find and delete all the trac patches, which as John points
out, is nice, since none of the other (proprietary) patches are killed
when I do this.

 I really like having the ticket number first, it makes it easy to see  
 (given an ordered list of patches) what patches belong as part of a  
 single ticket. E.g.

 6201-heegner.patch
 6201-referee-fixes.patch
 ...

+1




--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: patch naming scheme on trac

[Robert Miller]

On Jun 24, 10:34 pm, Robert Miller rlmills...@gmail.com wrote:
  I really like having the ticket number first, it makes it easy to see  
  (given an ordered list of patches) what patches belong as part of a  
  single ticket. E.g.

  6201-heegner.patch
  6201-referee-fixes.patch
  ...

 +1

Something occurs to me, which is that the sage-combinat group spends a
lot of time working on patches outside of trac. This is probably why
Nicolas prefers to have them organized by concept. But for me, I'm
always on trac-- everything I work on, even experimental, has a trac
ticket. I generally tend to have several tickets open in Firefox so I
know which issues I'm tracking. Then I just tab over to the relevant
ticket, and that's why trac_### is so useful. Since we are discussing
naming conventions for patches which are on trac, maybe we should keep
that in mind.

Maybe the combinat group can discuss a related scheme, and have
conversion tools which make it effortless to swap between the two
schemes (I'm not volunteering here, just so nobody gives the usual
response :-)  ).

I'd also like to point out that one of the biggest reasons projects
fail is due to trying to change their tools midstream, which is one
argument for keeping the convention the way it is. However, that is
precisely what the combinat group would have to do to adapt to this
scheme. This is why I recommend automated conversion tools.

Another point to make is a video I saw recently by the SVN guys, who
claimed that the amount of discussion which centers around a decision
is inversely proportional to how important it is. They related a story
where the project nearly forked and many feelings were hurt over
something ten times more trivial than this topic. Just for perspective.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: patch naming scheme on trac

[Robert Miller]

 Another point to make is a video I saw recently by the SVN guys, who
 claimed that the amount of discussion which centers around a decision
 is inversely proportional to how important it is. They related a story
 where the project nearly forked and many feelings were hurt over
 something ten times more trivial than this topic. Just for perspective.

By the way, I just rediscovered the video, and the topic was actually
whether or not to have spaces before parentheses. They didn't actually
almost fork, but there was a vast vote, where people who hadn't
contributed for a long time were being lobbied to.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: patch naming scheme on trac

[Jaap Spies]

Robert Miller wrote:
 I think the following is a counterexample to The trac_ prefix does
 not bring any useful information.
 I still think it's not really, and it is just making the name longer,
 but I don't really care either.
 I don't see the use for it either, but it's not a huge issue for me.
 
 I should explain my workflow, as I'm probably not the only person
 doing this (e.g. Craig). When I'm managing releases is one thing, but
 in daily practice, I always download patches to my home directory.
 Think about it. Open a terminal, wget a patch, and this is what
 happens. It's the easiest thing to do, and if everything starts with
 trac_, then they're all in the same place. And it's only five
 characters. Every once in a while, when I'm cleaning things out, it's
 easier to find and delete all the trac patches, which as John points
 out, is nice, since none of the other (proprietary) patches are killed
 when I do this.
 

+1

Jaap



 I really like having the ticket number first, it makes it easy to see  
 (given an ordered list of patches) what patches belong as part of a  
 single ticket. E.g.

 6201-heegner.patch
 6201-referee-fixes.patch
 ...
 
 +1
 
 
 
 
  
 


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage on Wikipedia

[Dr. David Kirkby]

kcrisman wrote:
 
 A related page to look at would be 
 http://en.wikipedia.org/wiki/Comparison_of_computer_algebra_systems
 Note that Mma is declared there to be ubiquitous while Maple only
 notes its libraries' sources are viewable.  Our friends at Axiom even
 link from there to a video!
 
 - kcrisman

I thought that the ubiquitous there was very odd. It was placed there 
by Cloudruns, whose edits to several pages are so pro-Mathematica, and 
so anti every other similar system, that I believe he probably works for 
Wolfram Research.

I asked him both on his talk page, and the in the talk page for 
Mathematica, but he never replied.


There is a section in the Mathematica page on Front ends I added to that

Sage, which aims to be a free alternative to Mathematica, can be used 
as an interface to Mathematica


Cloudruns, changed that to Sage mathematics software can be used as an 
interface to Mathematica

I stongly suspect he has a conflict of interest, but proving it is 
another matter.

http://en.wikipedia.org/wiki/Wikipedia:Conflict_of_interest/Noticeboard#Cloudruns._I_suspect_has_connections_with_Wolfram_Research_the_producers_of_Mathematica

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: typesetting partial derivatives

[Burcin Erocal]

Hi Golam,

On Wed, 24 Jun 2009 11:58:19 -0300
Golam Mortuza Hossain gmhoss...@gmail.com wrote:

 On Tue, Jun 23, 2009 at 9:00 PM, Burcin Erocalbur...@erocal.org
 wrote:
  If there are no objections to the above definition of hybrid
  approach, the options for default printing are:
 
  1) Mathematica style
  2) Maple style
  3) hybrid
 
  I still vote for 1, MMA style. To state the reasons again, it's
  consistent, and concise.
 
 Burcin, I am giving you my vote also, for implementing MMA
 style typesetting as the default one for partial derivatives.  Please
 have those {'} and {''} and may be even {'''} notations.
 
 So I would urge you to go ahead with the implementation.

:) I was hoping you'd implement it, since you did it in #5711 once.

I attached a patch to the trac ticket that contains an initial attempt
at the MMA notation:

http://trac.sagemath.org/sage_trac/ticket/6344


It doesn't work well for text mode:

sage: f = function('f')
sage: f(x).derivative(x,3)
f^{(3)}(x)


Comments, suggestions and patches are welcome.


Thanks.

Burcin

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 4.1.alpha0

[Rob Beezer]

On Jun 24, 5:04 am, Robert Miller rlmills...@gmail.com wrote:
         sage -t  devel/sage-main/sage/graphs/graph.py # 25 doctests
 failed
         sage -t  devel/sage-main/sage/databases/database.py # 20
 doctests failed
         sage -t  devel/sage-main/sage/geometry/polyhedra.py # 1
 doctests failed

Building from source on 64-bit Kubuntu 9.04 with Intel Core Duo, I get
the three expected failing modules as in the announcement.

I also continue to consistently get the cryptic

sage -t  devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py
# 0 doctests failed

The test passes just fine when run by itself.  Is this just noise, and
is it just me?  ;-)

Rob
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Reviewer needed for patch to allow ATLAS to build on Solaris with Sun linker

[Dr. David Kirkby]

As reported before, ATLAS fails to build on Solaris if the Sun linker is 
used, since the flags in one of the makefiles are GNU-specific.

The patch applies 'sed' a few times to substitute the GNU flags to the 
Sun flags:

-shared == -G
-soname == -h
--whole-archive ==  -z allextract
--no-whole-archive == -z defaultextract


http://trac.sagemath.org/sage_trac/ticket/6399

Patch is here.
http://sage.math.washington.edu/home/kirkby/Solaris-fixes/atlas/

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 4.1.alpha0

[Minh Nguyen]

Hi folks,

On Wed, Jun 24, 2009 at 10:04 PM, Robert Millerrlmills...@gmail.com wrote:

 This is the first release of the new cycle, and I've agreed to step in
 and co-chair the release with Tom. The source tarball and sage.math
 binary are available:

SNIP

Here are the tickets merged in Sage 4.1.alpha0:

#1871: Robert Miller: wiki -- pressing control-c just starts another
copy running [Reviewed by David Joyner]
#3084: Rob Beezer, Tom Boothby: Solve Sudoku faster! [Reviewed by Nick
Alexander]
#4196: John Palmieri: write a new coercion section for the
developer's/programmer's guide [Reviewed by Minh Van Nguyen]
#4290: Lloyd Kilford, John Cremona: function to construct an Elliptic
Curve from a plane curve of genus one (using Magma) [Reviewed by Nick
Alexander]
#4313: John Cremona: Add some functionality to matrices in eclib
[Reviewed by William Stein]
#4761: Martin Albrecht: global cputime (inclusive some subprocesses
like Singular) [Reviewed by Simon King, Nick Alexander]
#5080: David Loeffler: Bug in decomposing modular symbol subspace
[Reviewed by Craig Citro, Michael Abshoff]
#5280: Franco Saliola: problem with a subposet coming from an
order_filter [Reviewed by Mike Hansen, Robert Miller]
#5307: John Cremona: Bug in conductor() over number fields [Reviewed
by Nick Alexander]
#5594: John Palmieri: better error message for list_plot [Reviewed by
Nick Alexander]
#5637: John Palmieri: allow \[ and \] to delimit math in %html blocks
[Reviewed by Nick Alexander]
#5711: Golam Mortuza Hossain: Enhanced Typesetting of Symbolic
Functions [Reviewed by Burcin Erocal]
#5806: Dan Drake: Sage 3.4.1.rc3: failing test
devel/sage/sage/misc/sagedoc.py [Reviewed by John Palmieri]
#5850: Marc Mezzarobba, Dan Drake: add Creative Commons license to
French tutorial [Reviewed by Nicolas Borie]
#5878: Franco Saliola: Add support for constructing irreducible matrix
representations of the symmetric group [Reviewed by Mike Hansen]
#6027: Ryan Dingman: get_memory_usage() sucks performance wise on OSX
[Reviewed by Nick Alexander]
#6073: John Palmieri: Developer guide somewhat wrong about cython
extensions [Reviewed by David Joyner]
#6112: Dan Drake: Remove stale file sage/graphs/graph_isom.pyx
[Reviewed by Robert Miller]
#6215: Nicolas Thiery: Followup ot #6126: Symmetric group algebra
jucys_murphy elements incorrect [Reviewed by Robert Miller]
#6239: Minh Van Nguyen: fix ReST formatting for pydesign module
ext_rep [Reviewed by Carlo Hamalainen]
#6261: Yann Laigle-Chapuy: Add multiplicative order for matrices over
finite fields [Reviewed by John Cremona]
#6273: John Cremona: Improve random_element for number field orders
and ideals [Reviewed by Nick Alexander]
#6274: Minh Van Nguyen: fix formatting of files under sage/plot
[Reviewed by John Palmieri]
#6289: John Palmieri: minor ref manual issue with calculus stuff
[Reviewed by Minh Van Nguyen]
#6290: Golam Mortuza Hossain: Allow keywords such as latex_name=LaTeX
while defining symbolic function [Reviewed by Nick Alexander]
#6314: David Joyner: optional doctest failure -- many failures in
linear_codes related to wtdist [Reviewed by Robert Miller]
#6330: John Palmieri: optional doctest failure -- constructions number
fields doctest failures [Reviewed by David Joyner]
#6336: John Palmieri: optional doctest failure -- constructions
calculus tests hang forever [Reviewed by David Joyner]
#6349: Robert Miller: graphs -- bug in DiGraph constructor [Reviewed
by William Stein]
#6351: Robert Miller: typo in Graph.plot docstring [Reviewed by John Palmieri]
#6354: Nicolas Thiery: Advertise and improve sage -fixdoctest
[Reviewed by Mike Hansen]
#6361: Minh Van Nguyen: elliptic curves -- easy to fix mistake in docs
[Reviewed by Mike Hansen]
#6363: Mitesh Patel: Display Sage version on notebook login page
[Reviewed by John Cremona]

-- 
Regards
Minh Van Nguyen

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: #6343: Adds SageObject.check() generic testing framework

[Jason Grout]

William Stein wrote:
 On Wed, Jun 24, 2009 at 6:09 PM, Nicolas M.
 Thierynicolas.thi...@u-psud.fr wrote:
 On Wed, Jun 24, 2009 at 09:52:51AM +0200, William Stein wrote:
 One thing I am not very keen on is that to get the list of available
 tests, one need to do:

sage: t = Test(foo)
sage: t.asstab

 But I guess I can live with that (in practice, I myself will be using 
 t._test_asstab)
 Yeah -- it seems that we have a consensus!
 Ok. There just remains:

 What syntax would you suggest to run all tests?
 Test(foo).all()?
 Test(foo).run()?
 ...?
 
 I prefer run().


run is the verb, so it makes more sense.  However, the method name 
seems pretty vague.

Test(foo).test_all()?


Jason


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 4.1.alpha0

[Dr. David Kirkby]

Robert Miller wrote:
 This is the first release of the new cycle, and I've agreed to step in
 and co-chair the release with Tom. The source tarball and sage.math
 binary are available:
 
 http://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0.tar
 http://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0-sage.math-only-x86_64-Linux.tar.gz
 
 This is the first development release in which the new merge tools
 were used by people other than the authors. Several doctests fail on
 sage.math:
 
 sage -t  devel/sage-main/sage/graphs/graph.py # 25 doctests
 failed
 sage -t  devel/sage-main/sage/databases/database.py # 20
 doctests failed
 sage -t  devel/sage-main/sage/geometry/polyhedra.py # 1
 doctests failed
 
 These are all due to the removal of graph_isom.pyx, and I will be
 posting a patch to fix this shortly, at #6394. I think that there was
 no way to avoid these failures, since the only way to expose them was
 to remove the code, rebuild entirely from scratch, and then run the
 tests.
 
 This release does not include any tickets involving spkg's. I will
 make this the main focus of alpha1, which should drop before Friday.
 
 Each of the following tickets were rejected by the merge scripts, but
 unfortunately the failures are not available at this time (this is due
 to human error on my part). If you are involved with one of them, you
 are encouraged to try applying the patches to 4.1.alpha0 and see why/
 if they failed. Tom and I will eventually do this, but it would be
 helpful for people involved in the ticket to get things started:
 
 6196
 5481
 6276

I'd like to know why 6276 failed. It seemed pretty simple, and should 
have only had an effect on Solaris.

import shutil
if os.uname()[0] == 'SunOS': 
shutil.copy2('patches/mmsearch-with-temp-Solaris-fix.c','src/tune/blas/gemm/mmsearch.c')


6380 has positive review too, but that does not appear to have been 
listed as either failing, nor included.



Dave

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: patch naming scheme on trac

[Jason Grout]

Robert Miller wrote:
 I think the following is a counterexample to The trac_ prefix does
 not bring any useful information.
 I still think it's not really, and it is just making the name longer,
 but I don't really care either.
 I don't see the use for it either, but it's not a huge issue for me.
 
 I should explain my workflow, as I'm probably not the only person
 doing this (e.g. Craig). When I'm managing releases is one thing, but
 in daily practice, I always download patches to my home directory.
 Think about it. Open a terminal, wget a patch, and this is what

I presume that you're aware that hg qimport also takes http URLs and 
automatically downloads a patch and puts it onto the queue?  Ever since 
Carl showed that to me, I don't think I've downloaded any patch with wget.

Jason


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage on Wikipedia

[Jason Grout]

William Stein wrote:
 * Constrained and unconstrained local and global optimization
 


Yes, in scipy.  See http://docs.scipy.org/doc/scipy/reference/optimize.html


 
 * Support for complex number, arbitrary precision and symbolic
 computation for all functions
 
 all functions?  yeah right.


Note that Support is not defined.  I believe, for some definition of 
support, this might have at least some semblance of truth.  Then 
again, you might just get an unevaluated something which is not useful.

Jason


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 4.1.alpha0

[Jason Grout]

William Stein wrote:
 On Wed, Jun 24, 2009 at 5:13 PM, Jason Groutjason-s...@creativetrax.com 
 wrote:
 Robert Miller wrote:
 Other easy ways to save release managers time, resulting in more
 frequent releases and shorter wait times to get your code merged:

 * Please include the trac number in each commit message if possible.
 Surely this could be scripted?  Just prepend a Trac #:  to the
 commit message when the patch is merged?  You could even do Trac #,
 patch x: 

 
 I still think it is a very good idea to include the trac number in
 each commit message.
 It makes it vastly easier on people when reading through the hg history later.
 


I totally agree.  Is it possible to modify the commit message of a patch 
when applying the patch to the Sage tree?  That was my suggestion, so 
that I don't have to worry so much about including the trac ticket 
number.  I'm constantly finding myself in your situation, where I've 
created a patch, but then have to re-edit the message just to add the 
ticket number.

Jason


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Ports to FreeBSD and/or NetBSD

[Robert Bradshaw]

On Jun 23, 2009, at 4:56 PM, Dr. David Kirkby wrote:


  From the top README.txt

 ---
 NOT SUPPORTED:
   * FreeBSD
   * Arch Linux
   * Gentoo Linux
   * Microsoft Windows (via Visual Studio C++)
   * Microsoft Windows (via Cygwin)

   We like all of the above operating systems, but just haven't had
   the time to make Sage work well on them.  Help wanted!
 ---

 Would it not be sensible to ask around on some FreeBSD/NetBSD mailing
 lists etc, and see if one could drum up enough support to start a  
 port?

 I don't know much about the *BSD's, having never played with them for
 more than a few minutes, but I can't see why there should be any huge
 hurdles to overcome.

 Having a port to those would be one big plus over the
 Mathematica/MATLAB/Maple guys.

 Typing FreeBSD into Google I get 20 million hits. For NetBSD it is 7.9
 million. For Solaris it is 40 million, but of course there is the film
 'Solaris' and some other users. But the *BSDs seem popular enough to
 warrant at least some effort in getting a port started.

I'm fairly ignorant about porting, but I think the fact that we  
already support OS X (very well) should be interesting to anyone  
trying to port to some of the other BSDs.

 I do know one very tech-savy FreeBSD guy who is a 'time-nut' but would
 no doubt know the places to ask. If you have never come across the
 'time-nuts', take a look at this for a very accurate wrist atomic  
 watch
 which keeps accurate to a few nanoseconds per day, though the battery
 life is a bit on the short side.

 http://leapsecond.com/pages/atomic-bill/

 The guy that runs that site (Tom) is a true 'time-nut' and has done
 things like climb mountains with cesium clocks strapped to his  
 body. His
 most accurate time-piece is a hydorogen maser. At one point in time
 (excuse the pun), the definition of a second will probably change  
 to be
 in terms of oscillations in the hydrogen maser, as it is more stable
 than cesium, in which the second is currently defined.

Interesting diversion :)

- Robert



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 4.1.alpha0

[Robert Bradshaw]

On Jun 24, 2009, at 8:15 PM, Jason Grout wrote:

 William Stein wrote:
 On Wed, Jun 24, 2009 at 5:13 PM, Jason Groutjason- 
 s...@creativetrax.com wrote:
 Robert Miller wrote:
 Other easy ways to save release managers time, resulting in more
 frequent releases and shorter wait times to get your code merged:

 * Please include the trac number in each commit message if  
 possible.
 Surely this could be scripted?  Just prepend a Trac #:  to the
 commit message when the patch is merged?  You could even do Trac  
 #,
 patch x: 


 I still think it is a very good idea to include the trac number in
 each commit message.
 It makes it vastly easier on people when reading through the hg  
 history later.



 I totally agree.  Is it possible to modify the commit message of a  
 patch
 when applying the patch to the Sage tree?  That was my suggestion, so
 that I don't have to worry so much about including the trac ticket
 number.  I'm constantly finding myself in your situation, where I've
 created a patch, but then have to re-edit the message just to add the
 ticket number.

If you're using queues, just use qrefresh -e. Personally, whenever I  
realize I don't have a ticket number, I realize that's a hint I need  
to go and create a ticket :).

- Robert


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 4.1.alpha0

[Tom Boothby]

On Wed, Jun 24, 2009 at 7:55 PM, Dr. David
Kirkbydavid.kir...@onetel.net wrote:

 Robert Miller wrote:
 This is the first release of the new cycle, and I've agreed to step in
 and co-chair the release with Tom. The source tarball and sage.math
 binary are available:

 http://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0.tar
 http://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0-sage.math-only-x86_64-Linux.tar.gz

 This is the first development release in which the new merge tools
 were used by people other than the authors. Several doctests fail on
 sage.math:

         sage -t  devel/sage-main/sage/graphs/graph.py # 25 doctests
 failed
         sage -t  devel/sage-main/sage/databases/database.py # 20
 doctests failed
         sage -t  devel/sage-main/sage/geometry/polyhedra.py # 1
 doctests failed

 These are all due to the removal of graph_isom.pyx, and I will be
 posting a patch to fix this shortly, at #6394. I think that there was
 no way to avoid these failures, since the only way to expose them was
 to remove the code, rebuild entirely from scratch, and then run the
 tests.

 This release does not include any tickets involving spkg's. I will
 make this the main focus of alpha1, which should drop before Friday.

 Each of the following tickets were rejected by the merge scripts, but
 unfortunately the failures are not available at this time (this is due
 to human error on my part). If you are involved with one of them, you
 are encouraged to try applying the patches to 4.1.alpha0 and see why/
 if they failed. Tom and I will eventually do this, but it would be
 helpful for people involved in the ticket to get things started:

 6196
 5481
 6276

 I'd like to know why 6276 failed. It seemed pretty simple, and should
 have only had an effect on Solaris.

 import shutil
 if os.uname()[0] == 'SunOS':
 shutil.copy2('patches/mmsearch-with-temp-Solaris-fix.c','src/tune/blas/gemm/mmsearch.c')


 6380 has positive review too, but that does not appear to have been
 listed as either failing, nor included.

Robert was in error when he reported that those tickets failed.  I
didn't apply anything to the scripts repo, or anything with a spkg.
Also, a number of tickets appeared in report 11 during the time
between me pulling down the patches and getting them applied / tested.
 #6380 will go in for alpha2, which will be rc1 if Robert manages to
get Mike Hansen's Python 2.6 spkg in.

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---