5
$\begingroup$

I expected both results to be $0_3$:

P = RandomReal[1, {3, 3}];
A = MatrixFunction[Sin, t*P] /. t -> 0
B = With[{t = 0}, MatrixFunction[Sin, t*P]]

(* {{-0.362821 - 1.25562 I, 0.288053 + 1.1563 I, 0.107869 + 0.0658492 I}, 
   {0.133223 - 1.20752 I, -0.220254 +  1.22158 I, 0.181178 - 0.148004 I}, 
   {-0.0991967 + 0.526917 I, -0.208297 - 0.517217 I, 0.583075 + 0.0340421 }} *)

(* {{0., 0., 0.}, {0., 0., 0.}, {0., 0., 0.}} *)

Following J.M. comments:

P = RandomReal[1, {3, 3}, MachinePrecision -> 20] (* => A == B *)
P = RandomReal[1, {3, 3}, MachinePrecision -> 10] (* => A == B *)
P = RandomReal[1, {3, 3}, MachinePrecision -> $MachinePrecision] (* => A != B *)
a = $WorkingPrecision; P = RandomReal[1, {3, 3}, MachinePrecision -> a] (* => A == B *)

Also, using SetPrecision A is zero:

P = RandomReal[1, {3, 3}]
A = MatrixFunction[Sin, t*SetPrecision[P, $MachinePrecision]] /. t -> 0

So it's not a misunderstanding of mine, but a peculiar behaviour of MMA.

$\endgroup$
  • $\begingroup$ Check this: MatrixFunction[Sin, t*P][[1, 1]] // Expand and try to figure out what happens in the other case. $\endgroup$ – corey979 Oct 2 '16 at 15:38
  • $\begingroup$ It seems that I'm making a mistake of the kind "$(t\mapsto f(0))'$ instead of $f'(0)$" but I can't figure out where. Why isn't MatrixFunction[Sin, t*P] a function of $t$, and $B$ it's value in $0$? $\endgroup$ – anderstood Oct 2 '16 at 15:44
  • 1
    $\begingroup$ What happens if you use a matrix that is not machine precision; e.g. P = RandomReal[1, {3, 3}, WorkingPrecision -> 20];? $\endgroup$ – J. M. will be back soon Oct 2 '16 at 15:46
  • 1
    $\begingroup$ Likely, something peculiar is happening in the machine-precision evaluation, if so. Another confirmatory test: generate the random matrix again, but without the WorkingPrecision setting, and compare what happens when you feed it the usual machine precision matrix and the result of SetPrecision[P, 20]. $\endgroup$ – J. M. will be back soon Oct 2 '16 at 15:51
  • 2
    $\begingroup$ It is a bug that has been fixed in the development version. $\endgroup$ – ilian Oct 16 '16 at 14:01
3
$\begingroup$

BUG FIXED IN V11.1.0, CONFIRMED IN EARLIER VERSIONS

This is really nothing to do with With and ReplaceAll. (In the case of With the substitution t=0 happens first, so the apparent bug is not triggered).

It looks as if Mathematica gives incorrect answers for

MatrixFunction[Sin, t * P]

in almost all cases where P is a machine precision square matrix of size 2 or larger, and t is unassigned. This does not appear to be a precision issue.

For example, define notionally equivalent matrices

P = {{1, 2}, {4, 3}}/4;

Aa = MatrixFunction[Sin, t P];
An = MatrixFunction[Sin, t N[P]];

Compare

Aa /. t -> 0
An /. t -> 0
(* {{0, 0}, {0, 0}} *)
(* {{0.421637, -0.210819}, {0.843274, -0.421637}} *)

Further, compare the notionally equivalent

MatrixFunction[Sin, N[P]]
Aa /. t -> 1.0
An /. t -> 1.0
(* {{0.151392, 0.398796}, {0.797592, 0.550188}} *)
(* {{0.151392, 0.398796}, {0.797592, 0.550188}} *)
(* {{1.08194, -0.0664758}, {0.265903, 0.816033 *)}}

This even occurs when P is real, symmetric, positive definite with integer coefficients.

UPDATED

This appears to be the result of Mathematica choosing an incorrect algorithm in the specific (and probably unusual) case where MatrixFunction is applied to the product of an unassigned variable and a machine precision matrix. The results given appear to be incorrect for all values t and occur in cases where the matrix is well behaved (the Schur and Jordan decompositions computed in machine precision agree closely with their exact values). Computing the results with any finite precision (not machine precision) does not suffer from this problem.

$\endgroup$
  • 1
    $\begingroup$ A possible workaround would have been to use SchurDecomposition[] first, apply MatrixFunction[] to the (quasi-)triangular factor, and apply the similarity transformation. Unfortunately, I've seen that MatrixFunction[] still screws up on the triangular factors if they are machine precision matrices. Looks like a bug. $\endgroup$ – J. M. will be back soon Oct 3 '16 at 18:50
  • $\begingroup$ Another workaround is to define functions: Aa[t_] := MatrixFunction[Sin, t P]; An[t_] := MatrixFunction[Sin, t N[P]]; do not seem to have the same problems as using the replacement. $\endgroup$ – bill s Oct 3 '16 at 18:56
  • $\begingroup$ (Sorry for my late answer) Why do you say it does not seem to be a precision issue? The fact that it works for exact matrices and fails for almost every inexact matrices would make me think the reverse. $\endgroup$ – anderstood Oct 15 '16 at 15:30
  • $\begingroup$ @J.M. Is it really a bug, or is it an ineluctable consequence of inexact calculation? $\endgroup$ – anderstood Oct 15 '16 at 15:35
  • $\begingroup$ @anderstood, can't tell, as I don't know the fine details of MatrixFunction[], except that I know it's using Schur-Parlett in the inexact case and Jordan in the symbolic/exact case. $\endgroup$ – J. M. will be back soon Oct 15 '16 at 15:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.