Printing _Quad

cppcoder · ‎12-30-2010

Hello,

I know that MS library functions (e.g., printf) cannot output numbers stored in variables of type _Quad or long double. I get it.

.

Now, does anyone know how can I print (to the console) the value of a _Quad variable? Is there any function or library for this? I suppose that it must be "simple" to write one function for that, but I have no idea how to do it and it doesn't look simple to me.

.

Any help on this would be appreciated

.

Thanks in advance

TimP · ‎12-31-2010

The simple way is to cast to double, if you don't need to view the additional precision or range. Intel Fortran run-time library has quad precision WRITE.

cppcoder · ‎12-31-2010

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

mecej4 · ‎12-31-2010

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.

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 suggest that you make a "feature request" for the C compiler that you use.

cppcoder · ‎12-31-2010

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.

TimP · ‎12-31-2010

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.

aazue · ‎01-01-2011

Hi
Show if you can calling the MPFR lib with Intel compiler the more easy i think.
Load this link
I read success build (Microsoft) at end page

http://www.mpfr.org/mpfr-2.4.0/#platforms

I can not help you greater I have not machine to my hand disposed ready installed (compiler),
for Microsoft side.
Regards
See also (Mpir) ??
http://gladman.plushost.co.uk/oldsite/computing/gmp4win.php

TimP · ‎01-02-2011

As Bustaf hints, we see more demand for gmp and mpfr than for display of Intel C _Quad data types. 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.

cppcoder · ‎01-02-2011

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.

TimP · ‎01-02-2011

_Quad should comply with IEEE 128-bit data format, except that I don't know about gradual underflow (which, of course, would not have to be handled by mingw long double printf). As you say, there are good open source implementations of printf() for the more common data formats, which could be extended to 128-bit without much difficulty, if your usage doesn't pose difficulties with combination of open and closed source software.

I don't know how performance of cygwin run-time relates to the topic. In my experience, I haven't had any complaint about performance of cygwin libraries, other than libgomp, but I mentioned cygwin only in that it's the most popular and best tested gmp/mpfr for Windows, to agree that it's probably not your choice. gmp/mpfr evidently trade generality for performance, regardless of which compiler they are built with, so the icl _Quad ought to perform better. I wasn't attempting to take a position on Bustaf's suggestion that you adopt mpir.

aazue · ‎01-03-2011

Hi

If you have the time and practice C/C++ language you can build directly the lib with your compiler under Microsoft environment.
Probably to use mpfr could resulting more slow (Linux or Microsoft) that _quad, library aptitude Is too large for that is exactly function necessary to you.
Personal i use this library only when is required very large precision... (not other way possible)

About slow (using process msys.dll), now last version ,only (-7%) compared native Linux,also valid with hard source.

I have long time thinking same as you that to use (msys.dll) result very slow but in reality now is not true..

http://tdm-gcc.tdragon.net/download
install (Bundle Installer) all tool utility program complement are included
install complete require less that 5 minutes ;download included.
64 & 32 He working same the watch swiss... you have also now flto included default...
I like use Intel compiler and my answer is not to make promotion other product, just for correcting real value product is decreased no justified.

Probably i have not correctly understand this exchange with my bad control your language (relation msys.dll)

If you build as static an program (example using lib OpenMp or other... )with tdm-gcc , you can move binary to other computer without nothing
just computer hosting binary program require msys.dll.
Also in Linux i can compile an library with gcc/g and call this library with an other binary compiled with Intel compiler..
According ; it could be more complex for you with Microsoft where you must transform the (lib.a to dll...) if i remember exactly the process,
also source this lib precision not easy to move i think ....
if you can resolve with other (printf or other stream flux) under compiler Intel same supposed existing by TimP, better for exactly answering that you want make.
Regards

cppcoder · ‎01-03-2011

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.

Thanks.

aazue · ‎01-03-2011

Hi
That I know , Is gnu compiler in Cygwin complete or with shorted Mingw package is an product have origin similar. I have an doubt that is existing
really an great difference performance between the two.

That I know also is with MPFR you can outing is formated correctly or greater that required for you.
Is object major your question.

I have supposing that you are locked this point
My answer is just for help you troubleshoot before you find better voice more academic , only, you not lose money with your time increased.
MPFR working compiled with VC (2010), the friends have proposed to move to me. but no interest for me (not need) or for you ,
as same you have wrote your answer to me. (inappropriate solution)
Regards

cppcoder · ‎01-03-2011

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.

vvittaldev · ‎04-23-2013

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.

SergeyKostrov · ‎04-25-2013

Let's say you have 2048-bit signed integer declared as a struct HUGEINT of 32 integers of __int64 type. How would you print that huge number? CRT-libraries convert an integer to a string using a simple loop ( look at _itoa-like functions ). That is, with for-loop, or while-loop, or do-while-loop.Something like: ... void HugeIntToString( HUGEINT hiV, char *szV, int iBase ) { ... while( true ) { ... chDigit = iNum % iBase; if( chDigit > 9 ) chDigit = ( char )( chDigit - 10 + 'A' ); else chDigit = ( char )( chDigit + '0' ); ... iNum = iNum / iBase; ... break; } ... }