COMPGROUPS.NET | Search | Post Question | Groups | Stream | About | Register

### Programming 64 bit windows?

• Email
• Follow

```What sizes will 'int' and 'long' be? Will 32-bit programs have to be
rewritten?

```
 0
Reply core99 (35) 10/13/2003 2:14:34 PM

See related articles to this posting

```machine99 wrote:
> What sizes will 'int' and 'long' be?

On 32-bit system variable can have 2^32 = 4294967296 different values.
On 64-bit system variable can have 2^64 = 18446744073709551616 different
values.

So if we are talking about 64-bit unsigned int, it would propably have
values from 0 - 18446744073709551615

According to standard, the long must be atleast as large as int, not
necessarily larger. It is up to compiler and platform whether it is
larger or not. AFAIK most of the 32-bit compilers on Windows deal int
and long both as 32-bit variables.

> Will 32-bit programs have to be
> rewritten?

Usually it should be enough if you just compile it again. On some cases
you might get better performance by writing some parts of the program
again, but that is quite rare. AFAIK 64-bit Windowses should have
emulation for 32-bit programs.

Imagine this:

int main()
{
int a = 10;
a++;
return 0;
}

As you can see, we only use int values 10 and 11. We are not even near
the limits of int, so this program will be as fine on 16,32 and 64 bit
systems. Only think that needs to be done is to re-compile it with
64-bit compiler.

So only if you are handling very large numbers, you might benefit from
re-writing the code.

```
 0
Reply spammerdream (179) 10/13/2003 2:41:40 PM

```In article <3f8ab342\$0\$9722\$edfadb0f@dread14.news.tele.dk>, "machine99" <core99@delite.dk> wrote:
>What sizes will 'int' and 'long' be? Will 32-bit programs have to be
>rewritten?

I suppose int will probably be 32 or 64 bits depending on what is
optimal for typical processors.  Don't really know, though.

32-bit programs will run normally, as 16-bit ones do now.

If you compile them in 64-bit they should compile without error unless
you are doing something very special.  Indeed, one shouldn't make any
assumptions about the size of int, though "at least as big as the
current value" may be somewhat forgiveable.

(16-bit Windows programs compile normally in 32-bit, in my experience -
and the jump from 16 to 32 was bigger, because a 32-bit pointer or array
is big enough for most purposes.)

The compiled .exe will be larger.

Gerry Quinn
--
http://bindweed.com
Kaleidoscopic Screensavers and Games for Windows
New screensaver: "Hypercurve"
```
 0
Reply gerryq2 (435) 10/13/2003 2:53:06 PM

```On Mon, 13 Oct 2003 16:14:34 +0200, machine99 wrote:

> What sizes will 'int' and 'long' be? Will 32-bit programs have to be
> rewritten?

int will be 32 bits still. I dont't remember about long. Pointers,
however, will be 64 bits.

Win32 programs probably won't have to be rewritten, but they won't be able
to use the 64-bit DLLs. To take advantage of whatever DLLs are available,
you'll probably have to take much more care than most Windows programmers
generally do (including the MSDN examples).

Josh
```
 0
Reply curien (113) 10/13/2003 3:28:54 PM

```On Mon, 13 Oct 2003, machine99 wrote:

> What sizes will 'int' and 'long' be? Will 32-bit programs have to be
> rewritten?

I code so that the sizae of int and long does not matter. If you need to
know what size int and long are or you code in such a way that they must
be a specific size then you will have to re-write your code for a
different architecture.

If you are talking about C or C++ there is a header file called
<limits.h> that contains macros you can use. If you code with these macros
and never assume the size of your data types then you just need to
recompile your data on the 64-bit platform to maek it work correctly.

--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vice.president@whitehouse.gov
```
 0
Reply darrell13 (403) 10/13/2003 3:52:53 PM

```In article <bmegct\$lqg97\$1@ID-179017.news.uni-berlin.de>, "osmium" <r124c4u102@comcast.net> wrote:
>Gerry Quinn writes:
>
>> The compiled .exe will be larger.
>
>Could you please post a paragraph or two on why that will be so?

I found 16-bit programs doubled in size when compiled in 32-bit.

I assume the reason is that function addresses, elements of parameter
lists and the like simply get bigger.  Someone said that ints will be 32
bits but pointers will be 64-bit.  Presumably a function that looks
like:

SomeFunction( int x, int* pY );

Now compiles into :

Place on stack, x               // place, 32-bit value
Place on stack, pY             // place, 32-bit pointer
Jump SomeFunction           // jump, 32-bit function offset

Will become:

Place on stack, x               // place, 32-bit value
Place on stack, pY             // place, 64-bit pointer
Jump SomeFunction           // jump, 64-bit function offset

The program grew by 64 bits.

I'm just guessing that stuff like that is what happens.

Gerry Quinn
--
http://bindweed.com
Kaleidoscopic Screensavers and Games for Windows
New screensaver: "Hypercurve"
```
 0
Reply gerryq2 (435) 10/13/2003 5:07:04 PM

```> Imagine this:
>
> int main()
> {
>    int a = 10;
>    a++;
>    return 0;
> }
>
> As you can see, we only use int values 10 and 11. We are not even near
> the limits of int, so this program will be as fine on 16,32 and 64 bit
> systems. Only think that needs to be done is to re-compile it with
> 64-bit compiler.
>
> So only if you are handling very large numbers, you might benefit from
> re-writing the code.

What about moving multiple 16 or 32 bit integers(in a struct) into a single
64 bit integer? Wouldn't there be a performance gain here?

```
 0
Reply core99 (35) 10/13/2003 5:08:48 PM

```On Mon, 13 Oct 2003 10:30:34 -0700, osmium wrote:

> Gerry Quinn writes:
>
>> The compiled .exe will be larger.
>
> Could you please post a paragraph or two on why that will be so?

The main reason is that some types will be 64 bits long
instead of 32 bits. That means they take more space to
store in the executable.

If we're talking about Opteron/Athlon 64 code, then another
reason is that there is a new prefix byte in the instruction
set used to access the 8 new registers. That will make the
average instruction size (and therefore the object code) a
little bit larger as well.

-Sheldon

```
 0
Reply sheldonsimms (452) 10/13/2003 5:08:59 PM

```> >> The compiled .exe will be larger.
> >
> > Could you please post a paragraph or two on why that will be so?
>
> The main reason is that some types will be 64 bits long
> instead of 32 bits. That means they take more space to
> store in the executable.
>
> If we're talking about Opteron/Athlon 64 code, then another
> reason is that there is a new prefix byte in the instruction
> set used to access the 8 new registers. That will make the
> average instruction size (and therefore the object code) a
> little bit larger as well.
>
> -Sheldon

You shouldn't happen to know if this also applies to the new Pentium 5 ?

```
 0
Reply core99 (35) 10/13/2003 5:14:30 PM

```Gerry Quinn writes:

> The compiled .exe will be larger.

Could you please post a paragraph or two on why that will be so?

```
 0
Reply r124c4u1022 (2303) 10/13/2003 5:30:34 PM

```On Mon, 13 Oct 2003 19:14:30 +0200, machine99 wrote:

>> >> The compiled .exe will be larger.
>> >
>> > Could you please post a paragraph or two on why that will be so?
>>
>> The main reason is that some types will be 64 bits long
>> instead of 32 bits. That means they take more space to
>> store in the executable.
>>
>> If we're talking about Opteron/Athlon 64 code, then another
>> reason is that there is a new prefix byte in the instruction
>> set used to access the 8 new registers. That will make the
>> average instruction size (and therefore the object code) a
>> little bit larger as well.
>>
>> -Sheldon
>
> You shouldn't happen to know if this also applies to the
> new Pentium 5 ?

The first part would be true for any 64-bit architecture.

The second part depends on whether or not the P5 has enabled
64-bit instructions and what they look like.

```
 0
Reply sheldonsimms (452) 10/13/2003 5:39:47 PM

```In article <bmeqnr\$lhgvl\$1@ID-179017.news.uni-berlin.de>, "osmium" <r124c4u102@comcast.net> wrote:
>Sheldon Simms writes:
>
>> On Mon, 13 Oct 2003 19:14:30 +0200, machine99 wrote:
>>
>> >> >> The compiled .exe will be larger.
>> >> >
>> >> > Could you please post a paragraph or two on why that will be so?
>> >>
>> >> The main reason is that some types will be 64 bits long
>> >> instead of 32 bits. That means they take more space to
>> >> store in the executable.
>
><clip second reason>
>
>> The first part would be true for any 64-bit architecture.
>
>And seems to apply to "programs" that, for some reason, amount to a massive
>amount of fiddling with constants.  I would expect a 100K program of the
>kind I write to increase by at most a 100 bytes from that source.  IOW, not
>worth mentioning.

Well, a couple of little Windows 3.1 games of mine doubled in size when
I compiled in 32-bit instead of 16-bit.

I'd say they were a good mixture of typical coding structures, with a
fair amount of Window API calls (via MFC).

Gerry Quinn
--
http://bindweed.com
Kaleidoscopic Screensavers and Games for Windows
New screensaver: "Hypercurve"
```
 0
Reply gerryq2 (435) 10/13/2003 6:38:34 PM

```"osmium" <r124c4u102@comcast.net> writes:

> Sheldon Simms writes:
>
> > On Mon, 13 Oct 2003 19:14:30 +0200, machine99 wrote:
> >
> > >> >> The compiled .exe will be larger.
> > >> >
> > >> > Could you please post a paragraph or two on why that will be so?
> > >>
> > >> The main reason is that some types will be 64 bits long
> > >> instead of 32 bits. That means they take more space to
> > >> store in the executable.
>
> <clip second reason>
>
> > The first part would be true for any 64-bit architecture.
>
> And seems to apply to "programs" that, for some reason, amount to a massive
> amount of fiddling with constants.  I would expect a 100K program of the
> kind I write to increase by at most a 100 bytes from that source.  IOW, not
> worth mentioning.

Do you use pointers?  The size of pointers will double from 32 to
64 bits.
--
"A computer is a state machine.
Threads are for people who cant [sic] program state machines."
--Alan Cox
```
 0
Reply blp (3955) 10/13/2003 7:24:22 PM

```Sheldon Simms writes:

> On Mon, 13 Oct 2003 19:14:30 +0200, machine99 wrote:
>
> >> >> The compiled .exe will be larger.
> >> >
> >> > Could you please post a paragraph or two on why that will be so?
> >>
> >> The main reason is that some types will be 64 bits long
> >> instead of 32 bits. That means they take more space to
> >> store in the executable.

<clip second reason>

> The first part would be true for any 64-bit architecture.

And seems to apply to "programs" that, for some reason, amount to a massive
amount of fiddling with constants.  I would expect a 100K program of the
kind I write to increase by at most a 100 bytes from that source.  IOW, not
worth mentioning.

```
 0
Reply r124c4u1022 (2303) 10/13/2003 8:25:59 PM

```On Mon, 13 Oct 2003 16:25:25 -0700, osmium wrote:

> Gerry Quinn writes:
>
>> Well, a couple of little Windows 3.1 games of mine doubled in size when
>> I compiled in 32-bit instead of 16-bit.
>>
>> I'd say they were a good mixture of typical coding structures, with a
>> fair amount of Window API calls (via MFC).
>
> 16-bit addresses epitomized the 640 KB problem. The address range is now 4
> GB which is large enough to address any RAM, even considering the US
> Government's authority to print money. There is no technical reason to
> double the size of pointers again.

Obviously, you're not a sysadmin of a modern, high-demand database. 8 or
16GB machines are not uncommon in certain domains, these days. If an
architecture does not advance, it will die.

Josh
```
 0
Reply curien (113) 10/13/2003 9:31:37 PM

```"osmium" <r124c4u102@comcast.net> writes:

> 16-bit addresses epitomized the 640 KB problem. The address range is now 4
> GB which is large enough to address any RAM, even considering the US
> Government's authority to print money. There is no technical reason to
> double the size of pointers again.

4 GB of RAM can be had for under \$500, which is hardly a huge
sum.
--
Anyone who cannot cope with mathematics is not fully human.  At best he
is a tolerable subhuman who has learned to wear shoes, bathe and not
make messes in the house.
-- Lazarus Long, "Time Enough for Love"
```
 0
Reply blp (3955) 10/13/2003 9:43:12 PM

```Gerry Quinn writes:

> Well, a couple of little Windows 3.1 games of mine doubled in size when
> I compiled in 32-bit instead of 16-bit.
>
> I'd say they were a good mixture of typical coding structures, with a
> fair amount of Window API calls (via MFC).

16-bit addresses epitomized the 640 KB problem. The address range is now 4
GB which is large enough to address any RAM, even considering the US
Government's authority to print money. There is no technical reason to
double the size of pointers again.

```
 0
Reply r124c4u1022 (2303) 10/13/2003 11:25:25 PM

```machine99 wrote:

> What about moving multiple 16 or 32 bit integers(in a struct) into a single
> 64 bit integer? Wouldn't there be a performance gain here?

There might be a slight performance gain. Depending on what you do with
them. Just accessing two variables instead of one, one time in a program
run, is not slow.

It is not slow if you do some small calculations once in your program.
If you do that thousands and millions of time, for example in a loop.
Then you might get some delay to your program and you might gain from
64-bit integers, but only if you can use 1 variable to handle 2 or more
old variables. This is quite rare on 32-bit programs.

```
 0
Reply spammerdream (179) 10/14/2003 5:19:55 AM

```osmium wrote:

> 16-bit addresses epitomized the 640 KB problem. The address range is now 4
> GB which is large enough to address any RAM,

Do you want to repeat the history?

"640k of RAM should be enough for anyone" - Bill Gates

```
 0
Reply spammerdream (179) 10/14/2003 5:38:43 AM

```In article <%HLib.13\$Nf3.3@read3.inet.fi>, Aggro <spammerdream@yahoo.com> wrote:
>machine99 wrote:
>
>> What about moving multiple 16 or 32 bit integers(in a struct) into a single
>> 64 bit integer? Wouldn't there be a performance gain here?
>
>There might be a slight performance gain. Depending on what you do with
>them. Just accessing two variables instead of one, one time in a program
>run, is not slow.
>
>It is not slow if you do some small calculations once in your program.
>If you do that thousands and millions of time, for example in a loop.
>Then you might get some delay to your program and you might gain from
>64-bit integers, but only if you can use 1 variable to handle 2 or more
>old variables. This is quite rare on 32-bit programs.

Not rare at all, when you consider that multiple boolean flags are
frequently shoved into a single integer type.

Gerry Quinn
--
http://bindweed.com
Kaleidoscopic Screensavers and Games for Windows
New screensaver: "Hypercurve"
```
 0
Reply gerryq2 (435) 10/14/2003 9:32:35 AM

```osmium wrote:

>> "640k of RAM should be enough for anyone" - Bill Gates
>
> Good point.  But just because a bunch of writers dubbed something
> as "Moore's Law" as a law does not *make* it a law.  In fact, it
> is just a clever saying.  There are problems imposed by the
> wavelength of light.  And we could double the address range by
> adding a single bit, not 32 bits.

Agreed!  Seems like a good time to bring back a little exploring
Richard Heathfield and I did a while back when a certain poster
claimed that even with 64-bit addressing, discs would still fill

Turns out the numbers are a little suprising.... (see below for a
little "program" showing all the input assumptions and calculations).
Basicially, we figured an outrageously long and hi-fi movie, no
the disk, not sectors or clusters!) and a tasty download speed of
100MBits.  Even so:

Movie size (bytes):   70,406,492,913,664
Movies per Huge-Disk: 262,003
Years to Fill Disk:   46,658

Puts 64 bits into some sort of perspective, doesn't it....

disk_size           = (2 ** 64)
bits_per_sec        = 100000000
bits_per_byte       = 8
frames_per_sec      = 32
audio_freq          = 96000
bits_per_channel    = 24
nbr_channels        = 8
pixels              = 8192 * 4096
bytes_per_pixel     = 4
running_time        = 16384
long_movie          = 238 * 60
seconds_per_day     = 24 * 60 * 60
days_per_year       = 365

bytes_per_sec       = bits_per_sec / bits_per_byte
frame_bytes         = pixels * bytes_per_pixel
audio_sample_bits   = audio_freq * nbr_channels * bits_per_channel
audio_sample_bytes  = audio_sample_bits / bits_per_byte

movie_video_bytes   = running_time * frame_bytes * frames_per_sec
movie_audio_bytes   = running_time * audio_sample_bytes
movie_bytes         = movie_video_bytes + movie_audio_bytes

movies_per_disk = disk_size / movie_bytes

print "Movie size (bytes):   %s" movie_bytes
print "Movies per Huge-Disk: %s" movies_per_disk
print "Years to Fill Disk:   %s" disk_fill_time

end

--
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|
```
 0
Reply Chris7 (2511) 10/14/2003 3:15:55 PM

```Aggro writes:

> osmium wrote:
>
> > 16-bit addresses epitomized the 640 KB problem. The address range is now
4
> > GB which is large enough to address any RAM,
>
> Do you want to repeat the history?
>
> "640k of RAM should be enough for anyone" - Bill Gates

Good point.  But just because a bunch of writers dubbed something as
"Moore's Law" as a law does not *make* it a law.  In fact, it is just a
clever saying.  There are problems imposed by the wavelength of light.  And
we could double the address range by adding a single bit, not 32 bits.  Is a
5-byte address an outrageous idea in a world of 7-bit bytes? Or, more
likely, a little OS cooperation in the matter?

I shudder to think of a tree with 64-bit addresses and a measly billion or
so leafs on the tree.

```
 0
Reply r124c4u1022 (2303) 10/14/2003 3:17:37 PM

```On Tue, 14 Oct 2003 08:17:37 -0700, osmium wrote:

> Aggro writes:
>
>> osmium wrote:
>>
>> > 16-bit addresses epitomized the 640 KB problem. The address range is now
> 4
>> > GB which is large enough to address any RAM,
>>
>> Do you want to repeat the history?
>>
>> "640k of RAM should be enough for anyone" - Bill Gates
>
> Good point.  But just because a bunch of writers dubbed something as
> "Moore's Law" as a law does not *make* it a law.  In fact, it is just a
> clever saying.  There are problems imposed by the wavelength of light.  And
> we could double the address range by adding a single bit, not 32 bits.  Is a
> 5-byte address an outrageous idea in a world of 7-bit bytes? Or, more
> likely, a little OS cooperation in the matter?

Hardware and compatibility constraints prevent things like 7-bit bytes
and 35 (or even 40) bit addresses. Imagine all of the "well-written"
programs that would toss their cookies when they could suddenly no
longer store the value 128 in a byte. Imagine trying to convince
everyone in the world that they don't really need x86 compatibility
if they just throw away their entire install software base and buy
everything new.

> I shudder to think of a tree with 64-bit addresses and a measly
> billion or so leafs on the tree.

What's the big deal? Such a tree would use at most twice the
memory of the same tree constructed with 32 bit pointers (which
that would be impossible, by the way). What's so awful about that?

```
 0
Reply sheldonsimms (452) 10/14/2003 6:57:41 PM

```On Tue, 14 Oct 2003, osmium wrote:
>
> Sheldon Simms writes:
> [osmium wrote:]
> >>  And we could double the address range by adding a single bit, not
> >> 32 bits. Is a 5-byte address an outrageous idea in a world of 7-bit
> >> bytes? Or, more likely, a little OS cooperation in the matter?
> >
> > Hardware and compatibility constraints prevent things like 7-bit bytes
> > and 35 (or even 40) bit addresses. Imagine all of the "well-written"
> > programs that would toss their cookies when they could suddenly no
> > longer store the value 128 in a byte. Imagine trying to convince
> > everyone in the world that they don't really need x86 compatibility
> > if they just throw away their entire install software base and buy
> > everything new.
>
> I meant to say 7-bit characters.

Does that change Sheldon's point at all?  What *exactly* do you mean
using the eighth bit for parity checking or something?  What happens
when 35 bits isn't enough anymore?  Do we re-model all our software
again?

Much easier to continue the doubling trend -- old machines can handle
doublewords pretty easily, but going to 3- or 5-byte words would be
a jump something on the order of returning to decimal computing.
Modern architectures just don't work that way.

> > > I shudder to think of a tree with 64-bit addresses and a measly
> > > billion or so leafs on the tree.
> >
> > What's the big deal? Such a tree would use at most twice the
> > memory of the same tree constructed with 32 bit pointers (which
> > that would be impossible, by the way). What's so awful about that?
>
> If you think a doubling is towards the trivial end of things, think of
> what life would be like if the population of the planet were doubled.
> How about if your salary were simply cut in half?  Would you quibble?

If the population of the planet doubled [which it will, sooner or later,
if it doesn't get halved before then], and our computers didn't have
enough memory to handle that doubling, *then* who'd be quibbling? ;-)

My \$.02,
-Arthur
```
 0
Reply ajo (1601) 10/14/2003 7:46:50 PM

```Programmer Dude wrote:

> And for some serious extremism (and since I'm testing a little
> "big int" class), ever wondered how high you can count with a
> mere 8192 "doublings"?  Here's how high:
>
<snip>
>
> (2,467 digits!)
>
> Anyone able to validate the input for me??

Yes, to the very last digit. Either that, or we have remarkably similar bugs
in our bignum libs.

--
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
```
 0
Reply dontmail (1885) 10/14/2003 9:23:40 PM

```Sheldon Simms writes:

>>  And
> > we could double the address range by adding a single bit, not 32 bits.
Is a
> > 5-byte address an outrageous idea in a world of 7-bit bytes? Or, more
> > likely, a little OS cooperation in the matter?
>
> Hardware and compatibility constraints prevent things like 7-bit bytes
> and 35 (or even 40) bit addresses. Imagine all of the "well-written"
> programs that would toss their cookies when they could suddenly no
> longer store the value 128 in a byte. Imagine trying to convince
> everyone in the world that they don't really need x86 compatibility
> if they just throw away their entire install software base and buy
> everything new.

I meant to say 7-bit characters.

> > I shudder to think of a tree with 64-bit addresses and a measly
> > billion or so leafs on the tree.
>
> What's the big deal? Such a tree would use at most twice the
> memory of the same tree constructed with 32 bit pointers (which
> that would be impossible, by the way). What's so awful about that?

If you think a doubling is towards the trivial end of things, think of what
life would be like if the population of the planet were doubled.   How about
if your salary were simply cut in half?  Would you quibble?

```
 0
Reply r124c4u1022 (2303) 10/14/2003 9:36:19 PM

```On Tue, 14 Oct 2003 10:15:55 -0500, Programmer Dude wrote:

> osmium wrote:
>
>>> "640k of RAM should be enough for anyone" - Bill Gates
>>
>> Good point.  But just because a bunch of writers dubbed something
>> as "Moore's Law" as a law does not *make* it a law.  In fact, it
>> is just a clever saying.  There are problems imposed by the
>> wavelength of light.  And we could double the address range by
>> adding a single bit, not 32 bits.
>
> Agreed!  Seems like a good time to bring back a little exploring
> Richard Heathfield and I did a while back when a certain poster
> claimed that even with 64-bit addressing, discs would still fill

memory grows exponentially. However, disk capacity grows with the /square/
of the linear bit density of the platter.

Josh
```
 0
Reply curien (113) 10/14/2003 10:14:02 PM

```On Tue, 14 Oct 2003 14:36:19 -0700, osmium wrote:

> Sheldon Simms writes:
>
>> What's the big deal? Such a tree would use at most twice the
>> memory of the same tree constructed with 32 bit pointers (which
>> that would be impossible, by the way). What's so awful about that?
>
> If you think a doubling is towards the trivial end of things, think of what
> life would be like if the population of the planet were doubled.

It depends on where the extra people went, but I don't think it
would be much of a problem.

> How about if your salary were simply cut in half?  Would you quibble?

Hmmm. Half of zero is zero.

>> > I shudder to think of a tree with 64-bit addresses and a measly
>> > billion or so leafs on the tree.

The point you are missing is that the actual increased costs of
of 32 bit pointers is approximately \$2000 right now. By the time
the average user needs that much memory (32Gb) the price will
be about 1/10 that. So who cares?

```
 0
Reply sheldonsimms (452) 10/14/2003 10:52:27 PM

```Programmer Dude <Chris@Sonnack.com> wrote:

> And for some serious extremism (and since I'm testing a little
> "big int" class), ever wondered how high you can count with a
> mere 8192 "doublings"?  Here's how high:
>
> 1090748135619415929462984244733782862448264161996232692431832786189721
<snip>
> 05665475715792896
>
> (2,467 digits!)
>
> I confess to being somewhat in awe of having written something that
> just calculated and spit out that number... ;-\
>
> Anyone able to validate the input for me??

Python 2.2.2 agrees with you:

>>> x = 1090748135619415929462984244733...61997186505665475715792896L
>>> y = 2L**8192L
>>> x == y
1

--
Kevin Reid
```
 0
Reply kpreid (15) 10/14/2003 10:57:27 PM

```Richard Heathfield wrote:
>
> Programmer Dude wrote:
>
> > And for some serious extremism (and since I'm testing a little
> > "big int" class), ever wondered how high you can count with a
> > mere 8192 "doublings"?  Here's how high:
> >
> <snip>
> >
> > (2,467 digits!)
> >
> > Anyone able to validate the input for me??
>
> Yes, to the very last digit. Either that, or we have remarkably similar bugs
> in our bignum libs.
>
> --
> Richard Heathfield : binary@eton.powernet.co.uk
> "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> K&R answers, C books, etc: http://users.powernet.co.uk/eton

Classsic rexx too (without bignum).
```
 0
Reply wolfgang.riedel (50) 10/15/2003 10:04:07 AM

```Wolfgang Riedel <wolfgang.riedel@development.retarus.de> wrote in message news:<3F8D1B97.5398DC62@development.retarus.de>...
> Richard Heathfield wrote:
> >
> > Programmer Dude wrote:
> >
> > > And for some serious extremism (and since I'm testing a little
> > > "big int" class), ever wondered how high you can count with a
> > > mere 8192 "doublings"?  Here's how high:
> > >
>  <snip>
> > >
> > > (2,467 digits!)
> > >
> > > Anyone able to validate the input for me??
> >
> > Yes, to the very last digit. Either that, or we have remarkably similar bugs
> > in our bignum libs.
> >
> > --
> > Richard Heathfield : binary@eton.powernet.co.uk
> > "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> > C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> > K&R answers, C books, etc: http://users.powernet.co.uk/eton
>
> Classsic rexx too (without bignum).

Well, it's nice to know that you guys can get the right answer the
hard way, but:

log(2)*8192

yields the answer rather more quickly.  (Base ten log, of course,
since we're talking about decimal digits).
```
 0
Reply robertwessel2 (1674) 10/15/2003 9:06:10 PM

```Robert Wessel writes:

> Well, it's nice to know that you guys can get the right answer the
> hard way, but:
>
>   log(2)*8192
>
> yields the answer rather more quickly.  (Base ten log, of course,
> since we're talking about decimal digits).

But what?  Are you suggesting that this yields the right answer? If so, post
the program so we can test it.

```
 0
Reply r124c4u1022 (2303) 10/15/2003 11:44:38 PM

```Robert Wessel wrote:

> Well, it's nice to know that you guys can get the right answer the
> hard way, but:
>
>   log(2)*8192
>
> yields the answer rather more quickly.  (Base ten log, of course,
> since we're talking about decimal digits).

That tells you the number of digits, not the actual result of 2 to the power
8192. This may be my fault - I snipped Chris's result in the interests of
brevity, leaving only the digit count behind, and that may have misled you.
If so, my apologies.

--
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
```
 0
Reply dontmail (1885) 10/16/2003 12:01:08 AM

```"osmium" <r124c4u102@comcast.net> wrote in message news:<bmkf4l\$oci5o\$1@ID-179017.news.uni-berlin.de>...
> Robert Wessel writes:
>
> > Well, it's nice to know that you guys can get the right answer the
> > hard way, but:
> >
> >   log(2)*8192
> >
> > yields the answer rather more quickly.  (Base ten log, of course,
> > since we're talking about decimal digits).
>
> But what?  Are you suggesting that this yields the right answer? If so, post
> the program so we can test it.

remove calculator from pocket
turn on
if (calculator is RPN)
{
type "2"
press enter
press log-base-10 key
type "8192"
press enter
press multiply key
}
else
{
type "2"
press log-base-10 key
press multiply key
type "8192"
press equals key
}
```
 0
Reply robertwessel2 (1674) 10/16/2003 12:56:13 AM

```Robert Wessel wrote:
>
> "osmium" <r124c4u102@comcast.net> wrote in message news:<bmkf4l\$oci5o\$1@ID-179017.news.uni-berlin.de>...
> > Robert Wessel writes:
> >
> > > Well, it's nice to know that you guys can get the right answer the
> > > hard way, but:
> > >
> > >   log(2)*8192
> > >
> > > yields the answer rather more quickly.  (Base ten log, of course,
> > > since we're talking about decimal digits).
> >
> > But what?  Are you suggesting that this yields the right answer? If so, post
> > the program so we can test it.
>
> remove calculator from pocket
> turn on
> if (calculator is RPN)
>     {
>     type "2"
>     press enter
>     press log-base-10 key
>     type "8192"
>     press enter
>     press multiply key
>     }
> else
>     {
>     type "2"
>     press log-base-10 key
>     press multiply key
>     type "8192"
>     press equals key
>     }

_this_ is more quickly (,and precise) (,and any fun)?

on a Pentium K6-3/300:
it took 0.530000 seconds to calculate,
the length of 2 ** 8192 is 2467

Wolfgang
```
 0
Reply wolfgang.riedel (50) 10/16/2003 10:36:58 AM

```Robert wrote:
) remove calculator from pocket
) turn on
) if (calculator is RPN)
)     {
)     type "2"
)     press enter
)     press log-base-10 key
)     type "8192"
)     press enter
)     press multiply key
)     }
) else
)     {
)     type "2"
)     press log-base-10 key
)     press multiply key
)     type "8192"
)     press equals key
)     }

I find:

echo "2 8192 ^ p" | dc

To be a bit more precise.  And rather quick at that.

SaSW, Willem (at stack dot nl)
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
```
 0
Reply willem (1478) 10/16/2003 10:43:59 AM

```Richard Heathfield wrote:

>> Anyone able to validate the input for me??
>
> Yes, to the very last digit. Either that, or we have remarkably
> similar bugs in our bignum libs.

Wouldn't THAT be something!  (Thanks!!)

--
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|
```
 0
Reply Chris7 (2511) 10/16/2003 8:01:00 PM

```Wolfgang Riedel wrote:

>>> Anyone able to validate the input for me??
>>
>> Yes,...
>
> Classsic rexx too (without bignum).

That's two!  (Thank you, too!!)

--
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|
```
 0
Reply Chris7 (2511) 10/16/2003 8:02:27 PM

```Kevin Reid wrote:

>> Anyone able to validate the input for me??
>
> Python 2.2.2 agrees with you:
>
>   >>> x = 1090748135619415929462984244733...61997186505665475715792896L
>   >>> y = 2L**8192L
>   >>> x == y
>   1

Three!  (Thank Thee!!)

--
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|
```
 0
Reply Chris7 (2511) 10/16/2003 8:03:06 PM

38 Replies
42 Views

Similar Articles

12/5/2013 2:11:36 AM
page loaded in 29346 ms. (0)