Edit (15 Dec '16): bug noticed in v11.0 and reported as CASE:3796403.
Edit (03 May '17): bug fixed in v11.1 (verified in v11.1.1).
I stumbled upon the following strange behaviour. Disclaimer: I present the simplest instance that I could find in which some behaviour occurs that I first noticed in a different, more complicated setting. In particular I understand that there's no reason to work with $1\times1$ sparse arrays with a nonzero entry in general; I am just trying to give a minimal example.
Let's take an algebraic identity that Mathematica doesn't immediately recognize, yet does upon using FullSimplify
:
Csc[Pi/7]^2 + Sec[Pi/14]^2 + Sec[3 Pi/14]^2 == 8
FullSimplify @ %
(* Out: *)
Csc[Pi/7]^2 + Sec[Pi/14]^2 + Sec[3 Pi/14]^2 == 8
True
Now consider a "sparse-arrayed version" of the same equation:
SparseArray[{1} -> Csc[Pi/7]^2 + Sec[Pi/14]^2 + Sec[3 Pi/14]^2] == SparseArray[{1} -> 8]
(* Out is of the form *)
SparseArray[< 1 >, {1}] == SparseArray[< 1 >, {1}]
The output is as expected.
However, again applying FullSimplify
this time returns
SparseArray[{1} -> Csc[Pi/7]^2 + Sec[Pi/14]^2 + Sec[3 Pi/14]^2] == SparseArray[{1} -> 8] ;
FullSimplify @ %
(* Out is of the form *)
SparseArray[< 1 >, {1}] == 0
That seems strange: FullSimplify
ing an equality of sparse arrays apparently may yield an equality between a SparseArray
and a number!
My question is: is this a bug, or can we somehow understand it?
Here are some things that I am not asking. Firstly, the single specified entry of the sparse array is {1}->0
: there is no 'mathematical' inconsistency. Secondly, the strange behaviour may be easily avoided: for example, Mathematica does return True
when applying FullSimplify
to both sides of the equality separately (FullSimplify /@ %
) or by first going back to lists (FullSimplify @ Normal @ %
).
NB. I'm not sure if it's relevant that Simplify
does not yield True
for the identity that we started with. For example, the equality a Csc[Pi/5]^2 + a Csc[2 Pi/5]^2 == 4 a
(with the a
) is not automatically recognized to hold true, but here it suffices to use Simplify
; this time applying Simplify
to the 'sparse-arrayed version' of that identity just returns True
.
Edit (1 dec '16). Above I suggested two workarounds. In general I'd expect the second one (simplifying both sides of the equation separately: FullSimplify /@ %
) to be faster but less powerful than the former (first going to normal form: FullSimplify @ Normal @ %
). Indeed, on the one hand not going to normal form should save time (especially for large arrays that are fairly sparse). On the other hand, however, the separate simplifications of the two sides of the equation need not yield results written in identical ways, while the simplification of something that actually vanishes should be more likely to yield identically zero.
My additional question is: what would be the fastest way to check the equality given this apparent bug? (I am assuming that we're in a case where FullSimplify
can actually recognize the equality between the two sparse arrays as being true.)