On 10/22/07, Nils Bruin <[EMAIL PROTECTED]> wrote:
> See:
>
> http://sagetrac.org/sage_trac/ticket/768
>
> I have updated the attached patch to be clean against 2.8.8.1. When I
> checked the edit() command in sage 2.8.8.1, I realized it was really
> broken -- It doesn't work if EDITOR is unset in
Hi,
Our opinion piece "Open Source Mathematical Software"
appeared in the Notices of the AMS this month:
http://www.ams.org/notices/200710/
The link to the article is on the upper-right corner of the page.
Thanks to everybody who helped with the article!
-- William
--
William Stei
2007/10/23, Steffen <[EMAIL PROTECTED]>:
> Exactly, thats one of two points. The maximum degree in every variable
> is (maximum total degree of resulting polynomial) / (number of
> varialbes of the polynomial). Thus for example GF(10007)
> ['x,y,z'].random_element(5,9) will be limited in every var
On 10/23/07, John Voight <[EMAIL PROTECTED]> wrote:
> I think I figured out a brutal way: Just delete the $HOME/.dsage/dsage
> directory!
>
> There must be a better way...
I had precisely the same complaint very recently, and Yi added a new
command to deal with exactly this problem:
sage: d = DS
I think I figured out a brutal way: Just delete the $HOME/.dsage/dsage
directory!
There must be a better way...
JV
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECT
I start a DSage server, then add several jobs to it, then kill SAGE.
Then I start DSage up again, and start workers. These workers go
after the dead jobs! Maybe this is a feature?
How do I get a "clean" DSage server?
Thanks, JV
--~--~-~--~~~---~--~~
To post t
On 10/23/07, Steffen <[EMAIL PROTECTED]> wrote:
> > Given this definition (which I agree is correct), I would expect that
> > if I ask for a total degree of 4, I would sometimes see monomials like
> > x^4 or x*y^3. I think the lack of these monomials is what surprises
> > (and, coincidentally, pl
> Actually, soon I will be doing matrix multiply over Z/p^N for some
> large N, so the matrix_modn_dense thing is relevant.
Maybe, but unfortunately matrix_modn_dense is only for small p.
> Another question: for large moduli like this, does it delay the
> reduction until after the adds/subs, eit
Hi everyone,
> We do have A._multiply_linbox(B), but we never
> use it by default, since when we first wrapped it sadly turned out
> to be slower than using our own multi-modular implementation.
> This is the sort of thing that may change someday, I hope...
Yep, that should change pretty soon!
I
On Oct 23, 2007, at 6:51 PM, David Harvey wrote:
> On Oct 23, 2007, at 9:47 PM, William Stein wrote:
>
>>
>> On 10/23/07, David Harvey <[EMAIL PROTECTED]> wrote:
For huge Z, I wonder if it's still trying to do multi-modular? That
would probably be bad. I'm also not sure how much of the
On Oct 23, 2007, at 9:47 PM, William Stein wrote:
>
> On 10/23/07, David Harvey <[EMAIL PROTECTED]> wrote:
>>> For huge Z, I wonder if it's still trying to do multi-modular? That
>>> would probably be bad. I'm also not sure how much of the dispatching
>>> is done in Linbox vs. Sage.
>>
>> Multim
On Oct 23, 2007, at 9:43 PM, Robert Bradshaw wrote:
>> 1) mpz_sizeinbase(..., 2) gives the number of bits in the number.
>> This will be O(1), but has to count how many bits are used in the
>> highest-order word. mpz_sizeinbase(..., 16) or mpz_sizeinbase(...,
>> 32) may or may not be faster.
>>
On 10/23/07, David Harvey <[EMAIL PROTECTED]> wrote:
> > For huge Z, I wonder if it's still trying to do multi-modular? That
> > would probably be bad. I'm also not sure how much of the dispatching
> > is done in Linbox vs. Sage.
>
> Multimodular would be terrible. You don't get any of the benefit
On Oct 23, 2007, at 6:37 PM, cwitty wrote:
> On Oct 23, 6:24 pm, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
>> Is there a way to get the size of an integer (really fast, like a
>> macro getting the number of words)? One could perhaps override
>> _strassen_default_cutoff (though I don't know how
On Oct 23, 6:24 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> Is there a way to get the size of an integer (really fast, like a
> macro getting the number of words)? One could perhaps override
> _strassen_default_cutoff (though I don't know how much overhead this
> would be for matrices with sm
On 10/23/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> Is there a way to get the size of an integer (really fast, like a
> macro getting the number of words)? One could perhaps override
> _strassen_default_cutoff (though I don't know how much overhead this
> would be for matrices with smallish
On Oct 23, 2007, at 9:24 PM, Robert Bradshaw wrote:
> Is there a way to get the size of an integer (really fast, like a
> macro getting the number of words)? One could perhaps override
> _strassen_default_cutoff (though I don't know how much overhead this
> would be for matrices with smallish en
Is there a way to get the size of an integer (really fast, like a
macro getting the number of words)? One could perhaps override
_strassen_default_cutoff (though I don't know how much overhead this
would be for matrices with smallish entries).
One can always enforce it by doing M._multiply_
Hi,
I'm interested in multiplying smallish matrices over Z with huge
entries.
On my machine, sage can multiply 300-bit integers in about 0.14s,
and adding integers of that size takes about 1/1000 of the time:
sage: x = ZZ.random_element(2^300)
sage: y = ZZ.random_element(2^300)
Jaap,
dance(10) computes fine on sage.math (in about 6 hours under gdb), I
am running dance(11) to see if it finishes [I guess you would like the
result ;)]. So, any chance you are running the computation on a 32 bit
box and/or run out of memory/have highly fragmented memory after a
long uptime?
This is now ticket 975.
I listed the component as "distribution" because I am guessing that that
is supposed to mean "issues with how the different parts of sage are all
put together", but I'm not sure if that is correct.
Thanks.
On Tue, 2007-10-23 at 09:16 -0700, mabshoff wrote:
>
>
> On Oct
On Oct 23, 6:04 pm, Jonathan Bober <[EMAIL PROTECTED]> wrote:
> > Could you give us the output from echo 'LD_LIBRARY_PATH' and 'ldd xdg-
> > open' with and without sourcing sage-env. If you add an 'echo
> > LD_LIBRARY_PATH' right before xdg-open is called in P.show()
>
> > >From the name of the
> Could you give us the output from echo 'LD_LIBRARY_PATH' and 'ldd xdg-
> open' with and without sourcing sage-env. If you add an 'echo
> LD_LIBRARY_PATH' right before xdg-open is called in P.show()
>
> >From the name of the symbol I would guess that it is a libz
> incompability. There was a pat
On Oct 23, 1:23 pm, Jaap Spies <[EMAIL PROTECTED]> wrote:
> Last year after less than two days I could finish
> a calculation and write to William:
>
>
>
> > Original Message
> > Subject: dance(10)
> > Date: Thu, 09 Mar 2006 00:10:19 +0100
> > From: Jaap Spies <[EMAIL PROTECTED
On 10/23/07, Jonathan Bober <[EMAIL PROTECTED]> wrote:
>
> Hi folks.
>
> I tried to send the following email a few hours ago (but I put the email
> address in wrong) and I don't feel like rewriting it all. So I should
> add to it now that I have upgraded sage (so I am running 2.8.8.1) and
> the er
Last year after less than two days I could finish
a calculation and write to William:
> Original Message
> Subject: dance(10)
> Date: Thu, 09 Mar 2006 00:10:19 +0100
> From: Jaap Spies <[EMAIL PROTECTED]>
> To: William Stein <[EMAIL PROTECTED]>
>
> William,
>
> Some time ago,
On 17 Okt., 06:20, cwitty <[EMAIL PROTECTED]> wrote:
> On Oct 16, 8:32 pm, "didier deshommes" <[EMAIL PROTECTED]> wrote:
>
> > 2007/10/16, Steffen <[EMAIL PROTECTED]>:
>
> > > Hi didier,
>
> > > the implementation does not return a polynomial of a total degree of
> > > at most 4, but a polynomia
27 matches
Mail list logo
