Free42 with IEEE 754-2008 decimal floating-point -- interested in a sneak preview?

[Thomas Okken]

Reposting download link...

http://thomasokken.com/free42/download/intel-decimal/

[Thomas Okken]

(03-02-2014 02:14 PM)Gerson W. Barbosa Wrote:  Glen Sanft's FWIW program here was a nice way, but unfortunately it doesn't work anymore.

It works again now. It stopped working because AIP stopped working; I just uploaded a new build that fixes that problem.

(The AIP and MOD bugs were both caused by me not checking the behavior of bid128_rem(). The HP-42S MOD function gives a result which has the same sign as the denominator; the standard C library's fmod() function gives a result which has the same sign as the numerator; the Intel library's bid128_rem() function gives a result with the lowest possible magnitude, regardless of sign. Free42 uses bid128_rem() for AIP and MOD.)

Glen's program still only shows 25 digits, but with this fix, at least it shows 25 legitimate digits again, not digits interspersed with gibberish. I'll fix the FWIW program to show 34 digits tomorrow.

UPDATE: 34-digit version of FWIW is http://thomasokken.com/free42/42progs/FWIW34.raw

[Werner]

(03-02-2014 08:14 PM)Thomas Okken Wrote:  Re: changing the sign of zero: that's IEEE 754. Signed zeroes! Works in the binary version, too.

So is the 'inexact' flag. Any chance of having that implemented as a system flag? ;-)
Thanks for all this, Thomas!
Werner

[J-F Garnier]

A little observation:
In the binary version: SF 24 1E200 x^2 -> <Infinity> (previous versions: 1.7977...E308)

[Werner]

A quick hack, using the MANT routine from a previous thread:
Will show all digits in m.mmmExxx format, doesn't change any setting, works for the current 25-digit version as well as for the new 34-digit one.

Code:


00 { 71-Byte Prgm }
01>LBL "SHOW"
02 CLA
03 X<0?
04 "-"
05 ABS
06 ENTER
07 XEQ "MANT"
08 X!=0?
09 STO÷ ST Y
10 AIP
11 FS? 28
12 +"."
13 FC? 28
14 +","
15>LBL 02
16 FP
17 X=0?
18 GTO 01
19 0.1
20>LBL 03
21 X<=Y?
22 GTO 00
23 STO÷ ST Y
24 +"0"
25 GTO 03
26>LBL 00
27 ÷
28 AIP
29 GTO 02
30>LBL 01
31 +
32 X!=0?
33 LOG
34 +"E"
35 AIP
36 AVIEW
37 END

00 { 25-Byte Prgm }
01>LBL "MANT"
02 ABS
03 1
04 X<Y?
05 10^X
06 ÷
07 ENTER
08 X!=0?
09 LOG
10 IP
11 10^X
12 ÷
13 1
14 X>Y?
15 10^X
16 ×
17 END

Werner

[Thomas Okken]

(03-03-2014 08:29 AM)J-F Garnier Wrote:  A little observation:
In the binary version: SF 24 1E200 x^2 -> <Infinity> (previous versions: 1.7977...E308)

Ah, I think that means that VC++ 2008 has proper IEEE 754 support (VC++ 6.0 doesn't). That probably means I can get rid of my isinf() kludge and maybe also everything else in free42/windows/mathfudge.c.

[Mike T.]

Thank you - I can report that it works fine on Debial Lenny... (it proabably shouldn't but it does!)

Mike T.

[Gerson W. Barbosa]

(03-02-2014 09:42 AM)Paul Dale Wrote:  Finally a calculator that compares to the 34S in accuracy.....

Just an example:

163 √ π x eˣ 744 - 3 1/x yˣ

640319.9999999999999999999999993873 (Free42)
640319.9999999999999999999999993873 (WP 34S)

and another:

8002 1/x +/- 8002 + 1/x +/- 8002 + 1/x +/- 4001 + 5 / x²

640320.0000000000000000000000001523 (Free42)
640320.0000000000000000000000001523 (WP 34S)

[J-F Garnier]

and to check the *absolute* accuracy:
163 SQRT PI * E^X
Free42: 262537412640768743.9999999999992474
_exact: 262537412640768743.9999999999992501

[walter b]

I'd appreciate if you could press <Quote> at the post you are responding to. In this case it obviously was that one - it is hard to find in long threads.

d:-/

[Werner]

(03-04-2014 09:17 AM)J-F Garnier Wrote:  and to check the *absolute* accuracy:
163 SQRT PI * E^X
Free42: 262537412640768743.9999999999992474
_exact: 262537412640768743.9999999999992501

That's actually as good as it can get..
SQRT(163) and PI are correctly rounded to 34 digits, and their product is one ULP short of the true (but unobtainable) value.
1 ULP here is 10^-32, so the result is 2.6*10^17*10^-32 = 2.6*10^-15 off, exactly what we observe.
Werner

[Paul Dale]

The IEEE standard requires addition, multiplication, division and square root to be correctly rounded.

The 34S could suffer from a double rounding issue here since it is working to greater than 34 digit precision internally. However, the Intel library should get this correct.

Once you get into the transcendental functions, things aren't so nice.


- Pauli

[J-F Garnier]

(03-04-2014 09:27 AM)walter b Wrote:  I'd appreciate if you could press <Quote> at the post you are responding to. In this case it obviously was that one - it is hard to find in long threads.

d

Yes, it's one drawback of this new forum.
And I didn't use <Quote> in *this* case deliberatly, because it was not needed and too many quotes (IMHO) makes threads even longer:-)

[J-F Garnier]

(03-04-2014 10:30 AM)fhub Wrote:  If I switch from Free42 to any other open window with Alt-Tab, and then switch back again to Free42, then the program doesn't accept keystrokes on the PC-keyboard anymore, i.e. it loses all keymappings!

It's a known issue. Press Alt one or two times after going back to Free42 to recover.

Quote:If you press the Shift-key on the PC-keyboard and release it again, then the button [1/x] in Free42 moves as if you would have clicked on it.

Doesn't happen for me. The shift-key just activates the shift indicator.

[Thomas Okken]

(03-04-2014 10:30 AM)fhub Wrote:  If I switch from Free42 to any other open window with Alt-Tab, and then switch back again to Free42, then the program doesn't accept keystrokes on the PC-keyboard anymore

This is a bug in Windows. You can reproduce the exact same behavior with any other program that uses the classic type of menu bar. I verified this by running the Windows XP version of Microsoft Paint under Windows 7.
What happens is that the app sees you pressing Alt, and treats this as a request to start arrow-key navigation in the menu bar. Either Windows should delay sending the app the Alt-pressed event until it's sure that the user isn't performing Alt-Tab, or, after finding that the user pressed Alt-Tab, send the app a second Alt-key event to cancel the first. I don't know which approach they used in Windows before Vista, but they broke it in Vista and beyond.
Since MS isn't going to fix this, the only options right now are (1) live with the work-around of having to hit Alt again when switching back to Free42, or (2) I should change the UI to use the new-style menu bar. I find neither option very appealing...

(03-04-2014 10:30 AM)fhub Wrote:  If you press the Shift-key on the PC-keyboard and release it again, then the button [1/x] in Free42 moves as if you would have clicked on it. It's not really a problem, but it's strange and seems to indicate any issue with the keyboard handling (wrong interpretation of the release-code of the PC's Shift-key).

That is strange. I had never noticed this before, but sure enough, I can reproduce it in Windows 7.

[walter b]

You don't have to quote text (which would indeed elongate the thread unnecessarily). Please just get used to using <Quote> instead of <New reply> - the latter is evil.

d:-)

[Thomas Okken]

(03-04-2014 06:46 PM)walter b Wrote:  You don't have to quote text (which would indeed elongate the thread unnecessarily). Please just get used to using <Quote> instead of <New reply> - the latter is evil.

d:-)

Or, if I may make a suggestion -- use "new reply" only if you're replying to the thread in general; use "quote" if you're replying to a specific comment. Even if you the delete most of the quoted text before submitting your post, the header of the quotation box contains a little green arrow that people can click to jump to the message you were replying to.

[Thomas Okken]

(03-04-2014 03:12 PM)Thomas Okken Wrote:  

(03-04-2014 10:30 AM)fhub Wrote:  If I switch from Free42 to any other open window with Alt-Tab, and then switch back again to Free42, then the program doesn't accept keystrokes on the PC-keyboard anymore

This is a bug in Windows. [...] I verified this by running the Windows XP version of Microsoft Paint under Windows 7.

I just took another look at this, and it looks like this isn't a bug in Windows Vista/7/8 per se, but rather a bug in the newer Windows "themes". I use Windows 7 with the Windows Classic theme, a.k.a. the Windows 95/98/2000 look, and the bug doesn't happen there. When I press Alt, I see the little underlines under the menu titles appear, and when I then press Tab before releasing Alt, the application switch takes place, *and* the little underlines disappear from Freee42's menu bar, which would seem to indicate that it did receive a second Alt-key event.

I didn't notice the "twitch" in the 1/X key when pressing Shift under Windows XP, which is interesting, but maybe that has something to do with me running XP in a VM, which could mean that the screen is updating too slowly for that phenomenon to be noticeable. Either way, *this* isn't related to the choice of theme under Windows 7, because I see that twitch plain as day in Windows 7, even though I'm using the Windows Classic theme.

[Thomas Okken]

I fixed the behavior of Inifinity and NaN in the new Windows Binary build, and updated the Windows and source code packages.

For reference, my current to-do list for release 1.4.79 is:

* Implement Werner's angle reduction code.
* Fix backward state compatibility for Windows.
* Re-test *all* backward compatibility scenarios, including revisions 463, 647, and 1327 (last binary-only, old BCD20, new BCD20).
* Implement EBML-based state file.

* Find out how to build Intel library for ARM, and build new Android version.
* Find out what the exact requirements for iTunes app store submissions are. Is it still possible to submit 3.1.3-compatible apps? If so, is that orthogonal to supporting the iPhone 5 screen?

[J-F Garnier]

(03-06-2014 01:06 AM)Thomas Okken Wrote:  For reference, my current to-do list for release 1.4.79 is ...

Since the change to the Intel lib and the 34 digit accuracy is a major change (in my opinion), would you consider to name the new release 1.5.0 ?