ok, it isn't normalize, but a very small function called npWrite
void npWrite (number &a)
{
if ((long)a > (npPrimeM >>1)) StringAppend("-%d",(int)(npPrimeM-
((long)a)));
else StringAppend("%d",(int)((long)a));
}
This is set to the current ring
in numbers.cc
n->nWrite
> Did you check how fast singular is for the Lewis-Wester determinants?
Are these some kind of benchmark(et)ing examples? Where can I find the input
matrices? Sorry, never heard that name before ... which isn't that
surprising, since I never thought about this computation before the bug
report
> f():=randpoly(1,x)*randpoly(1,y)/rand(100)
Actually it should be f():=randpoly(1,x)*randpoly(1,y)/(1+rand(100)),
otherwise you would get sometimes infinity. It is not quite
equivalent, however I could manage to make some comparisons using sage
C=random_matrix() and maxima(C) to import C into g
On Thursday 11 September 2008, Martin Albrecht wrote:
> > Did you check how fast singular is for the Lewis-Wester determinants?
>
> Are these some kind of benchmark(et)ing examples? Where can I find the
> input matrices? Sorry, never heard that name before ... which isn't that
> surprising, since
> Okay, found it:
>
That's the M benchmarks (the matrices are dense), could you try O1,
O2?
(at least the det and gcd parts).
I guess you had to turn to QQ to call singular via your patch,
correct?
--~--~-~--~~~---~--~~
To post to this group, send email to sage-de
On Thursday 11 September 2008, parisse wrote:
> > Okay, found it:
>
> That's the M benchmarks (the matrices are dense), could you try O1,
> O2?
It turns out, here Sage/Singular is doing worse than Magma:
O1 (det1) = 0.720 (MAGMA)
O1 (det2) = 1.550 (MAGMA)
O1 = 2.420 (MAGMA)
O2 = 2.110 (MAGMA
Hi, Mike,
On Sep 9, 2008, at 9:34 PM, Mike Hansen wrote:
>> What's the difference between "==" and "is" (or, more to the point:
>> where is this discussed)?
>
> This is a Python thing as "==" is equality testing and "is" is memory
> address testing. For example,
>
> sage: a = 2
> sage: b = 2
>
Unless there is something I'm missing here, it seems to me this is a
classic problem that has been explored in the literature using several
approaches.
Depending on the sparsity of the entries, (sparse as polynomials) or
sparsity of the matrix (as zero entries) and size of coefficients, it
could
On Sep 11, 10:14 am, "Georg S. Weber" <[EMAIL PROTECTED]>
wrote:
> Hi,
Hi,
> more evidence that 3.1.2rc1 is severely broken on PPC platforms,
It is not broken any more or less than pretty much any other
platform :)
> most
> probably due to lisp problems, give the following three failures /
>
Hi,
more evidence that 3.1.2rc1 is severely broken on PPC platforms, most
probably due to lisp problems, give the following three failures /
maxima crashes on my PowerBook G4 (OS X 10.4):
...
sage -t -long devel/sage/sage/calculus/calculus.py
*
Hello number field gurus,
The following code appears in number_field.py. Caching refers to the
global cache of known number fields: if you create a number field with
same polynomial and same name, you get back a globally unique instance.
{{{
def _set_structure(self, from_self, to_self,
On 11 Sep., 19:21, mabshoff <[EMAIL PROTECTED]> wrote:
> On Sep 11, 10:14 am, "Georg S. Weber" <[EMAIL PROTECTED]>
> wrote:
>
> > Hi,
>
> Hi,
>
> > more evidence that 3.1.2rc1 is severely broken on PPC platforms,
>
> It is not broken any more or less than pretty much any other
> platform :)
>
>
On 10 Sep., 22:33, mabshoff <[EMAIL PROTECTED]> wrote:
> On Sep 10, 9:51 am, "William Stein" <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> Him
>
> > I'm not sure what has been reported so far regarding building rc1, but here
> > are some failures.
>
> > On OSX 10.5 these fail:
>
> > sage -t -
Sorry,
in my last message, I think I erred in blaiming Maxima or the
interface from Sage to Maxima.
It seems to be a "lisp-only" problem with low memory, which causes all
this, since the "lisp.py" has probably nothing to do with Maxima at
all.
But my guess still would be, that the sporadic hangs
Hi,
On 9 Sep., 22:46, Simon Beaumont <[EMAIL PROTECTED]> wrote:
> Ooops I only got as far as: make sure you're using better than gcc
> 4.0.0! I Didn't read the small print.
> I have Xcode 2.2.1 mea culpa.
>
> Component versions
> Xcode IDE: 656.0
> Xcode Core: 660.0
> ToolSupport: 651.0
>
> On Se
On Sep 11, 1:42 pm, "Georg S. Weber" <[EMAIL PROTECTED]>
wrote:
Hi,
> Hi,
> now that's interesting: gcc v4.0.1, i.e version greater than 4.0.0,
> but still Xcode version lower than 2.4 ...
> thanks Simon for the info!
>
> There are two trac tickets related to this,
> - #2210: make checkve
Ok - got there in the end...
I did a fresh build (OS X 10.5.4 intel) with 3.1.1 sources.
Applied David's patches and fixed up the externs in cvxopt sources as
he indicated. All built just fine.
All test pass apart from trace - which is no doubt due to sage command
line not being able to load rea
On 11 sep, 16:36, Martin Albrecht <[EMAIL PROTECTED]>
wrote:
> On Thursday 11 September 2008, parisse wrote:
>
> > > Okay, found it:
>
> > That's the M benchmarks (the matrices are dense), could you try O1,
> > O2?
>
Oops, M are indeed sparse.
> It turns out, here Sage/Singular is doing worse
On 11 sep, 17:42, rjf <[EMAIL PROTECTED]> wrote:
> Unless there is something I'm missing here, it seems to me this is a
> classic problem that has been explored in the literature using several
> approaches.
Correct, but we never said it was new :-)
> Depending on the sparsity of the entries, (
19 matches
Mail list logo
