fortran 128 bit precision

I have code that I want to port from fortran into Matlab hopefully. Does the new 2012a Matlab, 64Bit, have a true "REAL*16" long double type cast?

If so, how do you type cast a variable to be a specific size? e.g; REAL*8 or Real*16 for 64bit and 128bit respectively. I have a stiff differential solver program written for the CRAY and its convergence criteria requires this precision. Without re-writing for Windows 7, Fortran and hoping, I thought MATLAB 64 would be a good platform due to the high number of matrices written.

Thanks ahead of time, Bill

Answer 1

[Ben Barrowes]

To convert your code to matlab, f2matlab will help. It will do about 90% or more of the work for you. http://www.mathworks.com/matlabcentral/fileexchange/5260

Once you are in matlab, you can use the higher precision solutions above. In terms of more alternatives, you could use the multiple precision toolbox: http://www.mathworks.com/matlabcentral/fileexchange/6446 but that will be slow compared to even matlab code.

or the Mathematica interface if you happen to have mathematica: http://www.mathworks.com/matlabcentral/fileexchange/6044

If you need speed and real*16, just leave it in fortran if that works for you. It should be able to compile on a windows platform. You say you tried for 3 months, so it seems like there is some problem, but it should work and we or others in fortran forums should be able to help. Otherwise a mex interface is a good idea to preserve speed but add a matlab interface. In the mex case, your numbers will be converted down to doubles when they return to matlab.

bb

Answer 2

[Andrew Newell]

The default numerical type is double, which has 53 bit precision (the other 11 bits being for exponents and sign). If you have the Symbolic Toolbox or Maple Toolbox, you could use vpa to get any desired precision - at a cost in speed.

EDIT: See also Variable-precision arithmetic. For those without the Symbolic Toolbox, there is a function you can download from the File Exchange (see Variable precision arithmetic without the Symbolic Toolbox). Variable precision arithmetic is implemented by software, which is why it is not tied to the number of bits in the hardware (see this Wikipedia article).

Answer 3

[Walter Roberson]

MATLAB R2012a does not have any 128 bit numeric types.

Answer 4

[Bill Swain]

Is VPA really capable of "any?" precision? My problem was on WinXP, a 32 bit machine, the declarations worked to the 32bit software core and could get doubles to d-word64. However, our convergence tolerance on the stiff ODE equations (gas dynamics) would default to zero when the ODE solver was crunching and therefore would error out as a 'divide by zero', but in actuality the crunching and convergence was still on-going. So, a.) with a dual core IA-64 processor and with Windows 7, and finally with MATLAB 64 bit, I should theoretically get to have a 128bit quadruple (decimal-128) variable that can be seen moving through the convergence and not halt the process.

In today's world it sound a lot, but for the gas dynamics accuracy and the ODE solver the original, proofed program was done with 128bit and used on a CRAY in the late 80's.

Appreciate your first reply. Hoping to get a bit deeper understanding of your vpa answer as I'm relatively new to MATLAB and definatly have not used vpa. Old 'C' and Fortran coder that is being overtaken by windows vs. unix and looking to port for useability on any win7 running MATLAB, hopefully.

Thanks in advance again. Bill

[Andrew Newell]

I have added some links to my reply.

[Walter Roberson]

vpa should be good up to 100,000 or more digits. However, you might have trouble finding stiff solvers that operate within the symbolic toolbox.

It is _not_ possible to simply create a symbolic number and pass it around to the MATLAB numeric routines.

Answer 5

[James Tursa]

Are you trying to create a mex routine from your Fortran code (e.g. using Intel ifort) that does the 128-bit floating point calculations? Or are you trying to convert all the Fortran code to m-code? Without extras such as the Symbolic Toolbox, 64-bit is the largest floating point type supported. E.g., you aren't going to find any 128-bit BLAS or LAPACK routines for background linear algebra calculations shipped with MATLAB (if that even applies to your code). You could do all the 128-bit calculations inside a mex routine and then use MATLAB for display, plotting, etc purposes.

Answer 6

[Bill Swain]

Thanks Andrew, Walter and Janes:

    Our code is ifort compiled for unix.   It was originally run on a cray.  We now use glinux to run, it.  But,.......we just moved and the unix box is getting antiquated without users to actually run the code anymore.

It would be nice to run in windows. I spent about 3 months on and off trying to get it to run in winXP without success even though the compiler took the REAL*16 declaration. The processor was IA-64, but windows couldn't accept anything bigger than 80 bits. What a learning process.

Now that windows is 64 bit and so is MATlab, I am hoping to move off the "crippled" unix machine and onto a windows platform. I've never used MEX to even know if that would work, although I do have the symbolic toolbox at hand, just never used yet. A bit still new to matlab overall.

your continued help is greatly appreciated.

[James Tursa]

If you have working ifort Fortran code that uses 128-bit floats, I would opt to write a mex routine as a first choice. That being said, I still don't completely understand your situation. What does MATLAB have to do with any of this? Are you simply trying to move your Fortran code to *something*, *anything*, that will work on a Windows 7 platform and preserve your 128-bit floating point calculations? And something in your code doesn't work in your current Windows setup? What does "couldn't accept anything bigger than 80 bits" mean? What, exactly, is not working? I can easily write ifort Fortran code that uses 128-bit floats inside a mex routine and interface that to MATLAB on my 32-bit WinXP machine. I just don't understand what your real problem is yet. P.S. Windows and MATLAB being "64-bit" is an operating system and application thing. It mainly has to do with things like addressing space and pointer sizes, not floating point types that are available to the application. The latter will be dictated by the h/w and compiler used.

Answer 7

[Jan]

You can create a QFLOAT type using the library of the LCC compiler. You need a version from the net, not the outdated version shipped with Matlab/32. QFLOATs have 348 bits (about 104 digits) and the library is well tested and contains SIN, ERF, POWER etc also.

If the standard operators are defined e.g. in a folder called @qfloat, even the standard numerical methods (integrator, optimisation) should work seamlessly in Matlab.

I've implemented such a set of functions for SINGLE and INT64 arithmetics for Matlab 6.5. I took some hours only. For QFLOATs the ouztput to the command window or to files will be more complicated, but solvable. For QFLOATs the XSUM function from the FEX is 50 times slower than for DOUBLEs.

Anyhow, it is not usual, that a convergence requires such a high precision. There is simply no physical meaning of such high precision values anymore.