Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #89274 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2016-06-16 07:25 -0700 |
| Last post | 2016-06-20 21:25 -0700 |
| Articles | 8 on this page of 88 — 24 participants |
Back to article view | Back to comp.lang.c
[sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-16 07:25 -0700
Re: [sOT] compression 1 GB downto 100 MB mark.bluemel@gmail.com - 2016-06-16 08:08 -0700
Re: [sOT] compression 1 GB downto 100 MB Lynn McGuire <lmc@winsim.com> - 2016-06-17 12:04 -0500
Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 10:16 -0700
Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-17 23:08 -0700
Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 08:09 -0700
Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-16 08:15 -0700
Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-16 08:18 -0700
Re: [sOT] compression 1 GB downto 100 MB mark.bluemel@gmail.com - 2016-06-17 01:28 -0700
Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 02:03 -0700
Re: [sOT] compression 1 GB downto 100 MB Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 10:34 +0100
Re: [sOT] compression 1 GB downto 100 MB BartC <bc@freeuk.com> - 2016-06-17 10:44 +0100
Re: [sOT] compression 1 GB downto 100 MB Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 11:03 +0100
Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 03:51 -0700
Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-18 02:16 -0700
Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-18 02:29 -0700
Re: [sOT] compression 1 GB downto 100 MB "Osmium" <r124c4u102@comcast.net> - 2016-06-17 08:19 -0500
Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-18 03:17 -0700
Re: [sOT] compression 1 GB downto 100 MB Gareth Owen <gwowen@gmail.com> - 2016-06-17 18:32 +0100
Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 08:43 -0700
Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-16 08:48 -0700
Re: [sOT] compression 1 GB downto 100 MB "Osmium" <r124c4u102@comcast.net> - 2016-06-16 10:49 -0500
Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-16 09:10 -0700
Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 09:36 -0700
Re: [sOT] compression 1 GB downto 100 MB Keith Thompson <kst-u@mib.org> - 2016-06-16 11:18 -0700
Re: [sOT] compression 1 GB downto 100 MB "Osmium" <r124c4u102@comcast.net> - 2016-06-16 13:13 -0500
Re: [sOT] compression 1 GB downto 100 MB Gareth Owen <gwowen@gmail.com> - 2016-06-16 20:18 +0100
Re: [sOT] compression 1 GB downto 100 MB Richard Heathfield <rjh@cpax.org.uk> - 2016-06-16 22:07 +0100
Re: [sOT] compression 1 GB downto 100 MB Gareth Owen <gwowen@gmail.com> - 2016-06-17 06:04 +0100
Re: [sOT] compression 1 GB downto 100 MB Robert Wessel <robertwessel2@yahoo.com> - 2016-06-16 23:21 -0500
Re: [sOT] compression 1 GB downto 100 MB "Osmium" <r124c4u102@comcast.net> - 2016-06-17 07:49 -0500
Re: [sOT] compression 1 GB downto 100 MB Robert Wessel <robertwessel2@yahoo.com> - 2016-06-17 12:47 -0500
Re: [sOT] compression 1 GB downto 100 MB "Osmium" <r124c4u102@comcast.net> - 2016-06-17 14:47 -0500
Re: [sOT] compression 1 GB downto 100 MB Robert Wessel <robertwessel2@yahoo.com> - 2016-06-17 23:32 -0500
Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-18 01:33 -0700
Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-17 14:51 -0700
Re: [sOT] compression 1 GB downto 100 MB BartC <bc@freeuk.com> - 2016-06-16 16:50 +0100
Re: [sOT] compression 1 GB downto 100 MB BartC <bc@freeuk.com> - 2016-06-17 16:20 +0100
Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-16 08:34 -0700
Re: [sOT] compression 1 GB downto 100 MB Les Cargill <lcargill99@comcast.com> - 2016-06-16 12:55 -0500
Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-16 11:53 -0700
Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-16 12:14 -0700
Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-17 12:33 -0700
Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-17 12:46 -0700
Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-17 15:04 -0700
Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-17 22:55 -0700
Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-18 01:38 -0700
Re: [sOT] compression 1 GB downto 100 MB BartC <bc@freeuk.com> - 2016-06-18 10:41 +0100
Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-18 02:55 -0700
Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 05:08 -0700
Re: [sOT] compression 1 GB downto 100 MB "Bill Cunningham" <nospam@nspam.invalid> - 2016-06-18 15:11 -0400
Re: [sOT] compression 1 GB downto 100 MB "Bill Cunningham" <nospam@nspam.invalid> - 2016-06-18 15:13 -0400
Re: [sOT] compression 1 GB downto 100 MB luser droog <luser.droog@gmail.com> - 2016-06-18 12:43 -0700
Re: [sOT] compression 1 GB downto 100 MB Richard Heathfield <rjh@cpax.org.uk> - 2016-06-18 20:43 +0100
Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-18 12:53 -0700
Re: [sOT] compression 1 GB downto 100 MB "Chris M. Thomasson" <nospam@nospam.invalid> - 2016-06-20 20:32 -0700
Re: [sOT] compression 1 GB downto 100 MB Keith Thompson <kst-u@mib.org> - 2016-06-18 13:22 -0700
Re: [sOT] compression 1 GB downto 100 MB Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-18 16:35 -0400
Re: [sOT] compression 1 GB downto 100 MB Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-18 21:37 -0400
Re: [sOT] compression 1 GB downto 100 MB "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-18 16:59 -0400
Re: [sOT] compression 1 GB downto 100 MB crisdunbar@gmail.com - 2016-06-20 09:55 -0700
Re: [sOT] compression 1 GB downto 100 MB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 21:22 +0100
Re: [sOT] compression 1 GB downto 100 MB cris <crisdunbar@gmail.com> - 2016-06-20 17:13 -0700
Re: [sOT] compression 1 GB downto 100 MB Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-21 10:42 -0700
Re: [sOT] compression 1 GB downto 100 MB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-21 20:09 +0100
Re: [sOT] compression 1 GB downto 100 MB crisdunbar@gmail.com - 2016-06-21 13:39 -0700
Re: [sOT] compression 1 GB downto 100 MB Keith Thompson <kst-u@mib.org> - 2016-06-22 08:34 -0700
Re: [sOT] compression 1 GB downto 100 MB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-22 19:48 +0100
Re: [sOT] compression 1 GB downto 100 MB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 01:37 +0100
Re: [sOT] compression 1 GB downto 100 MB Richard Heathfield <rjh@cpax.org.uk> - 2016-06-19 02:22 +0100
Re: [sOT] compression 1 GB downto 100 MB Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-18 21:30 -0400
Re: [sOT] compression 1 GB downto 100 MB Richard Heathfield <rjh@cpax.org.uk> - 2016-06-19 02:41 +0100
Re: [sOT] compression 1 GB downto 100 MB Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-18 21:55 -0400
Re: [sOT] compression 1 GB downto 100 MB Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 03:20 +0100
Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-19 02:53 -0700
Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 16:05 -0700
Re: [sOT] compression 1 GB downto 100 MB "J. Clarke" <j.clarke.873638@gmail.com> - 2016-06-19 06:59 -0400
Re: [sOT] compression 1 GB downto 100 MB fir <profesor.fir@gmail.com> - 2016-06-19 05:55 -0700
Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 06:13 -0700
Re: [sOT] compression 1 GB downto 100 MB "J. Clarke" <j.clarke.873638@gmail.com> - 2016-06-26 12:26 -0400
Re: [sOT] compression 1 GB downto 100 MB Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-26 09:53 -0700
Re: [sOT] compression 1 GB downto 100 MB Richard Heathfield <rjh@cpax.org.uk> - 2016-06-18 20:41 +0100
Re: [sOT] compression 1 GB downto 100 MB "J. Clarke" <j.clarke.873638@gmail.com> - 2016-06-19 06:45 -0400
Re: [sOT] compression 1 GB downto 100 MB Robert Wessel <robertwessel2@yahoo.com> - 2016-06-18 14:42 -0500
Re: [sOT] compression 1 GB downto 100 MB gordonb.vnsk1@burditt.org (Gordon Burditt) - 2016-06-20 01:13 -0500
Re: [sOT] compression 1 GB downto 100 MB Keith Thompson <kst-u@mib.org> - 2016-06-20 12:16 -0700
Re: [sOT] compression 1 GB downto 100 MB David Brown <david.brown@hesbynett.no> - 2016-06-20 21:27 +0200
Re: [sOT] compression 1 GB downto 100 MB Xaltonon <xaltonon@gmail.com> - 2016-06-20 21:25 -0700
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-26 09:53 -0700 |
| Message-ID | <0aad6d8b-0645-4c5d-9bb1-e7307ac12bc8@googlegroups.com> |
| In reply to | #89801 |
On Sunday, June 26, 2016 at 5:26:49 PM UTC+1, J. Clarke wrote: > In article <96631b37-a326-4a3e-9eab-bf67279b82d5@googlegroups.com>, > malcolm.mclean5@btinternet.com says... > > > That's the same way of saying the same thing. > > You can think of the problem as there being two data items, A and B, > > with B following and before the program starts, we have no clue > > what A will be, but after A arrives, we've got an estimate of > > the probability distribution of B. > > Or you can think of the problem as most of the input having regular > > patterns, e.g. repeated runs of equal bytes or repeated substrings > > which you can detect and replace with more compact representations. > > > > Ultimately those are just two different ways of making the same > > observation. > > Why do we have no clue what A will be? If we are dealing with a > situation in which it is sufficiently important that compression be > achieved, we may look at the entire dataset and examine and analyze it > at length before we even start to write code. Compression doesn't have > to be on-the-fly in realtime with freshly acquired data to be useful. > If we say we don't know what A will be, it makes the problem easier to understand. Of course we do usually have a fair idea of what the data will be before we receive the first byte, but then that raises the issue of what is a "compression scheme" and what is a "representation". (English has two obsolete letters, ash and thorn, which appear in old texts. Now we can of course communicate that one of these letters is intended in ASCII - add a note to the reader that you're going to use _ae or _th or something similar. But it's less compact than if we had reserved codes. The situation =is tolerable because only a minority of people want to discuss Anglo-Saxon texts in ASCII-only fora such as this one. So is ASCII a "compression system" that is specialised for modern texts? You're straining the definition of compression system if you say "yes".)
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-18 20:41 +0100 |
| Message-ID | <nk485k$94m$1@dont-email.me> |
| In reply to | #89523 |
On 18/06/16 13:08, Malcolm McLean wrote: <snip> > truly random data can't be compressed at all, but neither does it mean > anything. There is at least one thing it might mean: "the exact series of bits needed for decrypting a given one-time-pad-encrypted message". -- 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]
| From | "J. Clarke" <j.clarke.873638@gmail.com> |
|---|---|
| Date | 2016-06-19 06:45 -0400 |
| Message-ID | <MPG.31d041c24e695d7798a28d@news.eternal-september.org> |
| In reply to | #89523 |
In article <be950b83-2eab-48aa-9616-ccc2174bf61c@googlegroups.com>, malcolm.mclean5@btinternet.com says... > > On Saturday, June 18, 2016 at 10:41:30 AM UTC+1, Bart wrote: > > > > If you need the recovered random data to be identical to the original > > for some reason, then I think this can be done for pseudo-random data. > > Then this reduces to an algorithm and some parameters (start state and > > length). > > > Psuedo random data can be compressed more efficiently than almost > anything else. Pass the seed and N > > srand(seed); > for(i=0;i<N;i++) > data[i] = rand(); > > truly random data can't be compressed at all, but neither does it mean > anything. While it doesn't mean anything, if it was used for testing something and you want to be sure that something else returns an identical result then it's useful to have the test case recorded in a reproducible manner.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-06-18 14:42 -0500 |
| Message-ID | <409bmbtlrjca6lk79p0dguvgucv67evhu7@4ax.com> |
| In reply to | #89512 |
On Sat, 18 Jun 2016 10:41:13 +0100, BartC <bc@freeuk.com> wrote: >On 18/06/2016 09:38, fir wrote: > >> truly random may be hard (maybe impossible) >> to compress i dont know.. > >Truly random data probably /can/ be compressed to 1 bit. (Or even 0 >bits. But it will need a flag saying it is truly random; and a length.) > >You just generate another random sequence when you decompress it. Who's >going to know the difference? I'm pretty sure that would be considered lossy compression.
[toc] | [prev] | [next] | [standalone]
| From | gordonb.vnsk1@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2016-06-20 01:13 -0500 |
| Message-ID | <aaedncHfg4AHFPrKnZ2dnUU7-SHNnZ2d@posted.internetamerica> |
| In reply to | #89512 |
>> truly random may be hard (maybe impossible) >> to compress i dont know.. You might succeed. I recall trying this with "gzip", and some blocks of random data compressed, with 0.1% compression or so, and some got larger, with -0.1% compression. You probably get on average 0.0% compression, but it will vary a bit with the random data and the compression algorithm. That's what I got just now, taking a 52 meg file from /dev/random and trying to compress it with gzip. -0.1% compression, according to gzip (which rounds to a tenth of a percent), and -0.03055% compression by manual calculation (the file only got 16k bigger for a 52 meg file). > Truly random data probably /can/ be compressed to 1 bit. (Or even 0 > bits. But it will need a flag saying it is truly random; and a length.) I disagree, unless you're going to argue that 100% lossy compression is still compression. And in that case, you can apply 100% lossy compression to the non-random data with equal justification. > You just generate another random sequence when you decompress it. Who's > going to know the difference? Anyone who saw the random sequence before you destroyed it with 100% lossy compression. In particular, if this was a message, the sender may still have a copy, and he may have used it or will later use it somehow (as an encryption key for a one-time pad comes to mind here, as someone else suggested, but it could be something else as simple as "Find that bunch of data, then take the 5th character, the 872nd character, the 57th character, ... and write them down in order and read it"). > If you need the recovered random data to be identical to the original > for some reason, then I think this can be done for pseudo-random data. > Then this reduces to an algorithm and some parameters (start state and > length). No, you can't replace true-random data with pseudo-random data without possible serious consequences, one of which might involve someone getting shot as a spy because the encryption using pseudo-random numbers was too weak. The random sequence need not have a "meaning" at the time it was sent. That "meaning" can be assigned later. Suppose I send you an email with the cryptic subject line "Keep This" and an attachment that looks like 100K bytes of random bits. It has no meaning. You save it. You don't know it, but I have not decided what to do with it either, yet. Five years later, I send you another message: "Remember the message I sent you on <date> with some data attached? That data is the key to the one-time pad, and the message is the attachment to *this* email. Since the (alternate reality) law only requires archiving internet email for 3 years, the Feds have forgotten that message." I have several times had to figure out why a particular sequence of data sent over a communication line disrupted communication repeatedly. In that situation, it is very important not to corrupt the random data if you find a set that repeats the problem consistently. (1) Someone was sending a particular file, compressed, over UUCP using 1200 baud modems. (Yes, this was a long time ago.) When sending this particular file, the first repeatable test case I got my hands on, which actually was random data [*1], the modems always dropped the line in the middle of the call. I generated about 500 random files and found one that consistently triggered the bug. When the connection aborted, UUCP would start again with the same file, creating a huge backlog of files behind it. - The link used 1200 baud modems that dropped back to command mode on seeing <PAUSE>+++<PAUSE>. UUCP didn't expect this in the middle of the packet protocol, so it would time out and drop the call. - The compressed data had the sequence +++ in it, but there's no reason for pauses around those three bytes. - The sending modem, owned by a customer, had the required time for the pause set way too low (by default). Fix that, and the problem disappeared, although it cropped up a couple of times with different customers having the same model of modem with the same default. I really wouldn't have appreciated it if some compression routine used on my email replaced one random sequence with another random sequence after all the work we did trying to generate a test case that consistently failed. *1 We "harvested" real-random bits from things like keystroke timing, disk latency, and file timestamps, so the data could not be reproduced by deterministic code, but we probably didn't have enough real-random bits mixed in. Previous attempts with pseudo-random data didn't reproduce the problem - I'm not sure why. Maybe just bad luck. (2) A modem vendor of a higher-speed modem sent us a pair of prototypes. These modems have a scrambler that tries to avoid long sequences of 0's, (or was it 1's?) which cause the modem to lose clock sync. If you *sent* a long sequence of 0's, the scrambler dealt with the problem (The scrambler was *NOT* a secret nor an attempt at encryption: it was written into the standard for this type of modem). If you sent a sequence which ended up after scrambling as a long sequence of 0's, the modem was supposed to insert 1 bits every so often (and the receiving modem would detect the pattern and delete them). Well, they found a bug in that insert-1 code, and fixed it (without telling us). But they sent us one modem with the old code and one modem with the new code, due to some kind of mix-up as to which was which, which meant they were incompatable with each other, but the incompatability wasn't going to show up often. Well, somehow the data we were sending hit the problem often. The vendor was amazed we were complaining about it in 4 hours after starting testing. The main reason we didn't complain about it in 4 minutes was we initially thought our test setup was broken. (3) I ran into some odd problem with data corruption in data sent over ethernet links, with some data patterns more likely than others to cause failures. The problem was eventually tracked down to one ethernet card which got shared around the lab a lot, and was suspected of having some buffer RAM with a few bad bits in it, enough that the corrupted packets didn't always fail the packet checksum. We never did dissect the card to test the RAM, but we confiscated it and got a replacement. The problem never recurred.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-20 12:16 -0700 |
| Message-ID | <ln7fdjsmax.fsf@kst-u.example.com> |
| In reply to | #89639 |
gordonb.vnsk1@burditt.org (Gordon Burditt) writes:
[...]
> You might succeed. I recall trying this with "gzip", and some
> blocks of random data compressed, with 0.1% compression or so, and
> some got larger, with -0.1% compression. You probably get on average
> 0.0% compression, but it will vary a bit with the random data and
> the compression algorithm. That's what I got just now, taking a
> 52 meg file from /dev/random and trying to compress it with gzip.
> -0.1% compression, according to gzip (which rounds to a tenth of a
> percent), and -0.03055% compression by manual calculation (the file
> only got 16k bigger for a 52 meg file).
[...]
You got 52 meg from /dev/random? On my system just now, I got less than
200 bytes before it stalled. Are you sure you didn't use /dev/urandom?
(Permission to quote my words in a followup is granted only if a proper
attribution line is included.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-20 21:27 +0200 |
| Message-ID | <nk9g2h$cs3$1@dont-email.me> |
| In reply to | #89666 |
On 20/06/16 21:16, Keith Thompson wrote: > gordonb.vnsk1@burditt.org (Gordon Burditt) writes: > [...] >> You might succeed. I recall trying this with "gzip", and some >> blocks of random data compressed, with 0.1% compression or so, and >> some got larger, with -0.1% compression. You probably get on average >> 0.0% compression, but it will vary a bit with the random data and >> the compression algorithm. That's what I got just now, taking a >> 52 meg file from /dev/random and trying to compress it with gzip. >> -0.1% compression, according to gzip (which rounds to a tenth of a >> percent), and -0.03055% compression by manual calculation (the file >> only got 16k bigger for a 52 meg file). > [...] > > You got 52 meg from /dev/random? On my system just now, I got less than > 200 bytes before it stalled. Are you sure you didn't use /dev/urandom? > > (Permission to quote my words in a followup is granted only if a proper > attribution line is included.) > At the risk of going off-topic, different *nix systems may implement /dev/random and /dev/urandom in different ways. Some are very strict in limiting /dev/random to data from specific non-deterministic sources, such as network packet timings, with /dev/urandom coming from pseudo-random sequences with non-deterministic seeding. But I believe I read somewhere about some systems using basically the same arrangement for both /dev/random and /dev/urandom (after all, in reality they are likely to pass all the same randomness tests).
[toc] | [prev] | [next] | [standalone]
| From | Xaltonon <xaltonon@gmail.com> |
|---|---|
| Date | 2016-06-20 21:25 -0700 |
| Message-ID | <nkafkc$97a$1@dont-email.me> |
| In reply to | #89667 |
On 2016-06-20 19:27:12 +0000, David Brown said: > On 20/06/16 21:16, Keith Thompson wrote: >> gordonb.vnsk1@burditt.org (Gordon Burditt) writes: >> [...] >>> You might succeed. I recall trying this with "gzip", and some >>> blocks of random data compressed, with 0.1% compression or so, and >>> some got larger, with -0.1% compression. You probably get on average >>> 0.0% compression, but it will vary a bit with the random data and >>> the compression algorithm. That's what I got just now, taking a >>> 52 meg file from /dev/random and trying to compress it with gzip. >>> -0.1% compression, according to gzip (which rounds to a tenth of a >>> percent), and -0.03055% compression by manual calculation (the file >>> only got 16k bigger for a 52 meg file). >> [...] >> >> You got 52 meg from /dev/random? On my system just now, I got less than >> 200 bytes before it stalled. Are you sure you didn't use /dev/urandom? >> >> (Permission to quote my words in a followup is granted only if a proper >> attribution line is included.) >> > > At the risk of going off-topic, different *nix systems may implement > /dev/random and /dev/urandom in different ways. Some are very strict > in limiting /dev/random to data from specific non-deterministic > sources, such as network packet timings, with /dev/urandom coming from > pseudo-random sequences with non-deterministic seeding. But I believe > I read somewhere about some systems using basically the same > arrangement for both /dev/random and /dev/urandom (after all, in > reality they are likely to pass all the same randomness tests). BSDs usually just link /dev/urandom to /dev/random because it only blocks until seeded.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web