# Revision history [back]

Looking in src/sage/interfaces/singular.py as suggested by @tmonteil, I noticed in some of the docstrings that the way to get at a Singular object is singular('obj_name'). Continuing the first example from the question, rlist can be accessed with singular('rlist'). Although it is still a Singular list, it can be iterated over, so something like the following will work:

sage: [[coord for coord in sol] for sol in singular('rlist')]


Again, the elements are still Singular objects, but one (perhaps rudimentary) way to convert them is

sage: [[sage_eval(coord._sage_repr()) for coord in sol] for sol in singular('rlist')]


Looking in src/sage/interfaces/singular.py as suggested by @tmonteil, I noticed in some of the docstrings that the way to get at a Singular object is singular('obj_name'). Continuing the first example from the question, rlist can be accessed with singular('rlist'). Although it is still a Singular list, it can be indexed into, iterated over, so etc. So something like the following will work:

sage: [[coord for coord in sol] for sol in singular('rlist')]


Again, the elements are still Singular objects, but one (perhaps rudimentary) way to convert them is

sage: [[sage_eval(coord._sage_repr()) for coord in sol] for sol in singular('rlist')]


Perhaps more robust than sage_eval and ._sage_repr() would be using .repart() and .impart() (which are the Singular functions for real and imaginary part):

sage: [[ComplexNumber(coord.repart(), coord.impart()) for coord in sol] for sol in singular('rlist')]


Note that ComplexNumber has an optional min_prec argument to control the precision of the ComplexField used to create the number, so that if the computations are performed at a high precision in Singular, the same precision can be ensured in Sage.