On 10/26/2012 10:01 PM, Jason Grout wrote:
For most computations in Sage, using RR gives better results. The
problem is that no one has implemented numerically stable linear algebra
algorithms for RR/CC/RealField/ComplexField (well, I guess at one point
I had a numerically stable LU decomposition
On 10/26/12 3:43 PM, Florent Hivert wrote:
Aside William's caveat, I would add "don't mix fork
and threads". A more or less accurate description of what could happen is that
forking is somehow not atomic so that you may end up forking also threads you
don't want to. Before being aware of that I
Hi There,
> > I have a Sage package/module that does parallelism by forking and
> > communicating over pipes. This of course forks the whole Sage executable.
> >
> > This seems to sometimes (but rarely) result in any of a large number of
> > problems: double-frees, corrupted internal glibc
On 10/26/12 12:26 PM, Volker Braun wrote:
It seems like the newest version doesn't support mpfr currently:
http://www.alglib.net/download.php
alglib-3.6.0.cpp
alglib-2.6.0.mpfr.zip
Huh; that is really interesting. The announcement "01.09.2010 New
release - ALGLIB 3.rc1 for C++" on http://w
The forked process is pretty much independent. In fact, this is probably
the main drawback of the fork() multiprocessing model: Its impossible for
processes to influence each other's address space after the fork() has
happened even if you want to pass data around.
Things to look out for:
* b
On Fri, Oct 26, 2012 at 12:33 PM, Pavel Panchekha wrote:
> I have a Sage package/module that does parallelism by forking and
> communicating over pipes. This of course forks the whole Sage executable.
>
> This seems to sometimes (but rarely) result in any of a large number of
> problems: double-f
I have a Sage package/module that does parallelism by forking and
communicating over pipes. This of course forks the whole Sage executable.
This seems to sometimes (but rarely) result in any of a large number of
problems: double-frees, corrupted internal glibc structures, hangs, null
pointers
It seems like the newest version doesn't support mpfr currently:
http://www.alglib.net/download.php
alglib-3.6.0.cpp
alglib-2.6.0.mpfr.zip
On Friday, October 26, 2012 4:01:01 PM UTC+1, jason wrote:
>
> On 10/26/12 9:50 AM, Volker Braun wrote:
> > Does alglib do linear algebra with MPFR? From a
On 10/26/12 10:00 AM, Jason Grout wrote:
Here's another message where we specifically talk abut multiprecision
linear algebra in Sage:
https://groups.google.com/forum/?fromgroups=#!topic/sage-devel/-X23TJvE8-A
It should be noted that MPACK [1] is now BSD licensed, and also has an
active devel
On 10/26/12 9:50 AM, Volker Braun wrote:
Does alglib do linear algebra with MPFR? From a cursory look I can only
find double std::complex versions.
Yes, that's my understanding. You can see the backends here:
http://www.alglib.net/translator/man/
as well as here:
http://www.alglib.net/abou
Does alglib do linear algebra with MPFR? From a cursory look I can only
find double std::complex versions.
On Friday, October 26, 2012 3:02:10 PM UTC+1, jason wrote:
>
> On 10/26/12 8:47 AM, P Purkayastha wrote:
>
> >
> > That raises a problem that I see with the current use of RR. What is th
On 10/26/12 8:47 AM, P Purkayastha wrote:
That raises a problem that I see with the current use of RR. What is the
reason behind using RR instead of RDF/CDF by default? I have been going
through the various methods available when doing M.. A lot more
methods have been implemented for RDF compar
On 10/26/2012 09:17 PM, Jason Grout wrote:
On 10/26/12 6:25 AM, Volker Braun wrote:
The matrix is over RR (MPFR software floats). M.change_ring(RDF).det()
gives the right answer.
There is no special det() implementation for RR, we compute the
Hessenberg form and from that characteristic polynom
On 10/26/12 8:25 AM, Harald Schilly wrote:
On Friday, October 26, 2012 1:25:51 PM UTC+2, Volker Braun wrote:
there is no overflow, its a numerical instability.
the condition number is quite high I would say:
sage: M = load("M.sobj")
sage: from numpy import linalg
sage: linalg.cond(M)
On Friday, October 26, 2012 1:25:51 PM UTC+2, Volker Braun wrote:
>
> there is no overflow, its a numerical instability.
>
>>
the condition number is quite high I would say:
sage: M = load("M.sobj")
sage: from numpy import linalg
sage: linalg.cond(M)
4.4178252500667382e+1
Agreed, unless you need extended precision for some reason. Using Gauss
elimination with MPFR-matrices is still a bug.
On Friday, October 26, 2012 2:17:43 PM UTC+1, jason wrote:
>
> On 10/26/12 6:25 AM, Volker Braun wrote:
> > The matrix is over RR (MPFR software floats). M.change_ring(RDF).de
On 10/26/12 6:25 AM, Volker Braun wrote:
The matrix is over RR (MPFR software floats). M.change_ring(RDF).det()
gives the right answer.
There is no special det() implementation for RR, we compute the
Hessenberg form and from that characteristic polynomial. Sage uses
Gaussian elimination to compu
On 10/26/2012 06:35 PM, LUIS BERLIOZ wrote:
det FUNCTION IS HAVING A VERY ANNOYING BEHAVIOR,GIVEN THE ATTACHED MATRIX FOR
EXAMPLE
IF I TRY TO GET THE DETERMINANTS WITH TWO DIFFERENT METHODS:
sage: M=load(PATHTOFILE +'/M.sobj')
sage: M.det()
6.49037107316853e32
sage: from numpy import linalg
sag
The matrix is over RR (MPFR software floats). M.change_ring(RDF).det()
gives the right answer.
There is no special det() implementation for RR, we compute the Hessenberg
form and from that characteristic polynomial. Sage uses Gaussian
elimination to compute the Hessenberg form, and this is know
det FUNCTION IS HAVING A VERY ANNOYING BEHAVIOR,GIVEN THE ATTACHED
MATRIX FOR EXAMPLE
IF I TRY TO GET THE DETERMINANTS WITH TWO DIFFERENT METHODS:
sage: M=load(PATHTOFILE + '/M.sobj')
sage: M.det()
6.49037107316853e32
sage: from numpy import linalg
sage: linalg.det(M)
-1.5055380070396349e-05
THE
20 matches
Mail list logo
