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
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
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
> >
> 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
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
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
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
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 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
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
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 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
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
> > 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 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
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
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 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
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
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 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
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, 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 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
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
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
> > 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
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
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 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 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
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
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
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.
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
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
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
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
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
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,
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
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_
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
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
44 matches
Mail list logo
