Thu 10 Apr 2014 01:19:57 AM UTC, comment #11:
Ok, so we are talking about Matlab's default output formatting being misleading here. Gladly closing as invalid.
For completeness, I had someone send me the following from Matlab (gratuitous blank lines removed):
These look identical to what I've seen in Octave.
|
Wed 09 Apr 2014 07:32:18 PM UTC, comment #10:
Did some rechecking and I mistyped (and
misinterpreted matlab result) so I came
to a wrong conclusion. The HEX is the same
and, with appropriate settings of format
or use of sprintf on Matlab I now get
expected and matching results.
The default Matlab output format for
results like exp(i200pi) is, I think,
not helpful. Trying to implement
it with --tranditional would not be
useful.
The sign difference was what originally
had me quite worried, but that was a mistyping
on my part.
So, sorry for the long digression.
Happy to have this closed.
|
Wed 09 Apr 2014 01:53:19 PM UTC, comment #9:
Agreed with jwe on comment #8, there's no way I would want to see less precision by default. If there is a desire by someone to add this mis-feature to --traditional, patches welcome? It could use the existing fixed_point_format setting that is set when using --traditional. This setting does what Matlab does for matrices, but apparently not for complex values currently.
|
Wed 09 Apr 2014 01:45:24 PM UTC, comment #8:
That Matlab displays the result below, even for format long, without automatically switching to E format seems like an undesirable feature that we should not copy by default.
|
Wed 09 Apr 2014 01:36:44 PM UTC, comment #7:
Based on your attachment, this example shows no numerical differences in format hex:
Do you have any examples that do show an actual numerical difference or a sign difference as you said before? You said you had actual differences in the results using format hex.
I think another decent way to compare Octave and Matlab for this case is to use "format long e" which is supported by both and should give comparable formatting. Here's a run in Octave dev on current Debian 64-bit:
I get identical results on a current Debian 32-bit. What does Matlab produce?
And here is the same set in Octave 3.8.1 on an ancient RHEL 5 32-bit (which is where I said I saw numerical errors in comment #3). I think we can chalk these differences up to improvements in the compiler and/or system libraries:
|
Wed 09 Apr 2014 08:37:26 AM UTC, comment #6:
As usual in these matters, best to start at the beginning.
The short answer is simple:
octave:3> i20pi
ans = 0000000000000000 404f6a7a2955385ei
octave:4> format long
octave:5> ans
ans = 0.000000000000000 + 62.831853071795862i
octave:6> exp(i20pi)
ans = 1.00000000000000e+00 - 2.44929359829471e-15i
octave:7>
MATLAB Version 7.9.0.529 (R2009b)
>> i20pi
ans =
0000000000000000 404f6a7a2955385ei
>> format long
>> ans
ans =
0 +62.831853071795862i
>> exp(i20pi)
ans =
1.000000000000000 - 0.000000000000002i
>>
So, it is time to fix the format conversion for
type complex. Any volunteers?
A longer version of the above is attached. No really
important information, just some history.
And, this report should be relabelled as
format conversion of imaginary part of type complex.
Michael
(file #31143)
|
Tue 08 Apr 2014 08:26:27 PM UTC, comment #5:
John,
I agree that if this reveals problems in the math
library, including complex cases, it should be fixed
at the source.
However, it would also be useful if it could be
discovered why Matlab is more correct. Is it known
whether they use the math library? I thought that they
did, but this is quite old information.
It would be very helpful if someone who is currently
working on numerical accuracy of the elementary
functions (or at least has recently taken Kahan's
or Muller's course)
could be convinced to work on this.
Finally, I very much doubt if the math library directly
produces non-monotonic convergence. This problem has
been known and solved many many years ago. Although,
if I recall correctly, the early solutions did not include
the complex case. Kahan dealt with that.
I could study this a bit more, but it would only be
luck if I got far enough to achieve a complete solution
even just for exp().
For instance, I have not even checked that Matlab is
monotonic even just for exp() with complex arg.
|
Tue 08 Apr 2014 08:01:50 PM UTC, comment #4:
If there are bugs in the system math library or C++ complex class, then I suppose we could try to work around them. But I think that's probably something that should go in gnulib, not Octave itself. And if the bugs are in the GNU C library or the GNU libstdc++ complex class, then those are things we should try to fix upstream so that everyone benefits from the fixes instead of just Octave.
|
Tue 08 Apr 2014 07:28:41 PM UTC, comment #3:
Ok, your original report showed the Matlab value as zero so I wasn't sure at what level of accuracy you were looking at. You didn't provide any clear examples from Matlab with output showing the order of error that you are talking about.
I agree that the results are different from Matlab on the order of 10^-21 for exp(complex(0,pi)) and agree that the error looks like it accumulates somewhat linearly with the argument to exp.
Can you provide an example that shows the wrong sign in Octave?
Please do continue to investigate. It might also help to note whether tests in each are done on x86 or x86_64, in case results are cpu-dependent.
|
Tue 08 Apr 2014 06:13:56 PM UTC, comment #2:
I think that you are missing something:
Actually, I used format hex to look at the actual
data. The results are not "the same." This includes
sign differences (Octave having the wrong
sign) which for algorithms which assume
the correct sign can lead to such things as
infinite loops in code that would, with correct values,
converge.
I doubt if this is as simple as "just using the underlying
C math," It is a bit suspicious that it appears to be
the case that only complex arguments are badly wrong.
So, if you do not think this matters to you, OK.
I will have to make a lot of changes to code to work
around these errors.
And, of course, these differences will need to be documented
in the Manual under Matlab incompatibilities.
Again, I would rather that some serious study go into this.
|
Tue 08 Apr 2014 05:38:51 PM UTC, comment #1:
Actually, I had someone check this in Matlab, and it looks to me like this is just Matlab's default output formatting making you see something that's not there :)
In Matlab:
These look the same as Octave to me, so I'm not sure there's a bug here. The answers are what the underlying C math library calls return. Or am I missing something?
|
Tue 08 Apr 2014 11:05:55 AM UTC, original submission:
I noticed the following:
exp(inpi)
produces results which are significantly
different from and less accurate than Matlab.
For example:
function Octave Matlab
exp(i*pi) -1.0000e+00 + 1.2246e-16i -1.0000 + 0.0000i
Using format hex shows the differences more clearly
And, the relative error increases for increasing n
in exp(inpi)
The problem also shows up for sin(inpi), but the
error is much less.
While I am reporting this as a bug, the issue deserves
systematic and careful study. I do not know what math library
Matlab uses, but I would have expected the results between
Octave and Matlab to be quite close.
Note that in a number of cases, the signs of the results
differ between Octave and Matlab. This will, for
instance, affect iterative improvement type code at
values approaching multiples of i*pi.
So far I have only tried experiments with sin and exp.
And, for real arguments the results are much closer.
|