(05-24-2017 06:42 PM)Guenter Schink Wrote:  I think the DM42 also uses this library, perhaps this explains something, I don't know what is correct.

(05-24-2017 06:48 PM)Ángel Martin Wrote:  

(05-24-2017 06:42 PM)Guenter Schink Wrote:  I think the DM42 also uses this library, perhaps this explains something, I don't know what is correct.

sorry to be blunt but this is math, and thus pretty rigid as to which one is the correct result.
You can check WolframAlpha if that adds more weight to the "credibility of options":

http://www.wolframalpha.com/input/?i=asin(acos(atan(tan(cos(sin(1%2B0i))))))

Logan is correct, the "glitch" occurs in the ATAN function.

(05-24-2017 08:25 PM)Hsilop Wrote:  Should we not be having this discussion about the DM42 over at their place, to give them as much value from the beta testing as possible?

(05-24-2017 08:25 PM)Hsilop Wrote:  As mentioned by Thomas Okken in this post, Swiss Micros are setting up a forum at http://forum.swissmicros.com.

Should we not be having this discussion about the DM42 over at their place, to give them as much value from the beta testing as possible?

Quote:The Intel library provides all the functions Free42 needs; it doesn't just have arithmetic and square root, but also trigonometrics, hyperbolics, logarithms, and gamma. The new code uses all of these wherever possible, using the highest-precision format, decimal128.

The higher-level functionality, like complex numbers, matrices, numerical integration, and numerical root-finding, is still done using the same algorithms and code as before, but everything now uses the new library for the basic operations underneath.

(05-24-2017 08:30 PM)Vtile Wrote:  ...
Guenter have already started a topic on there.

http://www.hpmuseum.org/forum/archive/index.php?thread-756.html
...

(05-24-2017 09:05 PM)Hsilop Wrote:  

(05-24-2017 08:30 PM)Vtile Wrote:  ...
Guenter have already started a topic on there.

http://www.hpmuseum.org/forum/archive/index.php?thread-756.html
...

I guess that Thomas Okken may be the right man for Free42 matters, but he's the one that mentioned Swiss Micros' forum. I see no mention as of yet of this issue at there.

(05-24-2017 09:08 PM)Vtile Wrote:  this complex oddity.

(05-24-2017 09:09 PM)Logan Wrote:  

(05-24-2017 09:08 PM)Vtile Wrote:  this complex oddity.

We'll try not to be too negative about it either

(05-24-2017 04:44 PM)Ángel Martin Wrote:  

(05-24-2017 04:32 PM)Logan Wrote:  I have Free42 on my iPhone and it returned -1. The real 42 returned +1.

So this is a version-dependent for Free42. I remember about 8 years ago (while working on the 41Z project) I corresponded w/ Thomas about this issue and he agreed it wasn't the correct result and sent me an update... maybe it was never turned into the "official" code?

Interested to see how will this one be dealt with now.

BTW the 15C and the 15C-LE both return +1 in case you had doubts...

(05-25-2017 12:59 AM)Paul Dale Wrote:  The 34S gets (1, 2.031x10^-35) as its result.

It is possible that the Intel library is introducing a rounding error. I've seen cases before where it rounded incorrectly in the last digit.

Pauli

(05-24-2017 11:25 PM)Thomas Okken Wrote:  That sounds like a Free42 bug, or maybe an edge case in the Intel library that Free42 should work around. If I fixed this eight years ago and now it is broken again, that could be because that fix was specific to the BCD20 library that I used back then; I switched to the Intel library three years ago.

Ángel, do you remember when I made this earlier change? What date or at which version number?
If you don't, it's not a big deal, I can do a binary search through my revision history, but I'd rather not if I don't have to. :-)

Anyway, I'll look into it this weekend.

(05-25-2017 04:50 AM)Ángel Martin Wrote:  

(05-24-2017 11:25 PM)Thomas Okken Wrote:  That sounds like a Free42 bug, or maybe an edge case in the Intel library that Free42 should work around. If I fixed this eight years ago and now it is broken again, that could be because that fix was specific to the BCD20 library that I used back then; I switched to the Intel library three years ago.

Ángel, do you remember when I made this earlier change? What date or at which version number?
If you don't, it's not a big deal, I can do a binary search through my revision history, but I'd rather not if I don't have to. :-)

Anyway, I'll look into it this weekend.

Yes I still have the emails from 2011 (so only 6 years ago, not 8 - I'm an outlook pack-rat) - will forward them to you in a moment.
BTW while re-reading that thread I realized the issue back then wasn't exactly in ATAN - but in ASIN. Still entirely within the same functionality area... I guess involving those pesky square root branches and principal values?

(05-25-2017 11:11 AM)Paul Dale Wrote:  Converting to reals and using real functions is a cheats way out. You'll get the correct answer in this case but it is only hiding the underlying problem.

(05-25-2017 11:31 AM)Thomas Okken Wrote:  The complex atanh code (which is also used for complex atan) is correct, but a bit inaccurate when the real part (imaginary part for atan) is too close to zero. I'll have to make it handle that as a special case.

(05-25-2017 11:11 AM)Paul Dale Wrote:  Converting to reals and using real functions is a cheats way out. You'll get the correct answer in this case but it is only hiding the underlying problem.

(05-25-2017 04:35 PM)Ángel Martin Wrote:  

(05-25-2017 11:31 AM)Thomas Okken Wrote:  The complex atanh code (which is also used for complex atan) is correct, but a bit inaccurate when the real part (imaginary part for atan) is too close to zero. I'll have to make it handle that as a special case.

ok, but then watch out for this one, not with small imag part :

ACOS(COS(1+i)) = -1-i

(oops !!)