On Wed, Aug 4, 2010 at 5:19 AM, Marco Streng wrote:
> Robert Bradshaw schreef:
>>
>> What should be done is either fixing LazyNamedUnop to preserve
>> documentation, or populating these methods at class creation time
>> (rather than attribute lookup time, perhaps dynamically creating a
>> docstrin
On Thu, Aug 5, 2010 at 3:25 AM, Bill Hart wrote:
> The single biggest improvement in my mind would be made to MPIR. And I
> know the MPIR devels would absolutely love to have them contribute.
>
> Jason and Brian have been working very hard on simplifying MPIR so
> that it can be more easily modifi
On Thu, Aug 5, 2010 at 4:26 AM, Mitesh Patel wrote:
> On 08/04/2010 03:10 AM, Robert Bradshaw wrote:
>> On Sat, Jul 31, 2010 at 2:51 AM, Mitesh Patel wrote:
>>> On 07/30/2010 01:54 AM, Craig Citro wrote:
So we're currently working on a long-overdue release of Cython with
all kinds of sn
On Thu, Aug 5, 2010 at 2:29 AM, Minh Nguyen wrote:
> Hi Fredrik,
>
> Here's a simplistic way that doesn't involve cloning or queues.
> Compile Sage from source on your machine and wrap up a binary for that
> machine with
>
> $ ./sage -bdist x.y.z-description
>
> The resulting binary then appears u
On Thu, Aug 5, 2010 at 7:13 PM, Carl Witty wrote:
> On Thu, Aug 5, 2010 at 2:59 PM, Dr. David Kirkby
> wrote:
>> On 08/ 5/10 06:17 PM, Sergey Bochkanov wrote:
>>>
>>> Hello,
>>>
Hmmm... Didn't thought about this situation yet. Definitely we can't
solve this problem with any kind o
On Thu, Aug 5, 2010 at 7:18 PM, Carl Witty wrote:
> On Thu, Aug 5, 2010 at 4:06 PM, Simon King wrote:
>> I think it is easier to do
>> from sage.all import ZZ
>> instead of providing its exact location (from sage.rings.integer...).
>>
>> Moreover, using sage.all is more stable, because the exact
Has sympow been tested on Itanium Linux much?
>
Itanium versions exist in the repositories for Debian (Lenny/Sid), Ubuntu
and Fedora. So, the short answer is "yes."
>
> If I'm not mistaken, that script will include x86 based code for the
> floating point processor (in the file fpu.c) if the syst
On Thu, Aug 5, 2010 at 4:06 PM, Simon King wrote:
> I think it is easier to do
> from sage.all import ZZ
> instead of providing its exact location (from sage.rings.integer...).
>
> Moreover, using sage.all is more stable, because the exact location of
> things can change (so that "from sage.rings
On Thu, Aug 5, 2010 at 2:59 PM, Dr. David Kirkby
wrote:
> On 08/ 5/10 06:17 PM, Sergey Bochkanov wrote:
>>
>> Hello,
>>
>>> Hmmm... Didn't thought about this situation yet. Definitely we can't
>>> solve this problem with any kind of regular expressions. One
>>> possible solution is to
On 08/ 5/10 06:55 PM, Carl Witty wrote:
On Thu, Aug 5, 2010 at 10:23 AM, David Kirkby wrote:
BTW, do you have any ideas why the second failure at #9099 might occur
sage -t -long devel/sage/sage/symbolic/expression.pyx
**
File
On Fri, 6 Aug 2010 07:06:33 +1000, Peter Jeremy wrote:
> On 2010-Aug-04 14:51:21 -0700, Nils Bruin wrote:
> >There are other areas of mathematics where "<" gets used for proper
> >inclusion. A group theorist is going to be very surprised if for two
> >groups H,G, the expression "H < G" is valid b
Hi Victor,
On 5 Aug., 23:37, VictorMiller wrote:
> I find that in writing python code for inclusion into SAGE that I
> always need to add lines like:
>
> from foo import baz,faz,buz
>
> to the top of my file, in order to get standard SAGE things such as
> ZZ, QQ, factor, randint, etc. etc. known
On 08/ 5/10 06:17 PM, Sergey Bochkanov wrote:
Hello,
Hmmm... Didn't thought about this situation yet. Definitely we can't
solve this problem with any kind of regular expressions. One
possible solution is to round data before printing. So both
1.01 and 0.
Has sympow been tested on Itanium Linux much?
Anyone that reads sage-solaris will know John Palmieri has got Sage building on
fulvia (Solaris x86), but has some problems with sympow.
I decided to have a look at the sympow source code. It's not the easiest code to
follow, for various reasons.
Hi There,
> There are going to be a couple of hours of coding sprints each day at
> Sage Days 25 in India (Mon - Thur this coming week):
>
> http://wiki.sagemath.org/daysindia25/schedule
>
> However, unfortunately, there might not be any experienced Sage
> developers there (I'm no
I find that in writing python code for inclusion into SAGE that I
always need to add lines like:
from foo import baz,faz,buz
to the top of my file, in order to get standard SAGE things such as
ZZ, QQ, factor, randint, etc. etc. known to the code. The way I've
been doing that is to look at my cod
On 2010-Aug-04 14:51:21 -0700, Nils Bruin wrote:
>There are other areas of mathematics where "<" gets used for proper
>inclusion. A group theorist is going to be very surprised if for two
>groups H,G, the expression "H < G" is valid but does not mean "H is a
>subgroup of G".
I expect this is prim
Hello all,
I'm the maintainer of the sagemath package. Due to the package taking 8
months to get through NEW (resulting in it starting out 8 months out of
date) and my founding a startup around the time it entered NEW, I've never
had the time to update it across the original 8 months of backlo
On Thu, Aug 5, 2010 at 10:23 AM, David Kirkby wrote:
> BTW, do you have any ideas why the second failure at #9099 might occur
>
> sage -t -long devel/sage/sage/symbolic/expression.pyx
> **
> File
> "/home/palmieri/fulvia/sage-4.
On Thu, Aug 5, 2010 at 9:44 AM, David Kirkby wrote:
> With all the numerical noise issues I've seen in Sage, the three dots
> solves its. So if we expect
>
> 1.00
> but get
> 1.01
> we can change that to
> 1.0...
> and the test will pass.
>
> However, what if we
On 5 August 2010 17:57, Dima Pasechnik wrote:
> On Aug 5, 6:44 pm, David Kirkby wrote:
>> With all the numerical noise issues I've seen in Sage, the three dots
>> solves its. So if we expect
>>
>> 1.00
>> but get
>> 1.01
>> we can change that to
>> 1.0...
>> a
Hello,
> Hmmm... Didn't thought about this situation yet. Definitely we can't
> solve this problem with any kind of regular expressions. One
> possible solution is to round data before printing. So both
> 1.01 and 0.99 will become 1.00.
...however, we
Hello, David.
You wrote 5 августа 2010 г., 20:44:53:
> With all the numerical noise issues I've seen in Sage, the three dots
> solves its. So if we expect
> 1.00
> but get
> 1.01
> we can change that to
> 1.0...
> and the test will pass.
> However, what if we ge
On Aug 5, 6:44 pm, David Kirkby wrote:
> 2010/8/5 Sergey Bochkanov :
> > Hello, Jason.
>
> > You wrote 5 августа 2010 г., 20:17:11:
> >>> (depending on problem and its stability properties). However I don't
> >>> know how to do it using doctest framework. Python tries to output
> >>> number
2010/8/5 Sergey Bochkanov :
> Hello, Jason.
>
> You wrote 5 августа 2010 г., 20:17:11:
>>> (depending on problem and its stability properties). However I don't
>>> know how to do it using doctest framework. Python tries to output
>>> numbers with full precision,and there is no way to te
Hello, Jason.
You wrote 5 августа 2010 г., 20:17:11:
>> (depending on problem and its stability properties). However I don't
>> know how to do it using doctest framework. Python tries to output
>> numbers with full precision,and there is no way to tell doctest
>> framework to compare d
On 8/5/10 8:41 AM, Sergey Bochkanov wrote:
Hello, David
You wrote 4 августа 2010 г., 14:49:47:
8:
sage: maxima('asinh(1.0)')
Expected:
0.881373587019543
Got:
.8813735870195429
Clearly there is some numerical noise issues, which need to be
investigated, but are probably t
Hello, Carl.
You wrote 3 августа 2010 г., 6:39:49:
> On Wed, Jul 28, 2010 at 11:38 PM, Sergey Bochkanov
> wrote:
>> My proposal is to make
>> * boolean vector/matrix = GF(2), RDF (non-zero = True)
>> * integer vector/matrix = RDF
>> * real = RDF
>> * complex = CDF
Forgot to add: I think
Hello, Carl.
You wrote 3 августа 2010 г., 6:39:49:
> On Wed, Jul 28, 2010 at 11:38 PM, Sergey Bochkanov
> wrote:
>> My proposal is to make
>> * boolean vector/matrix = GF(2), RDF (non-zero = True)
>> * integer vector/matrix = RDF
>> * real = RDF
>> * complex = CDF
One more addition: I think tha
Hello, David
You wrote 4 августа 2010 г., 14:49:47:
> 8:
> sage: maxima('asinh(1.0)')
> Expected:
> 0.881373587019543
> Got:
> .8813735870195429
> Clearly there is some numerical noise issues, which need to be
> investigated, but are probably trivial.
I think that it is more
2010/8/5 cschwan :
Hi,
> There are six python files which would need a patch and more than five
> (we need only small numbers of scripts from sage_scripts). You may
> have look and the patches here:
I agree that a s|SAGE_ROOT/foo|SAGE_FOO| is required, that is, not only
for SAGE_LOCAL :-)
> 2. -tnew
>
> Not in the developer walkthrough since I didn't know about it when I
> wrote that. Limited testing indicates it looks for changed files in
> the mercurial repository that have not been commit'ed and tests
> those. It strikes me that looking for dependencies is a big job -
> there
On 5 Aug., 06:12, William Stein wrote:
> 4:30pm-8:00pm Mumbai, India time
That's 1pm to 4:30pm in central europe with summer time. I'll try to
be available on IRC, c'ya there and hello India :D
H
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this gr
Well, all running soomthly. :)
A lot of thanks to Dr. David Kirkby.
copy /b xaa+xab+xac .. xdu worked. I didn't have to create part1, part2...
But, sage on vmware seems a bit slow :(
by the way, storing sage on a FAT32 partion was the main problem.
Therefore, never keep sage on FAT32
:)
On 8/5/1
On 08/04/2010 03:10 AM, Robert Bradshaw wrote:
> On Sat, Jul 31, 2010 at 2:51 AM, Mitesh Patel wrote:
>> On 07/30/2010 01:54 AM, Craig Citro wrote:
>>> So we're currently working on a long-overdue release of Cython with
>>> all kinds of snazzy new features. However, our automated testing
>>> syste
The single biggest improvement in my mind would be made to MPIR. And I
know the MPIR devels would absolutely love to have them contribute.
Jason and Brian have been working very hard on simplifying MPIR so
that it can be more easily modified.
There are some instances in flint that would benefit.
There are six python files which would need a patch and more than five
(we need only small numbers of scripts from sage_scripts). You may
have look and the patches here:
-
http://www.students.uni-mainz.de/cschwan/sage-baselayout-4.5.1-fix-SAGE_LOCAL.patch
-
http://www.students.uni-mainz.de/cschw
Hi Christopher,
On Thu, Aug 5, 2010 at 7:49 PM, cschwan wrote:
> The "problem" is that in Sage's sources and scripts "$SAGE_ROOT/local"
> is often used instead of "$SAGE_LOCAL" which breaks Sage when these
> variables are set as written above, of course. Now my question: should
> this be consider
Hi,
our work with sage-on-gentoo has seen great progress - we are now able
to supply fully working and recent versions of Sage which live in /
usr. We did this (among other things) by setting
SAGE_LOCAL=/usr
SAGE_ROOT=/usr/share/sage
This enables Sage to put all scripts and binaries into /usr/bi
Hi Fredrik,
Here's a simplistic way that doesn't involve cloning or queues.
Compile Sage from source on your machine and wrap up a binary for that
machine with
$ ./sage -bdist x.y.z-description
The resulting binary then appears under SAGE_ROOT/dist/. Copy/move
that binary to somewhere safe so yo
Hi Harald,
On Tue, Aug 3, 2010 at 4:41 AM, Harald Schilly wrote:
> Personally. if I could define it, I would use these definitions:
Consider moving your definition to the Sage Developer's Guide. This is
now ticket 9690:
http://trac.sagemath.org/sage_trac/ticket/9690
--
Regards
Minh Van Nguyen
On 5 August 2010 09:00, David Kirkby wrote:
> Following a talk I gave at the London OpenSolaris User Group (LOSUG),
> I had some discussions with someone who knows SPARC assembler, and
> would be willing to devote some time to addling SPARC assembly
> support. The question I have, is where would h
Following a talk I gave at the London OpenSolaris User Group (LOSUG),
I had some discussions with someone who knows SPARC assembler, and
would be willing to devote some time to addling SPARC assembly
support. The question I have, is where would his efforts be best
directed? Pari, Flint, MPIR, MPFR,
Last week I couldn't get it to load at all from Oberwolfach (kept
timing out); I didn't have any other internet problems there, and now
trac is working fine for me from Georgia (U.S.)
-Niles
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, se
44 matches
Mail list logo
