#13140: OS X Lion doctest failures for double dense QR decomposition
----------------------------------+-----------------------------------------
Reporter: jdemeyer | Owner: jason, was
Type: defect | Status: needs_review
Priority: major | Milestone: sage-5.2
Component: linear algebra | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: John Palmieri | Merged in:
Dependencies: | Stopgaps:
----------------------------------+-----------------------------------------
Comment (by jhpalmieri):
Hi Rob,
Here's another attempt.
Replying to [comment:4 rbeezer]:
> Some comments. I get 7 doctest failures. This is on 5.1.beta3, but the
offending #10795 applied cleanly, along with your #13140.
When applied to 5.1.beta6, the new patch passes tests for me on OS X Lion,
sage.math, and hawk (!OpenSolaris).
> It looks to me like the following stanza in `_normalize_columns()` finds
the first negative entry of the column, and adjusts that. Which would not
be the leading (non-zero) entry.
> {{{
> #!python
> for j from 0 <= j < M.ncols():
> for i from 0 <= i < M.column(j).degree():
> if M.column(j)[i] < 0:
> M = M.with_rescaled_col(j, -1)
> break
> }}}
You're right, thanks, I've fixed it.
> then the number of failures goes down to 4. Notice this does not
carefully consider the possibility of `-0.0` before the desired leading
entry (can we just test on that literal?).
Within Sage, `RDF(-0.0)` prints as "-0.0", so I think it's the right thing
to look at. `RDF(-0.0) == 0` returns True while `RDF(-0.0) < 0` returns
False, which suggests that we're okay, but I'm not absolutely sure.
> Line 2517 (new line number according to patch) has a
`.normalize_columns()` without an underscore.
Fixed.
> With my change above I think any remaining problems (barring one) are
just +/- 0 mixups. It might make sense to normalize first, then
round/clip to six places.
Right, good idea.
> Most critically - `Q*R` should be the original matrix. So if we adjust
a column of `Q`, then we need to adjust a '''row''' of `R` before testing
`Q*R == A`. We could test this property '''before''' normalizing. Then a
companion `_normalize_rows()` might be indicated before displaying `Q` and
`R`. But still, the rows of `R` to normalize may not be the same as the
columns of `Q` to normalize.
In the new patch, when printing Q or R for doctests, we normalize them.
When multiplying them, we don't normalize them. Then we don't have to
worry about compatibility of normalizations. I'm also now normalizing the
rows of R and the columns of Q, since those seem like the most natural
choices.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13140#comment:5>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
