[sage-devel] Re: Decorators degrading documentation
First of all, sorry for the terrible word-wrapping in my previous post; it seems Google groups wraps at less than 80 characters. On Sep 23, 2:57 pm, Jason Grout wrote: > On 9/23/10 7:13 AM, Johan S. R. Nielsen wrote: > > > > > Hi > > >> I find the generic version of the function definitions less than > >> satisfactory. I'd guess it would be had to make Sphinx pickup the > >> more detailed info in these situations? I'd also guess the decorators > >> could maybe manipulate the docstring and inject some information based > >> on the arguments of the decorator? Either way, could the effect of > >> these decorators on the documentation be improved? > > > I agree that this is completely unacceptable. I have created Trac 9976 > > and > > written a patch for Sage's custom version of Sphinx. This essentially > > checks if > > a function/method to be documented is a decorator by looking for the > > attribute > > "_sage_decorating". If a function/method is actually a decorated > > version of > > another callable, then this callable should be referenced to in > > _sage_decorating. With my patch, Sphinx then constructs the signature > > from this > > callable instead. > > In the case of an @options decorator, it would be really cool if the > function signature could be modified to show the options, or in the case > of a @suboptions decorator, show the suboptions. Is there an easy way > to have a decorator change the signature in the docs? For example, > could we make a _sage_signature attribute that the decorator could > change, and use that for the docs? > > Thanks, > > Jason Thats a very nice extension; I guess all sorts of uses for this could be imagined. With the current patch, there is no easy way for the signature to be changed. One would have to define a new function with the appropriate signature inside the decorator and assign to _sage_decorating, as _sage_decorating contains only a reference to a callable. Originally, I wanted to use a _sage_signature like you suggest instead, but the problem was in constructing such a signature. The most practical thing would probably be to construct a signature as a named tuple such as that returned by inspect.getargspec and then let Sphinx format this to text. However, as can be seen by the code in doc.common.sage_autodoc.py surrounding my patches, it takes Sphinx quite a bit of logic to extract the signature, and I wanted to avoid having to copy that. Especially references to custom C-function signature-extractors scared me a bit. There is, of course, the possibility to have both custom attributes, and let _sage_signature override _sage_decorating in case both are defined. It still leaves the problem of having to construct these signatures in the general case. I think the idea is good, but I'm not completely sure how to do it elegantly. Cheers, Johan -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: import scipy failing in sage 4.6.alpha1
it's probably some lapack/blas/atlas related. Hard to say without seeing what you replaced by ... On Sep 24, 5:58 am, Niles wrote: > I just compiled 4.6.alpha1 on the machine rosemary.math at UGA (24- > core SUN machine running Redhat Linux Enterprise Edition) with (I > thought) no problems. But now I get > > sage: import scipy > Traceback (most recent call last): > ... > ImportError: No module named scipy > > Importing scipy works fine on the same machine with sage 4.3.1 (the > system-wide install on that machine) > > Is there something easy I "forgot" to do? > > -Niles -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Function assume() has no effect on Maxima via desolve()
On Sep 23, 11:19 am, rjf wrote: > On Sep 23, 5:36 am, Burcin Erocal wrote: > > > I think it would be a huge overstatement to say that the symbolics > > subsystem in Sage was "designed" in any way. IMHO, it was mostly > > patched together to support educational use, then acquired more cruft > > through several rewrite attempts and cramped schedules. > > I think that is true of ALL the subsystems in Sage. As we have tried to convince you before, this is very much NOT the case for large portions of Sage. In particular the sage-combinat and much of the algebraic geometry/number theory piece are definitely designed, certainly by this point. > In terms of my own interests, that is why the idea of rewriting Maxima > in > Python is pointless. But your interests are not quite the same as that of a practicing mathematician who would rather *use* math software than create the perfect one. And neither is that of the practicing neuroscientist, etc., who just wants easy access to something like our new Brian experimental package along with some other mathematics. That's fine, but not relevant in a normative sense. > Wouldn't you prefer to write a system that > addressed > the shortcomings of Macsyma (etc.) No. That would be a very good idea for someone whose research is directly related to those shortcomings. For most of those on this list, we would prefer to contribute to a system that has 1) Killer app in web-based interface 2) Has cutting-edge combinatorics and algebraic functionality 3) Has access to huge amounts of other libraries That could have been Maxima, no doubt! But for whatever reason its development went in other directions. That's fine. Maxima also wants everything 'in-house'; that's fine too; Sage prefers to use Python to glue other high-quality projects together with its (substantial) new code. I still don't know why you don't consider the truly new code in those areas to be interesting, but I suppose we all have the occupational hazard of overspecialization; I certainly do. > And by shortcomings I don't mean > "written in Lisp instead of Python". > Although this is a shortcoming in the sense that it is far more likely that someone who is not a computer scientist by training might actually be able to contribute, of course it isn't in the sense of how to write a high-level symbolic program. But that doesn't happen to be a goal of this project, though of course we are grateful to the GPL for allowing us to use the constantly improving symbolics in Maxima. And if anyone with Lisp knowledge ever reviews Nils Bruin's patch to make library access to Maxima the default, it will even be fast :) so we won't complain about that any more. But please don't make these blanket statements about the whole content of Sage until you are familiar with all those subsystems. As I've said before, and will likely say again :) Still, it's worth saying. All the best, - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Function assume() has no effect on Maxima via desolve()
> See #9835 and #9961 on the issue tracker. The patch by Robert > Marik attached to #9835 solves the problem you show below. I applied the #9835 patch, no effect, same outcome for the earlier posted example. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Problem with Expect: Mutilated temporary files in _eval_line
Hi, Simon, On Sep 23, 2010, at 15:38 , Simon King wrote: > On 24 Sep., 00:04, "Justin C. Walker" wrote: >> For most unix-like systems, it's generally not true that a close() of a file >> descriptor will wait until the file is closed. > > Thank you, that's good to know! Then it seems more than likely to me > that there's the problem with the expect interface. Agreed; see below. >>> Would it make sense to call os.fsync(F) after F.close()? >> >> I would think that doing this will only cause an error of some sort to be >> handed to your code: 'F' is not associated with anything after the close, so >> "os.sync(F)" would be essentially meaningless to the kernel. > > Sure, I meant to catch the ValueError that is raised when the file > really is done. > > But do I understand correctly that os.sync(F) will either raise a > ValueError orr wait until F.close() is completed? I can't say for sure, not having looked at the code, but I think it's a safe bet that when F.close() returns, the internal (Python) state shows that file structure as no longer usable. Therefore, it doesn't matter what the state of the "external-to-python" file is; as far as python code is concerned, it's closed. The sync() call will have either no effect (maybe returning an EISCLOSED-type error) or throw an exception. My guess is the former, but the manual (which I haven't checked) should say for sure. >> To your problem with corruption, if you are opening a new file descriptor >> for a file that you are writing with an existing file descriptor, you are >> asking for trouble, ... > > It is not *I* who is asking for trouble here: The code that I posted > above is from sage/interfaces/expect.py. Well, I was referring to the generic, lower-cost, more-widely-available 'you' :-} >>You write to the file descriptor >> Python holds onto the data for a while >>You open a new descriptor on the same file >> Python reads in what's there > > I guess that is exactly what's happening in the Gap, Singular,... > interfaces: > > - If one has a big string s, then singular(s) will not directly send s > to the singular interface, but eventually > singular._eval_line_using_file(s) is called.In that method, the file > singular._local_tmpfile() is opened for writing, s is written to it, > then it is closed. > - Directly after closing the file, it is read into Singular. I could > imagine that sometimes it is attempted to read it before closing it > succeeded. > - Moreover, if the next large input line occurs, then > singular._local_tmpfile() is again opened for writing -- perhaps > before the previous I/O to it was completed? I would say, as we did in the 70's and 80's, that's a big 10-4. >> I don't know enough about the rest of the system or your code to be sure >> this is what's happening. If you haven't already, try F.sync() (or >> os.sync(F)) before closing the file. > > So, better before than afterwards. Makes sense. Again, don't rely on things to happen exactly as you want them to. The sync() call tells the system (maybe both python and the kernel; not sure how it's implemented and what kind of cacheing python does) that you want the data sent to its final resting place. How that happens is up to a lot of "strategic" code that lives in the kernel and perhaps in python. In general, think of these calls as telling the underlying system "here's what I want to happen", not "do this now and come back when you're done". >> Another hack: try pausing before accessing the file after the close, so >> you're (more) sure that the close has had an effect before proceeding. > > I doubt that it would be acceptable to slow down every single call to > an expect interface by pausing. The latter was more of a suggestion to try, with the hopes of understanding more about what was going wrong. I didn't intend that to be a fix. >From your description above, it sounds pretty much like you know what is going >wrong and where. Delay loops might help verify it, but that's all they are >good for. Cheers, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds Men are from Earth. Women are from Earth. Deal with it. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Problem with Expect: Mutilated temporary files in _eval_line
Hi Justin! On 24 Sep., 00:04, "Justin C. Walker" wrote: > For most unix-like systems, it's generally not true that a close() of a file > descriptor will wait until the file is closed. Thank you, that's good to know! Then it seems more than likely to me that there's the problem with the expect interface. > > Would it make sense to call os.fsync(F) after F.close()? > > I would think that doing this will only cause an error of some sort to be > handed to your code: 'F' is not associated with anything after the close, so > "os.sync(F)" would be essentially meaningless to the kernel. Sure, I meant to catch the ValueError that is raised when the file really is done. But do I understand correctly that os.sync(F) will either raise a ValueError orr wait until F.close() is completed? > To your problem with corruption, if you are opening a new file descriptor for > a file that you are writing with an existing file descriptor, you are asking > for trouble, ... It is not *I* who is asking for trouble here: The code that I posted above is from sage/interfaces/expect.py. > You write to the file descriptor > Python holds onto the data for a while > You open a new descriptor on the same file > Python reads in what's there I guess that is exactly what's happening in the Gap, Singular,... interfaces: - If one has a big string s, then singular(s) will not directly send s to the singular interface, but eventually singular._eval_line_using_file(s) is called.In that method, the file singular._local_tmpfile() is opened for writing, s is written to it, then it is closed. - Directly after closing the file, it is read into Singular. I could imagine that sometimes it is attempted to read it before closing it succeeded. - Moreover, if the next large input line occurs, then singular._local_tmpfile() is again opened for writing -- perhaps before the previous I/O to it was completed? > I don't know enough about the rest of the system or your code to be sure this > is what's happening. If you haven't already, try F.sync() (or os.sync(F)) > before closing the file. So, better before than afterwards. Makes sense. > Another hack: try pausing before accessing the file after the close, so > you're (more) sure that the close has had an effect before proceeding. I doubt that it would be acceptable to slow down every single call to an expect interface by pausing. Best regards, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Problem with Expect: Mutilated temporary files in _eval_line
On Sep 23, 2010, at 13:22 , Simon King wrote: > On 23 Sep., 21:11, Simon King wrote: >> ... >> I would expect that F.close() waits until the file F really is closed, >> but perhaps I am mistaken? For most unix-like systems, it's generally not true that a close() of a file descriptor will wait until the file is closed. The file may be open in multiple processes or threads, so the close just decrements a "hold count". Then there's the fact that closing a file on-disk is a multi-stage affair, and that in a sense, it's not really closed until all the appropriate disk blocks have actually been physically written to the "platters" on which they reside. File operations are generally asynchronous. In the interest of obsessive completeness (without claim of completeness), one exception is the (last) close on a device (like a tty) that has a state transition that is required for correct operation: the driver will hold the calling thread in abeyance until the proper state is reached. >> Anyway, it does occasionally happen to me (but it is hardly >> reproducible) that the temporary file is mutilated when >> self._eval_line(self._read_in_file_command(tmp_to_use), >> allow_use_file=False) is executed. Is there a way to test whether the >> creation of the file succeeded (and wait if it isn't done yet), before >> trying to read it? > > Would it make sense to call os.fsync(F) after F.close()? I would think that doing this will only cause an error of some sort to be handed to your code: 'F' is not associated with anything after the close, so "os.sync(F)" would be essentially meaningless to the kernel. To your problem with corruption, if you are opening a new file descriptor for a file that you are writing with an existing file descriptor, you are asking for trouble, particularly if Python (or some library between your code and Python or the kernel) is caching. Consider this: You write to the file descriptor Python holds onto the data for a while You open a new descriptor on the same file Python reads in what's there Now you have two internal (to Python) copies of data from the same file that differ. Wash rinse repeat. I don't know enough about the rest of the system or your code to be sure this is what's happening. If you haven't already, try F.sync() (or os.sync(F)) before closing the file. That may close the window where corruption can occur. I hadn't been following the thread so I'm not sure whether you're already doing this. Another hack: try pausing before accessing the file after the close, so you're (more) sure that the close has had an effect before proceeding. HTH Justin -- Justin C. Walker, Curmudgeon at Large Director Institute for the Enhancement of the Director's income --- -- They said it couldn't be done, but sometimes, it doesn't work out that way. - Casey Stengel -- -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] import scipy failing in sage 4.6.alpha1
I just compiled 4.6.alpha1 on the machine rosemary.math at UGA (24- core SUN machine running Redhat Linux Enterprise Edition) with (I thought) no problems. But now I get sage: import scipy Traceback (most recent call last): ... ImportError: No module named scipy Importing scipy works fine on the same machine with sage 4.3.1 (the system-wide install on that machine) Is there something easy I "forgot" to do? -Niles -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Problem with Expect: Mutilated temporary files in _eval_line
On 23 Sep., 21:11, Simon King wrote: > ... > I would expect that F.close() waits until the file F really is closed, > but perhaps I am mistaken? > > Anyway, it does occasionally happen to me (but it is hardly > reproducible) that the temporary file is mutilated when > self._eval_line(self._read_in_file_command(tmp_to_use), > allow_use_file=False) is executed. Is there a way to test whether the > creation of the file succeeded (and wait if it isn't done yet), before > trying to read it? Would it make sense to call os.fsync(F) after F.close()? Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Problem with Expect: Mutilated temporary files in _eval_line
Hi!
Occasionally, in particular if the hard disk is slow or the computer's
workload is heavy, I observe errors of the following kind:
File "/scratch/sking/sage-4.5.1-Solaris_10_SPARC-sun4u-SunOS/
local/lib/python/site-packages/sage/interfaces/expect.py", line 1032,
in __call__
return cls(self, x, name=name)
File "/scratch/sking/sage-4.5.1-Solaris_10_SPARC-sun4u-SunOS/
local/lib/python/site-packages/sage/interfaces/expect.py", line 1451,
in __init__
raise TypeError, x
TypeError: Unexpected EOF from Gap executing Read("/home/
SimonKing/.sage//temp/t2/26058//interface//tmp26058");
Similar errors occur for the Singular interface, and it is not only on
t2.
Could it be that the expect interface does not wait and tries to read
from the temporary file before it is completed?
I guess the relevant bit of code is in expect.py, namely line 612ff:
def _eval_line_using_file(self, line):
F = open(self._local_tmpfile(), 'w')
F.write(line+'\n')
F.close()
tmp_to_use = self._local_tmpfile()
if self.is_remote():
self._send_tmpfile_to_server()
tmp_to_use = self._remote_tmpfile()
try:
s =
self._eval_line(self._read_in_file_command(tmp_to_use),
allow_use_file=False)
...
I would expect that F.close() waits until the file F really is closed,
but perhaps I am mistaken?
Anyway, it does occasionally happen to me (but it is hardly
reproducible) that the temporary file is mutilated when
self._eval_line(self._read_in_file_command(tmp_to_use),
allow_use_file=False) is executed. Is there a way to test whether the
creation of the file succeeded (and wait if it isn't done yet), before
trying to read it?
Best regards,
Simon
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] (WARNING/2) toctree references unknown document
Hi Sébastien, On Fri, Sep 24, 2010 at 4:51 AM, slabbe wrote: > /Users/slabbe/Applications/sage-4.5.3/devel/sage/doc/en/reference/ > combinat/index.rst:4: (WARNING/2) toctree references unknown document > u'sage/combinat/e_one_star' > > But that file is added by the patch. Somebody ever seen that problem? Warnings like this happens when you rebuild the documentation. One way to fix it is to completely delete the whole output directory to which built documentation is deposited. Then build the documentation from scratch. That is, $ cd SAGE_ROOT $ rm -rf devel/sage-main/doc/output/ $ ./sage -b main $ ./sage -docbuild --no-pdf-links reference html 2>&1 | tee -a dochtml.log -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] (WARNING/2) toctree references unknown document
Hi sage-devel, I am actually reviewing ticket #8431 [1] and I have a problem with building the documentation. I obtain the following error message : /Users/slabbe/Applications/sage-4.5.3/devel/sage/doc/en/reference/ combinat/index.rst:4: (WARNING/2) toctree references unknown document u'sage/combinat/e_one_star' But that file is added by the patch. Somebody ever seen that problem? or know what is missing? More information are below. [1] http://trac.sagemath.org/sage_trac/ticket/8431 Thank you, Sébastien Labbé sla...@tchede ~/Applications/sage-4.5.3/devel/sage-review $ hg qpop patch queue now empty sla...@tchede ~/Applications/sage-4.5.3/devel/sage-review $ hg qpush applying trac_8431_e_one_star.patch now at: trac_8431_e_one_star.patch sla...@tchede ~/Applications/sage-4.5.3/devel/sage-review $ hg qst M doc/en/reference/combinat/index.rst A sage/combinat/e_one_star.py sla...@tchede ~/Applications/sage-4.5.3/devel/sage-review $ hg qdiff doc diff --git a/doc/en/reference/combinat/index.rst b/doc/en/reference/ combinat/index.rst --- a/doc/en/reference/combinat/index.rst +++ b/doc/en/reference/combinat/index.rst @@ -15,6 +15,7 @@ Combinatorics ../sage/combinat/dlx ../sage/combinat/matrices/dlxcpp ../sage/combinat/dyck_word + ../sage/combinat/e_one_star ../sage/combinat/finite_class ../sage/combinat/integer_list ../sage/combinat/integer_vector sla...@tchede ~/Applications/sage-4.5.3/devel/sage-review $ sage -b && sage -docbuild reference html -- sage: Building and installing modified Sage library files. Installing c_lib scons: `install' is up to date. Updating Cython code Time to execute 0 commands: 1.59740447998e-05 seconds Finished compiling Cython code (time = 0.746732950211 seconds) running install running build running build_py copying sage/combinat/e_one_star.py -> build/lib.macosx-10.5-i386-2.6/ sage/combinat running build_ext Total time spent compiling C/C++ extensions: 0.0658578872681 seconds. running install_lib copying build/lib.macosx-10.5-i386-2.6/sage/combinat/e_one_star.py -> / Users/slabbe/Applications/sage-4.5.3/local/lib/python2.6/site-packages/ sage/combinat byte-compiling /Users/slabbe/Applications/sage-4.5.3/local/lib/ python2.6/site-packages/sage/combinat/e_one_star.py to e_one_star.pyc running install_egg_info Removing /Users/slabbe/Applications/sage-4.5.3/local/lib/python2.6/ site-packages/sage-0.0.0-py2.6.egg-info Writing /Users/slabbe/Applications/sage-4.5.3/local/lib/python2.6/site- packages/sage-0.0.0-py2.6.egg-info real0m3.113s user0m1.909s sys 0m1.179s sphinx-build -b html -d /Users/slabbe/Applications/sage-4.5.3/devel/ sage/doc/output/doctrees/en/reference/Users/slabbe/Applications/ sage-4.5.3/devel/sage/doc/en/reference /Users/slabbe/Applications/ sage-4.5.3/devel/sage/doc/output/html/en/reference Running Sphinx v0.6.3 loading pickled environment... done building [html]: targets for 1 source files that are out of date updating environment: 0 added, 1 changed, 0 removed reading sources... [100%] combinat/ index /Users/slabbe/Applications/sage-4.5.3/devel/sage/doc/en/reference/ combinat/index.rst:4: (WARNING/2) toctree references unknown document u'sage/combinat/e_one_star' looking for now-outdated files... none found pickling environment... done checking consistency... done preparing documents... done writing output... [100%] index writing additional files... genindex modindex search copying static files... done dumping search index... done dumping object inventory... done build succeeded, 1 warning. Build finished. The built documents can be found in /Users/slabbe/ Applications/sage-4.5.3/devel/sage/doc/output/html/en/reference -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Bug: Python scripts try to run before Python is built.
On 23 September 2010 17:55, John H Palmieri wrote: > The script searches the files in the current directory, checking > whether the first line contains "python" and "#!". If so, it replaces > that line with "#!/usr/bin/env python". So if the package has > installed a python script, this makes sure it calls Sage's python. I > suppose it is possible that a package could install a python script > (e.g. for its front end) without python being present on the system > yet. > > So rewriting it using bash or sh or perl or some other prerequisite > might make the most sense. > > John Thank you John. In that case, I think it's better to just remove 29-line 'sage-make_relative' completely and move its functionality to the 426-line bash script ((sage-spkg) that calls 'sage-make_relative' It makes no sense to me to call one script from another like this. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Is the file $SAGE_ROOT/local/bin/sage-sage.py used for anything?
> > Wow, a TWO-digit Trac ticket. One of only three remaining, as far as > > I can tell... unfortunately it isn't easy to create a custom report > > listing things in numerical order only. > > > - kcrisman > > Click on the "Ticket #" header to sort by it. Or just go to: Oh, yeah. Sometimes I'm all GUIed out, and don't realize they serve a purpose other than looking pretty :) - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Is the file $SAGE_ROOT/local/bin/sage-sage.py used for anything?
On 9/23/10 12:28 PM, kcrisman wrote: On Sep 23, 11:33 am, John H Palmieri wrote: On Sep 23, 3:12 am, Jeroen Demeyer wrote: It seems to me that $SAGE_ROOT/local/bin/sage-sage.py is never used for anything. It seems to do more or less the same as $SAGE_ROOT/local/bin/sage-sage which is a shell script and which is called by $SAGE_ROOT/sage. It nobody complains, I will open a ticket to remove this file. Jeroen. It is not used. In fact, it isn't tracked by mercurial, so the release manager just has to delete the file from the version they're using to create the distributions. If someone wanted to work on trac ticket #21, then this file would Wow, a TWO-digit Trac ticket. One of only three remaining, as far as I can tell... unfortunately it isn't easy to create a custom report listing things in numerical order only. - kcrisman Click on the "Ticket #" header to sort by it. Or just go to: http://trac.sagemath.org/sage_trac/report/1?asc=1&sort=ticket Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Is the file $SAGE_ROOT/local/bin/sage-sage.py used for anything?
On Sep 23, 11:33 am, John H Palmieri wrote: > On Sep 23, 3:12 am, Jeroen Demeyer wrote: > > > It seems to me that > > $SAGE_ROOT/local/bin/sage-sage.py > > is never used for anything. It seems to do more or less the same as > > $SAGE_ROOT/local/bin/sage-sage > > which is a shell script and which is called by $SAGE_ROOT/sage. > > > It nobody complains, I will open a ticket to remove this file. > > > Jeroen. > > It is not used. In fact, it isn't tracked by mercurial, so the > release manager just has to delete the file from the version they're > using to create the distributions. > > If someone wanted to work on trac ticket #21, then this file would Wow, a TWO-digit Trac ticket. One of only three remaining, as far as I can tell... unfortunately it isn't easy to create a custom report listing things in numerical order only. - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Bug: Python scripts try to run before Python is built.
The script searches the files in the current directory, checking whether the first line contains "python" and "#!". If so, it replaces that line with "#!/usr/bin/env python". So if the package has installed a python script, this makes sure it calls Sage's python. I suppose it is possible that a package could install a python script (e.g. for its front end) without python being present on the system yet. So rewriting it using bash or sh or perl or some other prerequisite might make the most sense. John On Sep 23, 9:39 am, "Dr. David Kirkby" wrote: > On09/23/10 04:29 PM, John H Palmieri wrote: > > > > > > >> Notice two of the last last 3 lines above say > > >> Making Sage/Python scripts relocatable... > >> python: No such file or directory > > > This is from the script sage-spkg: > > > echo "Making Sage/Python scripts relocatable..." > > > cd "$SAGE_LOCAL"/bin > > ./sage-make_relative > > > Then sage-make_relative is a python script. > > > Maybe this part of the script should test for python's existence > > first, and if it's there, run it. Or test for the existence of both > > local/bin/python/... and python? > > > -- > > John > > Looking at the comments on the end, it makes no difference if this works or > not > before Python is built. I think testing for $SAGE_LOCAL/bin/python is probably > the best solution. I would not test for a system python, in case there's a > broken installation of Python, in which case it's anyones guess what will > happen. This error message is apparently harmless, but it's a bit dumb to have > confusing error messages. > > === > echo "Making Sage/Python scripts relocatable..." > > cd "$SAGE_LOCAL"/bin > ./sage-make_relative > > echo "Finished installing $PKG_NAME.spkg" > > # It's OK if the above fails -- in fact it will until Python > # itself gets installed. That's fine. > exit 0 > == > > I think just adding an > > if [ -f "$SAGE_LOCAL/bin/pthon" ] > > around the last few lines would avoid the error message. > > Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Bug: Python scripts try to run before Python is built.
On 09/23/10 04:29 PM, John H Palmieri wrote: Notice two of the last last 3 lines above say Making Sage/Python scripts relocatable... python: No such file or directory This is from the script sage-spkg: echo "Making Sage/Python scripts relocatable..." cd "$SAGE_LOCAL"/bin ./sage-make_relative Then sage-make_relative is a python script. Maybe this part of the script should test for python's existence first, and if it's there, run it. Or test for the existence of both local/bin/python/... and python? -- John Looking at the comments on the end, it makes no difference if this works or not before Python is built. I think testing for $SAGE_LOCAL/bin/python is probably the best solution. I would not test for a system python, in case there's a broken installation of Python, in which case it's anyones guess what will happen. This error message is apparently harmless, but it's a bit dumb to have confusing error messages. === echo "Making Sage/Python scripts relocatable..." cd "$SAGE_LOCAL"/bin ./sage-make_relative echo "Finished installing $PKG_NAME.spkg" # It's OK if the above fails -- in fact it will until Python # itself gets installed. That's fine. exit 0 == I think just adding an if [ -f "$SAGE_LOCAL/bin/pthon" ] around the last few lines would avoid the error message. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Bug: Python scripts try to run before Python is built.
On 09/23/10 04:29 PM, John H Palmieri wrote:
On Sep 23, 8:14 am, "Dr. David Kirkby"
wrote:
Readline is a package which has no dependences other than BASE (see
$SAGE_ROOT/spkg/standard/deps). So it can be built very early - before Python.
This is part of the log from a successful installation of readline.
=
-bash-4.1$ tail spkg/logs/readline-6.0.p2.log
make[2]: Leaving directory
`/home/users/drkirkby/sage-4.6.alpha1/spkg/build/readline-6.0.p2/src'
real8m1.326s
user4m33.895s
sys 0m50.145s
Successfully installed readline-6.0.p2
Now cleaning up tmp files.
Making Sage/Python scripts relocatable...
python: No such file or directory
Finished installing readline-6.0.p2.spkg
==
Notice two of the last last 3 lines above say
Making Sage/Python scripts relocatable...
python: No such file or directory
This is from the script sage-spkg:
echo "Making Sage/Python scripts relocatable..."
cd "$SAGE_LOCAL"/bin
./sage-make_relative
Then sage-make_relative is a python script.
Maybe this part of the script should test for python's existence
first, and if it's there, run it. Or test for the existence of both
local/bin/python/... and python?
--
John
But what if Python does not exist? We probably can't build it at this point, as
I doubt all Python's perquisites are in place.
This is the complete file, which is only 29 lines long.
=
drkir...@hawk:~/sage-4.6.alpha1$ cat ./spkg/base/sage-make_relative
#!/usr/bin/env python
import os
print "Making script relocatable"
for F in os.listdir('.'):
if F == 'sage-sage':
continue
if not os.path.isfile(F):
continue
try:
X = open(F,'r')
except IOError:
continue
L = X.readline()
if L.find("python") != -1 and L.find("#!") != -1:
Y = X.read()
X.close()
#print "Making interpreter for script %s relative"%F
try:
O = open(F,'w')
except IOError:
os.system('chmod u+w "%s"'%F)
O = open(F,'w')
O.write("#!/usr/bin/env python\n"+Y)
O.close()
==
I'm not a Python guru, but the first 12 lines seem to just try to check if
"sage-sage" can be opened for reading. Is it me, or is that Python overly
complicated?
I could easily do with:
if [ -r "sage-sage" ]
in a shell script.
I'd have to try to work out what the rest of this Python does, but at only 29
lines, I doubt it would be hard to rewrite this as a more portable shell script.
It looks like it creates the pyton script at the end, with the contents of just
"#!/usr/bin/env python"
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: Function assume() has no effect on Maxima via desolve()
To implement the proviso system I mentioned would require that it be deeply embedded in the algorithms. Whenever an algorithm (say, division) did an operation that involved a proviso it would need to (a) decorate the result with the proviso and (b) potentially split the answer into separate sub-answers for further computation. Note that I did not make any restrictions on the provisos so they could be anything (not even necessarily computable), such as polynomials or roots (e.g. [x suchthat x in roots of ] and they don't need to be intervals (e.g. f(x) is holonomic, the so-called "is" provisos). There are deep research questions here involving reformulating normal algorithmic computations to collect the provisos, splitting the collection into (not necessarily decidable) disjoint sets, doing parallel computation under a proviso set (generating further subsets as the computation proceeds), combining partial results to poison other branches of the parallel computation tree (which implies computing partial CAD results and a "blackboard architecture") and the question of combining results under proviso constraints (e.g. combining intervals if the representations are intervals, in order to recover the real line or the complex plane). There is a whole research program here but the NSF doesn't seem to know or care so its unlikely to be explored except by open source. Axiom has a long term goal of refactoring the algebra to include this in the design at the fundamental level (which was the point of the thesis work). It is only in recent years that hundred-core machines are becoming available to support the huge parallel trees this generates. A proviso-based system will enable parallel computation in a "natural" manner as opposed to the current ideas that depend on simple cases (like matrix multiply). An "assume" facility that is bolted-on after the fact cannot possibly handle issues that arise as part of the computation since intermediate expressions can contain computations that are not apparent in the final result. An assume facility could create some initial conditions but would naturally be expressed using something like Axiom's "suchthat". Tim Daly On 9/23/2010 11:19 AM, rjf wrote: On Sep 23, 5:36 am, Burcin Erocal wrote: I think it would be a huge overstatement to say that the symbolics subsystem in Sage was "designed" in any way. IMHO, it was mostly patched together to support educational use, then acquired more cruft through several rewrite attempts and cramped schedules. I think that is true of ALL the subsystems in Sage. In terms of my own interests, that is why the idea of rewriting Maxima in Python is pointless. Wouldn't you prefer to write a system that addressed the shortcomings of Macsyma (etc.) And by shortcomings I don't mean "written in Lisp instead of Python". There are perhaps papers hinting at the Macsyma "assume" system capabilities by Michael Genesereth, but a quick search did not reveal them. The Maple system has a more ambitious capability, but it is still patched on. I do not know where the Mathematica version contains, at the moment. It seems to grow, every so often. But it is still patched on. The note from Tim suggests that (I think) linear inequalities and rectangular regions can encode most conditions of interest. Or maybe polynomial conditions? Certainly not all. And cylindrical algebraic decomposition may be useful, though potentially quite expensive, there is all that other stuff that is not algebraic. Like log, exp, cos, ... I am definitely not an expert in this field and have no idea how the assumptions should work. If you can provide some references, perhaps these could be used as starting points when/if somebody decides to work on this. Well, you can probably start with that Maple reference, the next time you design a system. Unfortunately, Sage is already built, and it is probably too late. But Stein is doing something else, so you don't have to worry about him getting in the way. Maybe UberSage; you can call Sage if you need to. Here is the only reference I found on this topic: http://portal.acm.org/citation.cfm?id=680466 The article is available for download here (for those with access): http://www.springerlink.com/content/p77364025wh6j7h5/ Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Is the file $SAGE_ROOT/local/bin/sage-sage.py used for anything?
On Sep 23, 3:12 am, Jeroen Demeyer wrote: > It seems to me that > $SAGE_ROOT/local/bin/sage-sage.py > is never used for anything. It seems to do more or less the same as > $SAGE_ROOT/local/bin/sage-sage > which is a shell script and which is called by $SAGE_ROOT/sage. > > It nobody complains, I will open a ticket to remove this file. > > Jeroen. It is not used. In fact, it isn't tracked by mercurial, so the release manager just has to delete the file from the version they're using to create the distributions. If someone wanted to work on trac ticket #21, then this file would actually be relevant. (I think that a release manager tested #21 at some point, thus creating the file, then had problems and so backed out the patch. This left the file there, but made it no longer tracked. But it never got deleted from local/bin/.) -- John -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Sage is embarrassingly slow
On 23 Sep, 12:40, David Roe wrote: > So if people want speedups for coercion between Integers and > IntegerMods and between lists and Polynomial_zmod_flint, someone should > review the finite field patches. :-) > David As I pointed out earlier today in a comment on one of the tickets concerned, it's highly unlikely that anyone's going to review the finite field patches in their current state, because the whole lot is too big a target, and the individual tickets don't work on their own. I've spent the last half hour playing around backporting the necessary bits of #8333 and #8334 needed to get #7883 working so I can review it. I have now done this, and I am about to give it a positive review. I will look at #8333 next; but #8334 is currently very broken. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Bug: Python scripts try to run before Python is built.
On Sep 23, 8:14 am, "Dr. David Kirkby" wrote: > Readline is a package which has no dependences other than BASE (see > $SAGE_ROOT/spkg/standard/deps). So it can be built very early - before Python. > > This is part of the log from a successful installation of readline. > > = > -bash-4.1$ tail spkg/logs/readline-6.0.p2.log > make[2]: Leaving directory > `/home/users/drkirkby/sage-4.6.alpha1/spkg/build/readline-6.0.p2/src' > > real 8m1.326s > user 4m33.895s > sys 0m50.145s > Successfully installed readline-6.0.p2 > Now cleaning up tmp files. > Making Sage/Python scripts relocatable... > python: No such file or directory > Finished installing readline-6.0.p2.spkg > == > > Notice two of the last last 3 lines above say > > Making Sage/Python scripts relocatable... > python: No such file or directory This is from the script sage-spkg: echo "Making Sage/Python scripts relocatable..." cd "$SAGE_LOCAL"/bin ./sage-make_relative Then sage-make_relative is a python script. Maybe this part of the script should test for python's existence first, and if it's there, run it. Or test for the existence of both local/bin/python/... and python? -- John -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Function assume() has no effect on Maxima via desolve()
On Sep 23, 5:36 am, Burcin Erocal wrote: > I think it would be a huge overstatement to say that the symbolics > subsystem in Sage was "designed" in any way. IMHO, it was mostly > patched together to support educational use, then acquired more cruft > through several rewrite attempts and cramped schedules. I think that is true of ALL the subsystems in Sage. In terms of my own interests, that is why the idea of rewriting Maxima in Python is pointless. Wouldn't you prefer to write a system that addressed the shortcomings of Macsyma (etc.) And by shortcomings I don't mean "written in Lisp instead of Python". There are perhaps papers hinting at the Macsyma "assume" system capabilities by Michael Genesereth, but a quick search did not reveal them. The Maple system has a more ambitious capability, but it is still patched on. I do not know where the Mathematica version contains, at the moment. It seems to grow, every so often. But it is still patched on. The note from Tim suggests that (I think) linear inequalities and rectangular regions can encode most conditions of interest. Or maybe polynomial conditions? Certainly not all. And cylindrical algebraic decomposition may be useful, though potentially quite expensive, there is all that other stuff that is not algebraic. Like log, exp, cos, ... > > I am definitely not an expert in this field and have no idea how the > assumptions should work. If you can provide some references, perhaps > these could be used as starting points when/if somebody decides to > work on this. Well, you can probably start with that Maple reference, the next time you design a system. Unfortunately, Sage is already built, and it is probably too late. But Stein is doing something else, so you don't have to worry about him getting in the way. Maybe UberSage; you can call Sage if you need to. > > Here is the only reference I found on this topic: > > http://portal.acm.org/citation.cfm?id=680466 > > The article is available for download here (for those with access): > > http://www.springerlink.com/content/p77364025wh6j7h5/ > > Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Bug: Python scripts try to run before Python is built.
Readline is a package which has no dependences other than BASE (see $SAGE_ROOT/spkg/standard/deps). So it can be built very early - before Python. This is part of the log from a successful installation of readline. = -bash-4.1$ tail spkg/logs/readline-6.0.p2.log make[2]: Leaving directory `/home/users/drkirkby/sage-4.6.alpha1/spkg/build/readline-6.0.p2/src' real8m1.326s user4m33.895s sys 0m50.145s Successfully installed readline-6.0.p2 Now cleaning up tmp files. Making Sage/Python scripts relocatable... python: No such file or directory Finished installing readline-6.0.p2.spkg == Notice two of the last last 3 lines above say Making Sage/Python scripts relocatable... python: No such file or directory William created http://trac.sagemath.org/sage_trac/ticket/9507 to check that SAGE_LOCAL/bin/python exists before running any packages that have spkg-install in them, but there's nothing to stop Sage trying to run python scrips before Python is installed. As we found on bsd.math, a slightly broken version of Python caused all sorts of problems when sage_fortran got screwed up. Clearly Python is not installed on this system, as we can test in two ways. 1) The portable (POSIX compatible test) -bash-4.1$ command -v python 2) The non-portable (non POSIX) test you are probably more familiar with. -bash-4.1$ which python which: 0652-141 There is no python in /opt/pware/bin /usr/bin /etc /usr/sbin /usr/ucb /home/users/drkirkby/bin /usr/bin/X11 /sbin .. So there's no Python installed on this system, but Sage has generated messages that python does not exist, and that its making Sage/Python scripts relocatable, before it has built Python. This I believe is a bug, which was unsurprisingly found when trying to build Sage on a less popular operating system (AIX). Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Function assume() has no effect on Maxima via desolve()
The problem is called the "proviso" problem, as in things like 1/x provided x != 0 I did thesis work in this area. One of the attacks is to use cylindrical algebraic decomposition (CAD). A second approach is to create a tree of expressions based on intervals such as [1/x where x < 0] [1/x where x = 0] [1/x where x > 0] The computation proceeds in 3 parts, each one under an interval assumption. If a new proviso is added the program tree-forks again: [1/x where x < 0 && 1/y where y < 0] [1/x where x < 0 && 1/y where y = 0] [1/x where x < 0 && 1/y where y > 0] [1/x where x = 0 && 1/y where y < 0] [1/x where x = 0 && 1/y where y = 0] [1/x where x = 0 && 1/y where y > 0] [1/x where x > 0 && 1/y where y < 0] [1/x where x > 0 && 1/y where y = 0] [1/x where x > 0 && 1/y where y > 0] Note that these can all be run in parallel and the results combined after the computation. This approach lends itself to massively parallel computations. I did a literature analysis of a couple hundred textbooks and found that approximately 80 percent of all equation provisos could be rewritten into interval constraints. A simple "assume" facility does not begin to address the problem for many reasons, such as the fact that provisos can arise during intermediate computations. Tim Daly On 9/23/2010 8:36 AM, Burcin Erocal wrote: On Wed, 22 Sep 2010 11:40:44 -0700 (PDT) rjf wrote: Many features in Maxima do not use the "assume" features at all. If Macsyma were to be redesigned from the ground up, the issues related to assume etc would probably be addressed at a foundational level. To the extent that other computer algebra systems claim to be a fresh look at issues, it appears that they have all failed to address this one. Instead they ignore "assumptions" and later patch them on in peculiar ways and provide access to this information only from some specific programs, e.g Mathematica's Integrate, Reduce, Simplify. But probably not much else. So this known problem (at least since 1974) was off the radar of the brainiacs who designed all those subsequent systems, including I suppose, Sage. I think it would be a huge overstatement to say that the symbolics subsystem in Sage was "designed" in any way. IMHO, it was mostly patched together to support educational use, then acquired more cruft through several rewrite attempts and cramped schedules. I am definitely not an expert in this field and have no idea how the assumptions should work. If you can provide some references, perhaps these could be used as starting points when/if somebody decides to work on this. Here is the only reference I found on this topic: http://portal.acm.org/citation.cfm?id=680466 The article is available for download here (for those with access): http://www.springerlink.com/content/p77364025wh6j7h5/ Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Function assume() has no effect on Maxima via desolve()
> > So this known problem (at least since 1974) was off the radar of the > > brainiacs > > who designed all those subsequent systems, including I suppose, Sage. > > I think it would be a huge overstatement to say that the symbolics > subsystem in Sage was "designed" in any way. IMHO, it was mostly > patched together to support educational use, then acquired more cruft > through several rewrite attempts and cramped schedules. I was going to say basically the same thing - nice summary, except to say that it was patched together using Maxima's assumption framework, since that was the best thing going inside of Sage for this purpose. - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Improvement of numerical integration routines
On 9/23/10 1:34 AM, Jonathan Bober wrote: At the very least, if a warning might be printed to standard output I would like a way to turn it off. If you use the standard Python warning framework, this would be easy. Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Decorators degrading documentation
On 9/23/10 7:13 AM, Johan S. R. Nielsen wrote: Hi I find the generic version of the function definitions less than satisfactory. I'd guess it would be had to make Sphinx pickup the more detailed info in these situations? I'd also guess the decorators could maybe manipulate the docstring and inject some information based on the arguments of the decorator? Either way, could the effect of these decorators on the documentation be improved? I agree that this is completely unacceptable. I have created Trac 9976 and written a patch for Sage's custom version of Sphinx. This essentially checks if a function/method to be documented is a decorator by looking for the attribute "_sage_decorating". If a function/method is actually a decorated version of another callable, then this callable should be referenced to in _sage_decorating. With my patch, Sphinx then constructs the signature from this callable instead. In the case of an @options decorator, it would be really cool if the function signature could be modified to show the options, or in the case of a @suboptions decorator, show the suboptions. Is there an easy way to have a decorator change the signature in the docs? For example, could we make a _sage_signature attribute that the decorator could change, and use that for the docs? Thanks, Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Improvement of numerical integration routines
On Thu, 23 Sep 2010 02:34:09 -0400 Jonathan Bober wrote: > In sage it seems there are a few different ways to get a numeric > approximation to an integral. There are the top level functions > integral and numerical_integral (and their synonyms), and then > symbolic expressions have a method nintegrate. So if f is a symbolic > expression, > > 1.) numerical_integral(f, 0, 1) > 2.) integral(f, x, 0, 1).n() and > 3.) f.nintegrate(x, 0, 1) > > do 3 different things. Maybe there are also other "top level" ways of > definite integration that don't require either an import statement or > a direct call to mpmath. > > I think I would like 1 and 3 to do the exact same thing. I don't know > if there is a good reason for them to be different. (I do know that I > might often be interested in integrating things that aren't symbolic > expressions, though.) I think that the behavior of integral().n() that > you list above is reasonable, though. If it fails like in the first > example you have above, then that is probably a _different_ bug. And > the second example is a type of problem we will probably always have > to deal with. (I have a similar example that came up in the "real > world" that I might try to dig up because I think it will have the > same bad behavior.) AFAIK, the reason 1 and 3 work differently is mostly historic. Fixing this could be a part of #7763: http://trac.sagemath.org/sage_trac/ticket/7763 The behavior of integral().n() has to be different from numerical_integral() since integral() first tries to integrate symbolically. One can use integral(..., hold=True).n() to get a similar effect, but the options you can pass to the numerical evaluation routines of symbolic expressions are limited at the moment. > A different behavior that I would find reasonable is for > integral().n() to _never_ do numeric integration. If integral() can't > get an exact answer, then integral().n() could just give an error and > ask the user to call numerical_integral() if that's what's wanted. I would be OK with this as well. > If integral().n() always did numeric integration, then it would of > course suffer from the problems below. How does doing N[Integrate[ ... ]] in MMA compare to using NIntegrate? Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Function assume() has no effect on Maxima via desolve()
On Wed, 22 Sep 2010 11:40:44 -0700 (PDT) rjf wrote: > Many features in Maxima do not use the "assume" features at all. > If Macsyma were to be redesigned from the ground up, the issues > related to assume etc would probably be addressed at a foundational > level. > > To the extent that other computer algebra systems claim to be a fresh > look at issues, it appears that they have all failed to address this > one. > > Instead they ignore "assumptions" and later patch them on in peculiar > ways > and provide access to this information only from some specific > programs, e.g > Mathematica's Integrate, Reduce, Simplify. But probably not much > else. > > So this known problem (at least since 1974) was off the radar of the > brainiacs > who designed all those subsequent systems, including I suppose, Sage. I think it would be a huge overstatement to say that the symbolics subsystem in Sage was "designed" in any way. IMHO, it was mostly patched together to support educational use, then acquired more cruft through several rewrite attempts and cramped schedules. I am definitely not an expert in this field and have no idea how the assumptions should work. If you can provide some references, perhaps these could be used as starting points when/if somebody decides to work on this. Here is the only reference I found on this topic: http://portal.acm.org/citation.cfm?id=680466 The article is available for download here (for those with access): http://www.springerlink.com/content/p77364025wh6j7h5/ Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Two elliptic curve + PARI tickets needing review
Both done. David -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Decorators degrading documentation
Hi > I find the generic version of the function definitions less than > satisfactory. I'd guess it would be had to make Sphinx pickup the > more detailed info in these situations? I'd also guess the decorators > could maybe manipulate the docstring and inject some information based > on the arguments of the decorator? Either way, could the effect of > these decorators on the documentation be improved? I agree that this is completely unacceptable. I have created Trac 9976 and written a patch for Sage's custom version of Sphinx. This essentially checks if a function/method to be documented is a decorator by looking for the attribute "_sage_decorating". If a function/method is actually a decorated version of another callable, then this callable should be referenced to in _sage_decorating. With my patch, Sphinx then constructs the signature from this callable instead. All decorators (on documented functions/methods) should then set this attribute; in particular, sage_wraps does so (with my patch), and I guess that every decorator aimed at documented functions/methods should use sage_wraps. Ideally, noone should therefore again have to know about this workaround. This seems to work for every function and method I have looked at. However, it is a bit tedious to force Sphinx to do the rebuild. It seems that you have to manually touch all py-files, do a complete rebuild (sage -ba) and then rebuild the documentation. I hope that you agree this solution is sensible. Simon King wrote: > Why is this? For my group cohomology spkg, I wrote some decorator > "temporary_result" that caches methods of a ring approximation (i.e., > generators and relations are only known out to a certain degree), but > clears the cache if more generators or relations are found in higher > degree. > > So, in the code, I have, e.g.: > @temporary_result > def poincare_series(self): > """ > Return the Poincar\\'e series... > ... > """ > ... > > "poincare_series" DOES appear in the package's manual (see > http://sage.math.washington.edu/home/SimonKing/Cohomology/cohomology). The problem is not that the functions won't appear but that they will have the signature (argument list) of the decorator; for decorators which can decorate a function with any argument, this will often be the generic signature "(*args, **kwargs)". In your case, your method does not take any arguments (except for self), and neither does the decorator, so you will see no difference in the documentation. > Moreover, the decorator also manages to decorate the given docstring, > so that it becomes > Temporarily cached method: Return the Poincar’e series... > > The decorator is a callable class, and a decorated method is an > instance of this class. This instance can apparently borrow the name > and the docstring (even adding a modification) from the method. > > Since the decorators in Sage (more precisely: the cached method > decorator) were my source of inspiration, I am surprised that > @CachedFunction is problematic for the documentation. The docstring and name is inherited by the decorator by using Python's "wraps" decorator inside the decorator; isn't that what you did? We need a similar mechanism for inheriting the signature. My patch does this by requiring decorators to set the attribute _sage_decorating, which is automatically done by using Sage's "sage.misc.decorators.sage_wraps" decorator (see also Trac #9907). Cheers, Johan -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Two elliptic curve + PARI tickets needing review
I've done #9931. I have looked at #6327 and it looks fine; I have doctests running at the moment, and if they pass I will give a positive review for that one as well. On 23 Sep, 10:54, Jeroen Demeyer wrote: > Hello, > > I have two patches up for review involving both elliptic curves and > PARI. The second one depends on the first for a doctest. > * #9931: Implement conversion from EllipticCurvePoint to PARI > * #6327: Document PARI's ellpow() function for CM curves > > Thanks, > Jeroen. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Sage is embarrassingly slow
Patch up at http://trac.sagemath.org/sage_trac/ticket/9887 It speeds up the issues pointed out in #9882, #9883, #9884, #9885 and #9887. It should fix #9886 as well; I'm not sure why it doesn't. #9888 is still unresolved. It depends on #7883, #8333, #8334 and #9814 (this last is positively reviewed). So if people want speedups for coercion between Integers and IntegerMods and between lists and Polynomial_zmod_flint, someone should review the finite field patches. :-) David On Thu, Sep 9, 2010 at 20:53, David Roe wrote: > There are some implemented coercion maps already (see > sage.rings.finite_rings.integer_mod.Integer_to_IntegerMod). Many of these > tickets can be solved by writing optimized coercion and conversion morphisms > and including appropriate section() functions on some of them. See the > patch at #9814, though that still needs a bit of work. > > I can probably do this fairly easily, but not tonight. :-) > David > > > On Thu, Sep 9, 2010 at 12:24, David Harvey wrote: > >> Dear sage-devel, >> >> Sage is very slow. I discovered this (again) while trying to write a >> prototype of an algorithm for computing zeta functions of projective >> varieties. I need to multiply lots of polynomials and matrices over finite >> rings, and frequently move coefficients between polynomials and matrices. >> The arithmetic is actually not too bad; it's the boring data movement stuff >> that really sucks. I made a bunch of tickets: >> >> http://trac.sagemath.org/sage_trac/ticket/9882 >> http://trac.sagemath.org/sage_trac/ticket/9883 >> http://trac.sagemath.org/sage_trac/ticket/9884 >> http://trac.sagemath.org/sage_trac/ticket/9885 >> http://trac.sagemath.org/sage_trac/ticket/9886 >> http://trac.sagemath.org/sage_trac/ticket/9887 >> http://trac.sagemath.org/sage_trac/ticket/9888 >> >> Maybe I can be the first to #1 if I keep going! >> >> david >> >> -- >> To post to this group, send an email to sage-devel@googlegroups.com >> To unsubscribe from this group, send an email to >> sage-devel+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/sage-devel >> URL: http://www.sagemath.org >> > > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Strange behaviour with doctest
On Sep 22, 12:28 am, Mitesh Patel wrote: > On 09/21/2010 07:57 AM, luisfe wrote: > Could you give the output of the qepcad.py test? There is a related bug in trac: http://trac.sagemath.org/sage_trac/ticket/5155 I have posted there quepcad failures -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Strange behaviour with doctest
There is a related bug in trac http://trac.sagemath.org/sage_trac/ticket/5155 I have posted there quepcad failures -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Is the file $SAGE_ROOT/local/bin/sage-sage.py used for anything?
It seems to me that $SAGE_ROOT/local/bin/sage-sage.py is never used for anything. It seems to do more or less the same as $SAGE_ROOT/local/bin/sage-sage which is a shell script and which is called by $SAGE_ROOT/sage. It nobody complains, I will open a ticket to remove this file. Jeroen. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Build error in sqlite-3.6.22 found by randomised testing.
On 23 September 2010 10:42, Volker Braun wrote: > Something is wrong with escaping the quotation marks in the gcc call. > How are you implementing the delay? Are you sure it preserves shell > escapes? If anything it seems to be a bug in the shell or make, but > not sqlite. > > Cheers, > Volker Yes, I realised the problem. I will correct it. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Two elliptic curve + PARI tickets needing review
Hello, I have two patches up for review involving both elliptic curves and PARI. The second one depends on the first for a doctest. * #9931: Implement conversion from EllipticCurvePoint to PARI * #6327: Document PARI's ellpow() function for CM curves Thanks, Jeroen. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: does the cdd spkg really need its own (pseudo)random number generator added?
Just to summarize the pros and cons. Right now, cdd uses the system libc rng, which is not the same on all platforms and leads to doctest errors. We have two options: 1) Add a "stupid" rng to cdd. Quality of the random numbers is not important. Introduces a few lines of code duplicated from the GNU C library. 2) Make cdd depend on gsl. Enhance the automake scripts for cdd to allow "--with-gsl". Push the extra dependency upstream (cdd has not had a new release since 2006, and many other projects use the cdd library as well). I have currently implemented 1). Best wishes, Volker -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Build error in sqlite-3.6.22 found by randomised testing.
On Sep 23, 12:11 am, "Dr. David Kirkby" wrote: > gcc "-DPACKAGE_NAME=\"sqlite\"" "-DPACKAGE_TARNAME=\"sqlite\"" > "-DPACKAGE_VERSION=\"3.6.22\"" "-DPACKAGE_STRING=\"sqlite 3.6.22\"" > "-DPACKAGE_BUGREPORT=\"http://www.sqlite.org\""; "-DPACKAGE=\"sqlite\"" > "-DVERSION=\"3.6.22\"" -D_FILE_OFFSET_BITS=64 -DSTDC_HEADERS=1 > [...] > -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -g -O2 -MT sqlite3.lo -MD -MP -MF > .deps/sqlite3.Tpo -c sqlite3.c -fPIC -DPIC -o .libs/sqlite3.o > gcc: 3.6.22": No such file or directory > :0:16: warning: missing terminating " character Something is wrong with escaping the quotation marks in the gcc call. How are you implementing the delay? Are you sure it preserves shell escapes? If anything it seems to be a bug in the shell or make, but not sqlite. Cheers, Volker -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: 3 easy to review documentation tickets
On 2010-09-23 11:09, daveloeffler wrote: > This adds several files in number fields to the reference manual, and > adds lots of missing doctests. Any takers? I'm having a look... -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: 3 easy to review documentation tickets
Another documentation / doctest patch which could do with a review: * #9359 http://trac.sagemath.org/sage_trac/ticket/9359, get number field doctest coverage up to 100% This adds several files in number fields to the reference manual, and adds lots of missing doctests. Any takers? David On 21 Sep, 07:42, Minh Nguyen wrote: > Hi folks, > > We have three documentation tickets that should be easy to review: > > * #9850http://trac.sagemath.org/sage_trac/ticket/9850, make style of > documentation consistent with sagemath.org > > * #9936http://trac.sagemath.org/sage_trac/ticket/9936, add > sage.symbolic.function_factory to the reference manual > > * #8825http://trac.sagemath.org/sage_trac/ticket/8825, Improve > documentation for function norm > > The latter ticket is an attempt to make the documentation more useful > by adding suggestions for related commands. In this case the command > in question is norm(). The idea of adding suggestions for related > commands can be found at this AskSage thread: > > http://ask.sagemath.org/question/116/development-of-help-files > > If you have some suggestions for commands related to a specific > command, please open a ticket and list those related commands. Thank > you very much for improving the user friendliness of the Sage > documentation. > > -- > Regards > Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
