#17220: Matrix_complex_ball_dense: Level 1 implementation (using acb_mat from
Arb)
-------------------------------------+-------------------------------------
Reporter: cheuberg | Owner:
Type: enhancement | Status: needs_review
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: | c095ddd94dadc5523ebec3c0216dc0e2b25fd1f8
u/cheuberg/acb_mat | Stopgaps:
Dependencies: #18546, #19063, |
#19152 |
-------------------------------------+-------------------------------------
Changes (by cheuberg):
* status: needs_info => needs_review
Comment:
Replying to [comment:32 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 have a `acb_mat_t[10]`. In order to fill that array, I have to copy from
Sage objects.
>
> > 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).
The overhead is not problematic, it is only at initialization.
> Also, a 4th option would simply be to move this piece of code to #17222
and decide there.
sounds reasonable. Code is removed here.
> > > - 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.
fixed. Do you want to open a ticket for integer matrices?
> 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.
I do not know how to implement `copy=False`. I do not think that it can be
done as in `matrix_generic_dense` because we have a somewhat specialized
data structure here. Thus I still ignore `copy`, but tried to rewrite the
documentation.
--
Ticket URL: <http://trac.sagemath.org/ticket/17220#comment:34>
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.
