#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 |
-------------------------------------+-------------------------------------
Comment (by mmezzarobba):
Replying to [comment:31 cheuberg]:
> Thus it is convenient there to be able to convert a matrix of CIFs 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.
(It doesn't really matter, but I'm not sure I understand what you are
saying: why do you need to copy the `acb_mat_t`?)
> 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).
How problematic is the overhead? Anyway, all three options sound
reasonable to me. I guess using complex balls everywhere would be best,
but it all depends how much work you are willing to invest in #17222. If
speed is critical, though, you may want to avoid going through a list
representation in `acb_mat_to_matrix` (and create a new matrix over `CIF`
to write into using `_set_unsafe` instead).
Also, a 4th option would simply be to move this piece of code to #17222
and decide there.
> > - 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.
I'd say this is a weakness of the implementation over the integers, and it
would be better to be compatible with the generic case. What do you think?
BTW, changing it also would make it possible to call
`Matrix_complex_ball_dense` directly to convert a matrix over `CIF` to one
over `CBF`, reducing the overhead you were worrying about a little.
And one more thing I missed on first reading: I don't understand the part
that says “`copy` - ignored (since complex balls are immutable)” in the
docstring of `__init__`. Based on the code and documentation of
`MatrixSpace.matrix()`, it seems to me that this parameter is supposed to
control whether the matrix itself—not its entries—is copied.
--
Ticket URL: <http://trac.sagemath.org/ticket/17220#comment:32>
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.
