#17220: Matrix_complex_ball_dense: Level 1 implementation (using acb_mat from
Arb)
-------------------------------------+-------------------------------------
Reporter: cheuberg | Owner:
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.10
Component: numerical | Resolution:
Keywords: arb, acb_mat, | Merged in:
complex balls, matrix | Reviewers: Marc Mezzarobba
Authors: Clemens Heuberger | Work issues:
Report Upstream: N/A | Commit:
Branch: | 0e3c4cec8d6a42ec0f84f9b6c14637c19c155bd4
u/cheuberg/acb_mat | Stopgaps:
Dependencies: #18546, #19063, |
#19152 |
-------------------------------------+-------------------------------------
Changes (by cheuberg):
* commit: 41263f09f24efbb2178bba50e35c8f17b959c11c =>
0e3c4cec8d6a42ec0f84f9b6c14637c19c155bd4
Comment:
Hello,
Replying to [comment:28 mmezzarobba]:
> So I had a look and added a few reviewer patches with minor changes.
Thank you. I added one more minor commit on top of it (changing the title
in the documentation for consistency with `real_arb` and `complex_arb`.
> Two questions:
> - are the functions `matrix_to_acb_mat` & co really useful?
I use them in #17222: there, the time critical part does not use the full
coercion model, but just a C array of `acb_mat_t`. Thus it is convenient
there to be able to convert a matrix of `CIF`s to an `acb_mat_t` directly
instead of having it converted by a call to `matrix(CBF, ...)` and then
copying the resulting `acb_mat_t`. The same in the converse direction.
I see three options:
- keeping it the way it is now
- removing these functions here and doing (minimal) overhead in #17222
when initializing the computations there by calling `matrix(CBF, ...)`
- rewriting #17222 to use complex balls instead of complex intervals
throughout (that was not an option in October 2014 when I wrote that code,
because complex balls were not yet really implemented).
> - your `__init__` deviates a little bit from the logic in
`Matrix_generic_dense.__init__`, so that for example the following no
longer works, is that intentional?
> {{{
> sage: Pol.<x> = QQ[]
> sage: pol = 1 + x + x^2
> sage: Mat = MatrixSpace(CBF, 3, 1)
> sage: Mat(pol)
> [1.000000000000000]
> [1.000000000000000]
> [1.000000000000000]
> }}}
This is a consequence of following advice on
[https://groups.google.com/d/msg/sage-devel/kZX_Rh_V5vE/uSH6-sTpP0wJ sage-
devel]. Indeed,
{{{
sage: Pol.<x> = ZZ[]
sage: pol = 1 + x + x^2
sage: Mat = MatrixSpace(ZZ, 3, 1)
sage: Mat(pol)
[1.000000000000000]
[1.000000000000000]
[1.000000000000000]
}}}
does not work, either. BTW, most but not all of the cython oddities you
fixed in your commits here have been fixed in the integer matrices in the
meantime, however, the `for i from 0 <= i < self._nrows` are still there.
----
New commits:
||[http://git.sagemath.org/sage.git/commit/?id=0e3c4cec8d6a42ec0f84f9b6c14637c19c155bd4
0e3c4ce]||{{{Trac #17220: Change title for documentation}}}||
--
Ticket URL: <http://trac.sagemath.org/ticket/17220#comment:31>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
