Groups > comp.compression > #823 > unrolled thread

Modulus, Factoring and Compressing random data

Started by	Ernst <Ernst_Berg@sbcglobal.net>
First post	2012-01-24 09:46 -0800
Last post	2012-02-02 07:46 -0500
Articles	19 on this page of 119 — 13 participants

Back to article view | Back to comp.compression

  Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-24 09:46 -0800
    Re: Modulus, Factoring and Compressing random data Earl_Colby_Pottinger <earlcolby.pottinger@sympatico.ca> - 2012-01-24 13:03 -0800
      Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-24 14:52 -0800
        Re: Modulus, Factoring and Compressing random data jacko <jackokring@gmail.com> - 2012-01-24 15:25 -0800
          Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-24 16:49 -0800
            Re: Modulus, Factoring and Compressing random data Earl_Colby_Pottinger <earlcolby.pottinger@sympatico.ca> - 2012-01-24 18:55 -0800
              Re: Modulus, Factoring and Compressing random data jacko <jackokring@gmail.com> - 2012-01-24 19:23 -0800
                Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-24 21:08 -0800
              Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-24 20:50 -0800
    Re: Modulus, Factoring and Compressing random data Robert Wessel <robertwessel2@yahoo.com> - 2012-01-25 00:09 -0600
      Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-24 23:51 -0800
        Re: Modulus, Factoring and Compressing random data Robert Wessel <robertwessel2@yahoo.com> - 2012-01-25 02:28 -0600
          Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-25 02:54 -0800
          Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-25 03:08 -0800
        Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-24 23:58 -0800
      Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-25 00:08 -0800
      Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-25 02:40 -0800
        Re: Modulus, Factoring and Compressing random data Robert Wessel <robertwessel2@yahoo.com> - 2012-01-25 05:25 -0600
          Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-25 05:20 -0800
          Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-25 12:12 -0800
            Re: Modulus, Factoring and Compressing random data Earl_Colby_Pottinger <earlcolby.pottinger@sympatico.ca> - 2012-01-25 13:32 -0800
              Re: Modulus, Factoring and Compressing random data James Dow Allen <jdallen2000@yahoo.com> - 2012-01-25 14:33 -0800
                Re: Modulus, Factoring and Compressing random data Robert Wessel <robertwessel2@yahoo.com> - 2012-01-25 17:43 -0600
                  Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-25 19:00 -0800
                    Re: Modulus, Factoring and Compressing random data Earl_Colby_Pottinger <earlcolby.pottinger@sympatico.ca> - 2012-01-26 07:17 -0800
                  Re: Modulus, Factoring and Compressing random data David Thompson <dave.thompson2@verizon.net> - 2012-02-08 06:06 -0500
                    Re: Modulus, Factoring and Compressing random data Earl_Colby_Pottinger <earlcolby.pottinger@sympatico.ca> - 2012-02-08 07:30 -0800
              Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-25 15:19 -0800
    Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-26 02:20 -0800
      Re: Modulus, Factoring and Compressing random data Earl_Colby_Pottinger <earlcolby.pottinger@sympatico.ca> - 2012-01-26 07:25 -0800
        Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-26 18:52 -0800
          Re: Modulus, Factoring and Compressing random data Thomas Richter <thor@math.tu-berlin.de> - 2012-01-27 09:25 +0100
            Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-27 12:01 -0800
            Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-27 12:12 -0800
              Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-27 16:13 -0800
                Re: Modulus, Factoring and Compressing random data Thomas Richter <thor@math.tu-berlin.de> - 2012-01-28 11:22 +0100
                  Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-28 13:59 -0800
                    Re: Modulus, Factoring and Compressing random data Thomas Richter <thor@math.tu-berlin.de> - 2012-01-30 09:49 +0100
                      Re: Modulus, Factoring and Compressing random data stan <smoore@exis.net> - 2012-01-30 08:51 -0500
                        Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-30 08:51 -0800
                      Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-30 08:38 -0800
                        Re: Modulus, Factoring and Compressing random data stan <smoore@exis.net> - 2012-01-30 18:44 -0500
                          Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-30 15:49 -0800
                            Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-30 16:27 -0800
                              Re: Modulus, Factoring and Compressing random data Thomas Richter <thor@math.tu-berlin.de> - 2012-01-31 08:46 +0100
                                Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-31 03:58 -0800
                                  Re: Modulus, Factoring and Compressing random data Thomas Richter <thor@math.tu-berlin.de> - 2012-01-31 21:58 +0100
                            Re: Modulus, Factoring and Compressing random data stan <smoore@exis.net> - 2012-01-31 07:41 -0500
                              Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-31 15:27 -0800
                                Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-31 16:06 -0800
                                  Re: Modulus, Factoring and Compressing random data stan <smoore@exis.net> - 2012-02-01 07:47 -0500
                                    Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-01 09:38 -0800
                                      Re: Modulus, Factoring and Compressing random data "George Johnson" <matrix29@charter.net> - 2012-02-02 08:10 -0500
                                    Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-01 20:22 -0800
                                      Re: Modulus, Factoring and Compressing random data stan <smoore@exis.net> - 2012-02-02 06:31 -0500
                                        Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-02 14:15 -0800
                                        Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-02 19:18 -0800
                                          Re: Modulus, Factoring and Compressing random data "George Johnson" <matrix29@charter.net> - 2012-02-07 06:21 -0500
                                Re: Modulus, Factoring and Compressing random data stan <smoore@exis.net> - 2012-01-31 19:06 -0500
                                  Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-31 19:15 -0800
                                    Re: Modulus, Factoring and Compressing random data stan <smoore@exis.net> - 2012-02-01 08:24 -0500
                                      Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-01 09:54 -0800
                                      Re: Modulus, Factoring and Compressing random data Jim Leonard <mobygamer@gmail.com> - 2012-02-01 11:00 -0800
                                        Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-01 21:19 -0800
                                          Re: Modulus, Factoring and Compressing random data Jim Leonard <mobygamer@gmail.com> - 2012-02-02 07:15 -0800
                                      Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-01 20:25 -0800
                                        Re: Modulus, Factoring and Compressing random data stan <smoore@exis.net> - 2012-02-02 07:07 -0500
                                          Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-02 19:35 -0800
                                            Re: Modulus, Factoring and Compressing random data "George Johnson" <matrix29@charter.net> - 2012-02-07 06:33 -0500
                                  Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-31 18:51 -0800
                                    Re: Modulus, Factoring and Compressing random data Sebastian <s.gesemann@gmail.com> - 2012-02-01 03:51 -0800
                                      Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-01 09:34 -0800
                                    Re: Modulus, Factoring and Compressing random data stan <smoore@exis.net> - 2012-02-01 08:53 -0500
                                      Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-01 20:31 -0800
                                        Re: Modulus, Factoring and Compressing random data stan <smoore@exis.net> - 2012-02-02 07:18 -0500
                          Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-30 16:47 -0800
                            Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-30 17:00 -0800
                              Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-30 18:55 -0800
                            Re: Modulus, Factoring and Compressing random data stan <smoore@exis.net> - 2012-01-31 08:10 -0500
                              Re: Modulus, Factoring and Compressing random data Earl_Colby_Pottinger <earlcolby.pottinger@sympatico.ca> - 2012-01-31 11:31 -0800
                                Re: Modulus, Factoring and Compressing random data Noob <root@127.0.0.1> - 2012-02-02 11:11 +0100
                                  Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-02 14:05 -0800
                                    Re: Modulus, Factoring and Compressing random data stan <smoore@exis.net> - 2012-02-08 13:35 -0500
                                Re: Modulus, Factoring and Compressing random data Noob <root@127.0.0.1> - 2012-02-02 11:24 +0100
                                  Re: Modulus, Factoring and Compressing random data Noob <root@127.0.0.1> - 2012-02-02 12:52 +0100
                                  Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-02 14:06 -0800
                    Re: Modulus, Factoring and Compressing random data Sebastian <s.gesemann@gmail.com> - 2012-01-30 07:09 -0800
                      Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-30 07:45 -0800
                        Re: Modulus, Factoring and Compressing random data Sebastian <s.gesemann@gmail.com> - 2012-01-30 09:42 -0800
                          Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-30 10:19 -0800
                          Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-30 12:05 -0800
                            Re: Modulus, Factoring and Compressing random data Jim Leonard <mobygamer@gmail.com> - 2012-01-30 14:40 -0800
                              Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-30 15:11 -0800
                                Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-30 15:43 -0800
                              Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-30 14:52 -0800
                            Re: Modulus, Factoring and Compressing random data Sebastian <s.gesemann@gmail.com> - 2012-01-31 04:31 -0800
                              Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-01-31 14:21 -0800
                                Re: Modulus, Factoring and Compressing random data pfraser <pete_fraser@comcast.net> - 2012-01-31 15:04 -0800
                                  Re: Modulus, Factoring and Compressing random data Noob <root@127.0.0.1> - 2012-02-01 10:50 +0100
                                    Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-01 20:19 -0800
                              Re: Modulus, Factoring and Compressing random data jacko <jackokring@gmail.com> - 2012-02-02 00:51 -0800
                                Re: Modulus, Factoring and Compressing random data Thomas Richter <thor@math.tu-berlin.de> - 2012-02-02 10:09 +0100
                                  Re: Modulus, Factoring and Compressing random data jacko <jackokring@gmail.com> - 2012-02-02 11:43 -0800
                                    Re: Modulus, Factoring and Compressing random data Sebastian <s.gesemann@gmail.com> - 2012-02-03 01:21 -0800
                                      Re: Modulus, Factoring and Compressing random data Sebastian <s.gesemann@gmail.com> - 2012-02-03 02:43 -0800
                                        Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-04 15:42 -0800
                                  Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-02 13:53 -0800
                                    Re: Modulus, Factoring and Compressing random data stan <smoore@exis.net> - 2012-02-08 13:32 -0500
                                Re: Modulus, Factoring and Compressing random data Sebastian <s.gesemann@gmail.com> - 2012-02-02 01:56 -0800
                                  Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-02 13:54 -0800
                                Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-02 12:59 -0800
                                Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-02 12:47 -0800
                                  Re: Modulus, Factoring and Compressing random data Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-02 23:54 -0800
                                    Re: Modulus, Factoring and Compressing random data stan <smoore@exis.net> - 2012-02-08 13:22 -0500
                                  Re: Modulus, Factoring and Compressing random data Earl_Colby_Pottinger <earlcolby.pottinger@sympatico.ca> - 2012-02-04 20:45 -0800
            Re: Modulus, Factoring and Compressing random data Noob <root@127.0.0.1> - 2012-01-30 15:32 +0100
    Re: Modulus, Factoring and Compressing random data "George Johnson" <matrix29@charter.net> - 2012-02-02 06:34 -0500
    Re: Modulus, Factoring and Compressing random data "George Johnson" <matrix29@charter.net> - 2012-02-02 07:29 -0500
    Re: Modulus, Factoring and Compressing random data "George Johnson" <matrix29@charter.net> - 2012-02-02 07:46 -0500

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

#932

From	jacko <jackokring@gmail.com>
Date	2012-02-02 00:51 -0800
Message-ID	<17045896.574.1328172705434.JavaMail.geo-discussion-forums@yqad38>
In reply to	#902

Basically SG is saying compression (C) is impossible because assuming C and assuming certain properties of C (P) being a secondary implicit assumption, leads to a contradiction of counting, from which is implied NOT C.

As any rationalization which ignores the C AND NOT P alternative would not be suitable for SG and the majority, then it becomes held as crank. Which if you infer the reason for the majority not wanting to look stupid at having copied works containing flawed logic, it all makes sense. You're a crank, not because you are wrong, but because they say you're wrong, and they wish to infer there superior number of bodies, and imply a subconscious threat by it. It's all monkey see, monkey do round here.

The classic P is that all files shrink. But why is this so? The possibility that the file stays the same size is never considered. Because analyzing the possible information contents of a fixed size group of bits is so much more difficult than doing a triangular summation of states. So it is ignored by being said to be impossible without proof. This would make them cranks if they were not in the majority, and so maybe they should be considered pandemic cranks.

Cheers Jacko

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

#933

From	Thomas Richter <thor@math.tu-berlin.de>
Date	2012-02-02 10:09 +0100
Message-ID	<jgdjsa$5u$1@news.belwue.de>
In reply to	#932

Am 02.02.2012 09:51, schrieb jacko:
> Basically SG is saying compression (C) is impossible because assuming C and assuming certain properties of C (P) being a secondary implicit assumption, leads to a contradiction of counting, from which is implied NOT C.
>
> As any rationalization which ignores the C AND NOT P alternative would not be suitable for SG and the majority, then it becomes held as crank. Which if you infer the reason for the majority not wanting to look stupid at having copied works containing flawed logic, it all makes sense. You're a crank, not because you are wrong, but because they say you're wrong, and they wish to infer there superior number of bodies, and imply a subconscious threat by it. It's all monkey see, monkey do round here.
>
> The classic P is that all files shrink. But why is this so? The possibility that the file stays the same size is never considered. Because analyzing the possible information contents of a fixed size group of bits is so much more difficult than doing a triangular summation of states. So it is ignored by being said to be impossible without proof. This would make them cranks if they were not in the majority, and so maybe they should be considered pandemic cranks.


How come that so many people here seem to show here a sign of mental 
insanity? Just again, of course "it is considered" that the file size 
stays the same. Actually, this has been said a couple of times here that 
the only compression that compresses all files is the one that just 
leaves the file size identical. Just that nobody would call that 
compression with the output equally sized than the input. Or at least, 
if I had the option to buy or buy not such a "compression program", I 
would rather not. I would just use "cp", which does a similarly useful job.

Second, this has nothing to do with all the "factorization" business 
here. The question was: "Is modulus reduction a new idea", and the 
answer is "no", by pointing to the literature, which was declined by the 
OP by simply failing to get the literature. This is pretty much a sign 
of "crank-ism".

The question was "does it help for compression", and the answer is 
"likely not so", but whether that is or is not true is still to be seen. 
It has never been applied to compression, as nobody does forsee how it 
could, including the original poster who just posted this into the empty 
space without showing either having a clue of how to use it, or a 
working concept to demonstrate this, and neither a will to work upon it. 
There are two *sensible* reactions one could get from a thinking person: 
a) just to say, "ok, seems to be a stupid idea, you're right", or b) 
"no, here is a working concept, I'll write up a small article to show 
you how it would work, plus a demo program that does this". Instead, the 
OP picks c), namely denoting everyone as "Nazi" who states that using 
factorization is actually a stupid idea for compression. Which, IMHO, it 
really is, but this is an opinion.

What makes it so terribly hard just to get a good book on the 
fundamentals and read about them? It is not that any such reading could 
potentially destroy your brain... It just implies the risk that you
might actually understand why many ideas are stupid, but doesn't render 
any *really* new ideas invalid at all.

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

#948

From	jacko <jackokring@gmail.com>
Date	2012-02-02 11:43 -0800
Message-ID	<1605358.786.1328211796909.JavaMail.geo-discussion-forums@vby1>
In reply to	#933

So a file X bits long can have less than X bits of information due to it being compressible with zip say, AND a file of X bits can have greater than X bits of information due to the fact that it could be the output of say a zip.

So information in a file of X bits IMAX(X) => X => IMIN(X).

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

#959

From	Sebastian <s.gesemann@gmail.com>
Date	2012-02-03 01:21 -0800
Message-ID	<ee9b5b42-06ff-4419-ada9-54c077011d2d@bs8g2000vbb.googlegroups.com>
In reply to	#948

On 2 Feb., 20:43, jacko wrote:
> So a file X bits long can have less than X bits of information due
> to it being compressible with zip say,

Information depends on interpretation. A bunch of bits is a bunch of
bits. It's just data. It seems like you're confusing data with
information.

So, for an X above a certain threshold there will be some files X bits
long that ZIP (in compressor mode) maps to smaller files. Example:
Pick a text file.

> AND a file of X bits can have
> greater than X bits of information due to the fact that it could be
> the output of say a zip.

Again, your idea of "information" is not very useful. Actually, this
almost looks like this idea of "information" contradicts the idea of
"information" from your first part.

So, for an X above a certain threshold there will be some files X bits
long that ZIP (in decompressor mode) maps to larger files. Example:
Some ZIP file.

> So information in a file of X bits IMAX(X) => X => IMIN(X).

This a is nonsense result you derived from confusing data with
information.

ZIP is just one program of many that maps some files to shorter ones
and others to larger ones (or of equal size). Just like the following
function f:

  f: []   -> [0]
     [0]  -> [00]
     [1]  -> [01]
     [00] -> []
     [01] -> [1]
     [10] -> [10]
     [11] -> [11]

For f to be invertible, f needs to be injective. ZIP in compressor
mode is injective (once coding parameters are fixed). So is this
example of f.

What is the information of 00? is it zero because f maps 00 to a
string of zero length? Is it one because the inverse of f maps 00 to a
string of length one? It it two because 00 are two bits? The real
answer is: "It depends on the interpretation of the data"!

What is the information of "Yes"? What is the information of "No"?
Well, it depends what question has been asked! If I ask "Did your fair
coin flip turn out to be heads?" the amount information of both "Yes"
and "No" is exactly one bit because in both cases I would be equally
surprized. There is no way of predicting the outcome with a success
probability other than 50%. If I ask "Is Februrary 3rd your birthday?"
the amount of information I gain due to a "No" is pretty low. That's
because I already expect the answer to be "No". There are just so many
more birthday possibilities. The amount of information I guess due to
a "Yes" is somewhat around log2(365) or slightly less since birthdays
are not uniformly distributed. The trick of efficiently encoding
information is basically to ask few smart questions. Questions like
"Is your birthday somewhere between (and including) januaray 1st and
June 30st?" This is a smart question because you gain lots of
information with a single answer regardless of the actual answer.
Gaining lots of information per question makes it possible to reduce
the number of questions you may have to ask. This is what lossless
data compression is about, basically. Staring at bit strings like
those you can find in the million digits file does not get you
anywhere because they don't have any meaning. It's just data. It's
very likely that Mark chose this file by a process more or less
equivalent to coin flipping which makes this file as probable as any
other file of that size. In this case, the smart questions are
already:
- Is the first bit a one?
- Is the second bit a one?
- Is the third bit a one?
That's because the amount of information -- assuming the random
process I mentioned, of course -- of each possible answer is already
the highest possible. This basically boils down to a "compressior"
which does not do anything interesting. It just copies the file (if
you encode a YES with a binary one).

Cheers!
SG

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

#961

From	Sebastian <s.gesemann@gmail.com>
Date	2012-02-03 02:43 -0800
Message-ID	<caf60558-fea1-4c1c-af76-2405bf7f1b15@o13g2000vbf.googlegroups.com>
In reply to	#959

On 3 Feb., 10:21, Sebastian wrote:
> [...]
> What is the information of "Yes"? What is the information of "No"?
> Well, it depends what question has been asked! If I ask "Did your fair
> coin flip turn out to be heads?" the amount information of both "Yes"
> and "No" is exactly one bit because in both cases I would be equally
> surprized. There is no way of predicting the outcome with a success
> probability other than 50%.

The _expected_ amount of information gained is
50% * 1 bit + 50% * 1 bit = 1 bit

> If I ask "Is Februrary 3rd your birthday?"
> the amount of information I gain due to a "No" is pretty low. That's
> because I already expect the answer to be "No". There are just so many
> more birthday possibilities. The amount of information I guess due to
> a "Yes" is somewhat around log2(365) or slightly less since birthdays
> are not uniformly distributed.

Actually, the amount if information gained for a "Yes" is the log2(1/
Pr(X="february 3rd")) where Pr(X="february 3rd") is the probablity for
feburary 3rd being the correct birthday. The _expected_ information
gain w.r.t. this question is therefore

     Pr(X="february 3rd") *log2(1/   Pr(X="february 3rd") )
 +(1-Pr(X="february 3rd"))*log2(1/(1-Pr(X="february 3rd")))

which is approximately 0.027 bits. So, not very much.

> The trick of efficiently encoding
> information is basically to ask few smart questions. Questions like
> "Is your birthday somewhere between (and including) januaray 1st and
> June 30st?" This is a smart question because you gain lots of
> information with a single answer regardless of the actual answer.

The _expected_ information gain w.r.t. this question is

   50% * log2(1/0.5) + 50% * log2(1/0.5)
 = 50% * 1           + 50% * 1
 = 1 bit

since the probability for the birthday being in the first half of a
year is about 50%. That one bit of expected information is the best
you can do with a yes/no question.

> Gaining lots of information per question makes it possible to reduce
> the number of questions you may have to ask. This is what lossless
> data compression is about, basically. Staring at bit strings like
> those you can find in the million digits file does not get you
> anywhere because they don't have any meaning. It's just data. It's
> very likely that Mark chose this file by a process more or less
> equivalent to coin flipping which makes this file as probable as any
> other file of that size. In this case, the smart questions are
> already:
> - Is the first bit a one?
> - Is the second bit a one?
> - Is the third bit a one?
> That's because the amount of information -- assuming the random
> process I mentioned, of course -- of each possible answer is already
> the highest possible. This basically boils down to a "compressior"
> which does not do anything interesting. It just copies the file (if
> you encode a YES with a binary one).
>
> Cheers!
> SG

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

#974

From	Ernst <Ernst_Berg@sbcglobal.net>
Date	2012-02-04 15:42 -0800
Message-ID	<637729a9-05e5-45aa-b6cc-db5331ce2c2b@4g2000pbz.googlegroups.com>
In reply to	#961

I found this reference but it seems to not quite fit.

This recursive modulus could be considered "primitive recursive
function" since it provides elements used in factoring a number.

http://en.wikipedia.org/wiki/Primitive_recursive_function


Ernst

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

#951

From	Ernst <Ernst_Berg@sbcglobal.net>
Date	2012-02-02 13:53 -0800
Message-ID	<6a002f0c-ac1c-4a34-ac0e-656a435e7dda@pk8g2000pbb.googlegroups.com>
In reply to	#933

On Feb 2, 1:09 am, Thomas Richter <t...@math.tu-berlin.de> wrote:
> Am 02.02.2012 09:51, schrieb jacko:
>
> > Basically SG is saying compression (C) is impossible because assuming C and assuming certain properties of C (P) being a secondary implicit assumption, leads to a contradiction of counting, from which is implied NOT C.
>
> > As any rationalization which ignores the C AND NOT P alternative would not be suitable for SG and the majority, then it becomes held as crank. Which if you infer the reason for the majority not wanting to look stupid at having copied works containing flawed logic, it all makes sense. You're a crank, not because you are wrong, but because they say you're wrong, and they wish to infer there superior number of bodies, and imply a subconscious threat by it. It's all monkey see, monkey do round here.
>
> > The classic P is that all files shrink. But why is this so? The possibility that the file stays the same size is never considered. Because analyzing the possible information contents of a fixed size group of bits is so much more difficult than doing a triangular summation of states. So it is ignored by being said to be impossible without proof. This would make them cranks if they were not in the majority, and so maybe they should be considered pandemic cranks.
>
> How come that so many people here seem to show here a sign of mental
> insanity?

 Look at Cantor for example; Our greatest mathematician of all time he
died utterly alone.  Where were the Peers?  Writing attacks against
what he stood for and his wife didn't love him enough.

Just again, of course "it is considered" that the file size
> stays the same. Actually, this has been said a couple of times here that
> the only compression that compresses all files is the one that just
> leaves the file size identical. Just that nobody would call that
> compression with the output equally sized than the input. Or at least,
> if I had the option to buy or buy not such a "compression program", I
> would rather not. I would just use "cp", which does a similarly useful job.
>
> Second, this has nothing to do with all the "factorization" business
> here. The question was: "Is modulus reduction a new idea", and the
> answer is "no", by pointing to the literature, which was declined by the
> OP by simply failing to get the literature. This is pretty much a sign
> of "crank-ism".

Hey no one claims it's a new idea you are flawed in you perception
there but I'm guessing you won't post a long post putting yourself
down for being "flawed."

My question is has this method been discovered before.  There is a
difference but you should be able to discern that.  If not able to
discern then your worth as a Peer is in question.

>
> The question was "does it help for compression", and the answer is
> "likely not so", but whether that is or is not true is still to be seen.
> It has never been applied to compression, as nobody does forsee how it
> could, including the original poster who just posted this into the empty
> space without showing either having a clue of how to use it, or a
> working concept to demonstrate this,

Yes bad for me that I saw a thing and shared with you all.

and neither a will to work upon it.
> There are two *sensible* reactions one could get from a thinking person:
> a) just to say, "ok, seems to be a stupid idea, you're right", or b)
> "no, here is a working concept, I'll write up a small article to show
> you how it would work, plus a demo program that does this". Instead, the
> OP picks c), namely denoting everyone as "Nazi" who states that using
> factorization is actually a stupid idea for compression. Which, IMHO, it
> really is, but this is an opinion.
>
Here is the thing most of what you post has no relationship to the
basic question of has anyone seen this factoring method before.

It's no more deep or complicated then that.

 As for my fight with AA aka Sebastian it really isn't your business.
You just want more fighting because it is more exciting that anything
you have contributed in this thread so far.
 Please share you factorization discover of last week with us.  It has
to be different than mine.

> What makes it so terribly hard just to get a good book on the
> fundamentals and read about them? It is not that any such reading could
> potentially destroy your brain... It just implies the risk that you
> might actually understand why many ideas are stupid, but doesn't render
> any *really* new ideas invalid at all.

Perhaps some people know more than they are telling because it's no
fun to share here.  What do you think of that?  Can you blame them
when this is just a bitch-fight society in Comp.Compression.

 So I am a Friend of the Sciences not a Peer.  I do have other
discoveries and they deserve a proper paper which I admit I'm unsure
how to write.

 I could try and make friends here by dumping years of research in the
hope that you all will like me but that is silly.

 Now the scope of this thread for me is presenting a factoring method
I saw while working of a Hash function. Exploring it openly with
everyone so no hidden wires or no hidden strings ( as in rope ). And
asking if I discovered the method since all my Google searches and
reading failed to link the terms Modulus + Factoring and similar.

 What I am still here for is to see if someone finds that link to
Recursive Modulus.
 As for reading books on theory I probably will in the near future.  I
have read a few things on the Internet already.
 I'm more a practical use kind of guy.  I like the mechanics of
things.  I especially am wowed by the simplicity of the Recursive
Modulus function and the small amount of code required to factor any
number. For small numbers such as 64 bit the time required is very
reasonable for a 3ghz quad-core of my day.

 And according to one person this Recursive Modulus suffers the same
fate of other factoring methods and that is the amount of time
required to search for factors over all.   I read that Quantum-
computing functions do factor at a much faster speed but we are not
quite there to have Quantum desktop computers currently.

 So all the add-on qualifiers such as insisting I am factoring as a
method of compression are not currently true. I admit I am considering
it but I haven't had the "flash of genius" with that yet.
 What is true is this thread is a direct representation of the Sate of
our Comp.Compression community.

Just think if I did discover the method how many people will reference
this thread as the source of discovery.  I wonder just what all of
this bitch fighting will look to those even 10 years in the future.
 You all do know the Usenet is recorded in real time for all time by
Google and the USA government.

 To the future people I say; These guys leave little else but a "bitch-
fight" while they complain and fish for more information while
crapping on the people that share it.

So let me move on to the next complaint and maybe on to someone who
actually knows something as to who first reported this method if there
was a first besides me.

Ernst

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

#1015

From	stan <smoore@exis.net>
Date	2012-02-08 13:32 -0500
Message-ID	<nnra09-1ka.ln1@invalid.net>
In reply to	#951

Ernst wrote:
> On Feb 2, 1:09 am, Thomas Richter <t...@math.tu-berlin.de> wrote:

>> Second, this has nothing to do with all the "factorization" business
>> here. The question was: "Is modulus reduction a new idea", and the
>> answer is "no", by pointing to the literature, which was declined by the
>> OP by simply failing to get the literature. This is pretty much a sign
>> of "crank-ism".
>
> Hey no one claims it's a new idea you are flawed in you perception
> there but I'm guessing you won't post a long post putting yourself
> down for being "flawed."
>
> My question is has this method been discovered before.  There is a
> difference but you should be able to discern that.  If not able to
> discern then your worth as a Peer is in question.

What pray tell is the difference between a "new idea" and a "method
not discovered before"?

>> What makes it so terribly hard just to get a good book on the
>> fundamentals and read about them? It is not that any such reading could
>> potentially destroy your brain... It just implies the risk that you
>> might actually understand why many ideas are stupid, but doesn't render
>> any *really* new ideas invalid at all.
>
> Perhaps some people know more than they are telling because it's no
> fun to share here.  What do you think of that?  

You don't really want help or even people to share; you seem to simply
demand that people agree with you.

>  So I am a Friend of the Sciences not a Peer.

You will be hard pressed to get much agreement with your personal,
arbitrary definitions of science. The term is pretty well defined and
doesn't match what you want.

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

#934

From	Sebastian <s.gesemann@gmail.com>
Date	2012-02-02 01:56 -0800
Message-ID	<0ad6e5f4-39b6-41f4-8bcc-7244e18183ff@db5g2000vbb.googlegroups.com>
In reply to	#932

On 2 Feb., 09:51, jacko <jackokr...@gmail.com> wrote:
> Basically SG is saying compression (C) is impossible because
> assuming C and assuming certain properties of C (P) being a
> secondary implicit assumption, leads to a contradiction of
> counting, from which is implied NOT C.

Basically, I'm saying that dismissing "classical training" as
unnecessary is a stupid thing to do.

But the issue you actually pointed out here is that sometimes
"secondary implicit assumptions" are made. Why is that? I'll tell you.
This happens if people don't express themselves clearly and stick to
poor/vague wordings of their ideas. In my opinion, it makes little
sense to proceed without asking for clarifications. I'm the last one
to claim that something is impossible. Before I do, I'd like to make
sure that everybody talks about the same "something" and that there is
no miscommunication. Often, I feel like the miscommunication problem
cannot be solved in any other way than by suggesting "classical
training".

> The classic P is that all files shrink. But why is this so? The
> possibility that the file stays the same size is never considered.
> Because analyzing the possible information contents of a fixed
> size group of bits is so much more difficult than doing a
> triangular summation of states. So it is ignored by being said to
> be impossible without proof. This would make them cranks if they
> were not in the majority, and so maybe they should be considered
> pandemic cranks.

I'm glad that you -- unlike Enrst -- are not fixated on a single file
but think more in terms of _sets_ of files. Unfortunately, I could not
follow you here. Care to shed some more light on this? What exactly is
ignored and claimed to be impossible without proof? (See? I'm asking
for clarifications because, otherwise, I would probably add implicit
assumptions about what you could have meant that don't correspond to
what you were trying to talk about.)

Cheers!
SG

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

#952

From	Ernst <Ernst_Berg@sbcglobal.net>
Date	2012-02-02 13:54 -0800
Message-ID	<2bf811f2-f766-48ab-bbc2-e85b263f3a99@sk8g2000pbc.googlegroups.com>
In reply to	#934

On Feb 2, 1:56 am, Sebastian <s.gesem...@gmail.com> wrote:
> On 2 Feb., 09:51, jacko <jackokr...@gmail.com> wrote:
>
> > Basically SG is saying compression (C) is impossible because
> > assuming C and assuming certain properties of C (P) being a
> > secondary implicit assumption, leads to a contradiction of
> > counting, from which is implied NOT C.
>
> Basically, I'm saying that dismissing "classical training" as
> unnecessary is a stupid thing to do.
>
> But the issue you actually pointed out here is that sometimes
> "secondary implicit assumptions" are made. Why is that? I'll tell you.
> This happens if people don't express themselves clearly and stick to
> poor/vague wordings of their ideas. In my opinion, it makes little
> sense to proceed without asking for clarifications. I'm the last one
> to claim that something is impossible. Before I do, I'd like to make
> sure that everybody talks about the same "something" and that there is
> no miscommunication. Often, I feel like the miscommunication problem
> cannot be solved in any other way than by suggesting "classical
> training".
>
> > The classic P is that all files shrink. But why is this so? The
> > possibility that the file stays the same size is never considered.
> > Because analyzing the possible information contents of a fixed
> > size group of bits is so much more difficult than doing a
> > triangular summation of states. So it is ignored by being said to
> > be impossible without proof. This would make them cranks if they
> > were not in the majority, and so maybe they should be considered
> > pandemic cranks.
>
> I'm glad that you -- unlike Enrst -- are not fixated on a single file
> but think more in terms of _sets_ of files. Unfortunately, I could not
> follow you here. Care to shed some more light on this? What exactly is
> ignored and claimed to be impossible without proof? (See? I'm asking
> for clarifications because, otherwise, I would probably add implicit
> assumptions about what you could have meant that don't correspond to
> what you were trying to talk about.)
>
> Cheers!
> SG

Well AA how does his ass taste?

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

#949

From	Ernst <Ernst_Berg@sbcglobal.net>
Date	2012-02-02 12:59 -0800
Message-ID	<17dee380-6bf3-4e65-9497-3931515bd00b@o4g2000pbc.googlegroups.com>
In reply to	#932

On Feb 2, 12:51 am, jacko <jackokr...@gmail.com> wrote:
> Basically SG is saying compression (C) is impossible because assuming C and assuming certain properties of C (P) being a secondary implicit assumption, leads to a contradiction of counting, from which is implied NOT C.
>
> As any rationalization which ignores the C AND NOT P alternative would not be suitable for SG and the majority, then it becomes held as crank. Which if you infer the reason for the majority not wanting to look stupid at having copied works containing flawed logic, it all makes sense. You're a crank, not because you are wrong, but because they say you're wrong, and they wish to infer there superior number of bodies, and imply a subconscious threat by it. It's all monkey see, monkey do round here.
>
> The classic P is that all files shrink. But why is this so? The possibility that the file stays the same size is never considered. Because analysing the possible information contents of a fixed size group of bits is so much more difficult than doing a triangular summation of states. So it is ignored by being said to be impossible without proof. This would make them cranks if they were not in the majority, and so maybe they should be considered pandemic cranks.
>
> Cheers Jacko

I have an alternate I can share but it deserves a proper paper.  Since
I am a Friend not a Peer I'm stuck even getting started.

As for Crank or Kook I am a Friend of the sciences not a Peer.  Those
titles do not apply to me in case that last bit was aimed at
continuing the fight.

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

#950

From	Ernst <Ernst_Berg@sbcglobal.net>
Date	2012-02-02 12:47 -0800
Message-ID	<81cb999b-7cd5-48d0-aaae-88e9c77eb0d2@i10g2000pbl.googlegroups.com>
In reply to	#932

On Feb 2, 12:51 am, jacko <jackokr...@gmail.com> wrote:
> Basically SG is saying compression (C) is impossible because assuming C and assuming certain properties of C (P) being a secondary implicit assumption, leads to a contradiction of counting, from which is implied NOT C.
>
> As any rationalization which ignores the C AND NOT P alternative would not be suitable for SG and the majority, then it becomes held as crank. Which if you infer the reason for the majority not wanting to look stupid at having copied works containing flawed logic, it all makes sense. You're a crank, not because you are wrong, but because they say you're wrong, and they wish to infer there superior number of bodies, and imply a subconscious threat by it. It's all monkey see, monkey do round here.
>
> The classic P is that all files shrink. But why is this so? The possibility that the file stays the same size is never considered. Because analysing the possible information contents of a fixed size group of bits is so much more difficult than doing a triangular summation of states. So it is ignored by being said to be impossible without proof. This would make them cranks if they were not in the majority, and so maybe they should be considered pandemic cranks.
>
> Cheers Jacko

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

#958

From	Ernst <Ernst_Berg@sbcglobal.net>
Date	2012-02-02 23:54 -0800
Message-ID	<251f14db-c2b9-46c7-ba8e-d5e4177366ff@ow3g2000pbc.googlegroups.com>
In reply to	#950

I will be distracted with assembling a new computer so hang on for
more fighting that everyone loves.

 Please post all you want while I am busy.  Insults away!  I'll get
back to my role in this forum shortly and I'll try to pick something
really fun from all the replies to fight about.  I think we can make
this work.  If there is one particular fight point that will be more
fun than others just post the request.

When in Rome do as the Romans.

Ernst

P.S. on the serious side if anyone knows of a reference to recursive
modulus please share.  I will be kindly grateful. I promise!

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

#1014

From	stan <smoore@exis.net>
Date	2012-02-08 13:22 -0500
Message-ID	<p4ra09-1ka.ln1@invalid.net>
In reply to	#958

Ernst wrote:
>
> P.S. on the serious side if anyone knows of a reference to recursive
> modulus please share.  I will be kindly grateful. I promise!

You have been pointed it the proper direction multiple times. You
might be surprised to find that you can't find everything on the
internet. I haven't tried looking and I'm not interested in doing your
research, but it may help you to know that the experts in the field
rarely talk about modulus math but use the term congruences. To be
clear, I've never seen nor looked for the information on the internet
but I have seen it in books.

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

#977

From	Earl_Colby_Pottinger <earlcolby.pottinger@sympatico.ca>
Date	2012-02-04 20:45 -0800
Message-ID	<f8e2cfbb-dd7d-4a3a-8f27-b373d72e6a7c@18g2000yqe.googlegroups.com>
In reply to	#950

And yet despite all your claims about how good your code is you still
have not factored a single RSA number.

Until you can do that, all you are sprouting is hot air.

Want to prove you are right? Factor an unsolved RSA number.

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

#880

From	Noob <root@127.0.0.1>
Date	2012-01-30 15:32 +0100
Message-ID	<jg69lt$jee$1@dont-email.me>
In reply to	#864

Thomas Richter wrote:

> Of course he *knows* for sure. That's the whole point of how RSA works. 
> It is defined this way.

David Ireland has written a very good (IMHO) presentation of RSA.

http://www.di-mgt.com.au/rsa_alg.html

To the OP: JSH, king of cranks, has already claimed dominion
over "solving the factoring problem".

http://somemath.blogspot.com/

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

#937

From	"George Johnson" <matrix29@charter.net>
Date	2012-02-02 06:34 -0500
Message-ID	<VvuWq.6026$4K5.1528@newsfe16.iad>
In reply to	#823

"Ernst" <Ernst_Berg@sbcglobal.net> wrote in message 
news:e468319d-5350-4448-8238-be64c676ae68@n7g2000pbd.googlegroups.com...
>
> Hey all..
>
> I'm putting in hours of chair time exploring the nature of
> information and my attention has turned to Modulus.
>
> I see here, through results I wasn't expecting, that modulus is used
> for factoring.  I noticed the odd ends in one or zero to the sequences
> and thought hey that is cool!
> Turns out this is the basis of many factoring efforts.
>
> I'm hoping for input and conversation.  In return I will moderate my
> output so that it functions in a communal setting.
>
> I love to explore so I was looking at the sequence of reminders when
> they are reused as the modulus.
>
> So N mod M = A then N mod A = B and so on.  It ends in 1 or 0.  In
> simpler terms it finds a factor or it doesn't of N
>
> Is that the basic concept behind all the Modulus based factoring?
> I see names such as Fermat and Euler plus Wikipedia has a nice page
> on factoring large numbers.
>
> So, May I ask if anyone has heard of factoring with recursive modulus
> as i have stated?
> It must be common knowledge I assume.
>
> This is a clear idea of what I am asking.
>
> I was reading about using value about half the N to start.
>
> N = 14600207906227040223 mod 2^32 = 1233334239
> N mod 1233334239 = 647107860
> 48743583
> 17046876
> 15135939
> 601545, 209958,16905, 8988, 3927, 2898,  777,  441 , 21, 0
>
> So 3*7 are factors of N
>
> When the sequence ends in 1,0 I believe there are no factors.
>
>
> I see that searching for factors through changing the M takes a long
> time.
>
>
> So, I am interested in using the Modulus in creative ways and I
> welcome input.  I rarely use Modulus with the "things" I do but it
> looks like I'm moving that way.
>
> There is something more obvious to this.  Can anyone see it?
>
> Think Data compression.
>
> Ernst

    I can speed your search space reduction a tad.
    After checking for factors of 2 & 5, only check for numbers that end in 
1 or 3 or 7  or 9.

    All primes in Decimal Base 10 (except 2 & 5) end in 1 or 3 or 7  or 9.
    That reduces your search space from 10*N to 4*N. A reduction to 40% of 
the original search zone.
    For 1000 numbers checked for factors, this reduces it to 400+2 (primes 2 
& 5).  Or 402.
    With your choice to start in the middle (using the division by 2 
sorting) and work upwards then that reduced your search space to 200+1 
(prime 2 being already checked).
    For all factors of 2^100 = 1267650600228229401496703205376 this reduces 
the search zone to 253530120045645880299340641076 numbers.

http://en.wikipedia.org/wiki/Integer_factorization
http://en.wikipedia.org/wiki/Pollard%27s_rho_algorithm
http://en.wikipedia.org/wiki/Shor%27s_algorithm

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

#942

From	"George Johnson" <matrix29@charter.net>
Date	2012-02-02 07:29 -0500
Message-ID	<MivWq.7786$JN6.6239@newsfe13.iad>
In reply to	#823

"Ernst" <Ernst_Berg@sbcglobal.net> wrote in message 
news:e468319d-5350-4448-8238-be64c676ae68@n7g2000pbd.googlegroups.com...
>
> Hey all..
>
> I'm putting in hours of chair time exploring the nature of
> information and my attention has turned to Modulus.
>
> I see here, through results I wasn't expecting, that modulus is used
> for factoring.  I noticed the odd ends in one or zero to the sequences
> and thought hey that is cool!
> Turns out this is the basis of many factoring efforts.
>
> I'm hoping for input and conversation.  In return I will moderate my
> output so that it functions in a communal setting.
>
> I love to explore so I was looking at the sequence of reminders when
> they are reused as the modulus.
>
> So N mod M = A then N mod A = B and so on.  It ends in 1 or 0.  In
> simpler terms it finds a factor or it doesn't of N
>
> Is that the basic concept behind all the Modulus based factoring?
> I see names such as Fermat and Euler plus Wikipedia has a nice page
> on factoring large numbers.
>
> So, May I ask if anyone has heard of factoring with recursive modulus
> as i have stated?
> It must be common knowledge I assume.
>
> This is a clear idea of what I am asking.
>
> I was reading about using value about half the N to start.
>
> N = 14600207906227040223 mod 2^32 = 1233334239
> N mod 1233334239 = 647107860
> 48743583
> 17046876
> 15135939
> 601545, 209958,16905, 8988, 3927, 2898,  777,  441 , 21, 0
>
> So 3*7 are factors of N
>
> When the sequence ends in 1,0 I believe there are no factors.
>
>
> I see that searching for factors through changing the M takes a long
> time.
>
>
> So, I am interested in using the Modulus in creative ways and I
> welcome input.  I rarely use Modulus with the "things" I do but it
> looks like I'm moving that way.
>
> There is something more obvious to this.  Can anyone see it?
>
> Think Data compression.
>
> Ernst

    You might also want to check your math a bit closer.
14600207906227040223

    Factoring large numbers using a method is not really workable if your 
output is faulty.

    Running it through Wolfram Alpha
http://www.wolframalpha.com/input/?i=factor+14600207906227040223

3×7×41×27947×229771×2640739  (6 distinct prime factors)

{1, 3, 7, 21, 41, 123, 287, 861, 27947, 83841, 195629, 229771, 586887, 
689313, 1145827, 1608397, 2640739, 3437481, 4825191, 7922217, 8020789, 
9420611, 18485173, 24062367, 28261833, 55455519, 65944277, 108270299, 
197832831, 324810897, 757892093, 2273676279, 6421410137, 19264230411, 
44949870959, 73800732833, 134849612877, 221402198499, 263277815617, 
516605129831, 606765240769, 789833446851, 1549815389493, 1820295722307, 
1842944709319, 3025830046153, 4247356685383, 5528834127957, 9077490138459, 
12742070056149, 21180810323071, 24877374871529, 63542430969213, 
74632124614587, 174141624100703, 522424872302109, 16957268183771243, 
50871804551313729, 118700877286398701, 356102631859196103, 
695247995534620963, 2085743986603862889, 4866735968742346741, 
14600207906227040223} (64 divisors)

    Just to double check to be safe for your peace of mind
http://www.wolframalpha.com/input/?i=601545*209958*16905*8988*3927*2898*777*441*21
601545*209958*16905*8988*3927*2898*777*441*21
= 1571509362471417712012412374354800

http://www.wolframalpha.com/input/?i=factor+1571509362471417712012412374354800
2^4×3^11×5^2×7^11×11×17^2×23^2×37×107×337×4999  (37 prime factors, 11 
distinct)

    Hmm. You will want to recheck your math.

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

#943

From	"George Johnson" <matrix29@charter.net>
Date	2012-02-02 07:46 -0500
Message-ID	<bzvWq.7787$JN6.3574@newsfe13.iad>
In reply to	#823

"Ernst" <Ernst_Berg@sbcglobal.net> wrote in message 
news:e468319d-5350-4448-8238-be64c676ae68@n7g2000pbd.googlegroups.com...
>
> Hey all..
>
> I'm putting in hours of chair time exploring the nature of
> information and my attention has turned to Modulus.
>
> I see here, through results I wasn't expecting, that modulus is used
> for factoring.  I noticed the odd ends in one or zero to the sequences
> and thought hey that is cool!
> Turns out this is the basis of many factoring efforts.
>
> I'm hoping for input and conversation.  In return I will moderate my
> output so that it functions in a communal setting.
>
> I love to explore so I was looking at the sequence of reminders when
> they are reused as the modulus.
>
> So N mod M = A then N mod A = B and so on.  It ends in 1 or 0.  In
> simpler terms it finds a factor or it doesn't of N
>
> Is that the basic concept behind all the Modulus based factoring?
> I see names such as Fermat and Euler plus Wikipedia has a nice page
> on factoring large numbers.
>
> So, May I ask if anyone has heard of factoring with recursive modulus
> as i have stated?
> It must be common knowledge I assume.
>
> This is a clear idea of what I am asking.
>
> I was reading about using value about half the N to start.
>
> N = 14600207906227040223 mod 2^32 = 1233334239
> N mod 1233334239 = 647107860
> 48743583
> 17046876
> 15135939
> 601545, 209958,16905, 8988, 3927, 2898,  777,  441 , 21, 0
>
> So 3*7 are factors of N
>
> When the sequence ends in 1,0 I believe there are no factors.
>
>
> I see that searching for factors through changing the M takes a long
> time.
>
>
> So, I am interested in using the Modulus in creative ways and I
> welcome input.  I rarely use Modulus with the "things" I do but it
> looks like I'm moving that way.
>
> There is something more obvious to this.  Can anyone see it?
>
> Think Data compression.
>
> Ernst

    Ignore last post. When I copied plaintext from Wolfram Alpha the text in 
the email was having the multiplication symbol being 'x' and when I posted 
to this message board somehow it was bizarrely posted as 'W'. Very very 
weird. Especially since the plaintext from Wolfram Alpha looked correct when 
posting through Windows Live Mail.

2^4x3^11x5^2x7^11x11x17^2x23^2x37x107x337x4999
Or 2^4*3^11*5^2*7^11*11*17^2*23^2*37*107*337*4999

NOT
2^4W3^11W5^2W7^11W11W17^2W23^2W37W107W337W4999

Corrected message below.
=======

    You might also want to check your math a bit closer.
14600207906227040223

    Factoring large numbers using a method is not really workable if your
output is faulty.

    Running it through Wolfram Alpha
http://www.wolframalpha.com/input/?i=factor+14600207906227040223

3 * 7 * 41 * 27947 * 229771 * 2640739  (6 distinct prime factors)

{1, 3, 7, 21, 41, 123, 287, 861, 27947, 83841, 195629, 229771, 586887, 
689313, 1145827, 1608397, 2640739, 3437481, 4825191, 7922217, 8020789, 
9420611, 18485173, 24062367, 28261833, 55455519, 65944277, 108270299, 
197832831, 324810897, 757892093, 2273676279, 6421410137, 19264230411, 
44949870959, 73800732833, 134849612877, 221402198499, 263277815617, 
516605129831, 606765240769, 789833446851, 1549815389493, 1820295722307, 
1842944709319, 3025830046153, 4247356685383, 5528834127957, 9077490138459, 
12742070056149, 21180810323071, 24877374871529, 63542430969213, 
74632124614587, 174141624100703, 522424872302109, 16957268183771243, 
50871804551313729, 118700877286398701, 356102631859196103, 
695247995534620963, 2085743986603862889, 4866735968742346741, 
14600207906227040223} (64 divisors)

    Just to double check to be safe for your peace of mind
http://www.wolframalpha.com/input/?i=601545*209958*16905*8988*3927*2898*777*441*21
601545*209958*16905*8988*3927*2898*777*441*21
= 1571509362471417712012412374354800

http://www.wolframalpha.com/input/?i=factor+1571509362471417712012412374354800
(2^4)*(3^11)*(5^2)*(7^11)*(11)*(17^2)*(23^2)*(37)*(107)*(337)*(4999)  (37 
prime factors, 11 distinct)

    Hmm. You will want to recheck your math.

[toc] | [prev] | [standalone]

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

csiph-web

Modulus, Factoring and Compressing random data

Contents

#932

#933

#948

#959

#961

#974

#951

#1015

#934

#952

#949

#950

#958

#1014

#977

#880

#937

#942

#943