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

[Thomas Okken]

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

OK, that turned out to be a really silly bug. I always meant for there to be visible feedback on the screen when you pressed Shift, except of course it was the calculator's Shift key that was supposed to move, not the 1/x key. The reason nobody noticed until recently is, apparently, that the two paint requests, for key-down followed by key-up, come in such quick succession that you can't see them at all. I wasn't able to reproduce the issue at all under Windows XP, nor Windows 7 using its standard theme; I only saw in under Windows 7 with the classic theme.
Oh, well. I fixed it so that the visual feedback is now correct -- if the combination of your hardware and your version/theme of Windows is slow enough for it to be noticeable.
I uploaded the fixed Windows build and updated source code.

(03-06-2014 08:23 AM)J-F Garnier Wrote:  

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

Hmm. Reviewing the project history, it looks like I bumped the minor version number pretty inconsistently. Version 1.1 was fairly major because it was the first that supported loading and saving programs, but 1.2 only added copy and paste, 1.3 added nothing except now being compilable by C++ compilers; 1.4 added decimal, which was big... But loadable skins, on-screen printer emulation and GIF spooling, the Palm local filesystem and HotSync conduit, and the HTTP server for iPhone, all pretty major features, didn't earn minor version number increases.
I'm happy with the arbitrariness of the current numbering scheme. If I ever get around to rewriting the Free42 type system using C++ polymorphism, then I'll probably go to 2.0. :-)

UPDATE: On second thought, maybe it is a good idea to go to 1.5 for this release, just to make it a bit more obvious that something drastic and non-forward-compatible has happened, never mind the relatively minor amount of work that went into it. Which I assume was J-F's point anyway.

[Marcus von Cube]

(03-06-2014 11:40 PM)Thomas Okken Wrote:  Oh, well. I fixed it so that the visual feedback is now correct -- if the combination of your hardware and your version/theme of Windows is slow enough for it to be noticeable.

Maybe it would be better to react separately on key down and key up events. This would make the feedback independent of the speed of the host.

[Thomas Okken]

(03-07-2014 01:18 PM)fhub Wrote:  I'm missing the "SHOWing all 34 digits" in your last todo-list, did you just forget this or don't you plan to implement it?

I'm saving that for a later release. I want this one out the door already and there's still plenty left to do as is...

(03-08-2014 03:15 PM)Marcus von Cube Wrote:  

(03-06-2014 11:40 PM)Thomas Okken Wrote:  Oh, well. I fixed it so that the visual feedback is now correct -- if the combination of your hardware and your version/theme of Windows is slow enough for it to be noticeable.

Maybe it would be better to react separately on key down and key up events. This would make the feedback independent of the speed of the host.

The problem with that is when the user types, say, * using Shift-8. I didn't want the emulated Shift key to move when typing something that doesn't involve the emulated Shift key, and the only way to know that for sure is to wait until the PC Shift key is released. I suppose I could put a brief delay between the two paint requests, but since this is something that never seems to have bothered anyone, I think I'll just leave it like it is. The main thing is that when there *is* visible feedback, at least it should be *correct*.

[Thomas Okken]

This is what's happened so far relative to 1.4.78:

* Decimal version: switched from BCD20 to Intel's Decimal Floating-Point Library v2.1.
* Binary version: replaced the old binary-to-decimal and decimal-to-binary conversions with code that uses the standard C library's equivalent functionality. This fixes final-digit errors in the Binary version, and also final-digit errors when switching from the Decimal to the Binary version.
* All versions: added angle reduction code to make SIN, COS, and ->REC more accurate in DEG and GRAD modes.
* Windows version: now uses %APPDATA%\Free42 as the default Free42 directory (for storing state.bin, print.bin, and keymap.txt). This avoids permissions problems, in Windows Vista and later, when people install the executable in a directory to which they don't have write access, like the popular choice "C:\Program Files".

Note that the last two of these are not yet in the packages at http://thomasokken.com/free42/download/intel-decimal/ . They will be when I finish the state file portability stuff, hopefully tomorrow. I'll post again when the final preview is ready. Of course, feel free to comment!

[J-F Garnier]

(03-08-2014 11:55 PM)Thomas Okken Wrote:  * All versions: added angle reduction code to make SIN, COS, and ->REC more accurate in DEG and GRAD modes.

Indeed, I notided it in previous versions, for instance: DEG 0 ACOS 90 - -> 2.55E-22 (1.4.78) or -3E-32 (1.4.79).
It was not a big issue for me, but I'm happy that it will be improved!

[Thomas Okken]

I wasn't able to finish all the backward compatibility stuff in time to post an update this weekend. The Windows and 32-bit Linux versions are now backward compatible with all previous versions, but I'm still debugging the 64-bit Linux version, and haven't even started testing backward compatibility for the Mac version. I figure about one more day of work to finish all that; maybe I'll have the time and energy to do that during the coming week, but realistically I think 1.5 for Windows, Linux, and OS X will be out next weekend. (I'm not even going to guess when the iOS and Android versions will be available, because I have no idea how messy it will be to get the Intel library built for those platforms, and how much work will go into making the iOS version iPhone-5- and iOS-7-compliant.)

What will be in 1.5 is everything that has been discussed so far in this thread, except:

* The new forward and cross-platform compatible state file format
* 34-digit SHOW
* Exact results for acos(0), asin(0.5), etc., in DEG and GRAD modes

Those will all be in 1.5.1.

If anyone reports bugs in the current preview builds, I will of course incorporate fixes for those, but I won't post any more previews before 1.5 final. I'll stop spamming this forum until then. :-)

[Thomas Okken]

(03-09-2014 09:58 PM)Thomas Okken Wrote:  I'm still debugging the 64-bit Linux version, and haven't even started testing backward compatibility for the Mac version.

I fixed the problem with 64-bit Linux, and found no problems with the Mac version.
So, I released 1.5 on my web site -- http://thomasokken.com/free42/ -- and removed the previews.

Thank you to everyone who tried the preview and gave me feedback!

[J-F Garnier]

(03-09-2014 09:58 PM)Thomas Okken Wrote:  I'll stop spamming this forum until then. :-)

We can't stop so easily :-)
An observation on version 1.5 (Windows) Decimal and Binary:
in DEG mode, COS(90) -> -0 and SIN(180) -> -0

[Paul Dale]

Weird, I'd be surprised if the Intel libraries are return -0 in these cases. Maybe the recently introduced modulo reduction is the culprit here.


- Pauli

[Thomas Okken]

Yes, that's definitely the angle reduction code at work -- it changes the sign of the result depending on which quadrant the angle was in before the reduction.
I'll fix that, but now I wonder how many other situations there are like this? The Intel library and the angle reduction code aren't the only new features in 1.5; this is also the first that relies on library functions to display numbers (sprintf() for binary, bid128_to_string() for decimal, both followed by code that massages the output to make it look like it should on an HP-42S), and those functions make a point of rendering signed zero, while the old Free42-specific number formatting code didn't. There may have been signed zeroes haunting the hallways in Free42 Binary since version 1.0... You just couldn't see them. (Not in Free42 Decimal, since BCD20 doesn't support signed zero, if I remember correctly.)
To make it behave normally, preventing the number display code from rendering signed zero may be the right thing to do. -0 behaves exactly like +0, except for what happens when you divide by it, and Free42 doesn't allow division by zero anyway.

[Thomas Okken]

(03-10-2014 02:48 PM)fhub Wrote:  if there's a file 'portable' in the current directory, then Free42 uses this current directory for the 3 configuration files (and doesn't use the registry at all)

That's a possibility, but using a command-line switch would be cleaner. Something like "Free42Decimal.exe -localstate".
That would mean you'd have to launch it through a shortcut, though.

[Thomas Okken]

(03-10-2014 08:02 PM)fhub Wrote:  And creating a shortcut (*.lnk) has the disadvantage that then it's again not really portable anymore, because such a LNK-file always contains the FULL path to the EXE

Right. Hadn't thought of that. Magic file it is, then!

[Thomas Okken]

I just uploaded version 1.5.1. It has these improvements:

* exact asin(1), acos(0), etc., in DEG and GRAD modes
* it no longer shows negative zeroes
* Windows version: it supports running off a USB stick with a file named "portable" in the executable's directory

I think that covers everything that's come up in this thread.

[Werner]

(03-15-2014 11:54 PM)Thomas Okken Wrote:  I just uploaded version 1.5.1. It has these improvements:

* exact asin(1), acos(0), etc., in DEG and GRAD modes
* it no longer shows negative zeroes
* Windows version: it supports running off a USB stick with a file named "portable" in the executable's directory

I think that covers everything that's come up in this thread.

Thanks Thomas.
BUT
in DEG mode:
SIN(180°+x) = -SIN(x) fails for x=10^-31, 10^-30, 10^-16 ... and many more (these fail on the WP34 as well btw)
UPDATE (Free42, but not WP34): this is probably due to 1e-31 - 10^-31 not being zero.. in fact 10^x does not produce the correct result for x= integer; even -1..)
SIN(45°) ^= COS(45°)
I can't find the range reduction code straight away, to see what would be wrong with it.. can you point me to it?
Cheers, Werner

[Thomas Okken]

(03-16-2014 01:45 PM)Werner Wrote:  I can't find the range reduction code straight away, to see what would be wrong with it.. can you point me to it?

In core_helpers.cc, look for sin_or_cos_deg() and sin_or_cos_grad().

[Werner]

Thanks, see my update in the previous post: it's 10^x that is the culprit.
As for SIN(45°) ^ = COS(45°), you left out one line of code wrt mine:

if x = 45 then x := SQRT(0.5);
else do

if x > 45 -- SIN(90°-x) = COS(x) and vice versa
then do
x := 90 - x;
if fSIN then fSIN := FALSE;
else fSIN := TRUE;
end;

if fSIN then x := SINDEG(x);
else x := COSDEG(x);

end;

That's all. (only looked at this part, not the GRADS, not the addition of complex numbers in polar mode etc..)
Cheers, Werner

[Thomas Okken]

(03-16-2014 01:45 PM)Werner Wrote:  10^x does not produce the correct result for x= negative integer

Apparently, bid128_pow() does not handle integer exponents specially. I'll fix that by transplanting the repeated-squaring logic for the complex case. 10^-31 not being exact, sheesh!
Assuming nothing else is wrong, Free42 Binary should be OK, if you throw large negative powers of 2 at it. As far as I know, the libc pow() does use repeated squaring for integer exponents.

[Thomas Okken]

(03-16-2014 02:38 PM)Werner Wrote:  Thanks, see my update in the previous post: it's 10^x that is the culprit.

OK, the Phloat::pow() fix will be in 1.5.2. Still a lot of work to do on the new state file format, so probably no sooner than next weekend.

(03-16-2014 02:38 PM)Werner Wrote:  As for SIN(45°) ^ = COS(45°), you left out one line of code wrt mine:

if x = 45 then x := SQRT(0.5);
else do

It didn't seem relevant to the angle reduction, but I had ignored the sin(45°) = cos(45°) issue. I'll add that in 1.5.2 as well.
By the way, where can I find out what formatting is supported on this forum? I thought it was strictly plain text here until I saw your [b] tags. :-)
(UPDATE: Duh, Help -> Posting -> MyCode. Never mind!)

(03-16-2014 02:38 PM)Werner Wrote:  That's all. (only looked at this part, not the GRADS, not the addition of complex numbers in polar mode etc..)

The grads code is identical, just s/45/50/g etc.
Polar mode doesn't affect anything; complex numbers are always rectangular internally, and converted to polar only for display. The polar-to-rectangular conversion does rely on your angle reduction; see generic_p2r() in core_helpers.cc.

Thanks very much for you help!

- Thomas

[Thomas Okken]

While implementing the code for accurate decimal Y^X with integer exponents, I found a nasty bug that broke decimal Y^X for complex Y and negative integer exponents. I thought that was sufficiently serious to put out another release (1.5.2); it's on my web site now. It also includes the sin(45°) = cos(45°) fix, and the improved decimal Y^X and 10^X.

N.B. The bug in Y^X for complex Y and negative integer X is only in Free42 Decimal 1.5 and 1.5.1. Older decimal versions are OK, as is 1.5.2. The binary versions never had this bug.

[J-F Garnier]

(03-17-2014 01:01 AM)Thomas Okken Wrote:  ... release (1.5.2); it's on my web site now. It also includes the sin(45°) = cos(45°) fix, and the improved decimal Y^X and 10^X.

Thanks for the improved 10^X. It makes the FWIW utility to work correctly now (was failing in some cases before).
I noted that there is also a similar issue in the reverse situation:
1E5 LOG 5 - --> 1E-33 (also for 1E40 and other)
This didn't happen in versions 1.4.7x

J-F

[added: worst case is 1E63: 1E63 LOG IP --> 62 ; this can still make FWIW to fail to extract the mantissa/exponent correctly]