Only if you are printing it out incorrectly. Are you using %lld? It should be able to take you up to 7540113804746346429 before it wraps around. It can go one iteration higher if you make it unsigned.same result
Only if you are printing it out incorrectly. Are you using %lld? It should be able to take you up to 7540113804746346429 before it wraps around. It can go one iteration higher if you make it unsigned.same result
I'm again going to suggest you use GMP.yes, windows and gcc
%I64d yields the same result as %lld, which does work as it should, but still has the limit about the 92 iteration before it begins bouncing pos/neg.
bithub: can you please post a link for GMP use?
Use the Windows fork.
the windows fork is nothing but linux installation instructions, no use at all...
Maybe you should choose a different hobby -- programming does not seem to suite you. It took me about 15 seconds to find the Windows instructions:
MS-DOS and MS Windows
On an MS-DOS system DJGPP can be used to build MPIR, and on an MS Windows
system Cygwin, DJGPP and MINGW can all be used. All three are excellent ports
of GCC and the various GNU tools.
Cygwin Information and Installation
DJGPP
MinGW | Minimalist GNU for Windows
In addition, project les for MSVC are provided, allowing MPIR to build on Microsoft's
compiler. This support is provided by Brian Gladman.
Microsoft also publishes an Interix \Services for Unix" which can be used to build
MPIR on Windows (with a normal `./configure'), but it's not free software.
MS Windows DLLs
On systems `*-*-cygwin*', `*-*-mingw*' and `*-*-pw32*' by default MPIR builds
only a static library, but a DLL can be built instead using
./configure --disable-static --enable-shared
Static and DLL libraries can't both be built, since certain export directives in
`mpir.h' must be dierent.
A MINGW DLL build of MPIR can be used with Microsoft C. Libtool doesn't
install a `.lib' format import library, but it can be created with MS lib as follows,
and copied to the install directory. Similarly for `libmp' and `libmpirxx'.
cd .libs
lib /def:libgmp-3.dll.def /out:libgmp-3.lib
MINGW uses the C runtime library `msvcrt.dll' for I/O, so applications wanting
to use the MPIR I/O routines must be compiled with `cl /MD' to do the same. If
one of the other C runtime library choices provided by MS C is desired then the
suggestion is to use the MPIR string functions and conne I/O to the application.
I've written two articles that explain your problem: Print Precision of Dyadic Fractions Varies by Language - Exploring Binary and
Print Precision of Floating-Point Integers Varies Too - Exploring Binary .
What's happening is that your compiler is not printing enough digits. Surprisingly, compilers vary in how many they print.
Look at bithub's gcc output and notice that he gets more digits than you.
(BTW, I get the same "truncated" results that you get when I run your code on Visual C++.)
P.S. Those articles I cited only explain why you see trailing 0s and not "garbage digits." You still have the problem that your values are larger than what a double can hold accurately. Try long longs or GMP as others have suggested.
Last edited by DoctorBinary; 07-30-2009 at 08:40 PM. Reason: Added P.S. at bottom
I've used long long, and it still cant get past the 93rd iteration of the sequence.
Cycles 90 to 100 using long long and %lld
Code:2880067194370816120 4660046610375530309 7540113804746346429 -624658365858767487 1293530146158671551 -495305351242900332 -365952336627033177 -861257687869933510 6174643828739884737 -243793304995945036 3736710778780434371
modifying my code by adding the following line
following the second print statement, the new output is showing every number only being allotted 8 bytes, which although correct, does not explain why the display is stopping at 16 digits and buffering the rest with zeros. Changing the coding from double to long double changes this to 12 bytes as expected, however the printf is still only showing 16 digits, then zeros to the decimal point again. Does anyone have any further suggestions?Code:printf( "%d\n", sizeof(y));
Windows does not have the capability to print a long double, as a search on this very board would have shown you. You can print the mantissa and exponent yourself if you want.
At this point you should probably just write your own 16-byte bignum class and be done with it.