Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #2978 > unrolled thread

Re: KISS4691, a potentially top-ranked RNG.

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: KISS4691, a potentially top-ranked RNG. "robin" <robin51@dodo.mapson.com.au> - 2011-04-28 11:14 +1000
    Re: KISS4691, a potentially top-ranked RNG. "e p chandler" <epc8@juno.com> - 2011-04-28 07:42 -0400
      Re: KISS4691, a potentially top-ranked RNG. Gib Bogle <g.bogle@auckland.ac.nz> - 2011-04-29 12:55 +1200
      Re: KISS4691, a potentially top-ranked RNG. David Bernier <david250@videotron.ca> - 2011-04-28 21:50 -0400
        Re: KISS4691, a potentially top-ranked RNG. Ian Collins <ian-news@hotmail.com> - 2011-04-29 14:09 +1200
          Re: KISS4691, a potentially top-ranked RNG. Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-04-28 23:01 -0400
            Re: KISS4691, a potentially top-ranked RNG. Ian Collins <ian-news@hotmail.com> - 2011-04-29 15:09 +1200
              Re: KISS4691, a potentially top-ranked RNG. Uno <merrilljensen@q.com> - 2011-05-08 00:34 -0700
                Re: KISS4691, a potentially top-ranked RNG. Marni Zollinger <marni@altgreendesigns.com> - 2011-05-10 23:38 -0600
            Re: KISS4691, a potentially top-ranked RNG. nmm1@cam.ac.uk - 2011-04-29 07:15 +0100
          Re: KISS4691, a potentially top-ranked RNG. David Bernier <david250@videotron.ca> - 2011-04-28 23:16 -0400
        Re: KISS4691, a potentially top-ranked RNG. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-04-29 02:34 +0000
          Re: KISS4691, a potentially top-ranked RNG. Uno <Uno@example.invalid> - 2011-04-29 01:04 -0600
            Re: KISS4691, a potentially top-ranked RNG. "robin" <robin51@dodo.mapson.com.au> - 2011-04-30 20:48 +1000
              Re: KISS4691, a potentially top-ranked RNG. Uno <Uno@example.invalid> - 2011-05-04 19:12 -0600
          Re: KISS4691, a potentially top-ranked RNG. Keith Thompson <kst-u@mib.org> - 2011-04-29 08:13 -0700
            Re: KISS4691, a potentially top-ranked RNG. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-04-29 17:41 +0000
              Re: KISS4691, a potentially top-ranked RNG. Keith Thompson <kst-u@mib.org> - 2011-04-29 12:53 -0700
                Re: KISS4691, a potentially top-ranked RNG. Michael Press <rubrum@pacbell.net> - 2011-05-05 16:38 -0700
            Re: KISS4691, a potentially top-ranked RNG. Seebs <usenet-nospam@seebs.net> - 2011-04-29 22:45 +0000
            Re: KISS4691, a potentially top-ranked RNG. "Randy Brukardt" <randy@rrsoftware.com> - 2011-04-29 23:36 -0500
        Re: KISS4691, a potentially top-ranked RNG. Seebs <usenet-nospam@seebs.net> - 2011-04-29 22:43 +0000
      Re: KISS4691, a potentially top-ranked RNG. "robin" <robin51@dodo.mapson.com.au> - 2011-04-29 19:43 +1000
    Re: KISS4691, a potentially top-ranked RNG. Thad Smith <ThadSmith@acm.org> - 2011-05-01 08:31 -0700
      Re: KISS4691, a potentially top-ranked RNG. Ian Collins <ian-news@hotmail.com> - 2011-05-02 07:58 +1200
        Re: KISS4691, a potentially top-ranked RNG. James Kuyper <jameskuyper@verizon.net> - 2011-05-01 20:01 -0400
          Re: KISS4691, a potentially top-ranked RNG. Ian Collins <ian-news@hotmail.com> - 2011-05-02 12:42 +1200
            Re: KISS4691, a potentially top-ranked RNG. James Kuyper <jameskuyper@verizon.net> - 2011-05-01 22:34 -0400
            Re: KISS4691, a potentially top-ranked RNG. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-02 02:50 +0000
        Re: KISS4691, a potentially top-ranked RNG. Thad Smith <ThadSmith@acm.org> - 2011-05-01 21:21 -0700
          Re: KISS4691, a potentially top-ranked RNG. nmm1@cam.ac.uk - 2011-05-02 08:31 +0100
            Re: KISS4691, a potentially top-ranked RNG. "robin" <robin51@dodo.mapson.com.au> - 2011-05-23 16:52 +1000
            Re: KISS4691, a potentially top-ranked RNG. "robin" <robin51@dodo.mapson.com.au> - 2011-05-23 14:18 +1000
              Re: KISS4691, a potentially top-ranked RNG. "robin" <robin51@dodo.mapson.com.au> - 2011-05-23 17:20 +1000
            Re: KISS4691, a potentially top-ranked RNG. "robin" <robin51@dodo.mapson.com.au> - 2011-05-23 16:52 +1000
            Re: KISS4691, a potentially top-ranked RNG. "robin" <robin51@dodo.mapson.com.au> - 2011-05-23 16:52 +1000
            Re: KISS4691, a potentially top-ranked RNG. "robin" <robin51@dodo.mapson.com.au> - 2011-05-23 16:53 +1000
              Re: KISS4691, a potentially top-ranked RNG. Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2011-05-23 09:16 +0200
                Re: KISS4691, a potentially top-ranked RNG. Ilmari Karonen <usenet2@vyznev.invalid> - 2011-05-26 22:06 +0000
                Re: KISS4691, a potentially top-ranked RNG. "robin" <robin51@dodo.mapson.com.au> - 2011-06-28 17:19 +1000
                  Re: KISS4691, a potentially top-ranked RNG. "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> - 2011-06-28 10:44 +0200
                    Re: KISS4691, a potentially top-ranked RNG. Chris H <chris@phaedsys.org> - 2011-06-28 10:19 +0100
                  Re: KISS4691, a potentially top-ranked RNG. Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2011-06-28 11:14 +0200
                    Re: KISS4691, a potentially top-ranked RNG. "robin" <robin51@dodo.mapson.com.au> - 2011-06-28 21:59 +1000
                      Re: KISS4691, a potentially top-ranked RNG. Chris H <chris@phaedsys.org> - 2011-06-28 13:16 +0100
                        Re: KISS4691, a potentially top-ranked RNG. Peter Flass <Peter_Flass@Yahoo.com> - 2011-06-28 11:44 -0400
                      Re: KISS4691, a potentially top-ranked RNG. James Kuyper <jameskuyper@verizon.net> - 2011-06-28 08:33 -0400
                      Re: KISS4691, a potentially top-ranked RNG. Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2011-06-28 15:53 +0200
                        Re: KISS4691, a potentially top-ranked RNG. Brian Salter-Duke <b_duke@bigpond.com.au> - 2011-06-28 22:39 +0000
                  Re: KISS4691, a potentially top-ranked RNG. James Kuyper <jameskuyper@verizon.net> - 2011-06-28 08:32 -0400
                    Re: KISS4691, a potentially top-ranked RNG. Chris H <chris@phaedsys.org> - 2011-06-28 14:03 +0100
                      Re: KISS4691, a potentially top-ranked RNG. James Kuyper <jameskuyper@verizon.net> - 2011-06-28 10:25 -0400
                        Re: KISS4691, a potentially top-ranked RNG. Chris H <chris@phaedsys.org> - 2011-06-28 16:01 +0100
                          Re: KISS4691, a potentially top-ranked RNG. James Kuyper <jameskuyper@verizon.net> - 2011-06-28 20:20 -0400
                          Re: KISS4691, a potentially top-ranked RNG. Michael Press <rubrum@pacbell.net> - 2011-06-29 01:38 -0700
                  Re: KISS4691, a potentially top-ranked RNG. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-28 10:04 -0600
                    Re: KISS4691, a potentially top-ranked RNG. Chris H <chris@phaedsys.org> - 2011-06-28 17:36 +0100
                      Re: KISS4691, a potentially top-ranked RNG. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-28 10:51 -0600
                        Re: KISS4691, a potentially top-ranked RNG. James Kuyper <jameskuyper@verizon.net> - 2011-06-28 20:27 -0400
                          Re: KISS4691, a potentially top-ranked RNG. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-28 19:00 -0600
                          Re: KISS4691, a potentially top-ranked RNG. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-06-29 19:48 +0300
                      Re: KISS4691, a potentially top-ranked RNG. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-28 10:52 -0600
                      Re: KISS4691, a potentially top-ranked RNG. David Bernier <david250@videotron.ca> - 2011-06-28 13:06 -0400
                    Re: Wiki "robin" <robin51@dodo.mapson.com.au> - 2011-06-29 10:00 +1000
                      Re: Wiki James Kuyper <jameskuyper@verizon.net> - 2011-06-28 20:25 -0400
                        Re: Wiki Ivan Shmakov <ivan@gray.siamics.net> - 2011-06-29 16:03 +0700
                          Re: Wiki Chris H <chris@phaedsys.org> - 2011-06-30 13:39 +0100
                            Re: Wiki Frederick Williams <freddywilliams@btinternet.com> - 2011-07-01 22:15 +0100
                      Re: Wiki Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-28 18:52 -0600
                        Re: Wiki James Kuyper <jameskuyper@verizon.net> - 2011-06-29 05:52 -0400
                          Re: Wiki Peter Flass <Peter_Flass@Yahoo.com> - 2011-06-29 10:12 -0400
                          Re: Wiki Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-29 14:29 -0600
                      Re: Wiki Dr Nick <3-nospam@temporary-address.org.uk> - 2011-06-29 07:43 +0100
                        Re: Wiki Peter Flass <Peter_Flass@Yahoo.com> - 2011-06-29 10:10 -0400
                        Re: Wiki Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-06-29 19:42 +0300
                          Re: Wiki Chris H <chris@phaedsys.org> - 2011-06-29 18:09 +0100
                          Re: Wiki Dr Nick <3-nospam@temporary-address.org.uk> - 2011-06-29 18:48 +0100
                      Re: Wiki Peter Flass <Peter_Flass@Yahoo.com> - 2011-06-29 09:50 -0400

Page 1 of 4  [1] 2 3 4  Next page →

#2978 — Re: KISS4691, a potentially top-ranked RNG.

"Uno" <merrilljensen@q.com> wrote in message news:8bfh28Fve1U1@mid.individual.net...
| robin wrote:
| > "jacob navia" <jacob@spamsink.net> wrote in message news:i2fir2$op4$1@speranza.aioe.org...
| >
| > | This doesn't work with systems that have unsigned long as a 64 bit quantity.
| > |
| > | I obtain:
| > |
| > |  MWC result=3740121002 ?
| > |             4169348530
| > | KISS result=2224631993 ?
| > |             1421918629
| >
| > For a 64-bit machine (using 64-bit integer arithmetic),
| > you'd need to truncate each result to 32 bits.  That not
| > only applies to the multiplication, it also applies to addition, etc.
| > On a 32-bit machine, these extra bits are discarded,
| > but in 64-bit arithmetic, they are retained,
| > and unless they are similarly discarded,
| > you won't get the same results.
| > I suggest using IAND(k, 2*2147483647+1)
| > for the truncation.
| >
| > With such modifications in the program,
| > it should then produce the same results on both 32-bit and
| > 64-bit machines.
| >
| > P.S. the product 2*2... is best obtained using ISHFT.
| >
| > | Compiling with 32 bit machine yields:
| > |  MWC result=3740121002 ?
| > |             3740121002
| > | KISS result=2224631993 ?
| > |             2224631993
|
| First of all, I think we're talking to the actual George Marsaglia here.
|
| $ gcc -Wall -Wextra geo1.c -o out
| geo1.c: In function 'MWC':
| geo1.c:5: warning: type defaults to 'int' in declaration of 'c'
| geo1.c:5: warning: type defaults to 'int' in declaration of 'j'
| geo1.c:5: warning: unused variable 'i'
| geo1.c: In function 'main':
| geo1.c:21: warning: format '%22u' expects type 'unsigned int', but
| argument 2 has type 'long unsigned int'
| geo1.c:23: warning: format '%22u' expects type 'unsigned int', but
| argument 2 has type 'long unsigned int'
| geo1.c:24: warning: control reaches end of non-void function
|
| $ ./out
|  MWC result=3740121002 ?
|             3740121002
| KISS result=2224631993 ?
|             2224631993
| $ cat geo1.c
| static unsigned long xs=521288629,xcng=362436069,Q[4691];
|
| unsigned long MWC(void)  /*takes about 4.2 nanosecs or 238 million/
| second*/
| {unsigned long t,x,i; static c=0,j=4691;
|   j=(j<4690)? j+1:0;
|   x=Q[j];
|   t=(x<<13)+c+x; c=(t<x)+(x>>19);
|   return (Q[j]=t);
| }
|
| #define CNG ( xcng=69069*xcng+123 )
| #define XS ( xs^=(xs<<13), xs^=(xs>>17), xs^=(xs<<5) )
| #define KISS ( MWC()+CNG+XS ) /*138 million/sec*/
|
| #include <stdio.h>
| int main()
| {unsigned long i,x;
|  for(i=0;i<4691;i++) Q[i]=CNG+XS;
|  for(i=0;i<1000000000;i++) x=MWC();
|  printf(" MWC result=3740121002 ?\n%22u\n",x);
|  for(i=0;i<1000000000;i++) x=KISS;
|  printf("KISS result=2224631993 ?\n%22u\n",x);
| }

| So, what is all this?  In particular, is there something special about
| the value of 3.7 billion?

No, nothing special at all.
The purpose of the exercise is just to confirm that after generating
1000000000 random numbers, you get the same answer as George does. 

[toc] | [next] | [standalone]

#2984

"robin"  wrote in message

| So, what is all this?  In particular, is there something special about
| the value of 3.7 billion?

>No, nothing special at all.
>The purpose of the exercise is just to confirm that after generating
>1000000000 random numbers, you get the same answer as George does.

Alas, I think you are making some strong assumptions about the state of 
computing in the hereafter.

[toc] | [prev] | [next] | [standalone]

#3006

On 4/28/2011 11:42 PM, e p chandler wrote:
>
>
> "robin" wrote in message
>
> | So, what is all this? In particular, is there something special about
> | the value of 3.7 billion?
>
>> No, nothing special at all.
>> The purpose of the exercise is just to confirm that after generating
>> 1000000000 random numbers, you get the same answer as George does.
>
> Alas, I think you are making some strong assumptions about the state of
> computing in the hereafter.
>

George lives on in his code.

[toc] | [prev] | [next] | [standalone]

#3009

e p chandler wrote:
>
>
> "robin" wrote in message
>
> | So, what is all this? In particular, is there something special about
> | the value of 3.7 billion?
>
>> No, nothing special at all.
>> The purpose of the exercise is just to confirm that after generating
>> 1000000000 random numbers, you get the same answer as George does.
>
> Alas, I think you are making some strong assumptions about the state of
> computing in the hereafter.
>

All we have now are George Marsaglia's posts and writings.
I know there's now a move on the way to 64-bit processors,
which I take to mean the x86_64 or AMD64 design/instruction set.

In any case, with an executable compiled with a C compiler,
there's the function sizeof, which might be useful
in some cases at run time.

For example, one could add to main() in C :

printf("the size of an unsigned long in bytes is %d\n", sizeof(unsigned long));

There's also the Itanium architecture and others, and even with a known
processor, some compiler flags affect the number of bytes for
some data types, such as "long double" with the -m64 flag
on Fujitsu SPARC IV with Sun Solaris (--> 16 byte long
doubles with the -m64 flag).

AFAIK, sizeof(unsigned long) can be relied upon to give the size
in 8-bit bytes of a C "unsigned long".

Perhaps some documentation of language, machine, compiler, compiler
options examples where KISS4691 works as per the Marsaglia
specs could be helpful as a reference ...

David Bernier

-- 
The MegaPenny Project | One Trillion Pennies:
<http://www.kokogiak.com/megapenny/thirteen.asp>

[toc] | [prev] | [next] | [standalone]

#3010

On 04/29/11 01:50 PM, David Bernier wrote:
> e p chandler wrote:
>>
>>
>> "robin" wrote in message
>>
>> | So, what is all this? In particular, is there something special about
>> | the value of 3.7 billion?
>>
>>> No, nothing special at all.
>>> The purpose of the exercise is just to confirm that after generating
>>> 1000000000 random numbers, you get the same answer as George does.
>>
>> Alas, I think you are making some strong assumptions about the state of
>> computing in the hereafter.
>>
>
> All we have now are George Marsaglia's posts and writings.
> I know there's now a move on the way to 64-bit processors,
> which I take to mean the x86_64 or AMD64 design/instruction set.

The move happened several years ago (at least on the desktop and server).

> In any case, with an executable compiled with a C compiler,
> there's the function sizeof, which might be useful
> in some cases at run time.

Being pedantic, sizeof is a compile time operator when used with 
integral types.

> For example, one could add to main() in C :
>
> printf("the size of an unsigned long in bytes is %d\n", sizeof(unsigned long));

Given the code as written, assert(sizeof(unsigned long) == 4) would be 
more use.

> There's also the Itanium architecture and others, and even with a known
> processor, some compiler flags affect the number of bytes for
> some data types, such as "long double" with the -m64 flag
> on Fujitsu SPARC IV with Sun Solaris (-->  16 byte long
> doubles with the -m64 flag).
>
> AFAIK, sizeof(unsigned long) can be relied upon to give the size
> in 8-bit bytes of a C "unsigned long".

sizeof(unsigned long) is by definition the size in (not necessarily 8 
bit) bytes of an unsigned long.

> Perhaps some documentation of language, machine, compiler, compiler
> options examples where KISS4691 works as per the Marsaglia
> specs could be helpful as a reference ...

I suggested long ago the code be updated to use fixed width types, thus 
removing any ambiguities.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#3013

On 4/28/2011 10:09 PM, Ian Collins wrote:
> On 04/29/11 01:50 PM, David Bernier wrote:
>> [...]
>> All we have now are George Marsaglia's posts and writings.
>> I know there's now a move on the way to 64-bit processors,
>> which I take to mean the x86_64 or AMD64 design/instruction set.
>
> The move happened several years ago (at least on the desktop and server).

     ... for suitable values of "several."  DEC's first Alpha CPU's
shipped in 1992, and are now old enough to vote.

>> In any case, with an executable compiled with a C compiler,
>> there's the function sizeof, which might be useful
>> in some cases at run time.
>
> Being pedantic, sizeof is a compile time operator when used with
> integral types.

     It's an operator, always.  It's evaluable at compile time for
any operand, integral or not, except a variable-length array (whose
element count is not determined until run time).

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#3015

On 04/29/11 03:01 PM, Eric Sosman wrote:
> On 4/28/2011 10:09 PM, Ian Collins wrote:
>> On 04/29/11 01:50 PM, David Bernier wrote:
>
>>> In any case, with an executable compiled with a C compiler,
>>> there's the function sizeof, which might be useful
>>> in some cases at run time.
>>
>> Being pedantic, sizeof is a compile time operator when used with
>> integral types.
>
>       It's an operator, always.  It's evaluable at compile time for
> any operand, integral or not, except a variable-length array (whose
> element count is not determined until run time).

The context was integral types, I didn't want to venture anywhere near 
VLAs on a cross-post!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#3497

On 4/28/2011 8:09 PM, Ian Collins wrote:
> On 04/29/11 03:01 PM, Eric Sosman wrote:
>> On 4/28/2011 10:09 PM, Ian Collins wrote:
>>> On 04/29/11 01:50 PM, David Bernier wrote:
>>
>>>> In any case, with an executable compiled with a C compiler,
>>>> there's the function sizeof, which might be useful
>>>> in some cases at run time.
>>>
>>> Being pedantic, sizeof is a compile time operator when used with
>>> integral types.
>>
>> It's an operator, always. It's evaluable at compile time for
>> any operand, integral or not, except a variable-length array (whose
>> element count is not determined until run time).
>
> The context was integral types, I didn't want to venture anywhere near
> VLAs on a cross-post!
>

So Ian,

I wouldn't mind hearing your thoughts about corruption and empires.  Are 
they the same thing?

But to be topical, I thought I might re-write george in fortran, using 
the ISO_C_BINDING.

Attended the first funeral after my dad's today.
-- 
Uno

[toc] | [prev] | [next] | [standalone]

#3720

On 05/08/2011 01:34 AM, Uno wrote:
> On 4/28/2011 8:09 PM, Ian Collins wrote:

>> The context was integral types, I didn't want to venture anywhere near
>> VLAs on a cross-post!
>>
>
> So Ian,
>
> I wouldn't mind hearing your thoughts about corruption and empires. Are
> they the same thing?
>
> But to be topical, I thought I might re-write george in fortran, using
> the ISO_C_BINDING.
>
> Attended the first funeral after my dad's today.

Oh my goodness, you can't re-write george in these here united states.
-- 
mz

[toc] | [prev] | [next] | [standalone]

#3021

In article <ipd9oo$kug$1@dont-email.me>,
Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>On 4/28/2011 10:09 PM, Ian Collins wrote:
>
>>> In any case, with an executable compiled with a C compiler,
>>> there's the function sizeof, which might be useful
>>> in some cases at run time.
>>
>> Being pedantic, sizeof is a compile time operator when used with
>> integral types.
>
>     It's an operator, always.  It's evaluable at compile time for
>any operand, integral or not, except a variable-length array (whose
>element count is not determined until run time).

It's not just evaluable at compile time, it is evaluated using
only the type and not the value of the expression.  C99 6.5.3.4
paragraph 2.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#3014

Ian Collins wrote:
> On 04/29/11 01:50 PM, David Bernier wrote:
[...]

>> All we have now are George Marsaglia's posts and writings.
>> I know there's now a move on the way to 64-bit processors,
>> which I take to mean the x86_64 or AMD64 design/instruction set.
>
> The move happened several years ago (at least on the desktop and server).
>
>> In any case, with an executable compiled with a C compiler,
>> there's the function sizeof, which might be useful
>> in some cases at run time.
>
> Being pedantic, sizeof is a compile time operator when used with
> integral types.
>
>> For example, one could add to main() in C :
>>
>> printf("the size of an unsigned long in bytes is %d\n",
>> sizeof(unsigned long));
>
> Given the code as written, assert(sizeof(unsigned long) == 4) would be
> more use.
>
>> There's also the Itanium architecture and others, and even with a known
>> processor, some compiler flags affect the number of bytes for
>> some data types, such as "long double" with the -m64 flag
>> on Fujitsu SPARC IV with Sun Solaris (--> 16 byte long
>> doubles with the -m64 flag).
>>
>> AFAIK, sizeof(unsigned long) can be relied upon to give the size
>> in 8-bit bytes of a C "unsigned long".
>
> sizeof(unsigned long) is by definition the size in (not necessarily 8
> bit) bytes of an unsigned long.
>
>> Perhaps some documentation of language, machine, compiler, compiler
>> options examples where KISS4691 works as per the Marsaglia
>> specs could be helpful as a reference ...
>
> I suggested long ago the code be updated to use fixed width types, thus
> removing any ambiguities.

I'm sorry about the inaccuracies and falsehoods in my post.
I support your suggestion, perhaps also adding comments.
I'm the wrong person to update the code, but I would be
willing to test updated C code.

David Bernier

[toc] | [prev] | [next] | [standalone]

#3012

In comp.lang.fortran David Bernier <david250@videotron.ca> wrote:

(snip)
> All we have now are George Marsaglia's posts and writings.
> I know there's now a move on the way to 64-bit processors,
> which I take to mean the x86_64 or AMD64 design/instruction set.

I have an actual Itanium system, but not so many people do.

> In any case, with an executable compiled with a C compiler,
> there's the function sizeof, which might be useful
> in some cases at run time.

Well, sizeof is a compile time constant, but, yes, you can
use the value at run time.
 
(snip)
> AFAIK, sizeof(unsigned long) can be relied upon to give the size
> in 8-bit bytes of a C "unsigned long".

No.  You need CHAR_BIT to tell how many bits are in a char.
It has been known to get to 64 on word addressed 64 bit machines.
It must be at least 8, but can be more.

-- glen

[toc] | [prev] | [next] | [standalone]

#3023

On 04/28/2011 08:34 PM, glen herrmannsfeldt wrote:
> In comp.lang.fortran David Bernier<david250@videotron.ca>  wrote:
>
> (snip)
>> All we have now are George Marsaglia's posts and writings.
>> I know there's now a move on the way to 64-bit processors,
>> which I take to mean the x86_64 or AMD64 design/instruction set.
>
> I have an actual Itanium system, but not so many people do.
>
>> In any case, with an executable compiled with a C compiler,
>> there's the function sizeof, which might be useful
>> in some cases at run time.
>
> Well, sizeof is a compile time constant, but, yes, you can
> use the value at run time.
>
> (snip)
>> AFAIK, sizeof(unsigned long) can be relied upon to give the size
>> in 8-bit bytes of a C "unsigned long".
>
> No.  You need CHAR_BIT to tell how many bits are in a char.
> It has been known to get to 64 on word addressed 64 bit machines.
> It must be at least 8, but can be more.
>
> -- glen

I'm dealing with this same issue in my real life, as my algebraist uncle 
seems to have early-onset alzheimer's.   So he has his demonstrable 
achievements in science and the last few years where he embarrassed himself.

George's C was atrocious at the end.  I'd like to let that die.

A kiss is a kiss; it's simple, effective, and not improved by 
redefinition when you've lost your marbles.
-- 
Uno

[toc] | [prev] | [next] | [standalone]

#3086

"Uno" <Uno@example.invalid> wrote in message news:91v675F30vU1@mid.individual.net...

| I'm dealing with this same issue in my real life, as my algebraist uncle
| seems to have early-onset alzheimer's.   So he has his demonstrable
| achievements in science and the last few years where he embarrassed himself.
|
| George's C was atrocious at the end.  I'd like to let that die.

You might not have liked George's programming style,
but there is no suggestion that he was losing it.

| A kiss is a kiss; it's simple, effective, and not improved by
| redefinition when you've lost your marbles. 

[toc] | [prev] | [next] | [standalone]

#3244

On 04/30/2011 04:48 AM, robin wrote:

> You might not have liked George's programming style,
> but there is no suggestion that he was losing it.

If no one has suggested it, then I do so herewith.  What proof do you 
need?  (That the guy died?)

I'm not a stranger to numbers or C.  It's not "potentially top-ranked" 
so much as "rank."

I apologize to those I might offend with such rhetoric.  His 
acknowledged contributions to computer science live on.
- -
Uno

[toc] | [prev] | [next] | [standalone]

#3039

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> In comp.lang.fortran David Bernier <david250@videotron.ca> wrote:
[...]
>> AFAIK, sizeof(unsigned long) can be relied upon to give the size
>> in 8-bit bytes of a C "unsigned long".
>
> No.  You need CHAR_BIT to tell how many bits are in a char.
> It has been known to get to 64 on word addressed 64 bit machines.
> It must be at least 8, but can be more.

Certainly CHAR_BIT *could* be 64 (or even more), but I've never heard
of a 64-bit system with CHAR_BIT==64.  Such an implementation would
have trouble dealing with octet-oriented data from other systems.
Some DSPs (digital signal processors) do have CHAR_BIT > 8.
There have been systems with, for example, 9-bit bytes, but they
had pretty much become obsolete by the time C was standardized.

C defines two kinds of implementations, hosted and freestanding.
Hosted implementations must support the full standard library
(stdio and so forth); freestanding implementations are typically for
systems where the program doesn't run under an operating system,
such as embedded systems and OS kernels.  I've never heard of a
hosted implementation with CHAR_BIT > 8.

Do you know of such a system?

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

[toc] | [prev] | [next] | [standalone]

#3052

In comp.lang.fortran Keith Thompson <kst-u@mib.org> wrote:

(snip, I wrote)
>> No.  You need CHAR_BIT to tell how many bits are in a char.
>> It has been known to get to 64 on word addressed 64 bit machines.
>> It must be at least 8, but can be more.
 
> Certainly CHAR_BIT *could* be 64 (or even more), but I've never heard
> of a 64-bit system with CHAR_BIT==64.  Such an implementation would
> have trouble dealing with octet-oriented data from other systems.
> Some DSPs (digital signal processors) do have CHAR_BIT > 8.
> There have been systems with, for example, 9-bit bytes, but they
> had pretty much become obsolete by the time C was standardized.

The story I remember was for a Cray machine, but I never used
one to check on it.  I do know that there are some 64 bit
word addressed machines, especially some from Cray.

-- glen

[toc] | [prev] | [next] | [standalone]

#3057

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> In comp.lang.fortran Keith Thompson <kst-u@mib.org> wrote:
> (snip, I wrote)
>>> No.  You need CHAR_BIT to tell how many bits are in a char.
>>> It has been known to get to 64 on word addressed 64 bit machines.
>>> It must be at least 8, but can be more.
>  
>> Certainly CHAR_BIT *could* be 64 (or even more), but I've never heard
>> of a 64-bit system with CHAR_BIT==64.  Such an implementation would
>> have trouble dealing with octet-oriented data from other systems.
>> Some DSPs (digital signal processors) do have CHAR_BIT > 8.
>> There have been systems with, for example, 9-bit bytes, but they
>> had pretty much become obsolete by the time C was standardized.
>
> The story I remember was for a Cray machine, but I never used
> one to check on it.  I do know that there are some 64 bit
> word addressed machines, especially some from Cray.

I used to work on a Cray T90.  It had 64-bit words, and no direct
hardware access to smaller chunks of memory; to read an 8-bit byte,
you had to read the word containing it and then extract the bits
you wanted.  But the C compiler (C90, it never implemented C99)
had CHAR_BIT==8.  char was 8 bits; short, int, and long were all
64 bits.  A pointer to anything smaller than a 64-bit word stored
the byte offset in the high-order 3 bits (the address space was
much smaller than 64 bits, so the high-order bits weren't being
used for anything else).  This was all handled in software; the
compiler had to generate extra instructions to deal with byte data.

Making CHAR_BIT==64 would have made much more sense for the machine
itself in isolation, but it would have made interoperability with
other systems quite difficult.  It ran Unicos, Cray's BSDish Unix;
I'm not sure you can even implement Unix with bytes bigger than
8 bits.

It made it very slow for things like string processing, but since
it was primarily used for floating-point computations that wasn't
much of an issue.

Some older Cray vector systems ran other, non-Unix, operating systems
(COS, CTSS), but I never used any of those, and I don't know what
value their compilers used for CHAR_BIT -- if C was even supported.

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

[toc] | [prev] | [next] | [standalone]

#3333

In article <lnoc3ox2a0.fsf@nuthaus.mib.org>,
 Keith Thompson <kst-u@mib.org> wrote:

> Making CHAR_BIT==64 would have made much more sense for the machine
> itself in isolation, but it would have made interoperability with
> other systems quite difficult.  It ran Unicos, Cray's BSDish Unix;
> I'm not sure you can even implement Unix with bytes bigger than
> 8 bits.

Could tack on a satellite machine for interoperability
the way ARPANET was first configured. Each big machine
at Illinois, etc. had a Burroughs (6600?) that actually
did the networking.

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

#3061

On 2011-04-29, Keith Thompson <kst-u@mib.org> wrote:
> Certainly CHAR_BIT *could* be 64 (or even more), but I've never heard
> of a 64-bit system with CHAR_BIT==64.  Such an implementation would
> have trouble dealing with octet-oriented data from other systems.

I've heard of at least one system where sizeof(int64_t) was 1, but I'm not
sure what range of values was allowed in chars.  Presumably unsigned char
was 0..2^64-1.

It was also a LONG time ago, and may not have been standard C.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web