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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#3069

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnsjt1w0oc.fsf@nuthaus.mib.org...
> 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.

The Unisys U2200 implementation that we used in the mid-1990's had 9-bit 
characters, and had a full C implementation. I didn't use it much personally 
(I was working on the Ada compiler), but we had extensive facilities to 
interface to the C compiler which definitely used pointers at 9-bit bytes. 
(The machine was most efficient when used with 36-bit word addressing, which 
we used extensively in the Ada compiler, but the C-compiler used double-word 
pointers including a byte offset -- so we had to have conversion facilities 
to get back and forth).

Not sure of exactly what version of C that was, but surely well after "C was 
standardized".

                                  Randy.

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

#3060

On 2011-04-29, 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, it can be relied to give the size in "bytes" in C of "unsigned long",
but "byte" is just a synonym for "the type char", and there have been
systems where that's not 8-bit bytes.

-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]

#3068

"e p chandler" <epc8@juno.com> wrote in message news:ipbjqf$q4k$1@dont-email.me...

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

The sun is not scheduled for burnout for a few million years yet. 

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

#3103

On 4/27/2011 6:14 PM, robin wrote:
> "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.

Here is a modification of the program with masking to produce correct results 
with any conforming C implementation.  It truncates where when required.  A good 
optimizer should eliminate the unneeded masking for 32-bit unsigned long.

static unsigned long xs = 521288629;
static unsigned long xcng = 362436069;
static unsigned long Q[4691];

#define M32 0xffffffff

unsigned long   MWC(void)
{
     static unsigned long c = 0;
     static unsigned long j = 4691;
     unsigned long   t;
     unsigned long   x;
     j = (j < 4690) ? j + 1 : 0;
     x = Q[j];
     t = ((x << 13) + c) & M32;
     if (t < c) {
         c = (x >> 19) + 1;
         t = (t + x) & M32;
     } else {
         t = (t + x) & M32;
         c = (x >> 19) + (t < x);
     }
     return (Q[j] = t);

}

void            initMWC(void)
{
     unsigned long   i;
     for (i = 0; i < sizeof Q / sizeof Q[0]; i++)
         Q[i] = ((xcng = 69069 * xcng + 123) + (xs = (xs ^ (xs << 13)) & M32,
                 xs ^= (xs >> 17), xs ^= (xs << 5))) & M32;

}

#ifdef UNIT_TEST

#include <stdio.h>

int             main()
{
     unsigned long   i;
     unsigned long   x;

     initMWC();

     printf("Does  MWC result=3740121002 ?\n");
     for (i = 0; i < 1000000000; i++)
         x = MWC();
     printf("%27u\n", x);

     printf("Does KISS result=2224631993 ?\n");
     for (i = 0; i < 1000000000; i++)
         x = (MWC() + (xcng = 69069 * xcng + 123) + (xs = (xs ^ (xs << 13)) & M32,
              xs ^= (xs >> 17), xs ^= (xs << 5)));
     printf("%27u\n", x);
     return 0;
}

#endif



-- 
Thad

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

#3111

On 05/ 2/11 03:31 AM, Thad Smith wrote:
>
> Here is a modification of the program with masking to produce correct results
> with any conforming C implementation.  It truncates where when required.  A good
> optimizer should eliminate the unneeded masking for 32-bit unsigned long.

Why oh why can't people just use fixed width types?  What's the 
obsession with unsigned long and masking?

Add

#include <stdint.h>

change all references to "unsigned long" to uint32_t, remove all 
references to M32.

> static unsigned long xs = 521288629;
> static unsigned long xcng = 362436069;
> static unsigned long Q[4691];

> #define M32 0xffffffff
>
> unsigned long   MWC(void)
> {
>       static unsigned long c = 0;
>       static unsigned long j = 4691;
>       unsigned long   t;
>       unsigned long   x;
>       j = (j<  4690) ? j + 1 : 0;
>       x = Q[j];
>       t = ((x<<  13) + c)&  M32;
>       if (t<  c) {
>           c = (x>>  19) + 1;
>           t = (t + x)&  M32;
>       } else {
>           t = (t + x)&  M32;
>           c = (x>>  19) + (t<  x);
>       }
>       return (Q[j] = t);
>
> }
>
> void            initMWC(void)
> {
>       unsigned long   i;
>       for (i = 0; i<  sizeof Q / sizeof Q[0]; i++)
>           Q[i] = ((xcng = 69069 * xcng + 123) + (xs = (xs ^ (xs<<  13))&  M32,
>                   xs ^= (xs>>  17), xs ^= (xs<<  5)))&  M32;
>
> }
>
> #ifdef UNIT_TEST
>
> #include<stdio.h>
>
> int             main()
> {
>       unsigned long   i;
>       unsigned long   x;
>
>       initMWC();
>
>       printf("Does  MWC result=3740121002 ?\n");
>       for (i = 0; i<  1000000000; i++)
>           x = MWC();
>       printf("%27u\n", x);
>
>       printf("Does KISS result=2224631993 ?\n");
>       for (i = 0; i<  1000000000; i++)
>           x = (MWC() + (xcng = 69069 * xcng + 123) + (xs = (xs ^ (xs<<  13))&  M32,
>                xs ^= (xs>>  17), xs ^= (xs<<  5)));
>       printf("%27u\n", x);
>       return 0;
> }
>
> #endif
>
>
>


-- 
Ian Collins

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

#3114

On 05/01/2011 03:58 PM, Ian Collins wrote:
> On 05/ 2/11 03:31 AM, Thad Smith wrote:
>>
>> Here is a modification of the program with masking to produce correct results
>> with any conforming C implementation.  It truncates where when required.  A good
>> optimizer should eliminate the unneeded masking for 32-bit unsigned long.
> 
> Why oh why can't people just use fixed width types?

Because, in C at least, it's not mandatory for a conforming
implementation to support any of the fixed-width types.

-- 
James Kuyper

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

#3115

On 05/ 2/11 12:01 PM, James Kuyper wrote:
> On 05/01/2011 03:58 PM, Ian Collins wrote:
>> On 05/ 2/11 03:31 AM, Thad Smith wrote:
>>>
>>> Here is a modification of the program with masking to produce correct results
>>> with any conforming C implementation.  It truncates where when required.  A good
>>> optimizer should eliminate the unneeded masking for 32-bit unsigned long.
>>
>> Why oh why can't people just use fixed width types?
>
> Because, in C at least, it's not mandatory for a conforming
> implementation to support any of the fixed-width types.

But it's hardly rocket science to declare them for implementations that 
lack them.

-- 
Ian Collins

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

#3117

On 05/01/2011 08:42 PM, Ian Collins wrote:
> On 05/ 2/11 12:01 PM, James Kuyper wrote:
>> On 05/01/2011 03:58 PM, Ian Collins wrote:
>>> On 05/ 2/11 03:31 AM, Thad Smith wrote:
>>>>
>>>> Here is a modification of the program with masking to produce correct results
>>>> with any conforming C implementation.  It truncates where when required.  A good
>>>> optimizer should eliminate the unneeded masking for 32-bit unsigned long.
>>>
>>> Why oh why can't people just use fixed width types?
>>
>> Because, in C at least, it's not mandatory for a conforming
>> implementation to support any of the fixed-width types.
> 
> But it's hardly rocket science to declare them for implementations that 
> lack them.

More accurately, it's generally impossible to declare them for
implementations that lack them. If the implementation choses not to
provide a particular fixed-width type, it's generally because it's not
possible to do so on that platform; less frequently, it's because it
would be inconvenient to support them.

-- 
James Kuyper

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

#3118

In comp.lang.fortran Ian Collins <ian-news@hotmail.com> wrote:

(snip, someone wrote)
>> Because, in C at least, it's not mandatory for a conforming
>> implementation to support any of the fixed-width types.
 
> But it's hardly rocket science to declare them for implementations that 
> lack them.

With the assumption that the fixed-width is one implemented on
the host machine.  Neither Fortran nor C require a machine to
support a 32 bit type.  (Java does.)

-- glen

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

#3119

On 5/1/2011 12:58 PM, Ian Collins wrote:
> On 05/ 2/11 03:31 AM, Thad Smith wrote:
>>
>> Here is a modification of the program with masking to produce correct results
>> with any conforming C implementation. It truncates where when required. A good
>> optimizer should eliminate the unneeded masking for 32-bit unsigned long.
>
> Why oh why can't people just use fixed width types? What's the obsession with
> unsigned long and masking?

In my case, I work with a lot of compilers not supporting C99.  The code is thus 
more portable to existing applications.  Standard C doesn't guarantee the 
existence of a 32-bit integer type.

-- 
Thad

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

#3123

In article <4dbe2304$0$12961$892e0abb@auth.newsreader.octanews.com>,
Thad Smith  <ThadSmith@acm.org> wrote:
>On 5/1/2011 12:58 PM, Ian Collins wrote:
>> On 05/ 2/11 03:31 AM, Thad Smith wrote:
>>>
>>> Here is a modification of the program with masking to produce correct results
>>> with any conforming C implementation. It truncates where when required. A good
>>> optimizer should eliminate the unneeded masking for 32-bit unsigned long.
>>
>> Why oh why can't people just use fixed width types? What's the obsession with
>> unsigned long and masking?
>
>In my case, I work with a lot of compilers not supporting C99.  The code is thus 
>more portable to existing applications.  Standard C doesn't guarantee the 
>existence of a 32-bit integer type.

As those of us with significant experience of portability will
remember, building fixed sizes into a program is a cardinal
error.  Sooner or later, you will want to run that code on a
system with different sizes, and it won't work.  The vast
majority of clean programs, even in C90, needed NO source
changes to go from 32 to 64 bits; I have written code that was
moved to systems with 16, 24, 32, 36, 48, 60, 64 and perhaps
other sizes, and so have many other people.

I accept that Marsaglia's generator is a valid case for using
fixed-width types, but that is likely to make it very inefficient
indeed on a system where they are not natural.  Masking is a
far more portably efficient approach.


Regards,
Nick Maclaren.

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

#4546

<nmm1@cam.ac.uk> wrote in message news:iplmk8$2s6$1@gosset.csi.cam.ac.uk...

| As those of us with significant experience of portability will
| remember, building fixed sizes into a program is a cardinal
| error.  Sooner or later, you will want to run that code on a
| system with different sizes, and it won't work.

That's because FORTRAN was designed around a word machine,
where float precisions offered were single and/or single and double precision.
That could cause different actions when moving from a 32-bit word machine
to 60/64-bit word machine,

Later languages, including PL/I, were designed bearing in mind
byte machines.  The way in which float precisions are specified
lends itself to portability.  Thus, asking for say, 12 decimal digits
got you about that number of digits, whether the machine offered
32-bit or 60-bit words.  Some machines actually offered decimal
(BCD) floats in hardware,* and asking for 12 decimals got you about
that number of digits.

|  The vast
| majority of clean programs, even in C90, needed NO source
| changes to go from 32 to 64 bits; I have written code that was
| moved to systems with 16, 24, 32, 36, 48, 60, 64 and perhaps
| other sizes, and so have many other people.

Indeed.  (Including doing portable character handling before F77.)

| I accept that Marsaglia's generator is a valid case for using
| fixed-width types, but that is likely to make it very inefficient
| indeed on a system where they are not natural.

I very much doubt that any new machine is going to offer less than 32 bit
integer words ; for some years now the trend has been to machines of
64-bit integers.  Marsaglia's (integer) algorithms will run on such machines,
some possibly with minor alterations, but will not, even if modified,
will not run "inefficiently".

|  Masking is a
| far more portably efficient approach.

_______________
* some still do, in an updated verion of decimal. 

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

#4547

<nmm1@cam.ac.uk> wrote in message news:iplmk8$2s6$1@gosset.csi.cam.ac.uk...

| As those of us with significant experience of portability will
| remember, building fixed sizes into a program is a cardinal
| error.  Sooner or later, you will want to run that code on a
| system with different sizes, and it won't work.

That's because FORTRAN was designed around a word machine,
where float precisions offered were either single and double precision.
That could cause different actions when moving from a 32-bit word machine
to 60/64-bit word machine,

Later languages, including PL/I, were designed around
byte machines.  The way in which float precisions are specified
lends itself to portability.  Thus, asking for say, 12 decimal digits
got you about that number of digits, whether the machine offered
32-bit or 60-bit words.  Some machines actually offered decimal
(BCD) floats in hardware,* and asking for 12 decimals got you about
that number of digits.

|  The vast
| majority of clean programs, even in C90, needed NO source
| changes to go from 32 to 64 bits; I have written code that was
| moved to systems with 16, 24, 32, 36, 48, 60, 64 and perhaps
| other sizes, and so have many other people.

Indeed.  (Including doing portable character handling before F77.)

| I accept that Marsaglia's generator is a valid case for using
| fixed-width types, but that is likely to make it very inefficient
| indeed on a system where they are not natural.

I very much doubt that any new machine is going to offer less than 32 bit
integer words ; for some years now the trend has been to machines of
64-bit integers.  Marsaglia's (integer) algorithms will run on such machines,
some possibly with minor alterations, but will not, even if modified,
will not run "inefficiently".

|  Masking is a
| far more portably efficient approach.

_______________
* some still do, in an updated verion of decimal. 

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

#4553

"robin" <robin51@dodo.mapson.com.au> wrote in message news:4dda042b$1$67779$c30e37c6@exi-reader.telstra.net...

Looks like ISP server's malfunctioned again. 

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

#4548

<nmm1@cam.ac.uk> wrote in message news:iplmk8$2s6$1@gosset.csi.cam.ac.uk...

| As those of us with significant experience of portability will
| remember, building fixed sizes into a program is a cardinal
| error.  Sooner or later, you will want to run that code on a
| system with different sizes, and it won't work.

That's because FORTRAN was designed around a word machine,
where float precisions offered were single and/or single and double precision.
That could cause different actions when moving from a 32-bit word machine
to 60/64-bit word machine,

Later languages, including PL/I, were designed bearing in mind
byte machines.  The way in which float precisions are specified
lends itself to portability.  Thus, asking for say, 12 decimal digits
got you about that number of digits, whether the machine offered
32-bit or 60-bit words.  Some machines actually offered decimal
(BCD) floats in hardware,* and asking for 12 decimals got you about
that number of digits.

|  The vast
| majority of clean programs, even in C90, needed NO source
| changes to go from 32 to 64 bits; I have written code that was
| moved to systems with 16, 24, 32, 36, 48, 60, 64 and perhaps
| other sizes, and so have many other people.

Indeed.  (Including doing portable character handling before F77.)

| I accept that Marsaglia's generator is a valid case for using
| fixed-width types, but that is likely to make it very inefficient
| indeed on a system where they are not natural.

I very much doubt that any new machine is going to offer less than 32 bit
integer words ; for some years now the trend has been to machines of
64-bit integers.  Marsaglia's (integer) algorithms will run on such machines,
some possibly with minor alterations, but will not, even if modified,
will not run "inefficiently".

|  Masking is a
| far more portably efficient approach.

_______________
* some still do, in an updated verion of decimal. 

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

#4549

<nmm1@cam.ac.uk> wrote in message news:iplmk8$2s6$1@gosset.csi.cam.ac.uk...

| As those of us with significant experience of portability will
| remember, building fixed sizes into a program is a cardinal
| error.  Sooner or later, you will want to run that code on a
| system with different sizes, and it won't work.

That's because FORTRAN was designed around a word machine,
where float precisions offered were single and/or single and double precision.
That could cause different actions when moving from a 32-bit word machine
to 60/64-bit word machine,

Later languages, including PL/I, were designed bearing in mind
byte machines.  The way in which float precisions are specified
lends itself to portability.  Thus, asking for say, 12 decimal digits
got you about that number of digits, whether the machine offered
32-bit or 60-bit words.  Some machines actually offered decimal
(BCD) floats in hardware,* and asking for 12 decimals got you about
that number of digits.

|  The vast
| majority of clean programs, even in C90, needed NO source
| changes to go from 32 to 64 bits; I have written code that was
| moved to systems with 16, 24, 32, 36, 48, 60, 64 and perhaps
| other sizes, and so have many other people.

Indeed.  (Including doing portable character handling before F77.)

| I accept that Marsaglia's generator is a valid case for using
| fixed-width types, but that is likely to make it very inefficient
| indeed on a system where they are not natural.

I very much doubt that any new machine is going to offer less than 32 bit
integer words ; for some years now the trend has been to machines of
64-bit integers.  Marsaglia's (integer) algorithms will run on such machines,
some possibly with minor alterations, but will not, even if modified,
will not run "inefficiently".

|  Masking is a
| far more portably efficient approach.

_______________
* some still do, in an updated verion of decimal. 

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

#4550

<nmm1@cam.ac.uk> wrote in message news:iplmk8$2s6$1@gosset.csi.cam.ac.uk...

| As those of us with significant experience of portability will
| remember, building fixed sizes into a program is a cardinal
| error.  Sooner or later, you will want to run that code on a
| system with different sizes, and it won't work.

That's because FORTRAN was designed around a word machine,
where float precisions offered were single and/or single and double precision.
That could cause different actions when moving from a 32-bit word machine
to 60/64-bit word machine,

Later languages, including PL/I, were designed bearing in mind
byte machines.  The way in which float precisions are specified
lends itself to portability.  Thus, asking for say, 12 decimal digits
got you about that number of digits, whether the machine offered
32-bit or 60-bit words.  Some machines actually offered decimal
(BCD) floats in hardware,* and asking for 12 decimals got you about
that number of digits.

|  The vast
| majority of clean programs, even in C90, needed NO source
| changes to go from 32 to 64 bits; I have written code that was
| moved to systems with 16, 24, 32, 36, 48, 60, 64 and perhaps
| other sizes, and so have many other people.

Indeed.  (Including doing portable character handling before F77.)

| I accept that Marsaglia's generator is a valid case for using
| fixed-width types, but that is likely to make it very inefficient
| indeed on a system where they are not natural.

I very much doubt that any new machine is going to offer less than 32 bit
integer words ; for some years now the trend has been to machines of
64-bit integers.  Marsaglia's (integer) algorithms will run on such machines,
some possibly with minor alterations, but will not, even if modified,
will not run "inefficiently".

|  Masking is a
| far more portably efficient approach.

_______________
* some still do, in an updated verion of decimal. 

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

#4552

On 5/23/11 8:53 AM, robin wrote:
> <nmm1@cam.ac.uk>  wrote in message news:iplmk8$2s6$1@gosset.csi.cam.ac.uk...

> | I accept that Marsaglia's generator is a valid case for using
> | fixed-width types, but that is likely to make it very inefficient
> | indeed on a system where they are not natural.
>
> I very much doubt that any new machine is going to offer less than 32 bit
> integer words ; for some years now the trend has been to machines of
> 64-bit integers.

Not sure about the kind and specifics of technical systems in which
number generation plays a part.

But in case it does matter in computers embedded in  other
systems: the number of <32bit microcontrollers exceeds
the number of >=32bit processors built into PCs and
mobile computers (including "cellphones").

According to Wikipedia, counting all CPUs sold, even the share
of 8bit µcontrollers is more than a half. (They give sources for
the numbers.)

TTBOMK, it is very common that C compilers for 8bit
µcontrollers will offer int as a 16bit type.

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

#4848

On 2011-05-23, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> wrote:
>
> According to Wikipedia, counting all CPUs sold, even the share
> of 8bit µcontrollers is more than a half. (They give sources for
> the numbers.)
>
> TTBOMK, it is very common that C compilers for 8bit
> µcontrollers will offer int as a 16bit type.

In fact, I believe the C standard says that "int" must be at least 16
bits.

-- 
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.

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

#7126

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:4dda09ca$0$6629$9b4e6d93@newsspool2.arcor-online.net...
|
| According to Wikipedia, counting all CPUs sold, even the share
| of 8bit ľcontrollers is more than a half. (They give sources for
| the numbers.)

Wikipedia is not a reliable source. 

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web