From an article about implementing a C99 to C90 translator...

How does someone use integer arithmetic of at least 64 bits, and write in 
pure C90?

As I understand C90 (the standard is very elusive), long int is guaranteed 
to be at least 32 bits only.

So, do people rely on their known compiler limits, use clunky emulations, or 
do not bother with 64 bits when writing ultra-portable code?

-- 
 Bart

On Sun, 06 Apr 2008 15:37:28 +0000, Bartc wrote:
> From an article about implementing a C99 to C90 translator...
> 
> How does someone use integer arithmetic of at least 64 bits, and write
> in pure C90?
> 
> As I understand C90 (the standard is very elusive), long int is
> guaranteed to be at least 32 bits only.

Correct. And as long int is the widest type, C90 does not guarantee the 
presence of any 64-bit integer type.

> So, do people rely on their known compiler limits, use clunky
> emulations, or do not bother with 64 bits when writing ultra-portable
> code?

People do whatever works best for their situation. Sometimes, that may 
involve redefining the problem to fit 32-bit arithmetic (or floating-
point). Sometimes, that may be to rely on long being 64 bits. Sometimes, 
that may be to use implementation extensions. In any case, it's very much 
the same as how C90 programs have to deal with complex arithmetic. The 
language and library don't provide any possibility, so portable programs 
have no choice but to implement it themselves.

Bartc wrote:
> From an article about implementing a C99 to C90 translator...
> 

Interesting interesting.

And when you are going to do a C89 to K&R translator?


> How does someone use integer arithmetic of at least 64 bits, and write in 
> pure C90?
> 

There is no 64 bit arithmetic in C89. And you will have to do it
yourself!

(It is really easy. You just write it in C89. Not very difficult)

You translate

long long a,b,c;

....

b = (a+b)/(5+c);

by

assign64(div64(sum64(a,b),sum64(5,c)),&b);

You define
struct INT64{long hipart;long lowpart;};

and there you go!

Since you are doing a translator, nobody cares about how
difficult is to write the resulting code, or how readable it is!


> As I understand C90 (the standard is very elusive), long int is guaranteed 
> to be at least 32 bits only.
> 
> So, do people rely on their known compiler limits, use clunky emulations, or 
> do not bother with 64 bits when writing ultra-portable code?
> 


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

On Sun, 06 Apr 2008 15:37:28 GMT, "Bartc" <bc@freeuk.com> wrote:

>From an article about implementing a C99 to C90 translator...
>
>How does someone use integer arithmetic of at least 64 bits, and write in 
>pure C90?
>
>As I understand C90 (the standard is very elusive), long int is guaranteed 
>to be at least 32 bits only.
>
>So, do people rely on their known compiler limits, use clunky emulations, or 
>do not bother with 64 bits when writing ultra-portable code?

Many use a "big number library" that simulates arithmetic on very wide
integers.  I think Richard Heathfield put one on the web and google
can probably find you others.


Remove del for email

Barry Schwarz wrote:
> On Sun, 06 Apr 2008 15:37:28 GMT, "Bartc" <bc@freeuk.com> wrote:
> 
>>From an article about implementing a C99 to C90 translator...
>> How does someone use integer arithmetic of at least 64 bits, and write in 
>> pure C90?
>>
>> As I understand C90 (the standard is very elusive), long int is guaranteed 
>> to be at least 32 bits only.
>>
>> So, do people rely on their known compiler limits, use clunky emulations, or 
>> do not bother with 64 bits when writing ultra-portable code?
> 
> Many use a "big number library" that simulates arithmetic on very wide
> integers.  I think Richard Heathfield put one on the web and google
> can probably find you others.
> 
> 
> Remove del for email

That GUARANTEES that the software will run VERY slowly using
ALL the CPU for nothing. Heathfield's big numbers use characters
as the base representation.


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Barry Schwarz said:

<snip>

> Many use a "big number library" that simulates arithmetic on very wide
> integers.

Right.

> I think Richard Heathfield put one on the web

Actually, no, I haven't. I've got one, but I haven't published it.

As Mr Navia notes elsethread, it uses an array of unsigned char to store 
the data. He seems to think that this "GUARANTEES that the software will 
run VERY slowly using ALL the CPU for nothing". It doesn't, of course. 
Nevertheless, performance was not my highest priority. Those who want a 
super-fast bignum library would be well advised to use GMP or Miracl.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

jacob navia <jacob@nospam.com> writes:
> Bartc wrote:
>> From an article about implementing a C99 to C90 translator...
>>
>
> Interesting interesting.
>
> And when you are going to do a C89 to K&R translator?

It's been done; google "ansi2knr".  Though as I recall it's not a
complete translator; mostly it converts prototypes to old-style
function declarations.

The point, of course, is that a C89 to K&R translator, though it was
quite useful years ago, is no longer of much interest today, since the
C89 standard is almost universally supported (it would be difficult to
find a platform that has a K&R compiler but no C89 compiler).  This is
not yet the case for C99, a fact that you insist on ignoring, even
though your own lcc-win doesn't support the full language.

A C99 compiler that uses C89 as its intermediate language might be a
very useful thing.  If it managed to generate portable C89 code, it
could even permit the use of C99 on platforms where no C99 compiler
yet exists (something I would think you'd welcome).

I suspect that modifying an existing C89 compiler to handle C99 would
be easier than writing a complete translator (but the latter would
potentially only have to be done once for all target platforms).

> > How does someone use integer arithmetic of at least 64 bits, and
> > write in pure C90?
>
> There is no 64 bit arithmetic in C89. And you will have to do it
> yourself!

Yes, that's probably one of the more difficult aspects of translating
C99 to C89.  A quibble, though: C89 has no *guaranteed* 64-bit
arithmetic; it's perfectly legal to make long 64 bits.

-- 
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Richard Heathfield wrote:
> Barry Schwarz said:
> 
> <snip>
> 
>> Many use a "big number library" that simulates arithmetic on very wide
>> integers.
> 
> Right.
> 
>> I think Richard Heathfield put one on the web
> 
> Actually, no, I haven't. I've got one, but I haven't published it.
> 
> As Mr Navia notes elsethread, it uses an array of unsigned char to store 
> the data. He seems to think that this "GUARANTEES that the software will 
> run VERY slowly using ALL the CPU for nothing". It doesn't, of course. 
> Nevertheless, performance was not my highest priority. Those who want a 
> super-fast bignum library would be well advised to use GMP or Miracl.
> 

Using a char to store bignum data is like using a scooter to
move a 38 ton trailer.

It will work of course, and the 38 ton trailer will have a cruising
speed of several centimeters/hour...

Who cares?

That solution is PORTABLE. You can carry a scooter anywhere, they
are standard solutions, etc.


Portability means very often that you make mediocre software
that runs anywhere because it never uses the hardware/OS to
its maximum possibilities but just uses the least common
denominator of each one.

This is fine if you do not care about usability or similar problems.
GUIs?

Not portable. The command line is portable. Use the command line

Network?
Not portable...

Etc.

But this is more a philosophical question. Heathfield's viewpoint
is perfectly acceptable if you say:

Usability is less valuable than portability.
As he said, performance wasn't a concern for his software.
Portability was.

Result?

A mediocre but perfectly portable software.



-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia <jacob@nospam.com> writes:

> Richard Heathfield wrote:
>> Barry Schwarz said:
>>
>> <snip>
>>
>>> Many use a "big number library" that simulates arithmetic on very wide
>>> integers.
>>
>> Right.
>>
>>> I think Richard Heathfield put one on the web
>>
>> Actually, no, I haven't. I've got one, but I haven't published it.
>>
>> As Mr Navia notes elsethread, it uses an array of unsigned char to
>> store the data. He seems to think that this "GUARANTEES that the
>> software will run VERY slowly using ALL the CPU for nothing". It
>> doesn't, of course. Nevertheless, performance was not my highest
>> priority. Those who want a super-fast bignum library would be well
>> advised to use GMP or Miracl.
>>
>
> Using a char to store bignum data is like using a scooter to
> move a 38 ton trailer.
>
> It will work of course, and the 38 ton trailer will have a cruising
> speed of several centimeters/hour...
>
> Who cares?
>
> That solution is PORTABLE. You can carry a scooter anywhere, they
> are standard solutions, etc.
>
>
> Portability means very often that you make mediocre software
> that runs anywhere because it never uses the hardware/OS to
> its maximum possibilities but just uses the least common
> denominator of each one.
>
> This is fine if you do not care about usability or similar problems.
> GUIs?
>
> Not portable. The command line is portable. Use the command line
>
> Network?
> Not portable...
>
> Etc.
>
> But this is more a philosophical question. Heathfield's viewpoint
> is perfectly acceptable if you say:
>
> Usability is less valuable than portability.
> As he said, performance wasn't a concern for his software.
> Portability was.
>
> Result?
>
> A mediocre but perfectly portable software.

And guess what? Most of the blowhards in this group write SW which never
gets ported anywhere anyway.

Richard wrote:

> And guess what? Most of the blowhards in this group write SW which never
> gets ported anywhere anyway.

Umm - before you make a statement like that you might want to
check with some of those blowhards who make some of their C
source code available for free download...

....and on the other hand, you might prefer to not know.

;-)

-- 
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto/

Richard wrote, On 06/04/08 19:41:
> jacob navia <jacob@nospam.com> writes:
> 
>> Richard Heathfield wrote:

<snip>

>> But this is more a philosophical question. Heathfield's viewpoint
>> is perfectly acceptable if you say:
>>
>> Usability is less valuable than portability.
>> As he said, performance wasn't a concern for his software.
>> Portability was.
>>
>> Result?
>>
>> A mediocre but perfectly portable software.

Richard has on more than one occasion explicitly recommended using other 
bignum libraries if you want one with high performance. He even provided 
such recommendations in the post you responded to. Of course, a library 
that is not fully portable can (and if performance is the aim should) 
make use of non-portable tricks to get all the performance it can, 
possibly including conditional use of in-line assembler.

> And guess what? Most of the blowhards in this group write SW which never
> gets ported anywhere anyway.

Where is your proof that people have been lying when they have been 
talking about the porting of their SW that occurs in real life?
-- 
Flash Gordon

"Bartc" <bc@freeuk.com> wrote in message 
news:Y66Kj.3256$yD2.2536@text.news.virginmedia.com...
> From an article about implementing a C99 to C90 translator...
>
> How does someone use integer arithmetic of at least 64 bits, and write in 
> pure C90?
>
> As I understand C90 (the standard is very elusive), long int is guaranteed 
> to be at least 32 bits only.
>
> So, do people rely on their known compiler limits, use clunky emulations, 
> or do not bother with 64 bits when writing ultra-portable code?

OK, so for this to be practical, such a translator needs to know the 
capabilities of a C90 installation. If it has 64+ bit ints, then use them, 
otherwise make other arrangements. A pure translator would be of academic 
interest only.

Attend to 1000 other details and such a translator may be feasible.

(Note: I am not creating such a software, just interested in the issues.)

-- 
Bart 

Bartc wrote:
> OK, so for this to be practical, such a translator needs to know the 
> capabilities of a C90 installation. If it has 64+ bit ints, then use them, 
> otherwise make other arrangements. A pure translator would be of academic 
> interest only.
> 
> Attend to 1000 other details and such a translator may be feasible.
> 
> (Note: I am not creating such a software, just interested in the issues.)
> 


The bad news is that you will need:

o alloca() for implementing VLA arrays.
o a complex math library
o a 64 bit library
o Your own printf/scanf/ versions
o Many math library functions like remquo(), erf() lgamma()
   and several others
o You will have to implement fexxx() functions (floating point
   environment manipulating functions).
   This needs to be done in assembly for the most part.
o You will need a C99 parser


The good news is that I can sell you all of the above for several 
popular OSes :-)


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia <jacob@nospam.com> writes:
> Bartc wrote:
>> OK, so for this to be practical, such a translator needs to know the
>> capabilities of a C90 installation. If it has 64+ bit ints, then use
>> them, otherwise make other arrangements. A pure translator would be
>> of academic interest only.
>>
>> Attend to 1000 other details and such a translator may be feasible.
>>
>> (Note: I am not creating such a software, just interested in the issues.)
>>
>
>
> The bad news is that you will need:
>
> o alloca() for implementing VLA arrays.
[snip]

No, the usual behavior of alloca() (space is deallocated on return
from the calling function) is incompatible with the requirements for
VLAs.  For example, given this:

    for (int i = 1; i <= 1000; i ++) {
        int vla[i];
        // ...
    }

an alloca-based implementation would allocate space for all 1000
instances of ``vla'' before deallocating any of them.  I suppose you
could argue that the standard doesn't actually require that the
storage be physically deallocated on leaving the object's scope, but
it would be a seriously flawed implementation.

If you have an alloca()-like function that frees the storage on exit
from the scope, then that's not a problem (though it wouldn't satisfy
the usual, somewhat informal, requirements for alloca()).

(Didn't we discuss this just recently?)

-- 
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Flash Gordon said:

<snip>

> Richard has on more than one occasion explicitly recommended using other
> bignum libraries if you want one with high performance.

Right. In fact, I explicitly recommend using other bignum libraries even if 
you *don't* care about performance, because *my* bignum library is not 
generally available, so you can't use it even if you want to.

> He even provided
> such recommendations in the post you responded to.

Right.

[A troll said]
>> And guess what? Most of the blowhards in this group write SW which never
>> gets ported anywhere anyway.
> 
> Where is your proof that people have been lying when they have been
> talking about the porting of their SW that occurs in real life?

You're arguing with a troll, remember. They don't need proof. They don't 
even need evidence. They just need a good supply of mud.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

jacob navia said:

> Richard Heathfield wrote:
>> Barry Schwarz said:
>> 
>> <snip>
>> 
>>> Many use a "big number library" that simulates arithmetic on very wide
>>> integers.
>> 
>> Right.
>> 
>>> I think Richard Heathfield put one on the web
>> 
>> Actually, no, I haven't. I've got one, but I haven't published it.
>> 
>> As Mr Navia notes elsethread, it uses an array of unsigned char to store
>> the data. He seems to think that this "GUARANTEES that the software will
>> run VERY slowly using ALL the CPU for nothing". It doesn't, of course.
>> Nevertheless, performance was not my highest priority. Those who want a
>> super-fast bignum library would be well advised to use GMP or Miracl.
>> 
> 
> Using a char to store bignum data is like using a scooter to
> move a 38 ton trailer.

If you say so. In my experience, the performance is perfectly acceptable in 
those situations where I need bignums - and, if ever the performance 
*isn't* acceptable to me, there are other options available to me, such as 
the ones I mentioned in my earlier article.

> It will work of course, and the 38 ton trailer will have a cruising
> speed of several centimeters/hour...

Fine, if you say so - but that's *my* problem, right? Nobody else's. I'm 
not advocating that anyone else should use this software. For the record, 
however, yes, my bignum library is significantly slower than GMP (it takes 
about 20 times as long as GMP to calculate factorials, for instance). So 
what?

> Who cares?
> 
> That solution is PORTABLE. You can carry a scooter anywhere, they
> are standard solutions, etc.

That's a large part of it, yes. Licensing is another issue.


> Portability means very often that you make mediocre software
> that runs anywhere because it never uses the hardware/OS to
> its maximum possibilities but just uses the least common
> denominator of each one.

That's one way to do portability (although the result need *not* be 
mediocre - the fact that it usually *is* mediocre says a lot more about 
programmers than it does about portability). Another way is to recognise 
the reality that some code is portable and some isn't, and generally the 
parts that are portable can easily be isolated from those that aren't.

> This is fine if you do not care about usability or similar problems.

If I thought you were genuinely interested in learning how to solve these 
problems, I would continue to explain.

> But this is more a philosophical question. Heathfield's viewpoint
> is perfectly acceptable if you say:
> 
> Usability is less valuable than portability.

If it won't port to the user's system, how can it be called usable? Duh.

> As he said, performance wasn't a concern for his software.

I said no such thing. In the very article to which you replied, I said: 
"Nevertheless, performance was not my highest priority." There is a major 
semantic difference between "is not the highest priority" and "is not a 
concern". You often misinterpret people (especially me) in this way. That 
is either deliberate or accidental. If it is deliberate, then you are 
trolling. If it is accidental, then you need to learn to read for 
comprehension before trying to argue with those who can already do so.

> Portability was.
> 
> Result?
> 
> A mediocre but perfectly portable software.

Please explain how a program that *doesn't work* on the target platform is 
superior to one that does.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

"jacob navia" <jacob@nospam.com> wrote in message
news:ftblim$3tu$1@aioe.org...
> Bartc wrote:
>> OK, so for this to be practical, such a translator needs to know the
>> capabilities of a C90 installation. If it has 64+ bit ints, then use
>> them, otherwise make other arrangements. A pure translator would be of
>> academic interest only.
>>
>> Attend to 1000 other details and such a translator may be feasible.
>>
>> *(Note: I am not creating such a software, just interested in the
>> issues.)*
>>
>
> The bad news is that you will need:
>
> o alloca() for implementing VLA arrays.

I'm sure VLA and/or alloca() can be emulated with malloc(), where the native
C90 does not have alloca().

> o a complex math library

I would eliminate that completely, even though the popularity of my
translator would really suffer.

> o a 64 bit library

And written in C90, I know.

> o Your own printf/scanf/ versions

These are not in C90? Just a few extra formats needed.

> o Many math library functions like remquo(), erf() lgamma()
>   and several others
> o You will have to implement fexxx() functions (floating point
>   environment manipulating functions).
>   This needs to be done in assembly for the most part.

C seems a popular intermediate language, and presumably that is not C99. So
how do those other language compilers get around the problem of implementing
fexxx/remquo etc in assembler?

> o You will need a C99 parser

This should be OS-independent at least.

>
> The good news is that I can sell you all of the above for several popular
> OSes :-)

It would have to be for *every* OS; anything that has a C90 implementation.
And it would all have to be pure C90, no assembler.

-- 
Bart

Bartc wrote:
> "jacob navia" <jacob@nospam.com> wrote in message
> news:ftblim$3tu$1@aioe.org...
>> The bad news is that you will need:
>>
>> o alloca() for implementing VLA arrays.
> 
> I'm sure VLA and/or alloca() can be emulated with malloc(), where the native
> C90 does not have alloca().
> 

Yes but you will have to free the malloced memory
at block exit...

>> o a complex math library
> 
> I would eliminate that completely, even though the popularity of my
> translator would really suffer.
> 

Then you are not C99 compliant

>> o a 64 bit library
> 
> And written in C90, I know.
> 
>> o Your own printf/scanf/ versions
> 
> These are not in C90? Just a few extra formats needed.
> 

You will need to parse "%Lg" for instance, long double modifiers,
then "ll" long long modifiers, the hexadecimal %a for floats,
and many other goodies...

I *thought* that I could write my own printf by just "preprocessing"
the format string and calling an underlying printf but that wasn't very
efficient nor was it very easy. I ended up implementing my own
printf. Since you are not concerned about code quality, you can take
the preprocessing approach.

>> o Many math library functions like remquo(), erf() lgamma()
>>   and several others
>> o You will have to implement fexxx() functions (floating point
>>   environment manipulating functions).
>>   This needs to be done in assembly for the most part.
> 
> C seems a popular intermediate language, and presumably that is not C99. 

Yes it is. I would recommend you buying the standard C99 first.
Specifically the floating point manipulating functions are part
of the standard. All of the functions I named above are part
of the standard.

> So
> how do those other language compilers get around the problem of implementing
> fexxx/remquo etc in assembler?
> 

lcc-win implements it in assembler. What else?

>> o You will need a C99 parser
> 
> This should be OS-independent at least.
> 
>> The good news is that I can sell you all of the above for several popular
>> OSes :-)
> 
> It would have to be for *every* OS; anything that has a C90 implementation.
> And it would all have to be pure C90, no assembler.
> 

printf/erf/lgamma are written in C. The floating point environment
manipulating functions are in assembler, and they *have* to be written
in assembler for EACH supported FPU.



-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Richard Heathfield wrote:
> jacob navia said:

[big num stuff]

>> It will work of course, and the 38 ton trailer will have a cruising
>> speed of several centimeters/hour...
>
> Fine, if you say so - but that's *my* problem, right? Nobody else's.
> I'm not advocating that anyone else should use this software. For the
> record, however, yes, my bignum library is significantly slower than
> GMP (it takes about 20 times as long as GMP to calculate factorials,
> for instance). So what?

How long does it take to calculate 5^(4^(3^(2^1)))? (Ie. raising to the 
power.)

This came up in comp.programming a few weeks back. I knocked up a quick 
library that used byte arrays and stored a single decimal digit in each 
byte. And that was in interpreted code! (Only add unsigned and multiply by 
single digit were compiled.)

This took some 15 minutes to calculate the 183000-digit result (on a slowish 
Pentium cpu).

Just interested in how much extra work is needed...

-- 
Bart 

Bartc wrote:
> Richard Heathfield wrote:
>> jacob navia said:
> 
> [big num stuff]
> 
>>> It will work of course, and the 38 ton trailer will have a cruising
>>> speed of several centimeters/hour...
>> Fine, if you say so - but that's *my* problem, right? Nobody else's.
>> I'm not advocating that anyone else should use this software. For the
>> record, however, yes, my bignum library is significantly slower than
>> GMP (it takes about 20 times as long as GMP to calculate factorials,
>> for instance). So what?
> 
> How long does it take to calculate 5^(4^(3^(2^1)))? (Ie. raising to the 
> power.)
> 
> This came up in comp.programming a few weeks back. I knocked up a quick 
> library that used byte arrays and stored a single decimal digit in each 
> byte. And that was in interpreted code! (Only add unsigned and multiply by 
> single digit were compiled.)
> 
> This took some 15 minutes to calculate the 183000-digit result (on a slowish 
> Pentium cpu).
> 
> Just interested in how much extra work is needed...
> 

The french package "pari" calculates that in around 0.5 seconds
(In a dual core amd)

-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:
> Bartc wrote:
>> Richard Heathfield wrote:
>>> jacob navia said:
>>
>> [big num stuff]
>>
>>>> It will work of course, and the 38 ton trailer will have a cruising
>>>> speed of several centimeters/hour...
>>> Fine, if you say so - but that's *my* problem, right? Nobody else's.
>>> I'm not advocating that anyone else should use this software. For
>>> the record, however, yes, my bignum library is significantly slower
>>> than GMP (it takes about 20 times as long as GMP to calculate
>>> factorials, for instance). So what?
>>
>> How long does it take to calculate 5^(4^(3^(2^1)))? (Ie. raising to
>> the power.)
>>
>> This came up in comp.programming a few weeks back. I knocked up a
>> quick library that used byte arrays and stored a single decimal
>> digit in each byte. And that was in interpreted code! (Only add
>> unsigned and multiply by single digit were compiled.)
>>
>> This took some 15 minutes to calculate the 183000-digit result (on a
>> slowish Pentium cpu).
>>
>> Just interested in how much extra work is needed...
>>
>
> The french package "pari" calculates that in around 0.5 seconds
> (In a dual core amd)

So I need to make it about 1000 times faster then, on my slower machine. No 
problem..

-- 
Bart 

Bartc said:

<snip>
 
> How long does [RH's bignum lib] take to calculate 5^(4^(3^(2^1)))?
> (Ie. raising to the power.)

Around 25 seconds on a 1.4GHz Athlon.

> This came up in comp.programming a few weeks back. I knocked up a quick
> library that used byte arrays and stored a single decimal digit in each
> byte. And that was in interpreted code! (Only add unsigned and multiply
> by single digit were compiled.)
> 
> This took some 15 minutes to calculate the 183000-digit result (on a
> slowish Pentium cpu).

The difference is partly explained by your use of a single decimal digit 
(whether it be 0 to 9 or '0' to '9') in each byte rather than a full 
2-to-the-CHAR_BIT possible values. Bearing in mind that most uses of 
bignum libraries are *not* for calculating 183000-digit numbers or 
anything like them, the "inefficiency" of your library is unlikely to be 
particularly significant. If you're only dealing with numbers of, say, one 
or two hundred decimal digits (which is quite typical for modern 
cryptographic applications), I doubt very much whether your losses through 
inefficiency will be anything like as big as your gains in terms of 
readability, simplicity, and maintainability.

And if you /do/ need the extra speed, you know how to get it.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

"Morris Dovey" <mrdovey@iedu.com> wrote in message 
news:47F92AB2.674F6B6B@iedu.com...
> Richard wrote:
>
>> And guess what? Most of the b******s in this group write SW which
>> never gets ported anywhere anyway.
>
> Umm - before you make a statement like that you might want to
> check with some of those b*******s who make some of their C
> source code available for free download...
>
The University of Leeds kindly provides me with access statistics on my 
website. Pages with more than 100 hits in a 4 week period are listed. Apart 
from the homepage, the MPI tutorial is always the most accessed part of thwe 
website, followed by the Basic interpreter. No C source file has ever been 
hit more than 100 times, though the protein geometry routine documentation 
pages sometimes squeak in.

It's very rare to get any kind of response from readers, so it is difficult 
to know what is useful or not. Also, of course, one hit from someone who is 
doing research is worth several hits from computer science students, in 
terms of what I'm trying to achieve.

-- 
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message 
news:hNadnecAFc85lWTanZ2dnUVZ8uudnZ2d@bt.com...
> Barry Schwarz said:
>
> <snip>
>
>> Many use a "big number library" that simulates arithmetic on very wide
>> integers.
>
> Right.
>
>> I think Richard Heathfield put one on the web
>
> Actually, no, I haven't. I've got one, but I haven't published it.
>
> As Mr Navia notes elsethread, it uses an array of unsigned char to store
> the data. He seems to think that this "GUARANTEES that the software will
> run VERY slowly using ALL the CPU for nothing". It doesn't, of course.
> Nevertheless, performance was not my highest priority. Those who want a
> super-fast bignum library would be well advised to use GMP or Miracl.

Neither of those libraries are a good choice for 64 bit operations.  Both of 
those libraries are designed for integers that are hundreds or thousands of 
bits wide.  I assume that the OP wants hardware speed if the existing 
hardware has a 64 bit integer data type.

If there is a GCC available for the OP's platforms, then GCC has had 64 bit 
integers for a long time that work over a very wide range of platforms.

Many other compilers have had 64 bit integers for a long time as well.  Some 
compilers call the data type __int64 instead of long long.

Probably, an interesting question is:
"What are the 64 bit integers for?"

For instance, you can store 52 or 53 bit integers in most 8 byte double data 
types with perfect accuracy.  Are numbers larger than 4,503,599,627,370,496 
really needed?  The available size for perfect accuracy in storage will be 
+/- 2^DBL_MANT_DIG digits.

We might also ask if the large integers are needed for a wide range of 
platforms or for a small group of esoteric platforms.

If 64 bit support is truly needed, then the C90 standard offers no help. 
Unfortunately, as others have noted, the C99 standard has yet to receive 
ubiquitous support.  Hence, the goal of widespread portability may be hard 
to achieve.



** Posted from http://www.teranews.com **

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message 
news:yNudnfCEyLVycWTanZ2dneKdnZydnZ2d@bt.com...
> Bartc said:
>
> <snip>
>
>> How long does [RH's bignum lib] take to calculate 5^(4^(3^(2^1)))?
>> (Ie. raising to the power.)
>
> Around 25 seconds on a 1.4GHz Athlon.
>
>> This came up in comp.programming a few weeks back. I knocked up a quick
>> library that used byte arrays and stored a single decimal digit in each
>> byte. And that was in interpreted code! (Only add unsigned and multiply
>> by single digit were compiled.)
>>
>> This took some 15 minutes to calculate the 183000-digit result (on a
>> slowish Pentium cpu).
>
> The difference is partly explained by your use of a single decimal digit
> (whether it be 0 to 9 or '0' to '9') in each byte rather than a full
> 2-to-the-CHAR_BIT possible values. Bearing in mind that most uses of
> bignum libraries are *not* for calculating 183000-digit numbers or
> anything like them, the "inefficiency" of your library is unlikely to be
> particularly significant. If you're only dealing with numbers of, say, one
> or two hundred decimal digits (which is quite typical for modern
> cryptographic applications), I doubt very much whether your losses through
> inefficiency will be anything like as big as your gains in terms of
> readability, simplicity, and maintainability.
>
> And if you /do/ need the extra speed, you know how to get it.

With wide numbers (in the hundreds of bits) the schoolbook algorithm for 
multiplication is a bad idea.

For numbers in this range, Karatsooba or Toon-Cook multiplication is used.

For very wide numbers, multiplication is performed using FFTs.

The best way to speed up the fundamental arithmetic operations for large 
numbers is to change the fundamental underlying algorithm that performs 
them.
See (for instance):
http://mathworld.wolfram.com/KaratsubaMultiplication.html
http://numbers.computation.free.fr/Constants/Algorithms/fft.html


** Posted from http://www.teranews.com **

Dann Corbit said:

> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
> news:hNadnecAFc85lWTanZ2dnUVZ8uudnZ2d@bt.com...

<snip>

>> [...] Those who want a
>> super-fast bignum library would be well advised to use GMP or Miracl.
> 
> Neither of those libraries are a good choice for 64 bit operations.

Quite so, although the way I see it, if you need more than 32 bits, you 
probably need arbitrarily many bits, or at least way more than 64. The 
most common use I'm aware of for needing more than C90 gives you is calcs 
involving RSA and D-H, for both of which 64 bits isn't anywhere like 
enough.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

On Apr 7, 11:23=A0pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> Dann Corbit said:
>
> > "Richard Heathfield" <r...@see.sig.invalid> wrote in message
> >news:hNadnecAFc85lWTanZ2dnUVZ8uudnZ2d@bt.com...
>
> <snip>
>
> >> [...] Those who want a
> >> super-fast bignum library would be well advised to use GMP or Miracl.
>
> > Neither of those libraries are a good choice for 64 bit operations.
>
> Quite so, although the way I see it, if you need more than 32 bits, you
> probably need arbitrarily many bits, or at least way more than 64. The
> most common use I'm aware of for needing more than C90 gives you is calcs
> involving RSA and D-H, for both of which 64 bits isn't anywhere like
> enough.

There are also lots of useful calculations that benefit directly from
64 bit math like Chess programming (uses a 64 bit integer to hold the
board representation frequently) and things like the UMAC hash:
http://fastcrypto.org/umac/

Database systems often need to use 64 bit values, because 32 bit
values (e.g. transaction IDs or record serial ID values) tend to
overflow over time.

user923005 said:

> On Apr 7, 11:23 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> [...] if you need more than 32 bits, you
>> probably need arbitrarily many bits, or at least way more than 64. The
>> most common use I'm aware of for needing more than C90 gives you is
>> calcs involving RSA and D-H, for both of which 64 bits isn't anywhere
>> like enough.
> 
> There are also lots of useful calculations that benefit directly from
> 64 bit math like Chess programming (uses a 64 bit integer to hold the
> board representation frequently) and things like the UMAC hash:
> http://fastcrypto.org/umac/

I accept that I ought to have remembered bitboards.

> Database systems often need to use 64 bit values, because 32 bit
> values (e.g. transaction IDs or record serial ID values) tend to
> overflow over time.

Well, no, what they need is "big-enough" values. If overflow is 
unacceptable, then the day may come when a 64-bit value won't do.

Admittedly that day may be some way away. A computer whose job is to record 
every human born on this planet (assuming the population continues to grow 
at about 10% every 7 years) will not overflow a 64-bit ID until the year 
3604, by which time - with 123000 people for every square metre of land - 
we'll have more to worry about than computers not working properly.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

On Apr 8, 12:16=A0am, Richard Heathfield <r...@see.sig.invalid> wrote:
> user923005 said:
>
> > On Apr 7, 11:23 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> [...] if you need more than 32 bits, you
> >> probably need arbitrarily many bits, or at least way more than 64. The
> >> most common use I'm aware of for needing more than C90 gives you is
> >> calcs involving RSA and D-H, for both of which 64 bits isn't anywhere
> >> like enough.
>
> > There are also lots of useful calculations that benefit directly from
> > 64 bit math like Chess programming (uses a 64 bit integer to hold the
> > board representation frequently) and things like the UMAC hash:
> >http://fastcrypto.org/umac/
>
> I accept that I ought to have remembered bitboards.
>
> > Database systems often need to use 64 bit values, because 32 bit
> > values (e.g. transaction IDs or record serial ID values) tend to
> > overflow over time.
>
> Well, no, what they need is "big-enough" values. If overflow is
> unacceptable, then the day may come when a 64-bit value won't do.
>
> Admittedly that day may be some way away. A computer whose job is to recor=
d
> every human born on this planet (assuming the population continues to grow=

> at about 10% every 7 years) will not overflow a 64-bit ID until the year
> 3604, by which time - with 123000 people for every square metre of land -
> we'll have more to worry about than computers not working properly.

That day has been here for a long time now.  Take a look at the
PostgreSQL mailing list and you will see that 32 bit values caused no
end of headaches due to wrap around.
All of these systems perform over one million TPS:
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
There are 86400 seconds in one day, so we have 86,400,000,000
transactions in one day.  It will take about one hour to exhaust a 32
bit transaction ID or overflow a 32 bit serial value for a synthetic
primary key to store on disk.

There are dozens of petabyte database systems today.

Richard Heathfield wrote:
> Dann Corbit said:
> 
>> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
>> news:hNadnecAFc85lWTanZ2dnUVZ8uudnZ2d@bt.com...
> 
> <snip>
> 
>>> [...] Those who want a
>>> super-fast bignum library would be well advised to use GMP or Miracl.
>> Neither of those libraries are a good choice for 64 bit operations.
> 
> Quite so, although the way I see it, if you need more than 32 bits, you 
> probably need arbitrarily many bits, or at least way more than 64. The 
> most common use I'm aware of for needing more than C90 gives you is calcs 
> involving RSA and D-H, for both of which 64 bits isn't anywhere like 
> enough.
> 
> <snip>
> 

Never used a file bigger than 4GB?

With disks of 500GB now, a database of more than 4GB is
quite common.

Timestamps are 64 bits now, under windows.



-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia said:

> Richard Heathfield wrote:
>> Dann Corbit said:
>> 
>>> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
>>> news:hNadnecAFc85lWTanZ2dnUVZ8uudnZ2d@bt.com...
>> 
>> <snip>
>> 
>>>> [...] Those who want a
>>>> super-fast bignum library would be well advised to use GMP or Miracl.
>>> Neither of those libraries are a good choice for 64 bit operations.
>> 
>> Quite so, although the way I see it, if you need more than 32 bits, you
>> probably need arbitrarily many bits, or at least way more than 64. The
>> most common use I'm aware of for needing more than C90 gives you is
>> calcs involving RSA and D-H, for both of which 64 bits isn't anywhere
>> like enough.
>> 
>> <snip>
>> 
> 
> Never used a file bigger than 4GB?

You really don't get it, do you? Right - file sizes are growing rapidly. 
What makes you think they will stop growing when they hit 2^64?

> With disks of 500GB now, a database of more than 4GB is
> quite common.

At least one UK organisation (the Met Office) currently adds more than a 
Terabyte to its data store *every day*, and the rate of increase has 
itself been increasing over the years. My point is not that 32 bits are 
enough, but that 64 are *not* enough.

> Timestamps are 64 bits now, under windows.

That's nice.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

On Apr 8, 3:42 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> jacob navia said:
>
>
>
>
>
>
>
> > Richard Heathfield wrote:
> >> Dann Corbit said:
>
> >>> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
> >>>news:hNadnecAFc85lWTanZ2dnUVZ8uudnZ2d@bt.com...
>
> >> <snip>
>
> >>>> [...] Those who want a
> >>>> super-fast bignum library would be well advised to use GMP or Miracl.
> >>> Neither of those libraries are a good choice for 64 bit operations.
>
> >> Quite so, although the way I see it, if you need more than 32 bits, you
> >> probably need arbitrarily many bits, or at least way more than 64. The
> >> most common use I'm aware of for needing more than C90 gives you is
> >> calcs involving RSA and D-H, for both of which 64 bits isn't anywhere
> >> like enough.
>
> >> <snip>
>
> > Never used a file bigger than 4GB?
>
> You really don't get it, do you? Right - file sizes are growing rapidly.
> What makes you think they will stop growing when they hit 2^64?
>
> > With disks of 500GB now, a database of more than 4GB is
> > quite common.
>
> At least one UK organisation (the Met Office) currently adds more than a
> Terabyte to its data store *every day*, and the rate of increase has
> itself been increasing over the years. My point is not that 32 bits are
> enough, but that 64 are *not* enough.

You really don't get it, do you? Real hardware
and real files are a little different from imaginary
exponential growth of the Earth population. 2^24
is sixteen million; hundred terabytes a day is
some 495 years. Well, nevermind, that organization
perhaps can have 16 million times a terabyte of
storage. That organization probably can write a new OS
with fancy filesystem to make that storage into
one big file. Well, okay. Is it going to use
bignum for file offsets? Still unlikely. Most likely
it will use 128 bits and that's going to be enough
for next ten years for sure.

Anyway, is it really such a strange idea that
for some range of problems 32 bits are enough,
and for some bigger range of problems 64 bits
are enough? Say, 64 bits *are* enough if you
want to deal with files today...

Yevgen

Richard Heathfield wrote:
> 
> At least one UK organisation (the Met Office) currently adds more than a 
> Terabyte to its data store *every day*, and the rate of increase has 
> itself been increasing over the years. My point is not that 32 bits are 
> enough, but that 64 are *not* enough.
> 
Support is already there, the largest supported file size in the largest
file system I know of (ZFS) is 16 exbibytes (2^64 bytes).  Mind you, the
largest pool size is 256 zebibytes, so you could store quite a few of them.

-- 
Ian Collins.

On Apr 8, 8:42=A0am, Richard Heathfield <r...@see.sig.invalid> wrote:
> jacob navia said:
>

> > Richard Heathfield wrote:
> >> Dann Corbit said:
>
> >>> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
> >>>news:hNadnecAFc85lWTanZ2dnUVZ8uudnZ2d@bt.com...
>
> >> <snip>
>
> >>>> [...] Those who want a
> >>>> super-fast bignum library would be well advised to use GMP or Miracl.=

> >>> Neither of those libraries are a good choice for 64 bit operations.
>
> >> Quite so, although the way I see it, if you need more than 32 bits, you=

> >> probably need arbitrarily many bits, or at least way more than 64. The
> >> most common use I'm aware of for needing more than C90 gives you is
> >> calcs involving RSA and D-H, for both of which 64 bits isn't anywhere
> >> like enough.
>
> >> <snip>
>
> > Never used a file bigger than 4GB?
>
> You really don't get it, do you? Right - file sizes are growing rapidly.
> What makes you think they will stop growing when they hit 2^64?

64-bits is useful /now/ (and has been for a while) for such things as
file sizes.

64-bits datatypes are commonly available to anyone who doesn't insist
on C90 for example.

Exceeding 64-bits for file sizes, that's not going to be common, and
there are a number of techniques for dealing with that: emulate 96/128-
bit values, use a 2-part value, address files in units other that
bytes, and so on. Most people won't have to bother.

Totally disregarding migrating from 32 to 64-bits, simply because one
day in the future 64-bits may not quite be enough, is silly. Like not
buying that medium sized car now because, in ten years, you might need
a bigger one...

You may have noticed that many machines now have a 64-bit native type,
and totally ignoring that fact is also silly.


--
Bart

Richard Heathfield <rjh@see.sig.invalid> writes:

> jacob navia said:
>
>> Richard Heathfield wrote:
>>> Dann Corbit said:
>>> 
>>>> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
>>>> news:hNadnecAFc85lWTanZ2dnUVZ8uudnZ2d@bt.com...
>>> 
>>> <snip>
>>> 
>>>>> [...] Those who want a
>>>>> super-fast bignum library would be well advised to use GMP or Miracl.
>>>> Neither of those libraries are a good choice for 64 bit operations.
>>> 
>>> Quite so, although the way I see it, if you need more than 32 bits, you
>>> probably need arbitrarily many bits, or at least way more than 64. The
>>> most common use I'm aware of for needing more than C90 gives you is
>>> calcs involving RSA and D-H, for both of which 64 bits isn't anywhere
>>> like enough.
>>> 
>>> <snip>
>>> 
>> 
>> Never used a file bigger than 4GB?
>
> You really don't get it, do you? Right - file sizes are growing rapidly. 
> What makes you think they will stop growing when they hit 2^64?

They wont - but do you realise just how big a file can get with 64 bits?

user923005 said:

> On Apr 8, 12:16 am, Richard Heathfield <r...@see.sig.invalid> wrote:

<snip>

>> If overflow is
>> unacceptable, then the day may come when a 64-bit value won't do.
>>
>> Admittedly that day may be some way away. [...]
> 
> That day has been here for a long time now.  Take a look at the
> PostgreSQL mailing list and you will see that 32 bit values caused no
> end of headaches due to wrap around.

But that was a 32-bit day of reckoning. I was talking about a 64-bit day of 
reckoning. (This reply has been drastically snipped, but only in order to 
highlight the point; a re-reading of the original will show that the 
snippage has not changed the meaning of that point.)

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard wrote:
>> What makes you think they will stop growing when they hit 2^64?
> 
> They wont - but do you realise just how big a file can get with 64 bits?

Let's suppose the machines arrive at the density of DNA, i.e. around
(very roughly) 50 atoms/bit.

We have:
50*2^64 --> 922337203685477580800
Divided by Avogrado's number 6.022E23

is 0.001531612 liters

1.5 ml. The volume then, is just 1.5 ml.

Of course there is the packing overhead, let's say that
you multiply the bit density by 10. You arrive at
1.5Liters for a file of 2^64 bits!

In bytes you multiply by 8, you get 12 liters the volume
to store a file of 2^64 bytes

Very feasible.

Probably by 2020-2025


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Richard Heathfield <rjh@see.sig.invalid> writes:

> Dann Corbit said:
>
>> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
>> news:hNadnecAFc85lWTanZ2dnUVZ8uudnZ2d@bt.com...
>
> <snip>
>
>>> [...] Those who want a
>>> super-fast bignum library would be well advised to use GMP or Miracl.
>> 
>> Neither of those libraries are a good choice for 64 bit operations.
>
> Quite so, although the way I see it, if you need more than 32 bits, you 
> probably need arbitrarily many bits, or at least way more than 64. The 
> most common use I'm aware of for needing more than C90 gives you is calcs 
> involving RSA and D-H, for both of which 64 bits isn't anywhere like 
> enough.

No, but every doubling of integer width that is allowed roughly
doubles the speed of RSA and D-H calculations.  If C99 (or C0x)
becomes widespread, faster portable RSA and D-H code will be possible.
The fastest cryptographic code will always use non-portable
extensions, but a portable 32-bit multiply (=> 64 bit result) would be
very useful.

-- 
Ben.

On Tue, 08 Apr 2008 06:23:16 +0000, Richard Heathfield
<rjh@see.sig.invalid> wrote:

>Dann Corbit said:
>
>> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
>> news:hNadnecAFc85lWTanZ2dnUVZ8uudnZ2d@bt.com...
>
><snip>
>
>>> [...] Those who want a
>>> super-fast bignum library would be well advised to use GMP or Miracl.
>> 
>> Neither of those libraries are a good choice for 64 bit operations.
>
>Quite so, although the way I see it, if you need more than 32 bits, you 
>probably need arbitrarily many bits, or at least way more than 64. The 
>most common use I'm aware of for needing more than C90 gives you is calcs 
>involving RSA and D-H, for both of which 64 bits isn't anywhere like 
>enough.

Financial calculations and reporting by governments and
corporations.  32 bits is not enough; 48 bits suffices for
now; 64 bits is insurance.






Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message 
news:iPKdnZvUcrTQ0mbanZ2dnUVZ8uKdnZ2d@bt.com...
> user923005 said:
>
>> On Apr 8, 12:16 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> <snip>
>
>>> If overflow is
>>> unacceptable, then the day may come when a 64-bit value won't do.
>>>
>>> Admittedly that day may be some way away. [...]
>>
>> That day has been here for a long time now.  Take a look at the
>> PostgreSQL mailing list and you will see that 32 bit values caused no
>> end of headaches due to wrap around.
>
> But that was a 32-bit day of reckoning. I was talking about a 64-bit day 
> of
> reckoning. (This reply has been drastically snipped, but only in order to
> highlight the point; a re-reading of the original will show that the
> snippage has not changed the meaning of that point.)
>
> <snip>

Quite right, I misread you completely.



** Posted from http://www.teranews.com **

Richard Heathfield wrote:

> A computer whose job is to record every human born on this planet
> (assuming the population continues to grow at about 10% every 7
> years) will not overflow a 64-bit ID until the year 3604

Wait a minute.

The number of world births has remained stable for several years,
and is projected to remain stable for several years to come.

http://www.census.gov/ipc/prod/ib96_03.pdf

(There were 133M births in 1996, 129M births in 2004.)

+10% every 7 years = +1.371% every year

Your assumptions mean we should expect...

o ~500 million births in 2104
o   ~2 billion births in 2204

Unpossible :-)