j3-fortran / fortran_proposals

Proposals for the Fortran Standard Committee
173 stars 14 forks source link

Arbitrary precision type #179

Open Jim-215-Fisher opened 3 years ago

Jim-215-Fisher commented 3 years ago

Does the stdlib include arbitrary precision data type? Currently, python, julia, c++, and java all have arbitrary precision data type.

milancurcic commented 3 years ago

No, but it seems to me a good candidate for stdlib. Then, if it shows to be useful we can propose it for the standard. Can you propose it in the stdlib repo?

certik commented 3 years ago

In addition, I would like Fortran compilers to support arbitrary precision real types natively (as a real kind). I plan this for LFortran down the road.

klausler commented 3 years ago

There's a useful distinction to be made between "arbitrary" precision data types where the precision is known at compilation time and those whose precision is either not fixed at all or is at least deferred to execution time.

All of f18's REAL compilation-time arithmetic for constant folding, and decimal<->binary conversion during execution, are implemented with single C++ template classes that are instantiated for six different floating-point types, for example. This would be pretty much impossible to accomplish in Fortran without parameterized modules or some other generic facility, and that's at least a decade away in the standard language (plus years more to wait for a first implementation, and then dealing with the bugs in the standard that can only be discovered by a first implementation and then become impossible to fix due to "backward compatibility").

But types with runtime precision (esp. INTEGER) would be easy to implement in Fortran using a derived type with a LEN type parameter -- if you could find a compiler where they work, correctly, or even at all. So the best that we could do now would be a suite of arbitrary precision INTEGER and REAL types where the precision is dynamic and represented in a regular component of each value, and the bits are in an ALLOCATABLE component, with all the extra allocation overhead that implies.

certik commented 3 years ago

Speaking as a Fortran user, I would like to simply write code like this:

real(dp) :: s, x, dx
integer :: i, N
N = 100
dx = 1._dp / N
s = 0
do i = 1, N
    x = i*dx
    s = s + sin(x)*dx
end do
print *, "Integral:", s

And then just change dp from "double precison" to "100 decimal digits precision". This already works with quadruple precision, and it would be nice to work with arbitrary (compile time) precision also.

Then I also want a real kind that will use this library: http://arblib.org/ that automatically tracks the error for you. It works really great. I would like the "print" statement to print the error correctly (as Arb returns it), etc.

And I would like the compiler to generate the most efficient code possible.

klausler commented 3 years ago

Speaking as a Fortran user, I would like to simply write code like this:

real(dp) :: s, x, dx
integer :: i, N
N = 100
dx = 1._dp / N
s = 0
do i = 1, N
    x = i*dx
    s = s + sin(x)*dx
end do
print *, "Integral:", s

And then just change dp from "double precison" to "100 decimal digits precision". This already works with quadruple precision, and it would be nice to work with arbitrary (compile time) precision also.

Then I also want a real kind that will use this library: http://arblib.org/ that automatically tracks the error for you. It works really great. I would like the "print" statement to print the error correctly (as Arb returns it), etc.

And I would like the compiler to generate the most efficient code possible.

The most difficult part of implementing your example may be the call to sin(x).

certik commented 3 years ago

Yes, all Fortran special functions should work. If the MPFR library is used, it can do those. The Arb library can also do those (and more).