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

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

formats and endians

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

Contents

  formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 04:49 -0800
    formats and endians John Bode <jfbode1029@gmail.com> - 2014-12-16 05:24 -0800
      Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 05:38 -0800
        Re: formats and endians Kleuske <kleuske@nowhere.net> - 2014-12-16 13:55 +0000
          Re: formats and endians Stephen Sprunk <stephen@sprunk.org> - 2014-12-16 11:49 -0600
            Re: formats and endians BGB <cr88192@hotmail.com> - 2014-12-16 21:37 -0600
              Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-17 01:08 -0800
                Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-17 02:42 -0800
              Re: formats and endians Stephen Sprunk <stephen@sprunk.org> - 2014-12-18 14:38 -0600
                Re: formats and endians Rosario193 <Rosario@invalid.invalid> - 2014-12-18 23:09 +0100
                Re: formats and endians BGB <cr88192@hotmail.com> - 2014-12-18 16:52 -0600
            Re: formats and endians Kleuske <kleuske@nowhere.net> - 2014-12-17 11:11 +0000
              Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-17 03:49 -0800
              Re: formats and endians Stephen Sprunk <stephen@sprunk.org> - 2014-12-18 16:28 -0600
                Re: formats and endians BGB <cr88192@hotmail.com> - 2014-12-18 19:38 -0600
                Re: formats and endians Kleuske <kleuske@nowhere.net> - 2014-12-21 14:17 +0000
                  Re: formats and endians Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-22 02:19 -0800
                  Re: formats and endians Stephen Sprunk <stephen@sprunk.org> - 2015-01-15 12:18 -0600
                    Re: formats and endians Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-15 22:35 +0000
                      Re: formats and endians raltbos@xs4all.nl (Richard Bos) - 2015-01-20 16:06 +0000
                        Re: formats and endians Barry Schwarz <schwarzb@dqel.com> - 2015-01-22 15:41 -0800
                          Re: formats and endians Robert Wessel <robertwessel2@yahoo.com> - 2015-01-23 00:45 -0600
                            Re: formats and endians Richard Heathfield <invalid@see.sig.invalid> - 2015-01-23 08:52 +0000
                              Re: formats and endians Robert Wessel <robertwessel2@yahoo.com> - 2015-01-23 05:47 -0600
                              Re: formats and endians Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-23 03:51 -0800
                                Re: formats and endians Bartc <bc@freeuk.com> - 2015-01-23 12:18 +0000
                                  Re: formats and endians raltbos@xs4all.nl (Richard Bos) - 2015-01-23 13:49 +0000
                                  Re: formats and endians fir <profesor.fir@gmail.com> - 2015-01-23 07:02 -0800
                                  Re: formats and endians fmassei@gmail.com - 2015-01-23 07:39 -0800
                              Re: formats and endians Lowell Gilbert <lgusenet@be-well.ilk.org> - 2015-01-23 10:38 -0500
                                Re: formats and endians Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-23 17:45 +0000
                                  Re: formats and endians James Kuyper <jameskuyper@verizon.net> - 2015-01-23 12:59 -0500
                                    Re: formats and endians Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-23 18:30 +0000
                                      Re: formats and endians James Kuyper <jameskuyper@verizon.net> - 2015-01-26 12:35 -0500
                                        Re: formats and endians Richard Heathfield <invalid@see.sig.invalid> - 2015-01-26 18:15 +0000
                                          Re: formats and endians Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-26 10:53 -0800
                                            Re: formats and endians Richard Heathfield <invalid@see.sig.invalid> - 2015-01-26 19:06 +0000
                                            Re: formats and endians Les Cargill <lcargill99@comcast.com> - 2015-01-26 17:54 -0600
                                          Re: formats and endians Stephen Sprunk <stephen@sprunk.org> - 2015-01-26 19:09 -0600
                                            Re: formats and endians Richard Heathfield <invalid@see.sig.invalid> - 2015-01-27 01:49 +0000
                                            Re: formats and endians James Kuyper <jameskuyper@verizon.net> - 2015-01-26 21:37 -0500
                                    Re: formats and endians raltbos@xs4all.nl (Richard Bos) - 2015-01-23 22:33 +0000
                                  Re: formats and endians Richard Heathfield <invalid@see.sig.invalid> - 2015-01-23 18:02 +0000
                                    Re: formats and endians Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-23 18:50 +0000
                                    Re: formats and endians glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-24 00:01 +0000
                                      Re: formats and endians raltbos@xs4all.nl (Richard Bos) - 2015-01-24 10:05 +0000
                                        Re: formats and endians glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-24 11:57 +0000
                                          Re: formats and endians Geoff <geoff@invalid.invalid> - 2015-01-24 07:48 -0800
                                    Re: formats and endians Bartc <bc@freeuk.com> - 2015-01-24 10:43 +0000
                                      Re: formats and endians Geoff <geoff@invalid.invalid> - 2015-01-24 07:52 -0800
                          Re: formats and endians raltbos@xs4all.nl (Richard Bos) - 2015-01-23 13:51 +0000
        Re: formats and endians John Bode <jfbode1029@gmail.com> - 2014-12-16 06:56 -0800
      Re: formats and endians Robert Wessel <robertwessel2@yahoo.com> - 2014-12-16 13:20 -0600
        Re: formats and endians Stephen Sprunk <stephen@sprunk.org> - 2014-12-16 18:00 -0600
          Re: formats and endians "Bill Cunningham" <nospam@nspam.invalid> - 2014-12-17 16:32 -0500
    Re: formats and endians David Brown <david.brown@hesbynett.no> - 2014-12-16 15:26 +0100
      Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 06:57 -0800
        Re: formats and endians Lowell Gilbert <lgusenet@be-well.ilk.org> - 2014-12-16 11:34 -0500
          Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 08:47 -0800
            Re: formats and endians BartC <bc@freeuk.com> - 2014-12-16 17:02 +0000
              Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 10:49 -0800
                Re: formats and endians BartC <bc@freeuk.com> - 2014-12-16 19:10 +0000
                  Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 11:28 -0800
                    Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 11:43 -0800
                      Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 11:58 -0800
                        Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 12:20 -0800
                        Re: formats and endians BartC <bc@freeuk.com> - 2014-12-16 20:21 +0000
                          Re: formats and endians Keith Thompson <kst-u@mib.org> - 2014-12-16 13:08 -0800
                            Re: formats and endians Richard Heathfield <invalid@see.sig.invalid> - 2014-12-16 21:19 +0000
                            Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 13:27 -0800
                            Re: formats and endians Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-16 16:41 -0800
                          Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 13:22 -0800
                            Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 14:00 -0800
                              Re: formats and endians BartC <bc@freeuk.com> - 2014-12-16 22:26 +0000
                                Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 14:54 -0800
                                  Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 15:09 -0800
                    Re: formats and endians BartC <bc@freeuk.com> - 2014-12-16 20:08 +0000
                      Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 12:48 -0800
              Re: formats and endians Kaz Kylheku <kaz@kylheku.com> - 2014-12-16 22:21 +0000
                Re: formats and endians BartC <bc@freeuk.com> - 2014-12-16 22:39 +0000
                  Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 15:32 -0800
                  Re: formats and endians glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-17 00:51 +0000
                    Re: formats and endians BartC <bc@freeuk.com> - 2014-12-17 11:04 +0000
                      Re: formats and endians glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-17 17:04 +0000
            Re: formats and endians Lowell Gilbert <lgusenet@be-well.ilk.org> - 2014-12-16 12:29 -0500
            Re: formats and endians Ken Brody <kenbrody@spamcop.net> - 2014-12-16 12:40 -0500
              Re: formats and endians Lowell Gilbert <lgusenet@be-well.ilk.org> - 2014-12-16 13:10 -0500
                Re: formats and endians Kaz Kylheku <kaz@kylheku.com> - 2014-12-16 18:35 +0000
                  Re: formats and endians Stephen Sprunk <stephen@sprunk.org> - 2014-12-16 12:57 -0600
                    Re: formats and endians Lowell Gilbert <lgusenet@be-well.ilk.org> - 2014-12-16 15:11 -0500
                      Re: formats and endians Stephen Sprunk <stephen@sprunk.org> - 2014-12-16 18:10 -0600
              Re: formats and endians fir <profesor.fir@gmail.com> - 2014-12-16 10:51 -0800
              Re: formats and endians glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-16 19:43 +0000
          Re: formats and endians Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-16 10:37 -0800
            Re: formats and endians Stephen Sprunk <stephen@sprunk.org> - 2014-12-16 13:05 -0600
              Re: formats and endians Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-16 11:49 -0800
                Re: formats and endians Stephen Sprunk <stephen@sprunk.org> - 2014-12-16 17:16 -0600
            Re: formats and endians Lowell Gilbert <lgusenet@be-well.ilk.org> - 2014-12-16 14:55 -0500
              Re: formats and endians Stephen Sprunk <stephen@sprunk.org> - 2014-12-16 17:48 -0600
                Re: formats and endians BGB <cr88192@hotmail.com> - 2014-12-17 00:18 -0600
                  Re: formats and endians Stephen Sprunk <stephen@sprunk.org> - 2014-12-20 12:21 -0600
                    Re: formats and endians BGB <cr88192@hotmail.com> - 2014-12-22 01:38 -0600
        Re: formats and endians Stephen Sprunk <stephen@sprunk.org> - 2014-12-16 11:45 -0600
      Re: formats and endians Michael Angelo Ravera <maravera@prodigy.net> - 2014-12-18 16:50 -0800
    Re: formats and endians Nobody <nobody@nowhere.invalid> - 2014-12-17 04:51 +0000
      Re: formats and endians Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-19 10:16 -0800

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

#56577

On Tue, 20 Jan 2015 16:06:20 GMT, raltbos@xs4all.nl (Richard Bos)
wrote:

>Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:

<snip>

>> And practical reasons: ntohl() and htonl() exist, and map to efficient
>> implementations on all platforms that I'm aware of.
>
>Another practical reason: on the most common platform out there,
>little-endian is the native format, so files full of LE numbers would,
>e.g., map to memory immediately without even needing conversion in the
>first place.
>Which practical reason turns out to be most practical? Well, in a
>reasonable world, that would depend quite a lot on the problem in
>question. Measure, measure, measure.

Instead of the popularity of one endianness over the other as measured
by number of platforms, an argument can be made to measure by quantity
of data processed.  One big-endian IBM mainframe may process more data
than all the little-endian PCs in most countries.

-- 
Remove del for email

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

#56578

On Thu, 22 Jan 2015 15:41:22 -0800, Barry Schwarz <schwarzb@dqel.com>
wrote:

>On Tue, 20 Jan 2015 16:06:20 GMT, raltbos@xs4all.nl (Richard Bos)
>wrote:
>
>>Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>
><snip>
>
>>> And practical reasons: ntohl() and htonl() exist, and map to efficient
>>> implementations on all platforms that I'm aware of.
>>
>>Another practical reason: on the most common platform out there,
>>little-endian is the native format, so files full of LE numbers would,
>>e.g., map to memory immediately without even needing conversion in the
>>first place.
>>Which practical reason turns out to be most practical? Well, in a
>>reasonable world, that would depend quite a lot on the problem in
>>question. Measure, measure, measure.
>
>Instead of the popularity of one endianness over the other as measured
>by number of platforms, an argument can be made to measure by quantity
>of data processed.  One big-endian IBM mainframe may process more data
>than all the little-endian PCs in most countries.


Perhaps for very, very specific definitions of "data".

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

#56581

Robert Wessel wrote:

> On Thu, 22 Jan 2015 15:41:22 -0800, Barry Schwarz <schwarzb@dqel.com>
> wrote:
> 
<snip>

>>Instead of the popularity of one endianness over the other as measured
>>by number of platforms, an argument can be made to measure by quantity
>>of data processed.  One big-endian IBM mainframe may process more data
>>than all the little-endian PCs in most countries.
> 
> 
> Perhaps for very, very specific definitions of "data".

One man's noise is another man's signal.

Anything posted to Twitbook is noise - except to the NSA and GCHQ, 
obviously, for whom it is really is data.

Over 97% of email is noise.

Over 99% of Youtube is noise.

Over 99.8% of video games are noise.

Over 99.86% of Word documents are noise.

Way more than 99.9% of spreadsheets are noise.

In fact, it could be said that pretty much anything that passes through a PC 
is (unless it is on its way to a mainframe) a waste of perfectly good bits.

So, yes - one mainframe can easily process more data than a brazillion PCs.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#56588

On Fri, 23 Jan 2015 08:52:54 +0000, Richard Heathfield
<invalid@see.sig.invalid> wrote:

>Robert Wessel wrote:
>
>> On Thu, 22 Jan 2015 15:41:22 -0800, Barry Schwarz <schwarzb@dqel.com>
>> wrote:
>> 
><snip>
>
>>>Instead of the popularity of one endianness over the other as measured
>>>by number of platforms, an argument can be made to measure by quantity
>>>of data processed.  One big-endian IBM mainframe may process more data
>>>than all the little-endian PCs in most countries.
>> 
>> 
>> Perhaps for very, very specific definitions of "data".
>
>One man's noise is another man's signal.
>
>Anything posted to Twitbook is noise - except to the NSA and GCHQ, 
>obviously, for whom it is really is data.
>
>Over 97% of email is noise.
>
>Over 99% of Youtube is noise.
>
>Over 99.8% of video games are noise.
>
>Over 99.86% of Word documents are noise.
>
>Way more than 99.9% of spreadsheets are noise.
>
>In fact, it could be said that pretty much anything that passes through a PC 
>is (unless it is on its way to a mainframe) a waste of perfectly good bits.
>
>So, yes - one mainframe can easily process more data than a brazillion PCs.


Even if it's 99.9% noise, the number of units has a massive disparity.
There are about 10K mainframes in the world, and each core is very
roughly in the same general ballpark as a desktop Intel core.  An EC12
with 101 cores being the top end (until the ~50% bigger z13s start
appearing), we're talking about the equivalent of about 10K x86 cores,
or what, ~3K PCs?  And feel free to raise or lower than number by a
factor of three or four depending on your biases about MF performance.
But how many countries have only 12K PCs?

And assuming the average installed Z box has 30 active cores*, that's
only ~30 million x86 cores to match it, Intel probably ships that many
in a month.  Perhaps most countries in the world are small enough to
have fewer than 10 million PCs (again, give or take), so perhaps all
the mainframes in the world can process more data than the PCs in most
single countries, assuming a .1% signal ratio?


*Highly unlikely, IBM just doesn't post enough revenue for that
division to make that possible.  It's probably closer to 10 (given
probably sale prices, and reported revenues, IBM is moving the
equivalent of perhaps 200-300 fully configured mainframes annually,
assume a four years replacement cycle, divide the net core count by
the approximate installed base...).

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

#56589

On Friday, January 23, 2015 at 8:53:04 AM UTC, Richard Heathfield wrote:
> 
> In fact, it could be said that pretty much anything that passes through a PC 
> is (unless it is on its way to a mainframe) a waste of perfectly good bits.
> 
> So, yes - one mainframe can easily process more data than a brazillion PCs.
> 
Not all data has the same status, no.
Generally you have only a few underlying values, and a lot of dependent values.
So if you've a checkbox, the underlying value is just one bit, but there will be
kilobytes of image data to represent the tick, manage the screen,and communicate
that bit to the rest of the program.

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

#56591

On 23/01/2015 11:51, Malcolm McLean wrote:
> On Friday, January 23, 2015 at 8:53:04 AM UTC, Richard Heathfield wrote:
>>
>> In fact, it could be said that pretty much anything that passes through a PC
>> is (unless it is on its way to a mainframe) a waste of perfectly good bits.
>>
>> So, yes - one mainframe can easily process more data than a brazillion PCs.
>>
> Not all data has the same status, no.
> Generally you have only a few underlying values, and a lot of dependent values.
> So if you've a checkbox, the underlying value is just one bit, but there will be
> kilobytes of image data to represent the tick, manage the screen,and communicate
> that bit to the rest of the program.
>
That's been the case for a long time that a PC probably spends most of 
its time doing nothing of any significance.

All I'm doing is typing this text message at the minute, something that 
could have been done just as effectively on a 64KB 8-bit microcomputer, 
yet even my low-end PC seems to require 1200 MB of RAM, 900 threads (see 
the other thread), 80 processes and 200 services (whatever those are).

It has also been the case that I've needed to do something urgently, but 
the machine has apparently been too busy with more pressing matters of 
its own (no doubt downloading endless updates to itself). It forgets 
that it exists primarily to serve me not itself!

-- 
Bartc

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

#56592

Bartc <bc@freeuk.com> wrote:

> It has also been the case that I've needed to do something urgently, but 
> the machine has apparently been too busy with more pressing matters of 
> its own (no doubt downloading endless updates to itself). It forgets 
> that it exists primarily to serve me not itself!

That problem, IMO, lies not mainly with the computer, but with the
majority of the users. If _we_[1] didn't forget that the computer is to
serve us, and not we it, many of the problems we now have with them
would be solved.
Faceberk and Twatter, for starters, would not be nearly such scourges on
civilisation.

Richard

[1] And I don't mean we programmers, who are more aware of this, but we
the public-at-large

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

#56595

W dniu piątek, 23 stycznia 2015 13:19:05 UTC+1 użytkownik Bart napisał:
> On 23/01/2015 11:51, Malcolm McLean wrote:
> > On Friday, January 23, 2015 at 8:53:04 AM UTC, Richard Heathfield wrote:
> >>
> >> In fact, it could be said that pretty much anything that passes through a PC
> >> is (unless it is on its way to a mainframe) a waste of perfectly good bits.
> >>
> >> So, yes - one mainframe can easily process more data than a brazillion PCs.
> >>
> > Not all data has the same status, no.
> > Generally you have only a few underlying values, and a lot of dependent values.
> > So if you've a checkbox, the underlying value is just one bit, but there will be
> > kilobytes of image data to represent the tick, manage the screen,and communicate
> > that bit to the rest of the program.
> >
> That's been the case for a long time that a PC probably spends most of 
> its time doing nothing of any significance.
> 
> All I'm doing is typing this text message at the minute, something that 
> could have been done just as effectively on a 64KB 8-bit microcomputer, 
> yet even my low-end PC seems to require 1200 MB of RAM, 900 threads (see 
> the other thread), 80 processes and 200 services (whatever those are).
> 
> It has also been the case that I've needed to do something urgently, but 
> the machine has apparently been too busy with more pressing matters of 
> its own (no doubt downloading endless updates to itself). It forgets 
> that it exists primarily to serve me not itself!
> 
imo reality is this that SOFTWARE stays far away after HARDWARE today; in concept, idea, runtime properties etc; (speaking more on system and user application less on games); hardware is pleasantly more powerfull (then back then) though mess

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

#56597

On Friday, January 23, 2015 at 1:19:05 PM UTC+1, Bart wrote:
> That's been the case for a long time that a PC probably spends most of 
> its time doing nothing of any significance.
> 
> All I'm doing is typing this text message at the minute, something that 
> could have been done just as effectively on a 64KB 8-bit microcomputer, 
> yet even my low-end PC seems to require 1200 MB of RAM, 900 threads (see 
> the other thread), 80 processes and 200 services (whatever those are).
> 
> It has also been the case that I've needed to do something urgently, but 
> the machine has apparently been too busy with more pressing matters of 
> its own (no doubt downloading endless updates to itself). It forgets 
> that it exists primarily to serve me not itself!
> 

As a machine, it just does what it has been told to do - if you tell it
nothing, it will do what someone else (some guy at Microsoft, I guess) told
it to do, which probably isn't what you need.

The problem, I'd say, it's that, for any reason, most systems don't have a
decent and easy way to configure them properly.

I can define myself lucky to have spend years working with linux, so that I
can tweak my systems pretty much how I like (even if sometimes the new
distros use really weird stuff), but for the average user, even in the
programmers' world, I see that is a real pain.

Ciao!

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

#56596

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

> One man's noise is another man's signal.
>
> Anything posted to Twitbook is noise - except to the NSA and GCHQ, 
> obviously, for whom it is really is data.
>
> Over 97% of email is noise.
>
> Over 99% of Youtube is noise.
>
> Over 99.8% of video games are noise.
>
> Over 99.86% of Word documents are noise.
>
> Way more than 99.9% of spreadsheets are noise.
>
> In fact, it could be said that pretty much anything that passes through a PC 
> is (unless it is on its way to a mainframe) a waste of perfectly good bits.
>
> So, yes - one mainframe can easily process more data than a brazillion PCs.

"All of the books in the world contain no more information than is
broadcast as video in a single large American city in a single year.
Not all bits have equal value."
                -- Carl Sagan

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

#56598

On 2015-01-23, Lowell Gilbert <lgusenet@be-well.ilk.org> wrote:
> Richard Heathfield <invalid@see.sig.invalid> writes:
>
>> One man's noise is another man's signal.
>>
>> Anything posted to Twitbook is noise - except to the NSA and GCHQ, 
>> obviously, for whom it is really is data.
>>
>> Over 97% of email is noise.
>>
>> Over 99% of Youtube is noise.
>>
>> Over 99.8% of video games are noise.
>>
>> Over 99.86% of Word documents are noise.
>>
>> Way more than 99.9% of spreadsheets are noise.
>>
>> In fact, it could be said that pretty much anything that passes through a PC 
>> is (unless it is on its way to a mainframe) a waste of perfectly good bits.
>>
>> So, yes - one mainframe can easily process more data than a brazillion PCs.
>
> "All of the books in the world contain no more information than is
> broadcast as video in a single large American city in a single year.
> Not all bits have equal value."
>                 -- Carl Sagan

Indeed.

Given enough monkees with typewriters and enough time the complete works
of Shakespeare may well be produced, however there is an
equal likelyhood that, "but soft what light through yonder window
breaks", will be replaced with, "but soft what gas through yonder wazoo
breaks".

Meanwhile, the waves produced by humanities broadcasts continue at, or
close, to the speed of light, spreading the accumulated wisdom of the age
of TV to the universe.

Hi Ho.

-- 
http://www.softsprocket.com

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

#56599

On 01/23/2015 12:45 PM, Greg Martin wrote:
...
> Given enough monkees ...

There were only 4 monkees originally, and now we're down to three, and
these three are all getting pretty old. I recommend staffing up with
monkeys instead - there's a lot more of them, and on average they're in
much better physical condition.

> ... with typewriters and enough time the complete works
> of Shakespeare may well be produced, however there is an
> equal likelyhood that, "but soft what light through yonder window
> breaks", will be replaced with, "but soft what gas through yonder wazoo
> breaks".

The likelihoods are not equal. Because the replacement is shorter than
the original, it's more likely to be generated, by a factor which (IIRC)
is of the same order as the number of different keys on the keyboard.
The precise factor depends upon how random monkeys' typing is.

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

#56601

On 2015-01-23, James Kuyper <jameskuyper@verizon.net> wrote:
> On 01/23/2015 12:45 PM, Greg Martin wrote:
> ...
>> Given enough monkees ...
>
> There were only 4 monkees originally, and now we're down to three, and
> these three are all getting pretty old. I recommend staffing up with
> monkeys instead - there's a lot more of them, and on average they're in
> much better physical condition.
>

You know, I knew I was spelling that wrong and just couldn't wrap my head
around why it looked right! Speaking of the TV age!

>> ... with typewriters and enough time the complete works
>> of Shakespeare may well be produced, however there is an
>> equal likelyhood that, "but soft what light through yonder window
>> breaks", will be replaced with, "but soft what gas through yonder wazoo
>> breaks".
>
> The likelihoods are not equal. Because the replacement is shorter than
> the original, it's more likely to be generated, by a factor which (IIRC)
> is of the same order as the number of different keys on the keyboard.
> The precise factor depends upon how random monkeys' typing is.

Hm. I hadn't thought of that, though I wonder if once you take into
account the possible permutations of each sentence fragment (48! vs 46!) and
then facter that? against the possible combinations of keystrokes the 
difference must approach zero awful quickly. 

Obviously, I haven't a clue about the math involved here so it probably
would have been better put, "should a pack of monkeys produce the
complete works of Shakespeare then there is a likelyhood they also
produced the complete works of the monkees".

-- 
http://www.softsprocket.com

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

#56648

On 01/23/2015 01:30 PM, Greg Martin wrote:
> On 2015-01-23, James Kuyper <jameskuyper@verizon.net> wrote:
>> On 01/23/2015 12:45 PM, Greg Martin wrote:
>> ...
>>> Given enough monkees with typewriters and enough time the complete works
>>> of Shakespeare may well be produced, however there is an
>>> equal likelyhood that, "but soft what light through yonder window
>>> breaks", will be replaced with, "but soft what gas through yonder wazoo
>>> breaks".
>>
>> The likelihoods are not equal. Because the replacement is shorter than
>> the original, it's more likely to be generated, by a factor which (IIRC)
>> is of the same order as the number of different keys on the keyboard.
>> The precise factor depends upon how random monkeys' typing is.
> 
> Hm. I hadn't thought of that, though I wonder if once you take into
> account the possible permutations of each sentence fragment (48! vs 46!) and
> then facter that? against the possible combinations of keystrokes the 
> difference must approach zero awful quickly.

Not really. Here's a simple way to think about it. Consider the set of
all possible sequences of exactly N characters typed by the monkeys,
where N is much greater than the size of his complete works. Let n be
the number of different characters that can be appear at any give
location in one of those sequences. Consider every single location in
any of those sequences where you could find a complete copy of
Shakespeare's version of those works could be found. For each such
location, there are n^2 other sequences which are identical to that
sequence, except that they contain the alternative version of that
sentence in the corresponding location, followed by two random letters.
In addition, there's two locations near the end of an N-character
sequence where you could find the start of the shorter version, but
could not find the start of the longer version, because there's not
enough room. I think there's some double counting here, because you
could have sequences where the two "random characters" happen to be the
first two characters of another instance of the shorter sequence - but
for N >> the size of the complete works, I think the factor of n^2
dominates all other differences.


> Obviously, I haven't a clue about the math involved here so it probably
> would have been better put, "should a pack of monkeys produce the
> complete works of Shakespeare then there is a likelyhood they also
> produced the complete works of the monkees".

"The Monkees" ran for two seasons, with a total of 58 episodes, In
addition, "Between 1966 and 1970, The Monkees released 185 songs on 9
stereo albums, 5 mono albums, and 9 non-LP singles."
<http://en.wikipedia.org/wiki/The_Monkees>. Shakespeare is credited with
"38 plays, 154 sonnets, and a variety of other poems"
<http://en.wikipedia.org/wiki/Shakespeare_bibliography>. I have no idea
how to even estimate the size in characters of either set of "complete
works", therefore I have no idea which is shorter. As I've shown above,
even a small difference in the total length makes a huge difference in
the likelihood of generating the sequence randomly.

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

#56649

James Kuyper wrote:

<snip>
> As I've shown above,
> even a small difference in the total length makes a huge difference in
> the likelihood of generating the sequence randomly.

Setting aside the monkees and focusing instead on the monkeys:

1) with each bit of message that you add, you double the average time 
required to generate it randomly (assuming that all else remains constant). 
There comes a point at which the average time taken is so colossal that you 
can reasonably consider the probability of generating that sequence to be 0 
(not 0 in the absolute sense, of course, but a number so infinitesimally 
distant from 0 as to be /effectively/ 0).

2) you can give the monkeys a helping hand, by giving them computers rather 
than typewriters, using function keys to give them up to twelve macros (more 
if you have a longer keyboard), where ctrl-Fn = start recording macro n, 
shift-Fn = stop recording macro n, alt-Fn means add to existing macro n, and 
Fn = play back macro n (and yes, sequences such as:

ctrl-F2 fhjksdghj F3 the question; whethdsgf shift-F2

are legal). Then you arrange for the monkeys to undergo competitive 
examinations, with progressively stricter criteria for passing. You might 
proceed from, say, the avoidance of four or more identical contiguous 
letters in the first exam, to perhaps a good mix of vowels and consonants in 
the second, and then perhaps in the third you might judge on the number of 
times that 'the' appears (absolute value of actual minus expected number of 
occurrences for the corpus size), and so on, getting progressively fussier. 
Or, if you like the simple life, get them to produce exactly the right 
number of bits in the Complete Works of Shakespeare, and score them simply 
on the number of matching bits.

The monkeys are then ranked, and the lowest-scoring are eliminated (or, if 
you prefer, sent to a zoo or released into the wild) before they get a 
chance to breed.

Having lathered, all you have to do now is rinse and repeat a few million 
times.

This should cut down the time required to generate the complete works of 
Shakespeare by a great many orders of magnitude. Alas, not enough that 
you're likely to get a result any time this universe, but it should at least 
be better than random.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#56650

On Monday, January 26, 2015 at 6:15:35 PM UTC, Richard Heathfield wrote:
>
> The monkeys are then ranked, and the lowest-scoring are eliminated (or, if 
> you prefer, sent to a zoo or released into the wild) before they get a 
> chance to breed.
> 
> This should cut down the time required to generate the complete works of 
> Shakespeare by a great many orders of magnitude. Alas, not enough that 
> you're likely to get a result any time this universe, but it should at least 
> be better than random.
> 
Biologists believe that, using that algorithm, the monkeys did it in about 5
million years.

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

#56651

Malcolm McLean wrote:

> On Monday, January 26, 2015 at 6:15:35 PM UTC, Richard Heathfield wrote:
>>
>> The monkeys are then ranked, and the lowest-scoring are eliminated (or,
>> if you prefer, sent to a zoo or released into the wild) before they get a
>> chance to breed.
>> 
>> This should cut down the time required to generate the complete works of
>> Shakespeare by a great many orders of magnitude. Alas, not enough that
>> you're likely to get a result any time this universe, but it should at
>> least be better than random.
>> 
> Biologists believe that, using that algorithm, the monkeys did it in about
> 5 million years.

Clearly they haven't done the math. :-)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#56660

Malcolm McLean wrote:
> On Monday, January 26, 2015 at 6:15:35 PM UTC, Richard Heathfield wrote:
>>
>> The monkeys are then ranked, and the lowest-scoring are eliminated (or, if
>> you prefer, sent to a zoo or released into the wild) before they get a
>> chance to breed.
>>
>> This should cut down the time required to generate the complete works of
>> Shakespeare by a great many orders of magnitude. Alas, not enough that
>> you're likely to get a result any time this universe, but it should at least
>> be better than random.
>>
> Biologists believe that, using that algorithm, the monkeys did it in about 5
> million years.
>


DNA isn't random, though . Phenotypes are highly constrained in 
feasibility.

-- 
Les Cargill

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

#56665

On 26-Jan-15 12:15, Richard Heathfield wrote:
> ... Then you arrange for the monkeys to undergo competitive 
> examinations, with progressively stricter criteria for passing.

The original form of the Infinite Monkey Theorem has a single monkey
with infinite time, so I assume you're not using that form.

> The monkeys are then ranked, and the lowest-scoring are eliminated
> (or, if you prefer, sent to a zoo or released into the wild) before
> they get a chance to breed.
>
> Having lathered, all you have to do now is rinse and repeat a few
> million times.

There is a variant with infinite monkeys, but in that case, there is no
need to eliminate any of them; at least one (actually, an infinite
number) will produce the desired text _on the first try_.  Where to
store infinite monkeys is left as an exercise for the reader.

> This should cut down the time required to generate the complete works
> of Shakespeare by a great many orders of magnitude. Alas, not enough
> that you're likely to get a result any time this universe, but it
> should at least be better than random.

We have existence proof that it can take as little as a few million
years with actual primates, though using natural selection rather than
your (presumably more efficient) artificial selection.

OTOH, the "monkey" in the theorem is a metaphor for a random keypress
device, and in that case there is no point in competitions and such
because any "failure" or "success" at passing your tests will be a
random event, not a "better" device.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#56666

Stephen Sprunk wrote:

> On 26-Jan-15 12:15, Richard Heathfield wrote:
>> ... Then you arrange for the monkeys to undergo competitive
>> examinations, with progressively stricter criteria for passing.
> 
> The original form of the Infinite Monkey Theorem has a single monkey
> with infinite time, so I assume you're not using that form.

Right. One monkey isn't likely to produce very much, especially since the 
proportion of that infinite time in which he (or she) will be productive is 
as close to zero as makes no odds (monkeys have a finite lifetime).

>> The monkeys are then ranked, and the lowest-scoring are eliminated
>> (or, if you prefer, sent to a zoo or released into the wild) before
>> they get a chance to breed.
>>
>> Having lathered, all you have to do now is rinse and repeat a few
>> million times.
> 
> There is a variant with infinite monkeys, but in that case, there is no
> need to eliminate any of them; at least one (actually, an infinite
> number) will produce the desired text _on the first try_.  Where to
> store infinite monkeys is left as an exercise for the reader.

Even storing *one* monkey can be problematic, expensive, and stressful.

> 
>> This should cut down the time required to generate the complete works
>> of Shakespeare by a great many orders of magnitude. Alas, not enough
>> that you're likely to get a result any time this universe, but it
>> should at least be better than random.
> 
> We have existence proof that it can take as little as a few million
> years with actual primates, though using natural selection rather than
> your (presumably more efficient) artificial selection.

(a) Although a primate, Shakespeare wasn't a monkey, so he doesn't count.
(b) He didn't have a typewriter, so he's disqualified on that score as well.
(c) If you do the math, it comes out as way more than mere millions of 
years, which casts a certain amount of doubt on the validity of the 
existence proof.

> OTOH, the "monkey" in the theorem is a metaphor for a random keypress
> device, and in that case there is no point in competitions and such
> because any "failure" or "success" at passing your tests will be a
> random event, not a "better" device.

It is to circumvent that problem that I introduced the macro recorder. It is 
an attempt to harvest good bit sequences.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

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

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

csiph-web