 |
 |
Pierre Hugonnet wrote: > robin wrote: > > > REAL(selected_real_kind ( precision (1.0) + 1)) is also > > > identical if there is no intermediate precision between > > > default REAL and DOUBLE PRECISION kinds. > > > > Do you see a vendor providing such a one? > > Up to now, clearly no. > > But you cannot say that it will never be the case: Intel > architecture is based on 10bytes reals (I think). Intel is 4 bytes. Fout byte reals. Double precision is 8 bytes (15 digits). Extended precision is 10 bytes. The floating-point unit handles 10 bytes. > One could imagine > in the future compilers supporting 8bytes as REAL, 16bytes > as DOUBLE PRECISION, and in between 10bytes because it's > the native format. I don't know if it's realistic, but it could > happen. unlikely. > > > > And DOUBLE PRECISION does not work with COMPLEX. > > > > With COMPLEX, you need to use something like that > > > > which we have already elucidated, in order to obtain a > > > > precision grreater than single precision. > > > > > > > > > Requesting a given precision is specifying explicitly the precision > > > > > you want (p=6, p=12, ...) > > > > > > > > which is what " selected_real_kind ( precision (1.0) + 1)" does. > > > > > > It definitly doesn't: if I need 12 digits, > > > > It definitely does in the context of your original post, which > > is what we were discussing [quoted from above]: > > > > "> > > it requests a precision greater > > > > > than default REAL, that's all, like DOUBLE PRECISION (and I prefer > > > > > this latter, which is more readable than > > > > > selected_real_kind ( precision (1.0)) + 1) ) etc" > > > > > I can't use default REAL, since it is only 6 digits on most > > > 32bits machines. > > > > But you were saying that you use a 64-bit machine. > > Default real there is 15 or so digits. > > I use both 32bits and 64bits machines, and I want portable code > which efficiently run on both (and also on other possible > machines). I don't write code for a given a priori machine. But if you use a 64-bit machine, then you would use default real. > > > selected_real_kind ( precision (1.0) + 1) is OK on 32bits > > > machines, but will give a ~30 digits > > > kind (128bits) on some 64bits machines (Cray). default REAL > > > (15 digits) would have been prefered, since 128bits kinds > > > are generally software emulated and require more storage. > > > > And here [above] you confirm it. > > I just point the behaviors on both machines > > > To address this problem, you merely have to use > > SELECTED_REAL_KIND (15). > > Yes, and it has been showed that in that case > you cannot define generic interfaces... On the contrary, we showed you precisely how to do a generic interface for this. > Moreover, YOU claimed that libraries should be written > using REAL and DOUBLE PRECISION (or equivalent) > > > > If my algorithm requires some variables with 24 digits precision, > > > you can not say it's excessive precision! > > > > Of course I can say that. It's excessive precision > > because it's not available on most systems (about 99.9% of them). > > Did you read what I wrote above? : > > "> > It's excessive precision because not many machines > > > > support 24 digits. To be portable, about 15 digits is > > > > the maximum that can be "guaranteed". " > > Then quadruple precision should never be used ? Who said that? Nobody said that. > > > If you have a little moment, please could you write > > > for me a library containing the previously described example of "mysum", > > > with a generic interface, which is portable (assuming 24 digits > > > precision exists), > > > > [Isn't this an oxymoron? 24 digits does not exist in any way > > as portable.] > > > > > and which does not use more > > > memory and CPU than necessary. I'm almost sure that you can > > > not meet all of these requirements, but let's see... > > > > Anyway, we all have gone to some length to show you how > > this can be done. We have produced examples of declarations. > > Best regards > | Pierre Hugonnet %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%