5
$\begingroup$

I am trying to put in row reduced echelon form the following matrix $$ \left( \begin{array}{ccc} -0.1 & 0.1 & 2 \\ 0.3 & 0.2 & 0.7 \\ 0 & 0.5 & 6.7 \\ \end{array} \right) $$ I did the calculations by hand, and being a fairly simple matrix to reduce, I wanted to test it out in Mathematica, using

RowReduce[{{-0.1, 0.1, 2}, {0.3, 0.2, 0.7}, {0, 0.5, 6.7}}]

which agrees with my result. I also tried in WolframAlpha, keeping the same input, however, I get an "incorrect result", which is $$ \left( \begin{array}{ccc} 1 & 0. & 0. \\ 0 & 1 & 0. \\ 0 & 0 & 1 \\ \end{array} \right) $$ I noticed that there is a dot next to some of the $0$s, so I am assuming there are some rounding errors being made. So I tried this and it worked.

My question is, why is mathematica able to work with greater precision than Wolfram Alpha, even though the function being called is the same?


I am aware that this question does not involve solely Mathematica, however since the function is the same for both I wanted to understand the how each handled this.

$\endgroup$
  • 4
    $\begingroup$ I work on alpha, just reported this as a bug. $\endgroup$ – Jason B. Feb 13 '18 at 20:16
  • $\begingroup$ The (2,3) element of the original input matrix is 0; however, where you say "So I tried this" the (2,3) element of the given matrix is equal to 7/10 - not 0. So one shouldn't expect the same answer upon row reduction. $\endgroup$ – user15994 Feb 13 '18 at 20:54
  • $\begingroup$ I typed the original matrix wrong. I missed that. Thank you for pointing it out. I’ll edit $\endgroup$ – user372003 Feb 13 '18 at 21:06
  • $\begingroup$ @JasonB. I'm not convinced it's a bug. Please see my answer. Thx. $\endgroup$ – Michael E2 Feb 14 '18 at 4:22
3
$\begingroup$

As @ilian points out, this is caused by the underlying Mathematica version (along with the OS?):

$Version
"11.1.1 for Linux x86 (64-bit) (June 2, 2017)"
RowReduce[{{-0.1, 0.1, 2}, {0.3, 0.2, 0.7}, {0, 0.5, 6.7}}]]
{{1, 0., 0.}, {0, 1, 0.}, {0, 0, 1}}

@MichaelE2 argues that this is not a bug. While I agree this is not a Mathematica bug, I do consider it a Wolfram|Alpha bug. W|A should be treating 6.7 as 67/10 in this input, while Mathematica should not.

I suppose the logic is that the average W|A user shouldn't need to understand the nuances of machine precision, or what machine precision is for that matter. Mathematically 6.7 is 67/10, and W|A should understand this here.

$\endgroup$
  • $\begingroup$ I agree with you $\endgroup$ – user372003 Feb 14 '18 at 21:51
4
$\begingroup$

I think the reason is the underlying version of Mathematica (the result may also depend on the platform to some extent).

Using 64-bit Linux for example (since that's what Alpha servers run), this example works better in version 10 and later:

$Version                                                                            

(* 11.2.0 for Linux x86 (64-bit) (September 11, 2017) *)

RowReduce[{{-0.1, 0.1, 2}, {0.3, 0.2, 0.7}, {0, 0.5, 6.7}}]                         

(* {{1, 0., -6.6}, {0, 1, 13.4}, {0, 0, 0}} *)

while version 9 produces the suboptimal result

$Version                                                                            

(* 9.0 for Linux x86 (64-bit) (February 7, 2013) *)

RowReduce[{{-0.1, 0.1, 2}, {0.3, 0.2, 0.7}, {0, 0.5, 6.7}}]                         

RowReduce::luc: Result for RowReduce of badly conditioned matrix {{-0.1, 0.1, 2.}, {0.3, 0.2, 0.7}, {0., 0.5, 6.7}} may contain significant numerical errors.

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

Note also the appropriate warning message, although it is not visible when using Wolfram|Alpha.

$\endgroup$
  • $\begingroup$ Yes, you are right, it depends also on the platform $\endgroup$ – user372003 Feb 14 '18 at 21:51
3
$\begingroup$

I don't think this is a bug. First, keep in mind that the floating-point number 0.1 is not the same as 1/10:

SetPrecision[0.1, Infinity]
% - 1/10
(*
  3602879701896397/36028797018963968
  1/180143985094819840
*)

The "fairly simple" row reduction referred to in the OP is, I suppose, achieved by treating the decimals as exact numbers. But that is not what one gets by treating them as 64-bit binary floating-point numbers subject to rounding errors. They are treated an inexact floating-point numbers if the matrix is entered with entries like 0.1 instead of 1/10.

To get an result equivalent to the "human interpretation" of the problem, one can try the option Tolerance with RowReduce (q.v.).

mat = {{-0.1, 0.1, 2}, {0.3, 0.2, 0.7}, {0, 0.5, 6.7}};
RowReduce[mat, Tolerance -> 10^-15]
(*
  {{1,   0., -6.6},
   {0,   1,  13.4},
   {0,   0,   0}}
*)

Without tolerance (V11.2 MacOS):

RowReduce[mat]

RowReduce::luc: Result for RowReduce of badly conditioned matrix {{-0.1,0.1,2.},{0.3,0.2,0.7},{0.,0.5,6.7}} may contain significant numerical errors.

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

This is different from what @ilian reports for Linux.
The docs say that the setting for Tolerance in RowReduce is Automatic. Perhaps the default tolerance has changed from version to version.

$\endgroup$
  • 1
    $\begingroup$ I am using Version 11.2 Windows x64 and I do not need to specify tolerance. I get the correct answer by just using RowReduce[mat]. I understand what you are saying though. However, as Chip states, I think this is a W|A bug. $\endgroup$ – user372003 Feb 14 '18 at 21:50
  • $\begingroup$ @user372003 Yes, W|A has a different audience in mind than Mathematica. But this site is a site about Mathematica, not W|A. -- I think it's odd, though, that we're getting different results on Macs than on Windows/Linux. $\endgroup$ – Michael E2 Feb 15 '18 at 1:30

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.