DM 42

[Ángel Martin]

(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=asi...2B0i))))))

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

[Vtile]

(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=asi...2B0i))))))

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

All my sources have been saying that 1+i*0 = 1*e^(0*i) = +1 ... in this case 1*e^0 , As given z=a+i*b=ABS(z)(cos(w)+sin(w)*i=ABS(z)*e^(i*w))
So the calculation should behave excactly like with integer 1. (with this knowledge of mine)

Is the problem with intel decimal library? Isn't the newRPL using it also or do I remember incorrectly?

[Hsilop]

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?

[Logan]

(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?

This doesn't seem to be specifically a DM42 problem, but rather with the underlying Intel libraries of Free42, which underlies the DM42

[Vtile]

(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?

Guenter have already started a topic on there.

http://www.hpmuseum.org/forum/archive/in...d-756.html
Thomas Okken writes there:

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.

So maybe it is a bug in free42 codebase not in the intel library ??

[Hsilop]

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

http://www.hpmuseum.org/forum/archive/in...d-756.html
...

I guess that Thomas Okken is 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.

Any chance that Intel might be interested in fixing their bugs anytime soon?

[Vtile]

(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/in...d-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.

It is on: Board index / DM42 beta units / Free42 related

Yes, Thomas Okken should be the one who is best on track which is going on with this complex oddity.

[Logan]

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

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

[Vtile]

(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

Yes, lets be positive.

[Thomas Okken]

(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...

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.

[Paul Dale]

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

[Thomas Okken]

(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

I just tried the asin(acos(atan(tan(cos(sin(1+0i)))))) test case in Free42 1.4.77, so pre-Intel, and got the same result.
This looks like an edge case that needs special handling in Free42's math_atanh(). Not a bug in the Intel library.
Should be an easy fix, but I'll put it off until the weekend, when my mind will be a bit fresher than it is now. :-)

[Ángel Martin]

(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?

[Guenter Schink]

For what it's worth

The Prime calculator immediately discards the imaginary part if that is "0"

input: (1+0*i) ^Enter results in 1

So does Wolfram |Alpha
input (1+0i) ^Enter results in 1

Günter

[Paul Dale]

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.

[Thomas Okken]

(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?

Got 'em -- Thanks!

This issue is unrelated, though. 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.

[Ángel Martin]

(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.

Couldn't agree more.

Besides that won't solve infinite other cases, like z=1+i which also shows the same problem!

[Ángel Martin]

(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 !!)

[toml_12953]

(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.

But when the imaginary part is 0 doesn't that mean the number *is* a real?
It seems more intelligent to treat it that way than to mindlessly use complex routines that aren't necessary.

Tom L

[Thomas Okken]

(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 !!)

Aargh, wrong branch. Another bug.