Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@double/adjoint: Add new function. #1192

Merged
merged 1 commit into from
Jul 17, 2022
Merged

Conversation

alexvong243f
Copy link
Collaborator

Fixes #1049.

  • inst/@double/adjoint.m: New file.
  • INDEX: Adjust accordingly.
  • NEWS: Adjust accordingly.



function A = adjoint (M)
A = double (adjoint (vpa (M)));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If user sets digits(3) then this code will respect that and (I guess?) give a poor result even though they would not expect a double function to care...

Similarly, if user sets digits(1000) this will take a lot longer before truncating to double precision.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! It's probably better to call pycall_sympy__ directly instead of relying on vpa. Let's use vpa (M, 16) instead.

%! M = randn (2);
%! A = [M(2,2) -M(1,2); -M(2,1) M(1,1)];
%! assert (isequal (adjoint (M), A));
%! assert (isequal (adjoint (adjoint (M)), M));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these look like floating point equality tests. Is it reasonable to expect a double-precision function to satisfy this test?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, should I do abs (x - y) < 1e-15 instead?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose so, in a relative sense would be better. Maybe some of the other @double/<fcn> have some clues.

I worry a bit about the numerical stability of this sort of implementation (SymPy is not well-known for stability of its implementations when sympy.Float is involved: basically unless it calls mpmath I don't really trust it).

The short-term fix is that I think a random test is ill-advised unless you know the algorithm used is numerically stable. I'd suggest a couple hardcoded cases.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about a nearly singular one? [0 1; 0.0001 1]. Does that still give 1e-15?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It works for this particular case in sympy 1.10.1 with the default method of computing determinant. But let's keep it simple and use a fixed constant to avoid any future issues...

Fixes gnu-octave#1049.

* inst/@double/adjoint.m: New file.
* INDEX: Adjust accordingly.
* NEWS: Adjust accordingly.
@cbm755 cbm755 merged commit 0b66050 into gnu-octave:main Jul 17, 2022
@alexvong243f alexvong243f deleted the fixes-1049 branch July 18, 2022 10:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

adjoint function for numerical input
2 participants