Decimal Floating Point type 1287

General APL language issues

Decimal Floating Point type 1287

Postby paulmansour on Wed Feb 18, 2015 7:20 pm

The documentation contains the seemingly contradictory information that though ⎕FR may be localized, it is not advisable to alter it dynamically during a running application.

What is the reasoning behind this? I understand the specific issues mentioned in the documentation, and that care must be taken, but if I have a subsystem or class or some component of an app that wants to take advantage of decimal floats, and I want to integrate it with other code using 645s, should I not do this?

Specifically, if I have a class that covers a float of type 645 in my system, and then introduce a class that covers decimal floats of types 1287, I can, for example, control for the issue of comparing a 645 with a 1287 for equality (one of the warnings in the doc).


Bonus question:

In the docs, under "Settings Affecting Behavior of Primitive Functions" (page 203 of the Language Reference Guide) all of the system functions listed have namespace scope except ⎕FR and the associated ⎕DCT which have workspace scope. Why? It would have been nice to able to set ⎕FR in a class rather than localize it in every single function in the class.
paulmansour
 
Posts: 375
Joined: Fri Oct 03, 2008 4:14 pm

Re: Decimal Floating Point type 1287

Postby Morten|Dyalog on Wed Feb 25, 2015 9:44 pm

128-bit floating-point numbers were developed under the impetus of a major client large multi-currency portfolios that were testing the limits of binary double precision. When the new type was being designed, the users-to-be were adamant that they would throw the switch once and run the entire application using high precision numbers. For a long time, we considered making the floating-point data type a startup parameter, or even a compile-time option, but eventually decided to have a dynamic switch in order to make it more practical for clients to experiment with the new type - and for Dyalog to develop test scripts for it :-).

Although the system handles changes reasonably consistently, some odd situations can occur if you "mess around with ⎕FR". For example, the data type of a floating-point constant will depend on the value of ⎕FR when you fixed the function, not the runtime value. These effects should have no influence on the results that you get, but can be confusing, and it made us feel that a warning was appropriate.

To the best of our knowledge: in the years that have gone by, no client has yet switched to using DECF's throughout the application. Some have decided to do what you are considering, and have "high precision" modules that are called from applications that otherwise use regular double-precision binary floating-point. If you take the time to understand the transitions, this should be perfectly safe and predictable.

We plan to review the status of the DECF implementation in 2015, together with the original client, and see if adjustments are required. I think I can make the following statements:

1) Dyalog will continue to have a high-precision floating-point type. There is a small but non-zero chance that we will opt to replace the existing DECF's by something faster and/or more flexible. The next 5 years may well see us implement "unlimited" precision types (integers and rational numbers) as well.
2) There is a high probability that we will change the scope of ⎕FR and ⎕DCT to "namespace" in version 15.0, in order to make it easier to implement high-precision modules. Unfortunately it is too late to consider this for v14.1.

I hope this made it easier for you to take the necessary decisions. If I have left your more confused than before, please ask away!
User avatar
Morten|Dyalog
 
Posts: 409
Joined: Tue Sep 09, 2008 3:52 pm

Re: Decimal Floating Point type 1287

Postby paulmansour on Thu Feb 26, 2015 3:44 pm

Morten,

Thanks for the detailed reply. It would be (will be!) much better when these system functions have namespace scope - with that I could almost trivially add 1287 support to my app. Anyway, I think it is going to be essential to use 1287s, if one uses them at all, along side the existing 645s for now at least.

By the way, a while back, you, or someone, explained why we would not see something like a 64 bit int in the interpreter, as it messed up the progression of ..83 163 323 645 ... but there was more to it than that. What is the full answer to that? No rush, no need to answer now, happy to get the answer over a beer at the next conference.

Paul
paulmansour
 
Posts: 375
Joined: Fri Oct 03, 2008 4:14 pm

Re: Decimal Floating Point type 1287

Postby Morten|Dyalog on Fri Feb 27, 2015 9:24 pm

There are a couple of problems with 64-bit INTS:

If you are using normal double-precision floats, then if you have an integer larger than 2*53, and you apply something straightforward like the classical rounding expression to it {⌊0.5+⍵}, then the system will flip into 53-bit floats, round off, and not necessarily give you anything like the number you first thought of.

If you use normal tolerant comparisons, you may find that INT=INT+1.

In an APL interpreter, which automaticaly promotes (or demotes) types as required, having an integer representation with more precision than your floating-point representation is "bad medicine".

Richard Nabavi presents the design decisions that went into 64-bit INTS in APLX in a Vector article at http://archive.vector.org.uk/art10011570. We are not comfortable with heading down exactly the same path.

We have some ideas for a theoretical framework which recognises two types of numbers: Precise and imprecise (i.e. floating point), but we haven't been able to dot all the i's and cross the t's yet. These may require some sort of declaration by the user when creating numerical constants. Since we will have to live with the consequences for decades, we are not keen to push ahead without being sure we know where we want to go.
User avatar
Morten|Dyalog
 
Posts: 409
Joined: Tue Sep 09, 2008 3:52 pm


Return to Language

Who is online

Users browsing this forum: No registered users and 1 guest