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 S
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
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_
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 GN
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,
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
Y
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
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, v
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 sa
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
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.
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 argu
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
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 com
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 ninte
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 i
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
> > 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
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
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$ tai
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
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.
>
> ===
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
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 w
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-a
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
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-mak
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
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 whi
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 sh
> > 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
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 su
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/comb
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
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__
retur
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
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 th
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
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
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
> 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 fr
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
> >
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
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
44 matches
Mail list logo
