Second beta of ALGLIB.spkg is ready. It can be downloaded from
http://www.alglib.net/share/2010-07-26-alglib-for-sage/
Following issues were solved in this release:
* compilation on SPARC/Solaris
* missing support for SAGE64
* trashing of SAGE_LOCAL with additional dirs
Issues that were NOT solved in this release:
* OS X compilation (will be done in the next version)
What's new in this release:
* it was tested under SPARC/Solaris (and it works)
* it was tested with both 2.7 and 3.1 branches of Python
* Python-ALGLIB communication tests were added. They test ability to
pass data between computational core and Python environment. They can
also be used to generate doctests (will be implemented in one of the
next releases). Only two units are tested now: matdet and matinv (41
test in total), but one day we will see 100% coverage by communication
tests.
* ALGLIB interface gradually becomes more user-friendly (see below).
Plans for the future:
* OS X testing
* better integration with Sage (see below)
-- NEW 'FRIENDLY' INTERFACE --
Two units (matdet and matinv) now support two forms of calling their
functions: 'long' form, where matrix size and storage is explicitly
specified by function parameters, and 'friendly' form, where this
information is automatically determined from arguments.
EXAMPLE: you want calculate inverse of SPD matrix a=[[3,2],[2,3]].
In the 'long' mode it can be done by
$ matinv.spdmatrixinverse([[3,2],[2,3]],2,False)
call. Here second argument is matrix size, third argument is storare
format (False = only lower triangle of symmetric matrix is stored).
This is LAPACK style of calling linear algebra functions.
In the 'friendly' mode you can just call
$ matinv.spdmatrixinverse([[3,2],[2,3]])
Function will automatically determine matrix size and will check that
its argument is symmetric matrix given by both upper and lower
triangles. In case of non-symmetric argument an exception will be
generated. This mode is designed to be easy to use from interactive
Python (or Sage) prompt.
Currently only two units (determinants and inverses) support
'friendly' mode, but I want to make whole ALGLIB 'friendly' after
several months from now.
-- SAGE INTEGRATION --
Well, ALGLIB can be called from Python and Sage by now. But I think
that more can be done to integrate it with Sage. For example, we can't
write
sage: A = Matrix([[3,2],[2,3]])
sage: matdet.rmatrixdet(A)
because ALGLIB uses Python's list-of-lists to store matrices, and Sage
uses its own matrix class. But only several functions from _alglib.py
have to be fixed to work with Sage matrices/vectors:
* safe_len/safe_cols/safe_rows
* is_bool_vector/is_int_vector/is_real_vector/is_complex_vector
* is_bool_matrix/is_int_matrix/is_real_matrix/is_complex_matrix
* x_from_list/x_from_listlist
I think that it is very easy to do for someone familiar with Sage
internals. Anyone interested in helping me with this issue?
--
With best regards,
Sergey mailto:sergey.b...@alglib.net
Cool. Compiles for me, but I didn't try any tests.
> -- SAGE INTEGRATION --
>
> Well, ALGLIB can be called from Python and Sage by now. But I think
> that more can be done to integrate it with Sage. For example, we can't
> write
>
> sage: A = Matrix([[3,2],[2,3]])
> sage: matdet.rmatrixdet(A)
>
> because ALGLIB uses Python's list-of-lists to store matrices, and Sage
> uses its own matrix class. But only several functions from _alglib.py
> have to be fixed to work with Sage matrices/vectors:
> * safe_len/safe_cols/safe_rows
> * is_bool_vector/is_int_vector/is_real_vector/is_complex_vector
> * is_bool_matrix/is_int_matrix/is_real_matrix/is_complex_matrix
> * x_from_list/x_from_listlist
>
> I think that it is very easy to do for someone familiar with Sage
> internals. Anyone interested in helping me with this issue?
Sure, I can help. I have some API questions first.
What are the bool and int vectors and matrices used for? (Sage
doesn't really have vectors or matrices of booleans or of machine
ints. It has vectors and matrices over GF(2) (integers mod 2, so
1+1=0), which could be used as booleans. There are also numpy arrays
and matrices of these types.)
My suggestion would be to support Sage vectors and matrices over
GF(2), RDF, and CDF (machine floats and complex numbers), as well as
numpy arrays and matrices of appropriate types. If people think this
is the right choice, I can help write the code.
Carl
You wrote 29 июля 2010 г., 2:40:14:
> Sure, I can help. I have some API questions first.
Thanks a lot!
> What are the bool and int vectors and matrices used for? (Sage
> doesn't really have vectors or matrices of booleans or of machine
> ints. It has vectors and matrices over GF(2) (integers mod 2, so
> 1+1=0), which could be used as booleans. There are also numpy arrays
> and matrices of these types.)
I've made quick check and, to my surprise, there is no ALGLIB function
which is accessible from Sage and accepts/returns boolean vector or
matrix :) But I think that this feature should be supported in case
such function will appear in future.
Integer vectors are used to store permutation tables (LU decomposition
and related functions), by fitting functions (to specify derivative
information) and by several other functions. Integer matrices are not
used by functions accessible from Sage, but again I recommend to
support them.
> My suggestion would be to support Sage vectors and matrices over
> GF(2), RDF, and CDF (machine floats and complex numbers), as well as
> numpy arrays and matrices of appropriate types.
+1
My proposal is to make
* boolean vector/matrix = GF(2), RDF (non-zero = True)
* integer vector/matrix = RDF
* real = RDF
* complex = CDF
>> because ALGLIB uses Python's list-of-lists to store matrices, and Sage
>> uses its own matrix class. But only several functions from _alglib.py
>> have to be fixed to work with Sage matrices/vectors:
>> * safe_len/safe_cols/safe_rows
>> * is_bool_vector/is_int_vector/is_real_vector/is_complex_vector
>> * is_bool_matrix/is_int_matrix/is_real_matrix/is_complex_matrix
>> * x_from_list/x_from_listlist
Sorry, I've forgot to add several functions to this list:
* bool_vector_from_x/bool_matrix_from_x
* int_vector_from_x/int_matrix_from_x
* real_vector_from_x/real_matrix_from_x
* complex_vector_from_x/complex_matrix_from_x
x_from_list/x_from_listlist are used to convert from Python to ALGLIB,
and this functions are used to convert in backward direction.
Within 8 hours I'll write in more details about these functions.
Here is some documentation about Python-ALGLIB interface (called
X-interface in this document):
http://www.alglib.net/share/2010-07-26-alglib-for-sage/x-interface.pdf
It is very short, but should give a hint about meaning of all these
functions, expectations, functionality and etc. It describes functions
which are located in the _alglib.py unit.
I'll add more information and some case studies later, but I thin
kthat it is better to post early than to post later :)
Thanks.
> It is very short, but should give a hint about meaning of all these
> functions, expectations, functionality and etc. It describes functions
> which are located in the _alglib.py unit.
>
> I'll add more information and some case studies later, but I thin
> kthat it is better to post early than to post later :)
Sure; unfortunately, I probably won't be able to work on this until Monday.
Carl
But this raises another API question... should bool_matrix_from_x
return a matrix over GF(2) or over RDF?
(I'll start looking at the Sage -> ALGLIB direction for now.)
Carl
I've attached a patch to make alglib allow input in the following formats:
* boolean vector/matrix: GF(2), RDF, numpy.bool, numpy.float64
* integer vector/matrix: RDF, numpy.int32, numpy.float64
* real: RDF, numpy.float64
* complex: CDF, numpy.complex128
This is entirely untested, except that the following examples (adapted
from your "ALGLIB for Sage" page, and modified to use Sage or numpy
types) work:
sage: from alglib import conv
sage: conv.convr1d( # real convolution of signal and response
....: vector(RDF, [1, 0, 0, 0.1]), # signal
....: 4, # signal length
....: vector(RDF, [1, 0.1, 0.01]), # response
....: 3) # response length
[1.0, 0.10000000000000001, 0.01, 0.10000000000000001,
0.010000000000000002, 0.001]
sage: from alglib import conv
sage: conv.convr1d( # real convolution of signal and response
....: vector(RDF, [1, 0, 0, 0.1]).numpy(), # signal
....: 4, # signal length
....: vector(RDF, [1, 0.1, 0.01]).numpy(), # response
....: 3) # response length
[1.0, 0.10000000000000001, 0.01, 0.10000000000000001,
0.010000000000000002, 0.001]
sage: from alglib import rcond, densesolver
sage: a = matrix(RDF, [[ 1.0, 0.1],
....: [-0.1, 1.0]])
sage: b = vector(RDF, [ 1.1, 0.9])
sage: rcond.rmatrixrcond1( # condition number
....: a, # matrix
....: 2) # matrix size
0.83471074380165278
sage: info, rep, x = densesolver.rmatrixsolve(a, 2, b) # solve linear system
sage: x # solution
[1.0, 1.0]
sage: rep.r1 # condition number
0.83471074380165278
sage: from alglib import rcond, densesolver
sage: a = matrix(RDF, [[ 1.0, 0.1],
....: [-0.1, 1.0]]).numpy()
sage: b = vector(RDF, [ 1.1, 0.9]).numpy()
sage: rcond.rmatrixrcond1( # condition number
....: a, # matrix
....: 2) # matrix size
0.83471074380165278
sage: info, rep, x = densesolver.rmatrixsolve(a, 2, b) # solve linear system
sage: x # solution
[1.0, 1.0]
sage: rep.r1 # condition number
0.83471074380165278
(So I would not be at all surprised if there are bugs in my code.)
Note that I did not touch *_vector_from_x, *_matrix_from_x; so results
are still returned as lists. Also, I didn't worry about efficiency.
Carl
You wrote 3 августа 2010 г., 6:39:49:
> I've attached a patch to make alglib allow input in the following formats:
> * boolean vector/matrix: GF(2), RDF, numpy.bool, numpy.float64
> * integer vector/matrix: RDF, numpy.int32, numpy.float64
> * real: RDF, numpy.float64
> * complex: CDF, numpy.complex128
> This is entirely untested, except that the following examples (adapted
> from your "ALGLIB for Sage" page, and modified to use Sage or numpy
> types) work:
Thanks!
I am working on modification of check.py (Python-ALGLIB communication
tests). Currently it tries to pass Python lists between Python(Sage)
and ALGLIB. I want to make it use Python lists, numpy arrays, Sage
vectors/matrices (each function will be tested with all these types).
It should autodetect types of all variables, so you will be able to
rewrite *_vector_from_x/*_matrix_from_x one by one (rewrite
bool_vector_from_x, launch unit test, rewrite next function).
I'll release new test suite tomorrow.
> But this raises another API question... should bool_matrix_from_x
> return a matrix over GF(2) or over RDF?
Hmmm... I prefer GF(2), but I think that it in most part is just a
matter of taste :)
You wrote 3 августа 2010 г., 6:39:49:
> On Wed, Jul 28, 2010 at 11:38 PM, Sergey Bochkanov
> <sergey.b...@alglib.net> 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 that it is worth adding ZZ to all types of
vectors/matrices. Otherwise "matrix([[1,2],[2,3]])" will NOT be
identified as correct matrix (its base ring is Integer Ring).
BTW, I am still working on new test suite for Sage types. There are
some issues with doctest for numerical data which are briefly
mentioned by me in
http://groups.google.com/group/sage-devel/browse_thread/thread/c03ab63bec776b0
However, I think that I've found some good solution.
You wrote 3 августа 2010 г., 6:39:49:
> On Wed, Jul 28, 2010 at 11:38 PM, Sergey Bochkanov
> <sergey.b...@alglib.net> 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 that we should add RDF to complex
vectors/matrices too. Otherwise we won't be able to pass [[1,2],[3,4]]
as complex matrix.