Thanks, but when I cast to double I don't see the real number at least when I tried with long double and I presume the same will happen with _Quad.
For instance, instead of visualizing the long double1.463100e-3845, printf and std::cout output1.13261e-317 when the variable is cast to double.
You mention the Fortran function WRITE to display quad numbers, but is there an equivalent in the Intel C/C++ compiler? If not, how can I use the Fortran write in a C/C++ program?
Thanks in advance
Note what TimP said: "..if you don't need to view the additional precision or range". Your example value does not require more precision than in type double, but it clearly exceeds the range limits of type double.
The number I used was just an example for illustration purposes. If I didn't need the additional precision and range I would not be bothering anyone in this forum. I need to output other numbers that do require more precision
Using Fortran to do the output is probably overkill, but can also be troublesome. ISO Fortran C-interoperability does not require support for extended precision reals, and mixing C and Fortran I/O can also be troublesome.
I agree, but if that's the ONLY option, then I'm willing to take the risk
I hope that somebody who has some experience with Fortran and C can help me with this. I can't really believe that Intel provides support for a data type which can not be visualized. But whatever, I don't want to start a long discussion on that.
I suggest that you make a "feature request" for the C compiler that you use.
Thanks, but waiting until that's implemented would be really overkill. I hope this is not my only option.
I wouldn't advise taking risks with combining C and Fortran formatted output. This certainly involves annoying restrictions, like not accessing stdin, stdout or stderr from Fortran in a C program. Instead, you might pass the data across in character arrays and treat them as Fortran internal files.
Flushing each output stream before switching between Fortran and C access should be sufficient, supposing you do want to intermix outputs, when using companion C and Fortran run-times, but no one guarantees it.
Intel Fortran apparently defines real(C_LONG_DOUBLE) appropriately for linux (ifort doesn't have an 80-bit data type), but it may not have the same meaning on Windows, or in other Fortran compilers.
than for display of Intel C _Quad data types.
Is there any place where you have thoroughly documented your _Quad implementation? Maybe if people are more knowledgeable about it, we can write our own print routines.
Also, is there any way to convert from Intel's _Quad or long double to a mpfr representation?
The guys at MinGW have implemented their own printf for long double and you have not. It could be good if you implemented visualization routines for for _Quad and long double too. For several reasons I cannot use MinGW, unfortunately.
As Bustaf hints, we see more demand for gmp and mpfr
Why? Do gmp and/or mpfr not compile with your Windows compiler for x64? If not, why not?
By the way, it seems that gmp does not have a power function for floating point parameters, (although I think mpfr does) so that's not an option to me.
As far as Windows is concerned, the usual way to run gmp/mpfr is by installing cygwin. You would need mpir for linkage with Microsoft tools.
Are you sure you meant "run" and not "compile"? Cygwin's runtime it's slow. I don't have a problem with using Cywgin to compile source code (e.g., with the MinGW compiler that produces native Windows executables. I think MSVC compiler is also supported), but I don't want my programs to be linked to cygwin's slow run-time libraries.
Probably i have not correctly understand this exchange with my bad control your language (relation msys.dll)
Yes, you didn't quite get it.
As far as I know msys.dll is a __MinGW__ library. I never claimed MinGW was slow. I said the __CYGWIN__ runtime is slower than native Windows executables such as those produced by MSVC, or MinGW (that's one the advantages of the latter, it's faster than cygwin). What I said is that, unfortunately, I cannot use MinGW (though I really want) but for other reasons (too long to explain).
I suspect that Intel's compiler could link an executable to a MinGW-compiled MPFR library, but introducing even another compiler into the mix only increases complexity. I prefer to stick with only one compiler, and we are using Intel's for now.
Probably to use mpfr could resulting more slow (Linux or Microsoft) that _quad, library
Exactly. Besides, _Quad is enough for my needs. I don't need the extra precision/range that mpfr allows.
I have an doubt that is existing really an great difference performance between the two.
OK. I have read something different. Honestly, I don't want to keep arguing with you about cygwin vs mingw.
That I know also is with MPFR you can outing is formated correctly or greater that required for you. Is object major your question.
My primary question was about printing _Quad variables. I am very happy with the performance of my calculations with that data type, and I think that switching to MPFR, despite other people's constant nagging, is better to be left as a last resort. All in all, I think there is no other choice to implement some printing routine myself or user someone else's (except for Intel which obviously doesn't care)
But thanks for your feedback.
Sorry for reviving this old thread. I was wondering if this problem has now been solved. I need to find the difference between 2 very small quad precision numbers and so I need to be able to see quad precision numbers.