On 11/30/2022 12:04 PM, Chris M. Thomasson wrote:
> On 11/21/2022 10:00 PM, Chris M. Thomasson wrote:
>> On 11/21/2022 9:12 PM, FromTheRafters wrote:
>>> Sergi o formulated on Friday :
>>>> On 11/18/2022 3:46 PM, Chris M. Thomasson wrote:
>>>>> On 11/18/2022 1:42 PM, Sergi o wrote:
>>>>>> On 11/18/2022 3:33 PM, WM wrote:
>>>>>>> Fritz Feldhase schrieb am Freitag, 18. November 2022 um 21:30:45
>>>>>>> UTC+1:
>>>>>>>> On Friday, November 18, 2022 at 7:36:20 PM UTC+1, Sergi o wrote:
>>>>>>>
>>>>>>>>> but you only have crap [...]
>>>>>>>>
>>>>>>>> Yeah, it's crap!
>>>>>>>
>>>>>>> Says Franz Fritsche who believes that lossless exchange can
>>>>>>> suffer from infinitely many losses.
>>>>>>>
>>>>>>> Regards, WM
>>>>>>
>>>>>>
>>>>>> your "lossless" exchanges creates an infinite amount of litter;
>>>>>>
>>>>>> 1. each time a O stickie is put onto a fraction covering it, then
>>>>>> pulled off later and discarded,
>>>>>> 2. each time an X pastie is put onto a fraction hiding it, or on
>>>>>> top of an O stickie and then discarded,
>>>>>>
>>>>>> do you pick up after yourself, or just let it rot in the
>>>>>> environment, like your O's ?
>>>>>
>>>>> I wonder if WM is familiar with lossless compression...
>>>>
>>>>
>>>> FTX said they were a lossless exchange, too.
>>>>
>>>> lossless compression (the still FAT boys)=> PNG, GIF, ZIP, RAW, BMP,
>>>> FLAC, ALAC, WMA
>>>
>>> There is lossless JPEG too, but is RAW or BMP ever even compressed?
>
> Depends on the data stored within.

A question arises, compressing random bits generated from, say a TRNG.
Can it be done? Humm... No?

>
>
>>
>> I don't think so. A BMP can store lossless compressed data. Also, a
>> PNG is nice because it is lossless.
>

On 11/30/2022 10:42 AM, WM wrote:
> Jim Burns schrieb am Mittwoch,
> 30. November 2022 um 12:55:06 UTC+1:

>> However,
>> even though _each_ exchange leaves Bob
>> somewhere in the matrix,
>> _all_ the exchanges do not leave Bob
>> anywhere in the matrix.
>
> If each exchange maintains Bob,
> then there is none where he could leave.

Each exchange maintains Bob.
There is no single exchange where he leaves.

Bob-conservation is a property that
_sets_ of exchanges have or do not have.

The set of exchanges involving Bob
*up to* some exchange is
a terminating Bob-mover.
That set has Bob-conservation.

The set of _all_ exchanges involving Bob
-- the same exchanges -- is NOT
a _terminating_ Bob-mover.
It does not terminate.
That set _does not_ have Bob-conservation.

> If he leaves nevertheless,
> then it is in the darkness, i.e.,
> such that his first absence cannot be detected.

O's and X's ⟹ ⟨p/q,k/1⟩ ⟸ X's alone

Each p, each q, each k is in the matrix
iff
it ends an ordered set
which begins at 1, and
which, for each split,
some i is last-before the split and
i⁺⁺ is first-after the split.

Bob does not step out of the matrix.

Insisting that Bob either stays in the
matrix or steps out of the matrix
is insisting on Bob-conservation.

The set of all exchanges does not have
Bob-conservation.

On 11/30/2022 4:23 AM, zelos...@gmail.com wrote:
> onsdag 30 november 2022 kl. 12:19:31 UTC+1 skrev WM:
>> Sergi o schrieb am Mittwoch, 30. November 2022 um 03:15:56 UTC+1:
>>
>>> Cantor is right, and verifies in his own words, provided by you above, that a bijection exists, a paring exists.
>> Cantor is wrong, and claims in his own words, provided by me above, that a bijection exists, a paring exists.
>>
>> Regards, WM
> The function fucking exists! Will you stop being a retard already!?

I think you just insulted every retarded person out there by comparing
them to WM. Humm... ;^o Ouch.

On 11/30/2022 2:06 PM, Chris M. Thomasson wrote:
> On 11/30/2022 12:04 PM, Chris M. Thomasson wrote:
>> On 11/21/2022 10:00 PM, Chris M. Thomasson wrote:
>>> On 11/21/2022 9:12 PM, FromTheRafters wrote:
>>>> Sergi o formulated on Friday :
>>>>> On 11/18/2022 3:46 PM, Chris M. Thomasson wrote:
>>>>>> On 11/18/2022 1:42 PM, Sergi o wrote:
>>>>>>> On 11/18/2022 3:33 PM, WM wrote:
>>>>>>>> Fritz Feldhase schrieb am Freitag, 18. November 2022 um 21:30:45 UTC+1:
>>>>>>>>> On Friday, November 18, 2022 at 7:36:20 PM UTC+1, Sergi o wrote:
>>>>>>>>
>>>>>>>>>> but you only have crap [...]
>>>>>>>>>
>>>>>>>>> Yeah, it's crap!
>>>>>>>>
>>>>>>>> Says Franz Fritsche who believes that lossless exchange can suffer from infinitely many losses.
>>>>>>>>
>>>>>>>> Regards, WM
>>>>>>>
>>>>>>>
>>>>>>> your "lossless" exchanges creates an infinite amount of litter;
>>>>>>>
>>>>>>> 1. each time a O stickie is put onto a fraction covering it, then pulled off later and discarded,
>>>>>>> 2. each time an X pastie is put onto a fraction hiding it, or on top of an O stickie and then discarded,
>>>>>>>
>>>>>>> do you pick up after yourself, or just let it rot in the environment, like your O's ?
>>>>>>
>>>>>> I wonder if WM is familiar with lossless compression...
>>>>>
>>>>>
>>>>> FTX said they were a lossless exchange, too.
>>>>>
>>>>> lossless compression (the still FAT boys)=> PNG, GIF, ZIP, RAW, BMP, FLAC, ALAC, WMA
>>>>
>>>> There is lossless JPEG too, but is RAW or BMP ever even compressed?
>>
>> Depends on the data stored within.
>
> A question arises, compressing random bits generated from, say a TRNG. Can it be done? Humm... No?
>

assuming a binary stream, each bit is independently determined by TRNG, where you have a long string of 0's, or long string of 1's, you could encode
that, but the code for the long space or all high would have to be stuck in the space or highs, (teletype?) and that is inefficient with the
distribution of 1's and 0's from a TRNG. [Codes are designed for the transmission channel.]

you can determine how many strings of 10 1's there will be in a time period, (0.5^(number of spaces or 1's))
That would be something like a normal distribution or a Poisson distribution where compression works on the tails, but not the middle part, which is
most of the data stream. So you could determine how much can be compressed.

It could be compressed, slightly. but how to recognize the code for the spaces/1's in the stream, from random data in the stream...

>>
>>
>>>
>>> I don't think so. A BMP can store lossless compressed data. Also, a PNG is nice because it is lossless.
>>
>

On 11/30/2022 12:34 PM, Sergi o wrote:
> On 11/30/2022 2:06 PM, Chris M. Thomasson wrote:
>> On 11/30/2022 12:04 PM, Chris M. Thomasson wrote:
>>> On 11/21/2022 10:00 PM, Chris M. Thomasson wrote:
>>>> On 11/21/2022 9:12 PM, FromTheRafters wrote:
>>>>> Sergi o formulated on Friday :
>>>>>> On 11/18/2022 3:46 PM, Chris M. Thomasson wrote:
>>>>>>> On 11/18/2022 1:42 PM, Sergi o wrote:
>>>>>>>> On 11/18/2022 3:33 PM, WM wrote:
>>>>>>>>> Fritz Feldhase schrieb am Freitag, 18. November 2022 um
>>>>>>>>> 21:30:45 UTC+1:
>>>>>>>>>> On Friday, November 18, 2022 at 7:36:20 PM UTC+1, Sergi o wrote:
>>>>>>>>>
>>>>>>>>>>> but you only have crap [...]
>>>>>>>>>>
>>>>>>>>>> Yeah, it's crap!
>>>>>>>>>
>>>>>>>>> Says Franz Fritsche who believes that lossless exchange can
>>>>>>>>> suffer from infinitely many losses.
>>>>>>>>>
>>>>>>>>> Regards, WM
>>>>>>>>
>>>>>>>>
>>>>>>>> your "lossless" exchanges creates an infinite amount of litter;
>>>>>>>>
>>>>>>>> 1. each time a O stickie is put onto a fraction covering it,
>>>>>>>> then pulled off later and discarded,
>>>>>>>> 2. each time an X pastie is put onto a fraction hiding it, or on
>>>>>>>> top of an O stickie and then discarded,
>>>>>>>>
>>>>>>>> do you pick up after yourself, or just let it rot in the
>>>>>>>> environment, like your O's ?
>>>>>>>
>>>>>>> I wonder if WM is familiar with lossless compression...
>>>>>>
>>>>>>
>>>>>> FTX said they were a lossless exchange, too.
>>>>>>
>>>>>> lossless compression (the still FAT boys)=> PNG, GIF, ZIP, RAW,
>>>>>> BMP, FLAC, ALAC, WMA
>>>>>
>>>>> There is lossless JPEG too, but is RAW or BMP ever even compressed?
>>>
>>> Depends on the data stored within.
>>
>> A question arises, compressing random bits generated from, say a TRNG.
>> Can it be done? Humm... No?
>>
>
> assuming a binary stream, each bit is independently determined by TRNG,
> where you have a long string of 0's, or long string of 1's, you could
> encode that, but the code for the long space or all high would have to
> be stuck in the space or highs, (teletype?) and that is inefficient with
> the distribution of 1's and 0's from a TRNG.  [Codes are designed for
> the transmission channel.]
>
> you can determine how many strings of 10 1's there will be in a time
> period, (0.5^(number of spaces or 1's))

Well, since I mentioned bits, that is 2-ary. Perhaps go 3-ary where the
extra symbol can be "special", so to speak? Still. Compressing TRNG data
should be very hard to do...

On 11/30/2022 3:06 PM, Chris M. Thomasson wrote:

> A question arises,
> compressing random bits generated from,
> say a TRNG.
> Can it be done? Humm... No?

To my (very non-technical) recollection,
a compression algorithm can only
make some files shorter
by making other files longer.

There are a fixed number of files shorter than
1 Gbytes. Push down here, pop up there.

If I understood the explanation,
a good compression algorithm makes the files
_you want_ shorter. But with that comes the files
you _don't want_ getting longer in compensation.

The way I'd bet is that random bits are
files the algorithms think you don't want,
and they'll get longer.

I-am-not-a-software-engineer.

Chris M. Thomasson wrote on 11/30/2022 :
> On 11/30/2022 12:04 PM, Chris M. Thomasson wrote:
>> On 11/21/2022 10:00 PM, Chris M. Thomasson wrote:
>>> On 11/21/2022 9:12 PM, FromTheRafters wrote:
>>>> Sergi o formulated on Friday :
>>>>> On 11/18/2022 3:46 PM, Chris M. Thomasson wrote:
>>>>>> On 11/18/2022 1:42 PM, Sergi o wrote:
>>>>>>> On 11/18/2022 3:33 PM, WM wrote:
>>>>>>>> Fritz Feldhase schrieb am Freitag, 18. November 2022 um 21:30:45
>>>>>>>> UTC+1:
>>>>>>>>> On Friday, November 18, 2022 at 7:36:20 PM UTC+1, Sergi o wrote:
>>>>>>>>
>>>>>>>>>> but you only have crap [...]
>>>>>>>>>
>>>>>>>>> Yeah, it's crap!
>>>>>>>>
>>>>>>>> Says Franz Fritsche who believes that lossless exchange can suffer
>>>>>>>> from infinitely many losses.
>>>>>>>>
>>>>>>>> Regards, WM
>>>>>>>
>>>>>>>
>>>>>>> your "lossless" exchanges creates an infinite amount of litter;
>>>>>>>
>>>>>>> 1. each time a O stickie is put onto a fraction covering it, then
>>>>>>> pulled off later and discarded,
>>>>>>> 2. each time an X pastie is put onto a fraction hiding it, or on top
>>>>>>> of an O stickie and then discarded,
>>>>>>>
>>>>>>> do you pick up after yourself, or just let it rot in the environment,
>>>>>>> like your O's ?
>>>>>>
>>>>>> I wonder if WM is familiar with lossless compression...
>>>>>
>>>>>
>>>>> FTX said they were a lossless exchange, too.
>>>>>
>>>>> lossless compression (the still FAT boys)=> PNG, GIF, ZIP, RAW, BMP,
>>>>> FLAC, ALAC, WMA
>>>>
>>>> There is lossless JPEG too, but is RAW or BMP ever even compressed?
>>
>> Depends on the data stored within.
>
> A question arises, compressing random bits generated from, say a TRNG. Can it
> be done? Humm... No?

Generally speaking, no. Even more so when you consider the overhead of
header information may make the transmission longer (expansion) rather
than shorter (compression).

On 11/30/2022 2:40 PM, Chris M. Thomasson wrote:
> On 11/30/2022 12:34 PM, Sergi o wrote:
>> On 11/30/2022 2:06 PM, Chris M. Thomasson wrote:
>>> On 11/30/2022 12:04 PM, Chris M. Thomasson wrote:
>>>> On 11/21/2022 10:00 PM, Chris M. Thomasson wrote:
>>>>> On 11/21/2022 9:12 PM, FromTheRafters wrote:
>>>>>> Sergi o formulated on Friday :
>>>>>>> On 11/18/2022 3:46 PM, Chris M. Thomasson wrote:
>>>>>>>> On 11/18/2022 1:42 PM, Sergi o wrote:
>>>>>>>>> On 11/18/2022 3:33 PM, WM wrote:
>>>>>>>>>> Fritz Feldhase schrieb am Freitag, 18. November 2022 um 21:30:45 UTC+1:
>>>>>>>>>>> On Friday, November 18, 2022 at 7:36:20 PM UTC+1, Sergi o wrote:
>>>>>>>>>>
>>>>>>>>>>>> but you only have crap [...]
>>>>>>>>>>>
>>>>>>>>>>> Yeah, it's crap!
>>>>>>>>>>
>>>>>>>>>> Says Franz Fritsche who believes that lossless exchange can suffer from infinitely many losses.
>>>>>>>>>>
>>>>>>>>>> Regards, WM
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> your "lossless" exchanges creates an infinite amount of litter;
>>>>>>>>>
>>>>>>>>> 1. each time a O stickie is put onto a fraction covering it, then pulled off later and discarded,
>>>>>>>>> 2. each time an X pastie is put onto a fraction hiding it, or on top of an O stickie and then discarded,
>>>>>>>>>
>>>>>>>>> do you pick up after yourself, or just let it rot in the environment, like your O's ?
>>>>>>>>
>>>>>>>> I wonder if WM is familiar with lossless compression...
>>>>>>>
>>>>>>>
>>>>>>> FTX said they were a lossless exchange, too.
>>>>>>>
>>>>>>> lossless compression (the still FAT boys)=> PNG, GIF, ZIP, RAW, BMP, FLAC, ALAC, WMA
>>>>>>
>>>>>> There is lossless JPEG too, but is RAW or BMP ever even compressed?
>>>>
>>>> Depends on the data stored within.
>>>
>>> A question arises, compressing random bits generated from, say a TRNG. Can it be done? Humm... No?
>>>
>>
>> assuming a binary stream, each bit is independently determined by TRNG, where you have a long string of 0's, or long string of 1's, you could encode
>> that, but the code for the long space or all high would have to be stuck in the space or highs, (teletype?) and that is inefficient with the
>> distribution of 1's and 0's from a TRNG.  [Codes are designed for the transmission channel.]
>>
>> you can determine how many strings of 10 1's there will be in a time period, (0.5^(number of spaces or 1's))
>
> Well, since I mentioned bits, that is 2-ary. Perhaps go 3-ary where the extra symbol can be "special", so to speak? Still. Compressing TRNG data should
> be very hard to do...
>

agree, you could put in a header that holds many of the locations of groups of spaces or ones for a block of random data bits, and snip out the groups
of spaces or ones from the "data" block. So you could decode the header, and re insert the deadzones.

tradeoff is amount of overhead for the encoding + counter, vs length of the deadzones snipped. It would work on very long blocks, but not much as the
probability of 100 zeros in a row is (.5^100)

header => at bit 209182, there is a 120 segment of spaces (0s)
so you need count, #spaces, and type 0 or 1

then balance that with the probability of the strings occurring.

you could limit the amount of stuff in the header too.

Hmmm... could code this up,

variables
block length would be a variable,
segment run length (where you switch it on ),
and header size limit

On 11/30/2022 3:06 PM, Chris M. Thomasson wrote:
> On 11/30/2022 12:04 PM, Chris M. Thomasson wrote:
>> On 11/21/2022 10:00 PM, Chris M. Thomasson wrote:
>>> On 11/21/2022 9:12 PM, FromTheRafters wrote:
>>>> Sergi o formulated on Friday :
>>>>> On 11/18/2022 3:46 PM, Chris M. Thomasson wrote:
>>>>>> On 11/18/2022 1:42 PM, Sergi o wrote:
>>>>>>> On 11/18/2022 3:33 PM, WM wrote:
>>>>>>>> Fritz Feldhase schrieb am Freitag, 18. November 2022 um 21:30:45
>>>>>>>> UTC+1:
>>>>>>>>> On Friday, November 18, 2022 at 7:36:20 PM UTC+1, Sergi o wrote:
>>>>>>>>
>>>>>>>>>> but you only have crap [...]
>>>>>>>>>
>>>>>>>>> Yeah, it's crap!
>>>>>>>>
>>>>>>>> Says Franz Fritsche who believes that lossless exchange can
>>>>>>>> suffer from infinitely many losses.
>>>>>>>>
>>>>>>>> Regards, WM
>>>>>>>
>>>>>>>
>>>>>>> your "lossless" exchanges creates an infinite amount of litter;
>>>>>>>
>>>>>>> 1. each time a O stickie is put onto a fraction covering it, then
>>>>>>> pulled off later and discarded,
>>>>>>> 2. each time an X pastie is put onto a fraction hiding it, or on
>>>>>>> top of an O stickie and then discarded,
>>>>>>>
>>>>>>> do you pick up after yourself, or just let it rot in the
>>>>>>> environment, like your O's ?
>>>>>>
>>>>>> I wonder if WM is familiar with lossless compression...
>>>>>
>>>>>
>>>>> FTX said they were a lossless exchange, too.
>>>>>
>>>>> lossless compression (the still FAT boys)=> PNG, GIF, ZIP, RAW,
>>>>> BMP, FLAC, ALAC, WMA
>>>>
>>>> There is lossless JPEG too, but is RAW or BMP ever even compressed?
>>
>> Depends on the data stored within.
>
> A question arises, compressing random bits generated from, say a TRNG.
> Can it be done? Humm... No?

No. Compression works because the data has patterns. Random numbers
don't have patterns.

I once saw a computer problem report where the problem was some
compressed, encrypted data wasn't compressed. It was, theoretically, but
the code encrypted the data (which doesn't change the size much if at
all) and then compressed it. Encrypted data theoretically doesn't have
patterns so the "compressed" data was the same size as the original. The
code should have compressed the data first and then encrypted it.

Michael Moroney brought next idea :
> On 11/30/2022 3:06 PM, Chris M. Thomasson wrote:
>> On 11/30/2022 12:04 PM, Chris M. Thomasson wrote:
>>> On 11/21/2022 10:00 PM, Chris M. Thomasson wrote:
>>>> On 11/21/2022 9:12 PM, FromTheRafters wrote:
>>>>> Sergi o formulated on Friday :
>>>>>> On 11/18/2022 3:46 PM, Chris M. Thomasson wrote:
>>>>>>> On 11/18/2022 1:42 PM, Sergi o wrote:
>>>>>>>> On 11/18/2022 3:33 PM, WM wrote:
>>>>>>>>> Fritz Feldhase schrieb am Freitag, 18. November 2022 um 21:30:45
>>>>>>>>> UTC+1:
>>>>>>>>>> On Friday, November 18, 2022 at 7:36:20 PM UTC+1, Sergi o wrote:
>>>>>>>>>
>>>>>>>>>>> but you only have crap [...]
>>>>>>>>>>
>>>>>>>>>> Yeah, it's crap!
>>>>>>>>>
>>>>>>>>> Says Franz Fritsche who believes that lossless exchange can suffer
>>>>>>>>> from infinitely many losses.
>>>>>>>>>
>>>>>>>>> Regards, WM
>>>>>>>>
>>>>>>>>
>>>>>>>> your "lossless" exchanges creates an infinite amount of litter;
>>>>>>>>
>>>>>>>> 1. each time a O stickie is put onto a fraction covering it, then
>>>>>>>> pulled off later and discarded,
>>>>>>>> 2. each time an X pastie is put onto a fraction hiding it, or on top
>>>>>>>> of an O stickie and then discarded,
>>>>>>>>
>>>>>>>> do you pick up after yourself, or just let it rot in the environment,
>>>>>>>> like your O's ?
>>>>>>>
>>>>>>> I wonder if WM is familiar with lossless compression...
>>>>>>
>>>>>>
>>>>>> FTX said they were a lossless exchange, too.
>>>>>>
>>>>>> lossless compression (the still FAT boys)=> PNG, GIF, ZIP, RAW, BMP,
>>>>>> FLAC, ALAC, WMA
>>>>>
>>>>> There is lossless JPEG too, but is RAW or BMP ever even compressed?
>>>
>>> Depends on the data stored within.
>>
>> A question arises, compressing random bits generated from, say a TRNG. Can
>> it be done? Humm... No?
>
> No. Compression works because the data has patterns. Random numbers don't
> have patterns.
>
> I once saw a computer problem report where the problem was some compressed,
> encrypted data wasn't compressed. It was, theoretically, but the code
> encrypted the data (which doesn't change the size much if at all) and then
> compressed it. Encrypted data theoretically doesn't have patterns so the
> "compressed" data was the same size as the original. The code should have
> compressed the data first and then encrypted it.

That's generally the way, some crypto algorithms do compression then
encryption. No sense in encrypting more data than you need to, it can
be expensive in clock ticks.

On 11/30/2022 3:44 PM, FromTheRafters wrote:
> Michael Moroney brought next idea :
>> On 11/30/2022 3:06 PM, Chris M. Thomasson wrote:
>>> On 11/30/2022 12:04 PM, Chris M. Thomasson wrote:
>>>> On 11/21/2022 10:00 PM, Chris M. Thomasson wrote:
>>>>> On 11/21/2022 9:12 PM, FromTheRafters wrote:
>>>>>> Sergi o formulated on Friday :
>>>>>>> On 11/18/2022 3:46 PM, Chris M. Thomasson wrote:
>>>>>>>> On 11/18/2022 1:42 PM, Sergi o wrote:
>>>>>>>>> On 11/18/2022 3:33 PM, WM wrote:
>>>>>>>>>> Fritz Feldhase schrieb am Freitag, 18. November 2022 um 21:30:45 UTC+1:
>>>>>>>>>>> On Friday, November 18, 2022 at 7:36:20 PM UTC+1, Sergi o wrote:
>>>>>>>>>>
>>>>>>>>>>>> but you only have crap [...]
>>>>>>>>>>>
>>>>>>>>>>> Yeah, it's crap!
>>>>>>>>>>
>>>>>>>>>> Says Franz Fritsche who believes that lossless exchange can suffer from infinitely many losses.
>>>>>>>>>>
>>>>>>>>>> Regards, WM
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> your "lossless" exchanges creates an infinite amount of litter;
>>>>>>>>>
>>>>>>>>> 1. each time a O stickie is put onto a fraction covering it, then pulled off later and discarded,
>>>>>>>>> 2. each time an X pastie is put onto a fraction hiding it, or on top of an O stickie and then discarded,
>>>>>>>>>
>>>>>>>>> do you pick up after yourself, or just let it rot in the environment, like your O's ?
>>>>>>>>
>>>>>>>> I wonder if WM is familiar with lossless compression...
>>>>>>>
>>>>>>>
>>>>>>> FTX said they were a lossless exchange, too.
>>>>>>>
>>>>>>> lossless compression (the still FAT boys)=> PNG, GIF, ZIP, RAW, BMP, FLAC, ALAC, WMA
>>>>>>
>>>>>> There is lossless JPEG too, but is RAW or BMP ever even compressed?
>>>>
>>>> Depends on the data stored within.
>>>
>>> A question arises, compressing random bits generated from, say a TRNG. Can it be done? Humm... No?
>>
>> No. Compression works because the data has patterns. Random numbers don't have patterns.
>>
>> I once saw a computer problem report where the problem was some compressed, encrypted data wasn't compressed. It was, theoretically, but the code
>> encrypted the data (which doesn't change the size much if at all) and then compressed it. Encrypted data theoretically doesn't have patterns so the
>> "compressed" data was the same size as the original. The code should have compressed the data first and then encrypted it.
>
> That's generally the way, some crypto algorithms do compression then encryption. No sense in encrypting more data than you need to, it can be expensive
> in clock ticks.

encryption typically scrambles up compressible parts.

most microwave data systems use a form of encryption/decryption to scramble up the data from transmitter to receiver to avoid zero bias drift. there are
other layers of encryption/decryption for security at a higher level.

On 11/30/2022 6:15 PM, Sergi o wrote:
> On 11/30/2022 3:44 PM, FromTheRafters wrote:
>> Michael Moroney brought next idea :
>>> On 11/30/2022 3:06 PM, Chris M. Thomasson wrote:
>>>> On 11/30/2022 12:04 PM, Chris M. Thomasson wrote:
>>>>> On 11/21/2022 10:00 PM, Chris M. Thomasson wrote:
>>>>>> On 11/21/2022 9:12 PM, FromTheRafters wrote:
>>>>>>> Sergi o formulated on Friday :
>>>>>>>> On 11/18/2022 3:46 PM, Chris M. Thomasson wrote:
>>>>>>>>> On 11/18/2022 1:42 PM, Sergi o wrote:
>>>>>>>>>> On 11/18/2022 3:33 PM, WM wrote:
>>>>>>>>>>> Fritz Feldhase schrieb am Freitag, 18. November 2022 um
>>>>>>>>>>> 21:30:45 UTC+1:
>>>>>>>>>>>> On Friday, November 18, 2022 at 7:36:20 PM UTC+1, Sergi o
>>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> but you only have crap [...]
>>>>>>>>>>>>
>>>>>>>>>>>> Yeah, it's crap!
>>>>>>>>>>>
>>>>>>>>>>> Says Franz Fritsche who believes that lossless exchange can
>>>>>>>>>>> suffer from infinitely many losses.
>>>>>>>>>>>
>>>>>>>>>>> Regards, WM
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> your "lossless" exchanges creates an infinite amount of litter;
>>>>>>>>>>
>>>>>>>>>> 1. each time a O stickie is put onto a fraction covering it,
>>>>>>>>>> then pulled off later and discarded,
>>>>>>>>>> 2. each time an X pastie is put onto a fraction hiding it, or
>>>>>>>>>> on top of an O stickie and then discarded,
>>>>>>>>>>
>>>>>>>>>> do you pick up after yourself, or just let it rot in the
>>>>>>>>>> environment, like your O's ?
>>>>>>>>>
>>>>>>>>> I wonder if WM is familiar with lossless compression...
>>>>>>>>
>>>>>>>>
>>>>>>>> FTX said they were a lossless exchange, too.
>>>>>>>>
>>>>>>>> lossless compression (the still FAT boys)=> PNG, GIF, ZIP, RAW,
>>>>>>>> BMP, FLAC, ALAC, WMA
>>>>>>>
>>>>>>> There is lossless JPEG too, but is RAW or BMP ever even compressed?
>>>>>
>>>>> Depends on the data stored within.
>>>>
>>>> A question arises, compressing random bits generated from, say a
>>>> TRNG. Can it be done? Humm... No?
>>>
>>> No. Compression works because the data has patterns. Random numbers
>>> don't have patterns.
>>>
>>> I once saw a computer problem report where the problem was some
>>> compressed, encrypted data wasn't compressed. It was, theoretically,
>>> but the code encrypted the data (which doesn't change the size much
>>> if at all) and then compressed it. Encrypted data theoretically
>>> doesn't have patterns so the "compressed" data was the same size as
>>> the original. The code should have compressed the data first and then
>>> encrypted it.
>>
>> That's generally the way, some crypto algorithms do compression then
>> encryption. No sense in encrypting more data than you need to, it can
>> be expensive in clock ticks.
>
>
> encryption typically scrambles up compressible parts.
>
> most microwave data systems use a form of encryption/decryption to
> scramble up the data from transmitter to receiver to avoid zero bias
> drift. there are other layers of encryption/decryption for security at a
> higher level.

http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=f7cbc95d342d3bc0d548b1dfd52fe6c2da7226ddfc1f27787e6d2b927374463856f19c84964903103f77f69922ba8641cec331481c855b96b42a9a2e4d6404af0a1d3f26d536b3f4bf8e433cb6319b309210c638180d91535c9a10b4c8408c42c879d0ee612827d414a8f4

onsdag 30 november 2022 kl. 16:52:50 UTC+1 skrev WM:
> Jim Burns schrieb am Mittwoch, 30. November 2022 um 14:21:20 UTC+1:
> > On 11/30/2022 6:27 AM, WM wrote:
>
> > > All definable Bob-movers leave Bob in the matrix.
> > All terminating Bob-movers leave Bob in the
> > matrix.
> There are no other definable Bob-movers. But there are undefinable Bob-movers, so-called dark Bob-movers.
> > > A bijection à la Cantor
> > If Cantor said what you (WM) think Cantor said,
> > then Cantor would be wrong.
> I told you what Cantor said. "every number p/q comes at an absolutely fixed position of a simple infinite sequence." Of course he was wrong. Dark Bob-movers cannot produce a mapping.
>
> By the way, your argument fits Cantor's diagonal argument very nicely. Every line with finite line number does not contain the diagonal number. But all lines together contain it.
>
> Regards, WM
you are aware he is mocking your stupid shit, right?

Chris M. Thomasson formulated the question :
> On 11/30/2022 6:15 PM, Sergi o wrote:
>> On 11/30/2022 3:44 PM, FromTheRafters wrote:
>>> Michael Moroney brought next idea :
>>>> On 11/30/2022 3:06 PM, Chris M. Thomasson wrote:
>>>>> On 11/30/2022 12:04 PM, Chris M. Thomasson wrote:
>>>>>> On 11/21/2022 10:00 PM, Chris M. Thomasson wrote:
>>>>>>> On 11/21/2022 9:12 PM, FromTheRafters wrote:
>>>>>>>> Sergi o formulated on Friday :
>>>>>>>>> On 11/18/2022 3:46 PM, Chris M. Thomasson wrote:
>>>>>>>>>> On 11/18/2022 1:42 PM, Sergi o wrote:
>>>>>>>>>>> On 11/18/2022 3:33 PM, WM wrote:
>>>>>>>>>>>> Fritz Feldhase schrieb am Freitag, 18. November 2022 um 21:30:45
>>>>>>>>>>>> UTC+1:
>>>>>>>>>>>>> On Friday, November 18, 2022 at 7:36:20 PM UTC+1, Sergi o wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> but you only have crap [...]
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yeah, it's crap!
>>>>>>>>>>>>
>>>>>>>>>>>> Says Franz Fritsche who believes that lossless exchange can
>>>>>>>>>>>> suffer from infinitely many losses.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards, WM
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> your "lossless" exchanges creates an infinite amount of litter;
>>>>>>>>>>>
>>>>>>>>>>> 1. each time a O stickie is put onto a fraction covering it, then
>>>>>>>>>>> pulled off later and discarded,
>>>>>>>>>>> 2. each time an X pastie is put onto a fraction hiding it, or on
>>>>>>>>>>> top of an O stickie and then discarded,
>>>>>>>>>>>
>>>>>>>>>>> do you pick up after yourself, or just let it rot in the
>>>>>>>>>>> environment, like your O's ?
>>>>>>>>>>
>>>>>>>>>> I wonder if WM is familiar with lossless compression...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> FTX said they were a lossless exchange, too.
>>>>>>>>>
>>>>>>>>> lossless compression (the still FAT boys)=> PNG, GIF, ZIP, RAW, BMP,
>>>>>>>>> FLAC, ALAC, WMA
>>>>>>>>
>>>>>>>> There is lossless JPEG too, but is RAW or BMP ever even compressed?
>>>>>>
>>>>>> Depends on the data stored within.
>>>>>
>>>>> A question arises, compressing random bits generated from, say a TRNG.
>>>>> Can it be done? Humm... No?
>>>>
>>>> No. Compression works because the data has patterns. Random numbers don't
>>>> have patterns.
>>>>
>>>> I once saw a computer problem report where the problem was some
>>>> compressed, encrypted data wasn't compressed. It was, theoretically, but
>>>> the code encrypted the data (which doesn't change the size much if at
>>>> all) and then compressed it. Encrypted data theoretically doesn't have
>>>> patterns so the "compressed" data was the same size as the original. The
>>>> code should have compressed the data first and then encrypted it.
>>>
>>> That's generally the way, some crypto algorithms do compression then
>>> encryption. No sense in encrypting more data than you need to, it can be
>>> expensive in clock ticks.
>>
>>
>> encryption typically scrambles up compressible parts.
>>
>> most microwave data systems use a form of encryption/decryption to scramble
>> up the data from transmitter to receiver to avoid zero bias drift. there
>> are other layers of encryption/decryption for security at a higher level.
>
> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=f7cbc95d342d3bc0d548b1dfd52fe6c2da7226ddfc1f27787e6d2b927374463856f19c84964903103f77f69922ba8641cec331481c855b96b42a9a2e4d6404af0a1d3f26d536b3f4bf8e433cb6319b309210c638180d91535c9a10b4c8408c42c879d0ee612827d414a8f4

More opinions here:

https://superuser.com/questions/257782/compress-and-then-encrypt-or-vice-versa

and here

https://stackoverflow.com/questions/4399812/is-it-better-to-encrypt-a-message-and-then-compress-it-or-the-other-way-around

Jim Burns schrieb am Mittwoch, 30. November 2022 um 21:27:20 UTC+1:
> On 11/30/2022 10:42 AM, WM wrote:

> > If each exchange maintains Bob,
> > then there is none where he could leave.
> Each exchange maintains Bob.
> There is no single exchange where he leaves.

But everything that happens can only happen at a single exchange, a step.
>
> Bob-conservation is a property that
> _sets_ of exchanges have or do not have.

No.
>
> The set of exchanges involving Bob
> *up to* some exchange is
> a terminating Bob-mover.
> That set has Bob-conservation.

Every set of definable exhanges contains only matrices up to a terminating one.
>
> > If he leaves nevertheless,
> > then it is in the darkness, i.e.,
> > such that his first absence cannot be detected.
> Bob does not step out of the matrix.
>
> Insisting that Bob either stays in the
> matrix or steps out of the matrix
> is insisting on Bob-conservation.

I would say it is insisting on the laws of logic. And I do not allow myself and others, whom I can influence, to violate these laws.
>
> The set of all exchanges does not have
> Bob-conservation.

The Cantor list of all lines does not exclude the diagonal number which is excluded by every finite list up to line n since the n-th digits of line number and diagonal number differ.

Regards, WM

zelos...@gmail.com schrieb am Donnerstag, 1. Dezember 2022 um 07:18:41 UTC+1:
> onsdag 30 november 2022 kl. 16:52:50 UTC+1 skrev WM:

> > By the way, your argument fits Cantor's diagonal argument very nicely. Every line with finite line number does not contain the diagonal number. But all lines together contain it.
> >
> you are aware he is mocking your stupid shit, right?

That is no mocking but a simple consequence.

Regards, WM

On 12/1/2022 5:25 AM, FromTheRafters wrote:
> Chris M. Thomasson formulated the question :
>> On 11/30/2022 6:15 PM, Sergi o wrote:
>>> On 11/30/2022 3:44 PM, FromTheRafters wrote:
>>>> Michael Moroney brought next idea :
>>>>> On 11/30/2022 3:06 PM, Chris M. Thomasson wrote:
>>>>>> On 11/30/2022 12:04 PM, Chris M. Thomasson wrote:
>>>>>>> On 11/21/2022 10:00 PM, Chris M. Thomasson wrote:
>>>>>>>> On 11/21/2022 9:12 PM, FromTheRafters wrote:
>>>>>>>>> Sergi o formulated on Friday :
>>>>>>>>>> On 11/18/2022 3:46 PM, Chris M. Thomasson wrote:
>>>>>>>>>>> On 11/18/2022 1:42 PM, Sergi o wrote:
>>>>>>>>>>>> On 11/18/2022 3:33 PM, WM wrote:
>>>>>>>>>>>>> Fritz Feldhase schrieb am Freitag, 18. November 2022 um 21:30:45 UTC+1:
>>>>>>>>>>>>>> On Friday, November 18, 2022 at 7:36:20 PM UTC+1, Sergi o wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> but you only have crap [...]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yeah, it's crap!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Says Franz Fritsche who believes that lossless exchange can suffer from infinitely many losses.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards, WM
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> your "lossless" exchanges creates an infinite amount of litter;
>>>>>>>>>>>>
>>>>>>>>>>>> 1. each time a O stickie is put onto a fraction covering it, then pulled off later and discarded,
>>>>>>>>>>>> 2. each time an X pastie is put onto a fraction hiding it, or on top of an O stickie and then discarded,
>>>>>>>>>>>>
>>>>>>>>>>>> do you pick up after yourself, or just let it rot in the environment, like your O's ?
>>>>>>>>>>>
>>>>>>>>>>> I wonder if WM is familiar with lossless compression...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> FTX said they were a lossless exchange, too.
>>>>>>>>>>
>>>>>>>>>> lossless compression (the still FAT boys)=> PNG, GIF, ZIP, RAW, BMP, FLAC, ALAC, WMA
>>>>>>>>>
>>>>>>>>> There is lossless JPEG too, but is RAW or BMP ever even compressed?
>>>>>>>
>>>>>>> Depends on the data stored within.
>>>>>>
>>>>>> A question arises, compressing random bits generated from, say a TRNG. Can it be done? Humm... No?
>>>>>
>>>>> No. Compression works because the data has patterns. Random numbers don't have patterns.
>>>>>
>>>>> I once saw a computer problem report where the problem was some compressed, encrypted data wasn't compressed. It was, theoretically, but the code
>>>>> encrypted the data (which doesn't change the size much if at all) and then compressed it. Encrypted data theoretically doesn't have patterns so the
>>>>> "compressed" data was the same size as the original. The code should have compressed the data first and then encrypted it.
>>>>
>>>> That's generally the way, some crypto algorithms do compression then encryption. No sense in encrypting more data than you need to, it can be
>>>> expensive in clock ticks.
>>>
>>>
>>> encryption typically scrambles up compressible parts.
>>>
>>> most microwave data systems use a form of encryption/decryption to scramble up the data from transmitter to receiver to avoid zero bias drift. there
>>> are other layers of encryption/decryption for security at a higher level.
>>
>> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=f7cbc95d342d3bc0d548b1dfd52fe6c2da7226ddfc1f27787e6d2b927374463856f19c84964903103f77f69922ba8641cec331481c855b96b42a9a2e4d6404af0a1d3f26d536b3f4bf8e433cb6319b309210c638180d91535c9a10b4c8408c42c879d0ee612827d414a8f4
>
>
> More opinions here:
>
> https://superuser.com/questions/257782/compress-and-then-encrypt-or-vice-versa
>
> and here
>
> https://stackoverflow.com/questions/4399812/is-it-better-to-encrypt-a-message-and-then-compress-it-or-the-other-way-around

gad, there is a lot of misinformation on that site,

Always compress first. (Some content from: "Applied Cryptography, 2nd Ed.", Bruce Schneier, 1996

Bruce has a blog, and has written a few books lately, good stuff.

https://www.schneier.com

On 12/1/2022 10:43 AM, WM wrote:
> Jim Burns schrieb am Mittwoch,
> 30. November 2022 um 21:27:20 UTC+1:
>> On 11/30/2022 10:42 AM, WM wrote:

>>> If each exchange maintains Bob,
>>> then there is none where he could leave.
>>
>> Each exchange maintains Bob.
>> There is no single exchange where he leaves.
>
> But everything that happens
> can only happen at a single exchange,
> a step.

Bob is born at 1/2
An exchange takes him to 2/1
Another exchange takes him to 3/1
Yet another exchange takes him to 6/1

Bob arrives at 6/1.
It takes three exchanges.

>> Bob-conservation is a property that
>> _sets_ of exchanges have or do not have.
>
> No.

Consider another property,
one you'll like better:
taking-Bob-to-6/1-ness.

Some _sets_ of exchanges have
taking-Bob-to-6/1-ness.
Some _sets_ of exchanges don't have
taking-Bob-to-6/1-ness.

Should we ask:
Does the _exchange_ ⟨2/1,3/1⟩ have
taking-Bob-to-6/1-ness?

The same ⟨2/1,3/1⟩ which is in sets with
taking-Bob-to-6/1-ness
is in sets without
taking-Bob-to-6/1-ness.

A set of exchanges, though, either
takes Bob to 6/1 or doesn't take Bob to 6/1

>> The set of exchanges involving Bob
>> *up to* some exchange is
>> a terminating Bob-mover.
>> That set has Bob-conservation.
>
> Every set of definable exhanges contains
> only matrices up to a terminating one.

Define the sequence 𝐶𝑎𝑛𝑡𝑜𝑟 of exchanges
⟨ ⟨1/1,1/1⟩ ⟨1/2,2/1⟩ ⟨2/1,3/1⟩ ... ⟩
so that

⟨p/q,k/1⟩ is in 𝐶𝑎𝑛𝑡𝑜𝑟
if and only if
a terminating sequence 𝐶𝑎𝑛𝑡𝑜𝑟ₖ exists
such that

⟨1/1,1/1⟩ begins 𝐶𝑎𝑛𝑡𝑜𝑟ₖ
⟨p/q,k/1⟩ ends 𝐶𝑎𝑛𝑡𝑜𝑟ₖ

and, for each split of 𝐶𝑎𝑛𝑡𝑜𝑟ₖ
some ⟨pᵢ/qᵢ,kᵢ/1⟩ is last-before
and ⟨pᵢ₊₁/qᵢ₊₁,kᵢ₊₁/1⟩ is first-after

with
kᵢ₊₁ = kᵢ⁺⁺
and,
if qᵢ ≠ 1
then pᵢ₊₁/qᵢ₊₁ = pᵢ⁺⁺/qᵢ⁻⁻
else pᵢ₊₁/qᵢ₊₁ = 1/pᵢ⁺⁺

> Every set of definable exhanges contains
> only matrices up to a terminating one.

If ⟨p/q,k/1⟩ in 𝐶𝑎𝑛𝑡𝑜𝑟 is NOT definable,
then
there is a _first_ ⟨p₁/q₁,k₁/1⟩ in 𝐶𝑎𝑛𝑡𝑜𝑟
which is NOT definable which, being first,
has an immediate predecessor ⟨p₀/q₀,k₀/1⟩
which IS definable.

However,
if p₀ q₀ k₀ are definable,
then p₀⁺⁺ q₀⁻⁻ k₀⁺⁺ are definable,
and,
if ⟨p₀/q₀,k₀/1⟩ is definable,
then ⟨p₁/q₁,k₁/1⟩ =
⟨p₀⁺⁺/q₀⁻⁻,k₀⁺⁺/1⟩ or ⟨1/p₀⁺⁺,k₀⁺⁺/1⟩
is definable.
Contradiction.

Therefore,
if ⟨p/q,k/1⟩ is in 𝐶𝑎𝑛𝑡𝑜𝑟
then ⟨p/q,k/1⟩ is definable.

> Every set of definable exhanges contains
> only matrices up to a terminating one.

If ⟨p/q,k/1⟩ is in 𝐶𝑎𝑛𝑡𝑜𝑟
then
there is another exchange ⟨p'/q',k'/1⟩
in 𝐶𝑎𝑛𝑡𝑜𝑟 after ⟨p/q,k/1⟩

Let
k' = k⁺⁺
and,
if q ≠ 1
then p'/q' = p⁺⁺/q⁻⁻
else p'/q' = 1/p⁺⁺

If
⟨p/q,k/1⟩ is in 𝐶𝑎𝑛𝑡𝑜𝑟
then
𝐶𝑎𝑛𝑡𝑜𝑟ₖ -- ended by ⟨p/q,k/1⟩ -- exists

If
𝐶𝑎𝑛𝑡𝑜𝑟ₖ -- ended by ⟨p/q,k/1⟩ -- exists
then
𝐶𝑎𝑛𝑡𝑜𝑟ₖ₊₁ -- ended by ⟨p'/q',k'/1⟩ -- exists

If
𝐶𝑎𝑛𝑡𝑜𝑟ₖ₊₁ -- ended by ⟨p'/q',k'/1⟩ -- exists
then
⟨p'/q',k'/1⟩ is in 𝐶𝑎𝑛𝑡𝑜𝑟

If
⟨p'/q',k'/1⟩ -- after ⟨p/q,k/1⟩ -- is in 𝐶𝑎𝑛𝑡𝑜𝑟
then
⟨p/q,k/1⟩ doesn't terminate 𝐶𝑎𝑛𝑡𝑜𝑟

Therefore,
if ⟨p/q,k/1⟩ is in 𝐶𝑎𝑛𝑡𝑜𝑟
then ⟨p/q,k/1⟩ doesn't terminate 𝐶𝑎𝑛𝑡𝑜𝑟

> Every set of definable exhanges contains
> only matrices up to a terminating one.

No.
Consider the sequence 𝐶𝑎𝑛𝑡𝑜𝑟 of exchanges,
defined above.

If ⟨p/q,k/1⟩ is in 𝐶𝑎𝑛𝑡𝑜𝑟
then ⟨p/q,k/1⟩ is definable.

If ⟨p/q,k/1⟩ is in 𝐶𝑎𝑛𝑡𝑜𝑟
then ⟨p/q,k/1⟩ doesn't terminate 𝐶𝑎𝑛𝑡𝑜𝑟

𝐶𝑎𝑛𝑡𝑜𝑟, defined above, contains only
definable and non-terminating exchanges.

On 12/1/2022 3:25 AM, FromTheRafters wrote:
> Chris M. Thomasson formulated the question :
>> On 11/30/2022 6:15 PM, Sergi o wrote:
>>> On 11/30/2022 3:44 PM, FromTheRafters wrote:
>>>> Michael Moroney brought next idea :
>>>>> On 11/30/2022 3:06 PM, Chris M. Thomasson wrote:
>>>>>> On 11/30/2022 12:04 PM, Chris M. Thomasson wrote:
>>>>>>> On 11/21/2022 10:00 PM, Chris M. Thomasson wrote:
>>>>>>>> On 11/21/2022 9:12 PM, FromTheRafters wrote:
>>>>>>>>> Sergi o formulated on Friday :
>>>>>>>>>> On 11/18/2022 3:46 PM, Chris M. Thomasson wrote:
>>>>>>>>>>> On 11/18/2022 1:42 PM, Sergi o wrote:
>>>>>>>>>>>> On 11/18/2022 3:33 PM, WM wrote:
>>>>>>>>>>>>> Fritz Feldhase schrieb am Freitag, 18. November 2022 um
>>>>>>>>>>>>> 21:30:45 UTC+1:
>>>>>>>>>>>>>> On Friday, November 18, 2022 at 7:36:20 PM UTC+1, Sergi o
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> but you only have crap [...]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yeah, it's crap!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Says Franz Fritsche who believes that lossless exchange can
>>>>>>>>>>>>> suffer from infinitely many losses.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards, WM
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> your "lossless" exchanges creates an infinite amount of litter;
>>>>>>>>>>>>
>>>>>>>>>>>> 1. each time a O stickie is put onto a fraction covering it,
>>>>>>>>>>>> then pulled off later and discarded,
>>>>>>>>>>>> 2. each time an X pastie is put onto a fraction hiding it,
>>>>>>>>>>>> or on top of an O stickie and then discarded,
>>>>>>>>>>>>
>>>>>>>>>>>> do you pick up after yourself, or just let it rot in the
>>>>>>>>>>>> environment, like your O's ?
>>>>>>>>>>>
>>>>>>>>>>> I wonder if WM is familiar with lossless compression...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> FTX said they were a lossless exchange, too.
>>>>>>>>>>
>>>>>>>>>> lossless compression (the still FAT boys)=> PNG, GIF, ZIP,
>>>>>>>>>> RAW, BMP, FLAC, ALAC, WMA
>>>>>>>>>
>>>>>>>>> There is lossless JPEG too, but is RAW or BMP ever even
>>>>>>>>> compressed?
>>>>>>>
>>>>>>> Depends on the data stored within.
>>>>>>
>>>>>> A question arises, compressing random bits generated from, say a
>>>>>> TRNG. Can it be done? Humm... No?
>>>>>
>>>>> No. Compression works because the data has patterns. Random numbers
>>>>> don't have patterns.
>>>>>
>>>>> I once saw a computer problem report where the problem was some
>>>>> compressed, encrypted data wasn't compressed. It was,
>>>>> theoretically, but the code encrypted the data (which doesn't
>>>>> change the size much if at all) and then compressed it. Encrypted
>>>>> data theoretically doesn't have patterns so the "compressed" data
>>>>> was the same size as the original. The code should have compressed
>>>>> the data first and then encrypted it.
>>>>
>>>> That's generally the way, some crypto algorithms do compression then
>>>> encryption. No sense in encrypting more data than you need to, it
>>>> can be expensive in clock ticks.
>>>
>>>
>>> encryption typically scrambles up compressible parts.
>>>
>>> most microwave data systems use a form of encryption/decryption to
>>> scramble up the data from transmitter to receiver to avoid zero bias
>>> drift. there are other layers of encryption/decryption for security
>>> at a higher level.
>>
>> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=f7cbc95d342d3bc0d548b1dfd52fe6c2da7226ddfc1f27787e6d2b927374463856f19c84964903103f77f69922ba8641cec331481c855b96b42a9a2e4d6404af0a1d3f26d536b3f4bf8e433cb6319b309210c638180d91535c9a10b4c8408c42c879d0ee612827d414a8f4
>
>
> More opinions here:
>
> https://superuser.com/questions/257782/compress-and-then-encrypt-or-vice-versa
>
> and here
>
> https://stackoverflow.com/questions/4399812/is-it-better-to-encrypt-a-message-and-then-compress-it-or-the-other-way-around

My two cents, you must compress _before_ encryption. Period. It makes sense.

on 12/1/2022, Chris M. Thomasson supposed :
> On 12/1/2022 3:25 AM, FromTheRafters wrote:
>> Chris M. Thomasson formulated the question :
>>> On 11/30/2022 6:15 PM, Sergi o wrote:
>>>> On 11/30/2022 3:44 PM, FromTheRafters wrote:
>>>>> Michael Moroney brought next idea :
>>>>>> On 11/30/2022 3:06 PM, Chris M. Thomasson wrote:
>>>>>>> On 11/30/2022 12:04 PM, Chris M. Thomasson wrote:
>>>>>>>> On 11/21/2022 10:00 PM, Chris M. Thomasson wrote:
>>>>>>>>> On 11/21/2022 9:12 PM, FromTheRafters wrote:
>>>>>>>>>> Sergi o formulated on Friday :
>>>>>>>>>>> On 11/18/2022 3:46 PM, Chris M. Thomasson wrote:
>>>>>>>>>>>> On 11/18/2022 1:42 PM, Sergi o wrote:
>>>>>>>>>>>>> On 11/18/2022 3:33 PM, WM wrote:
>>>>>>>>>>>>>> Fritz Feldhase schrieb am Freitag, 18. November 2022 um
>>>>>>>>>>>>>> 21:30:45 UTC+1:
>>>>>>>>>>>>>>> On Friday, November 18, 2022 at 7:36:20 PM UTC+1, Sergi o
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> but you only have crap [...]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yeah, it's crap!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Says Franz Fritsche who believes that lossless exchange can
>>>>>>>>>>>>>> suffer from infinitely many losses.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards, WM
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> your "lossless" exchanges creates an infinite amount of litter;
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. each time a O stickie is put onto a fraction covering it,
>>>>>>>>>>>>> then pulled off later and discarded,
>>>>>>>>>>>>> 2. each time an X pastie is put onto a fraction hiding it, or on
>>>>>>>>>>>>> top of an O stickie and then discarded,
>>>>>>>>>>>>>
>>>>>>>>>>>>> do you pick up after yourself, or just let it rot in the
>>>>>>>>>>>>> environment, like your O's ?
>>>>>>>>>>>>
>>>>>>>>>>>> I wonder if WM is familiar with lossless compression...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> FTX said they were a lossless exchange, too.
>>>>>>>>>>>
>>>>>>>>>>> lossless compression (the still FAT boys)=> PNG, GIF, ZIP, RAW,
>>>>>>>>>>> BMP, FLAC, ALAC, WMA
>>>>>>>>>>
>>>>>>>>>> There is lossless JPEG too, but is RAW or BMP ever even compressed?
>>>>>>>>
>>>>>>>> Depends on the data stored within.
>>>>>>>
>>>>>>> A question arises, compressing random bits generated from, say a TRNG.
>>>>>>> Can it be done? Humm... No?
>>>>>>
>>>>>> No. Compression works because the data has patterns. Random numbers
>>>>>> don't have patterns.
>>>>>>
>>>>>> I once saw a computer problem report where the problem was some
>>>>>> compressed, encrypted data wasn't compressed. It was, theoretically,
>>>>>> but the code encrypted the data (which doesn't change the size much if
>>>>>> at all) and then compressed it. Encrypted data theoretically doesn't
>>>>>> have patterns so the "compressed" data was the same size as the
>>>>>> original. The code should have compressed the data first and then
>>>>>> encrypted it.
>>>>>
>>>>> That's generally the way, some crypto algorithms do compression then
>>>>> encryption. No sense in encrypting more data than you need to, it can be
>>>>> expensive in clock ticks.
>>>>
>>>>
>>>> encryption typically scrambles up compressible parts.
>>>>
>>>> most microwave data systems use a form of encryption/decryption to
>>>> scramble up the data from transmitter to receiver to avoid zero bias
>>>> drift. there are other layers of encryption/decryption for security at a
>>>> higher level.
>>>
>>> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=f7cbc95d342d3bc0d548b1dfd52fe6c2da7226ddfc1f27787e6d2b927374463856f19c84964903103f77f69922ba8641cec331481c855b96b42a9a2e4d6404af0a1d3f26d536b3f4bf8e433cb6319b309210c638180d91535c9a10b4c8408c42c879d0ee612827d414a8f4
>>
>>
>> More opinions here:
>>
>> https://superuser.com/questions/257782/compress-and-then-encrypt-or-vice-versa
>>
>> and here
>>
>> https://stackoverflow.com/questions/4399812/is-it-better-to-encrypt-a-message-and-then-compress-it-or-the-other-way-around
>
> My two cents, you must compress _before_ encryption. Period. It makes sense.

On its surface. Then again the algorithm must be known, so one could
expect a parse tree or something specific to the compression scheme
used to be some known plaintext as far as the encryption is concerned.

Eh, it gets complicated.

On 12/1/2022 2:01 PM, Jim Burns wrote:
> On 12/1/2022 10:43 AM, WM wrote:
>> Jim Burns schrieb am Mittwoch,
>> 30. November 2022 um 21:27:20 UTC+1:
>>> On 11/30/2022 10:42 AM, WM wrote:
>
>>>> If each exchange maintains Bob,
>>>> then there is none where he could leave.
>>>
>>> Each exchange maintains Bob.
>>> There is no single exchange where he leaves.
>>
>> But everything that happens
>> can only happen at a single exchange,
>> a step.
>
> Bob is born at 1/2
> An exchange takes him to 2/1
> Another exchange takes him to 3/1
> Yet another exchange takes him to 6/1

at each "exchange", money changes hands.

*Bob was SOLD 3 times*, making McWM even richer.

WM has dug a hole so deep, he cannot get out of it.

It is very obvious to all that WM's "dark numbers" is a total fabrication, a bold lie.

On 12/1/2022 3:07 PM, Chris M. Thomasson wrote:

> My two cents, you must compress _before_ encryption. Period. It makes
> sense.

Exactly. The problem report I mentioned was originally that compression
was skipped if encrypted, but that wasn't true. The sw did things out of
order, it encrypted first (result about the same size) and then
"compressed" what looked like random data, so the result was also about
the same size.

What's funny is even ancient Morse Code from the mid 1800s has
(timewise) compression for the letters. Each character is some number of
dots and dashes (3 times as long as a dot) followed by 1 time unit of
silence to separate dots and dashes, or 3 total units to separate
characters. An "E" is just a dot, 4 units total (dot + 3 separator)
while "Q" is dash dash dot dash, a total of 16 time units. English text
would be shorter timewise than transmitting an equal number of random
letters, as "rare" letters in English were longer than "common" letters.

On 12/1/2022 1:25 PM, FromTheRafters wrote:
> on 12/1/2022, Chris M. Thomasson supposed :
>> On 12/1/2022 3:25 AM, FromTheRafters wrote:
>>> Chris M. Thomasson formulated the question :
>>>> On 11/30/2022 6:15 PM, Sergi o wrote:
>>>>> On 11/30/2022 3:44 PM, FromTheRafters wrote:
>>>>>> Michael Moroney brought next idea :
>>>>>>> On 11/30/2022 3:06 PM, Chris M. Thomasson wrote:
>>>>>>>> On 11/30/2022 12:04 PM, Chris M. Thomasson wrote:
>>>>>>>>> On 11/21/2022 10:00 PM, Chris M. Thomasson wrote:
>>>>>>>>>> On 11/21/2022 9:12 PM, FromTheRafters wrote:
>>>>>>>>>>> Sergi o formulated on Friday :
>>>>>>>>>>>> On 11/18/2022 3:46 PM, Chris M. Thomasson wrote:
>>>>>>>>>>>>> On 11/18/2022 1:42 PM, Sergi o wrote:
>>>>>>>>>>>>>> On 11/18/2022 3:33 PM, WM wrote:
>>>>>>>>>>>>>>> Fritz Feldhase schrieb am Freitag, 18. November 2022 um
>>>>>>>>>>>>>>> 21:30:45 UTC+1:
>>>>>>>>>>>>>>>> On Friday, November 18, 2022 at 7:36:20 PM UTC+1, Sergi
>>>>>>>>>>>>>>>> o wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> but you only have crap [...]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yeah, it's crap!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Says Franz Fritsche who believes that lossless exchange
>>>>>>>>>>>>>>> can suffer from infinitely many losses.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards, WM
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> your "lossless" exchanges creates an infinite amount of
>>>>>>>>>>>>>> litter;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. each time a O stickie is put onto a fraction covering
>>>>>>>>>>>>>> it, then pulled off later and discarded,
>>>>>>>>>>>>>> 2. each time an X pastie is put onto a fraction hiding it,
>>>>>>>>>>>>>> or on top of an O stickie and then discarded,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> do you pick up after yourself, or just let it rot in the
>>>>>>>>>>>>>> environment, like your O's ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I wonder if WM is familiar with lossless compression...
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> FTX said they were a lossless exchange, too.
>>>>>>>>>>>>
>>>>>>>>>>>> lossless compression (the still FAT boys)=> PNG, GIF, ZIP,
>>>>>>>>>>>> RAW, BMP, FLAC, ALAC, WMA
>>>>>>>>>>>
>>>>>>>>>>> There is lossless JPEG too, but is RAW or BMP ever even
>>>>>>>>>>> compressed?
>>>>>>>>>
>>>>>>>>> Depends on the data stored within.
>>>>>>>>
>>>>>>>> A question arises, compressing random bits generated from, say a
>>>>>>>> TRNG. Can it be done? Humm... No?
>>>>>>>
>>>>>>> No. Compression works because the data has patterns. Random
>>>>>>> numbers don't have patterns.
>>>>>>>
>>>>>>> I once saw a computer problem report where the problem was some
>>>>>>> compressed, encrypted data wasn't compressed. It was,
>>>>>>> theoretically, but the code encrypted the data (which doesn't
>>>>>>> change the size much if at all) and then compressed it. Encrypted
>>>>>>> data theoretically doesn't have patterns so the "compressed" data
>>>>>>> was the same size as the original. The code should have
>>>>>>> compressed the data first and then encrypted it.
>>>>>>
>>>>>> That's generally the way, some crypto algorithms do compression
>>>>>> then encryption. No sense in encrypting more data than you need
>>>>>> to, it can be expensive in clock ticks.
>>>>>
>>>>>
>>>>> encryption typically scrambles up compressible parts.
>>>>>
>>>>> most microwave data systems use a form of encryption/decryption to
>>>>> scramble up the data from transmitter to receiver to avoid zero
>>>>> bias drift. there are other layers of encryption/decryption for
>>>>> security at a higher level.
>>>>
>>>> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=f7cbc95d342d3bc0d548b1dfd52fe6c2da7226ddfc1f27787e6d2b927374463856f19c84964903103f77f69922ba8641cec331481c855b96b42a9a2e4d6404af0a1d3f26d536b3f4bf8e433cb6319b309210c638180d91535c9a10b4c8408c42c879d0ee612827d414a8f4
>>>
>>>
>>> More opinions here:
>>>
>>> https://superuser.com/questions/257782/compress-and-then-encrypt-or-vice-versa
>>>
>>> and here
>>>
>>> https://stackoverflow.com/questions/4399812/is-it-better-to-encrypt-a-message-and-then-compress-it-or-the-other-way-around
>>
>> My two cents, you must compress _before_ encryption. Period. It makes
>> sense.
>
> On its surface. Then again the algorithm must be known, so one could
> expect a parse tree or something specific to the compression scheme used
> to be some known plaintext as far as the encryption is concerned.
>
> Eh, it gets complicated.

Yeah. Actually, compressing then encrypting, can introduce certain
things into the plaintext. Like a header, or magic number... Give Eve a
heads up.

On 12/1/2022 4:12 PM, Chris M. Thomasson wrote:
> On 12/1/2022 1:25 PM, FromTheRafters wrote:
>> on 12/1/2022, Chris M. Thomasson supposed :
>>> On 12/1/2022 3:25 AM, FromTheRafters wrote:
>>>> Chris M. Thomasson formulated the question :
>>>>> On 11/30/2022 6:15 PM, Sergi o wrote:
>>>>>> On 11/30/2022 3:44 PM, FromTheRafters wrote:
>>>>>>> Michael Moroney brought next idea :
>>>>>>>> On 11/30/2022 3:06 PM, Chris M. Thomasson wrote:
>>>>>>>>> On 11/30/2022 12:04 PM, Chris M. Thomasson wrote:
>>>>>>>>>> On 11/21/2022 10:00 PM, Chris M. Thomasson wrote:
>>>>>>>>>>> On 11/21/2022 9:12 PM, FromTheRafters wrote:
>>>>>>>>>>>> Sergi o formulated on Friday :
>>>>>>>>>>>>> On 11/18/2022 3:46 PM, Chris M. Thomasson wrote:
>>>>>>>>>>>>>> On 11/18/2022 1:42 PM, Sergi o wrote:
>>>>>>>>>>>>>>> On 11/18/2022 3:33 PM, WM wrote:
>>>>>>>>>>>>>>>> Fritz Feldhase schrieb am Freitag, 18. November 2022 um 21:30:45 UTC+1:
>>>>>>>>>>>>>>>>> On Friday, November 18, 2022 at 7:36:20 PM UTC+1, Sergi o wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> but you only have crap [...]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yeah, it's crap!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Says Franz Fritsche who believes that lossless exchange can suffer from infinitely many losses.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards, WM
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> your "lossless" exchanges creates an infinite amount of litter;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. each time a O stickie is put onto a fraction covering it, then pulled off later and discarded,
>>>>>>>>>>>>>>> 2. each time an X pastie is put onto a fraction hiding it, or on top of an O stickie and then discarded,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> do you pick up after yourself, or just let it rot in the environment, like your O's ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I wonder if WM is familiar with lossless compression...
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> FTX said they were a lossless exchange, too.
>>>>>>>>>>>>>
>>>>>>>>>>>>> lossless compression (the still FAT boys)=> PNG, GIF, ZIP, RAW, BMP, FLAC, ALAC, WMA
>>>>>>>>>>>>
>>>>>>>>>>>> There is lossless JPEG too, but is RAW or BMP ever even compressed?
>>>>>>>>>>
>>>>>>>>>> Depends on the data stored within.
>>>>>>>>>
>>>>>>>>> A question arises, compressing random bits generated from, say a TRNG. Can it be done? Humm... No?
>>>>>>>>
>>>>>>>> No. Compression works because the data has patterns. Random numbers don't have patterns.
>>>>>>>>
>>>>>>>> I once saw a computer problem report where the problem was some compressed, encrypted data wasn't compressed. It was, theoretically, but the
>>>>>>>> code encrypted the data (which doesn't change the size much if at all) and then compressed it. Encrypted data theoretically doesn't have
>>>>>>>> patterns so the "compressed" data was the same size as the original. The code should have compressed the data first and then encrypted it.
>>>>>>>
>>>>>>> That's generally the way, some crypto algorithms do compression then encryption. No sense in encrypting more data than you need to, it can be
>>>>>>> expensive in clock ticks.
>>>>>>
>>>>>>
>>>>>> encryption typically scrambles up compressible parts.
>>>>>>
>>>>>> most microwave data systems use a form of encryption/decryption to scramble up the data from transmitter to receiver to avoid zero bias drift.
>>>>>> there are other layers of encryption/decryption for security at a higher level.
>>>>>
>>>>> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=f7cbc95d342d3bc0d548b1dfd52fe6c2da7226ddfc1f27787e6d2b927374463856f19c84964903103f77f69922ba8641cec331481c855b96b42a9a2e4d6404af0a1d3f26d536b3f4bf8e433cb6319b309210c638180d91535c9a10b4c8408c42c879d0ee612827d414a8f4
>>>>
>>>>
>>>> More opinions here:
>>>>
>>>> https://superuser.com/questions/257782/compress-and-then-encrypt-or-vice-versa
>>>>
>>>> and here
>>>>
>>>> https://stackoverflow.com/questions/4399812/is-it-better-to-encrypt-a-message-and-then-compress-it-or-the-other-way-around
>>>
>>> My two cents, you must compress _before_ encryption. Period. It makes sense.
>>
>> On its surface. Then again the algorithm must be known, so one could expect a parse tree or something specific to the compression scheme used to be
>> some known plaintext as far as the encryption is concerned.
>>
>> Eh, it gets complicated.
>
> Yeah. Actually, compressing then encrypting, can introduce certain things into the plaintext. Like a header, or magic number... Give Eve a heads up.
>

....which is why I stopped using ROT13

torsdag 1 december 2022 kl. 16:46:17 UTC+1 skrev WM:
> zelos...@gmail.com schrieb am Donnerstag, 1. Dezember 2022 um 07:18:41 UTC+1:
> > onsdag 30 november 2022 kl. 16:52:50 UTC+1 skrev WM:
>
> > > By the way, your argument fits Cantor's diagonal argument very nicely. Every line with finite line number does not contain the diagonal number. But all lines together contain it.
> > >
> > you are aware he is mocking your stupid shit, right?
> That is no mocking but a simple consequence.
>
> Regards, WM
There is mocking because you are an idiot when it comes ot mathematics