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

Groups > comp.compression > #978 > unrolled thread

Factoring

Back to article view | Back to comp.compression

Contents

  Factoring Mark Nelson <snorkelman@gmail.com> - 2012-02-05 12:08 -0800
    Re: Factoring LawCounsels <LawCounsels@aol.com> - 2012-02-05 13:09 -0800
    Re: Factoring jules Gilbert <jules.stocks@gmail.com> - 2012-02-06 05:44 -0800
      Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-06 10:17 -0800
        Re: Factoring Jim Leonard <mobygamer@gmail.com> - 2012-02-06 14:05 -0800
          Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-06 16:51 -0800
            Re: Factoring Thomas Richter <thor@math.tu-berlin.de> - 2012-02-07 16:58 +0100
        Re: Factoring stan <smoore@exis.net> - 2012-02-08 13:14 -0500
          Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-10 16:58 -0800
            Re: Factoring stan <smoore@exis.net> - 2012-02-10 21:31 -0500
              Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-10 23:29 -0800
                Re: Factoring Robert Wessel <robertwessel2@yahoo.com> - 2012-02-11 01:53 -0600
                  Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-11 09:08 -0800
                    Re: Factoring stan <smoore@exis.net> - 2012-02-11 12:46 -0500
                      Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-11 10:21 -0800
                        Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-11 11:15 -0800
                          Re: Factoring stan <smoore@exis.net> - 2012-02-11 15:14 -0500
                          Re: Factoring Robert Wessel <robertwessel2@yahoo.com> - 2012-02-11 16:01 -0600
                            Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-11 14:34 -0800
                        Re: Factoring stan <smoore@exis.net> - 2012-02-11 15:08 -0500
                      Re: Factoring "George Johnson" <matrix29@charter.net> - 2012-02-11 21:14 -0500
                Re: Factoring "George Johnson" <matrix29@charter.net> - 2012-02-11 21:08 -0500
                  Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-11 22:31 -0800
              Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-10 23:38 -0800
                Re: Factoring Thomas Richter <thor@math.tu-berlin.de> - 2012-02-11 14:50 +0100
                  Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-11 09:01 -0800
                  Re: Factoring Noob <root@127.0.0.1> - 2012-02-16 11:28 +0100
                Re: Factoring stan <smoore@exis.net> - 2012-02-11 12:29 -0500
                  Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-11 09:49 -0800
                    Re: Factoring stan <smoore@exis.net> - 2012-02-11 15:05 -0500
              Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-11 09:20 -0800
                Re: Factoring stan <smoore@exis.net> - 2012-02-11 14:30 -0500
                  Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-11 14:24 -0800
      Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-06 10:18 -0800
    Re: Factoring LawCounsels <LawCounsels@aol.com> - 2012-02-06 18:40 -0800
    Re: Factoring "George Johnson" <matrix29@charter.net> - 2012-02-07 07:42 -0500
      Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-07 05:40 -0800
        Re: Factoring "George Johnson" <matrix29@charter.net> - 2012-02-07 21:27 -0500
          Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-02-10 17:15 -0800
    Re: Factoring Ernst <Ernst_Berg@sbcglobal.net> - 2012-04-15 18:13 -0700

Page 1 of 2  [1] 2  Next page →

#978 — Factoring

For some reason Google Groups stopped sending me daily digests from
comp.compression. The fact that it took me a month to notice is
interesting all in itself.

Ernst is working on trying to factor the million digit number.

As I've mentioned before, if the million digit number just happened to
be prime, it would probably result in a win for someone. The prime
number theorem says that the number of primes below 10^1000000 is
4.3*10^999993.

This means the prime can be denoted by a number that saves six+ digits
over the million digit file.

Feed that number into a computational engine that has two
instructions: 1) calculate prime n, 2) print result

And you have defeated the million digit file by four bytes. I would
definitely count it as a win.

But this unlikely result brings up the more important question: why do
attempts to use factoring, combinatorial techniques, and mathematical
series inevitably result in derision in this NG?

Mostly because they have no track record. And they have no track
record because they don't usually produce useful results.

The interesting data that we want to compress is based on human
language and perception - even executable code is based on human
language. And in that domain, factoring and combinations don't produce
useful results, nor is it likely they will. The data domain is kind of
more fractally than arithmeticy.

From time to time there might be crossovers, but AFAIK nobody has
really found anything interesting down these paths.

If we were trying to compress, say, data generated by automota with a
mathematical bent, it might be a completely different story. But we're
not.

If someone found a way to transform one domain to the other, then we
might really see something. But it seems like a pretty big problem to
get there.

- Mark

[toc] | [next] | [standalone]

#979

On Feb 5, 8:08 pm, Mark Nelson <snorkel...@gmail.com> wrote:
> For some reason Google Groups stopped sending me daily digests from
> comp.compression. The fact that it took me a month to notice is
> interesting all in itself.
>
> Ernst is working on trying to factor the million digit number.
>
> As I've mentioned before, if the million digit number just happened to
> be prime, it would probably result in a win for someone. The prime
> number theorem says that the number of primes below 10^1000000 is
> 4.3*10^999993.
>
> This means the prime can be denoted by a number that saves six+ digits
> over the million digit file.
>
> Feed that number into a computational engine that has two
> instructions: 1) calculate prime n, 2) print result
>
> And you have defeated the million digit file by four bytes. I would
> definitely count it as a win.
>
> But this unlikely result brings up the more important question: why udo
> attempts to use factoring, combinatorial techniques, and mathematical
> series inevitably result in derision in this NG?
>
> Mostly because they have no track record. And they have no track
> record because they don't usually produce useful results.
>
> The interesting data that we want to compress is based on human
> language and perception - even executable code is based on human
> language. And in that domain, factoring and combinations don't produce
> useful results, nor is it likely they will. The data domain is kind of
> more fractally than arithmeticy.
>
> From time to time there might be crossovers, but AFAIK nobody has
> really found anything interesting down these paths.
>
> If we were trying to compress, say, data generated by automota with a
> mathematical bent, it might be a completely different story. But we're
> not.
>
> If someone found a way to transform one domain to the other, then we
> might really see something. But it seems like a pretty big problem to
> get there.
>
> - Mark

Mark :

Applauds than better than most insights shared that factoring,
combinatorics , mathematical series 'may yet' produce the results
( albeit most difficult ) but count as unlikely because so far all
results not yet support .... however this not mathematics ruled out

thought the challenge does not involve every days English type data,
specifically solely deal with only 'random' fair coin toss type
automata generated domain... .hence not dependent on attaining
crossover of 'fractal' domain into 'arithmeticity' domain

Matter of fact would be useful if you would elaborate on 'domains'
mentioned for the forum...

RE : in your web homepage discussions you offer to co-solve the Clay
Institute 7 remaining items & share the prize...... how confident are
you you have already 'mapped out' the proof solution routes to these ?
I will be in touch private email soon ,  on usual standard
confidentialiatity of course

Warm regards,
LawCounsels

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

#981

On Feb 5, 3:08 pm, Mark Nelson <snorkel...@gmail.com> wrote:
> For some reason Google Groups stopped sending me daily digests from
> comp.compression. The fact that it took me a month to notice is
> interesting all in itself.
>
> Ernst is working on trying to factor the million digit number.
>
> As I've mentioned before, if the million digit number just happened to
> be prime, it would probably result in a win for someone. The prime
> number theorem says that the number of primes below 10^1000000 is
> 4.3*10^999993.
>
> This means the prime can be denoted by a number that saves six+ digits
> over the million digit file.
>
> Feed that number into a computational engine that has two
> instructions: 1) calculate prime n, 2) print result
>
> And you have defeated the million digit file by four bytes. I would
> definitely count it as a win.
>
> But this unlikely result brings up the more important question: why do
> attempts to use factoring, combinatorial techniques, and mathematical
> series inevitably result in derision in this NG?
>
> Mostly because they have no track record. And they have no track
> record because they don't usually produce useful results.
>
> The interesting data that we want to compress is based on human
> language and perception - even executable code is based on human
> language. And in that domain, factoring and combinations don't produce
> useful results, nor is it likely they will. The data domain is kind of
> more fractally than arithmeticy.
>
> From time to time there might be crossovers, but AFAIK nobody has
> really found anything interesting down these paths.
>
> If we were trying to compress, say, data generated by automota with a
> mathematical bent, it might be a completely different story. But we're
> not.
>
> If someone found a way to transform one domain to the other, then we
> might really see something. But it seems like a pretty big problem to
> get there.
>
> - Mark

Factoring and compression are as closely related as, say, fish and
bicycling.  These are utterly and completely different topics.  When I
began to look at compression, I too, fumbled around, trying out
different approaches, But nothing,,,

Of course we all know the story about an alien who comes to earth,
discovers and organizes all human learning and understanding, and then
represents this massive quantity of knowledge as a bit-string, places
a binary point to the left of the binary sequence, and proceeds to
notch a stick at the position indicated.  To which I say:

Good work if you can get it...

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

#983

On Feb 6, 5:44 am, jules Gilbert <jules.sto...@gmail.com> wrote:
> On Feb 5, 3:08 pm, Mark Nelson <snorkel...@gmail.com> wrote:
>
>
>
> > For some reason Google Groups stopped sending me daily digests from
> > comp.compression. The fact that it took me a month to notice is
> > interesting all in itself.
>
> > Ernst is working on trying to factor the million digit number.
>
> > As I've mentioned before, if the million digit number just happened to
> > be prime, it would probably result in a win for someone. The prime
> > number theorem says that the number of primes below 10^1000000 is
> > 4.3*10^999993.
>
> > This means the prime can be denoted by a number that saves six+ digits
> > over the million digit file.
>
> > Feed that number into a computational engine that has two
> > instructions: 1) calculate prime n, 2) print result
>
> > And you have defeated the million digit file by four bytes. I would
> > definitely count it as a win.
>
> > But this unlikely result brings up the more important question: why do
> > attempts to use factoring, combinatorial techniques, and mathematical
> > series inevitably result in derision in this NG?
>
> > Mostly because they have no track record. And they have no track
> > record because they don't usually produce useful results.
>
> > The interesting data that we want to compress is based on human
> > language and perception - even executable code is based on human
> > language. And in that domain, factoring and combinations don't produce
> > useful results, nor is it likely they will. The data domain is kind of
> > more fractally than arithmeticy.
>
> > From time to time there might be crossovers, but AFAIK nobody has
> > really found anything interesting down these paths.
>
> > If we were trying to compress, say, data generated by automota with a
> > mathematical bent, it might be a completely different story. But we're
> > not.
>
> > If someone found a way to transform one domain to the other, then we
> > might really see something. But it seems like a pretty big problem to
> > get there.
>
> > - Mark
>
> Factoring and compression are as closely related as, say, fish and
> bicycling.  These are utterly and completely different topics.  When I
> began to look at compression, I too, fumbled around, trying out
> different approaches, But nothing,,,
>
> Of course we all know the story about an alien who comes to earth,
> discovers and organizes all human learning and understanding, and then
> represents this massive quantity of knowledge as a bit-string, places
> a binary point to the left of the binary sequence, and proceeds to
> notch a stick at the position indicated.  To which I say:
>
> Good work if you can get it...

What may have been over looked is that Sebastian inserted the idea
that I was trying to compress using factoring. I never wrote that I am
trying to compress by factoring because I am not.
 I considered Mark's suggestion of generating the Nth prime but it
would need to function for all strings to be practical and in the
specific case of the third factor of MDN that third may or may not be
prime but it is huge and so there is a lot of cpu time to find out if
it is composite or prime. The idea of factoring in general would work
if the strings share enough factors in common but that too is
dependant on the data. But this is digression from the hash function
homework.
 I am designing my first hash functions.  The observation and report
of seeing factors in the recursive modulus "stream" was shared almost
directly with this NG after a couple requests in Mr. Nelson's forum
for the Million Digit Challenge.
 I didn't expect a fight since I was following what rules I gleaned
from here.  I presented the discovery, provided proof and asked
questions sharing it with everyone. However, each year I also have to
remind people that insults such as crank and kook are offensive and
each year it seems to be ignored. I am glad this is far out in the
open now. Perhaps some of you will avoid the bullying if you think I
will fight back.  Not everyone will be alike in this world but we all
have two things in common that can serve as a basis for friendship and
they are; Everyone dies and no one knows everything.

 As for the hash function design you have to admit that if all the
results from recursive modulus are strung together it is an output of
a long string of bits for an input of a small string of bits and that
is the attraction.
 The problem I have currently is I have several choices of sources of
large data from small data to choose from so I am still deciding which
is more dependable.  No Worry I am not asking for help here.  The
recursive modulus just added more complexity to the deliberations is
all.

 I simply was excited and sought out the friends to chat it up.  If we
can stop the war it will be nicer for all of us.  Compressing random
data is fringe yes but, for me it is a gateway to discovery.

  I hope this helps clear the air.. I really am doing good works and I
am not spamming the NG with irrational boasts.  This was nit-picking a
fight and insults and it took all of us to make it happen.

 I care about working on Million Digit Challenge and there may be no
solution but it is still fun to discover what I can.  Turn over the
proverbial rocks and see what may have been missed if anything and
simply enjoy the C language and my new 8-core!  I realized that I use
C as my math and that my proofs are programs.  That is one reason
there is a disconnect between some of you and I.  Some of you think
math first code second.

 But as what John Lennon Sang http://www.youtube.com/watch?v=7qwq76p93U8

"Party on Gath"

Be well

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

#985

On Feb 6, 12:17 pm, Ernst <Ernst_B...@sbcglobal.net> wrote:
> What may have been over looked is that Sebastian inserted the idea
> that I was trying to compress using factoring. I never wrote that I am
> trying to compress by factoring because I am not.

Then why are you posting about factoring in comp.compression?
Shouldn't you be posting in a math or cryptography group instead?

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

#986

On Feb 6, 2:05 pm, Jim Leonard <mobyga...@gmail.com> wrote:
> On Feb 6, 12:17 pm, Ernst <Ernst_B...@sbcglobal.net> wrote:
>
> > What may have been over looked is that Sebastian inserted the idea
> > that I was trying to compress using factoring. I never wrote that I am
> > trying to compress by factoring because I am not.
>
> Then why are you posting about factoring in comp.compression?
> Shouldn't you be posting in a math or cryptography group instead?

Because it is related to encoding and data compression is encoding.
 Stop and think I was designing a hash code not factoring when I saw
the factors in the stream of output.

 Perhaps there is no crime here at all.

 This is a good a way to say it and as good of a place.  Jim has asked
the best questions of all of you so far and I thank Jim.

 To Jim and all.

 It is possible that there are only three factors of million digit
"number" as imported from the file into GMP.
 My import settings I can disclose so we are all on the same page.
 A friend has said he independently confirmed the third factor. He is
not using my software so I value his opinion but it's open to
verification of both the number and the software I am using to do it.

 It is possible we have been trying to compress a large prime number
times 2^2
 What will be needed is to determine if the third factor is prime or
composite. Recursive Modulus has shown it will emit both.

 What needs to happen here is I must replace the cpu in the quad core
and it is now a speciality part.  Once I have that machine back in
service then it can be dedicated to searching for factors.
 Also there is a test in GMP that I was running when the old CPU let
me know it had heat issues.

 I posted on Marks site that I am open to working with others to
further factor that third factor and if we use recursive modulus then
anyone helping can work blocks of numbers and together we can shorten
the search time.
 I can dedicate 4 cores to the process so I can run 4 blocks at a
time.
 Some additional programming is needed on the software to make it a
utility so that too is open to share.
 Perhaps it is as simple as starting the search with M=1 and M++
instead of M = N-1 and M-- to find further factors using recursive
modulus. I admit I am chomping at the bit to write that version and
run it when I get access to the drives back

 So here is an olive branch.  I am a common man and this finding
factors of this new number is of unknown importance but I open it to
the Friends here if you want.

  On the inside track here a friend and I are looking at ways to
predict if there will be a factor other than 1 early in sequence.
That would be helpful.  That too is open to discussion.

 I trust that knowing what exactly we have here in the third factor
can help us understand the nature of things.  It would be helpful for
my reasoning to know have a prime or not since I assumed that it
wasn't.  Even thought and expected a flood of small factors to stream
out but the whole event took a couple of seconds and there were
three.

 So Jim, I think all tools are useful and if we exchange compress for
the word encode then what I am doing isn't such sin I think.  Also Jim
if I remember right these guys will tell you data modelling is part of
data compression.  Maybe it won't hurt to see what kind of number the
third one is even though this will be a factoring effort on the side
as we all work other things.

 I trust my thoughts are kind and my words soft.  I would like to be
this way if I can in this forum.

Ernst

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

#997

On 07.02.2012 01:51, Ernst wrote:

> Because it is related to encoding and data compression is encoding.
>   Stop and think I was designing a hash code not factoring when I saw
> the factors in the stream of output.

XML is also encoding. Thus, should I post XML related questions here?

>   It is possible that there are only three factors of million digit
> "number" as imported from the file into GMP.

Are you aware that the probabilities are against you? The probability 
that a random number between 0 and x is prime is approximately 1/log(x), 
which means that the probability that a number of a million digits is 
approximately prime is approximately (up to an unimportant factor of 
about three, no need to be picky about this) one million to one against 
you. If you have found three factors already, you can apply the same 
argument again to the third factor just to get an idea on your chances.

>   It is possible we have been trying to compress a large prime number
> times 2^2
>   What will be needed is to determine if the third factor is prime or
> composite. Recursive Modulus has shown it will emit both.

Likely not because it is not a very powerful method. Again, why don't 
you do your homework and read about what I have suggested. "Factoring by 
the rho method" is much more powerful, but likely neither the top-notch 
method as I'm not an expert in the field. Have you made an estimate how 
long this may take?

>   What needs to happen here is I must replace the cpu in the quad core
> and it is now a speciality part.

No, not at all. This will probably improve computation time by a factor 
of two to four, a rather unimportant factor if the method you picked is 
unsuitable. Honestly, whether I have to wait ten or twenty years for a 
result I do not bother much. I wouldn't accept either time.


>   I trust that knowing what exactly we have here in the third factor
> can help us understand the nature of things.

About what, precisely? Prime-probabilities are actually known:

http://primes.utm.edu/howmany.shtml

and this is just the outcome of a five minute research, to give you some 
ideas. What exactly do you want to learn from a single number?

Analyzing the methods would be beneficial, but as already stated, why 
don't you do some minimal research and improve your methods, or at least 
try to bring you up to date?

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

#1013

Ernst wrote:
> What may have been over looked is that Sebastian inserted the idea
> that I was trying to compress using factoring. I never wrote that I am
> trying to compress by factoring because I am not.

Are you using factoring as a preprocessing step in a compression
scheme or are you simply posting off topic factoring threads in the
compressions newsgroup. From your words you claimed factoring was
attractive because is gave a longer string of bits (see below). You
never clearly stated what would happen next even when asked. So I ask
now. Does this factoring have anything to do with you compression
idea?
>
>  As for the hash function design you have to admit that if all the
> results from recursive modulus are strung together it is an output of
> a long string of bits for an input of a small string of bits and that
> is the attraction.


>  The recursive modulus just added more complexity to the
> deliberations is all.

Those deliberations happened over a hundred years ago.

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

#1046

On Feb 8, 10:14 am, stan <smo...@exis.net> wrote:
> Ernst wrote:
> > What may have been over looked is that Sebastian inserted the idea
> > that I was trying to compress using factoring. I never wrote that I am
> > trying to compress by factoring because I am not.
>
> Are you using factoring as a preprocessing step in a compression
> scheme or are you simply posting off topic factoring threads in the
> compressions newsgroup. From your words you claimed factoring was
> attractive because is gave a longer string of bits (see below). You
> never clearly stated what would happen next even when asked. So I ask
> now. Does this factoring have anything to do with you compression
> idea?
>
>
>
> >  As for the hash function design you have to admit that if all the
> > results from recursive modulus are strung together it is an output of
> > a long string of bits for an input of a small string of bits and that
> > is the attraction.
> >  The recursive modulus just added more complexity to the
> > deliberations is all.
>
> Those deliberations happened over a hundred years ago.

I am simply interacting for social gratification.

 If you don't like it go suck an egg.


Later.

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

#1048

Ernst wrote:
> On Feb 8, 10:14 am, stan <smo...@exis.net> wrote:
>>
>> Are you using factoring as a preprocessing step in a compression
>> scheme or are you simply posting off topic factoring threads in the
>> compressions newsgroup. From your words you claimed factoring was
>> attractive because is gave a longer string of bits (see below). You
>> never clearly stated what would happen next even when asked. So I ask
>> now. Does this factoring have anything to do with you compression
>> idea?

<snip>

> I am simply interacting for social gratification.

I see. I was having a hard time figuring out what your plan or goal
could be and I figured I was just missing it. So it's good to see you
don't actually have a plan or goal; I wasn't "missing" anything.

I do applaud your direct honesty in admitting your purpose is
trolling. It really is a time saver. 

>  If you don't like it go suck an egg.

I'll go out on a limb with a prediction. Your lack of understanding of
what usenet is and is not will lead to your continued frustration and
will further erode both your manners and behavior.

I further predict that your barking orders at people will never lead
to any measureable result.

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

#1049

On Feb 10, 6:31 pm, stan <smo...@exis.net> wrote:
> Ernst wrote:
> > On Feb 8, 10:14 am, stan <smo...@exis.net> wrote:
>
> >> Are you using factoring as a preprocessing step in a compression
> >> scheme or are you simply posting off topic factoring threads in the
> >> compressions newsgroup. From your words you claimed factoring was
> >> attractive because is gave a longer string of bits (see below). You
> >> never clearly stated what would happen next even when asked. So I ask
> >> now. Does this factoring have anything to do with you compression
> >> idea?
>
> <snip>
>
> > I am simply interacting for social gratification.
>
> I see. I was having a hard time figuring out what your plan or goal
> could be and I figured I was just missing it. So it's good to see you
> don't actually have a plan or goal; I wasn't "missing" anything.
>
> I do applaud your direct honesty in admitting your purpose is
> trolling. It really is a time saver.
>
> >  If you don't like it go suck an egg.
>
> I'll go out on a limb with a prediction. Your lack of understanding of
> what usenet is and is not will lead to your continued frustration and
> will further erode both your manners and behavior.
>
> I further predict that your barking orders at people will never lead
> to any measureable result.

Fuck that.


 Pi has to repeat!~

 Think about this: Given probability and domain sampling of say 64 bit
lengths but that is arbitrary,

 Just how many times a 64bit pattern can be expressed is bounded.

Pi repeats!


Just thinking that is.

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

#1050

On Fri, 10 Feb 2012 23:29:59 -0800 (PST), Ernst
<Ernst_Berg@sbcglobal.net> wrote:

>On Feb 10, 6:31 pm, stan <smo...@exis.net> wrote:
>> Ernst wrote:
>> > On Feb 8, 10:14 am, stan <smo...@exis.net> wrote:
>>
>> >> Are you using factoring as a preprocessing step in a compression
>> >> scheme or are you simply posting off topic factoring threads in the
>> >> compressions newsgroup. From your words you claimed factoring was
>> >> attractive because is gave a longer string of bits (see below). You
>> >> never clearly stated what would happen next even when asked. So I ask
>> >> now. Does this factoring have anything to do with you compression
>> >> idea?
>>
>> <snip>
>>
>> > I am simply interacting for social gratification.
>>
>> I see. I was having a hard time figuring out what your plan or goal
>> could be and I figured I was just missing it. So it's good to see you
>> don't actually have a plan or goal; I wasn't "missing" anything.
>>
>> I do applaud your direct honesty in admitting your purpose is
>> trolling. It really is a time saver.
>>
>> >  If you don't like it go suck an egg.
>>
>> I'll go out on a limb with a prediction. Your lack of understanding of
>> what usenet is and is not will lead to your continued frustration and
>> will further erode both your manners and behavior.
>>
>> I further predict that your barking orders at people will never lead
>> to any measureable result.
>
>Fuck that.
>
>
> Pi has to repeat!~
>
> Think about this: Given probability and domain sampling of say 64 bit
>lengths but that is arbitrary,
>
> Just how many times a 64bit pattern can be expressed is bounded.
>
>Pi repeats!
>
>
>Just thinking that is.


Sure, Pi repeats any given digit an infinite number of times.  And the
selection of digits is obviously dependent on the based used to
represent Pi.  In decimal, the first thousand digits of Pi contain:

0 - 93 times
1 - 116
2 - 103
3 - 102
4 - 93
5 - 97
6 - 94
7 - 95
8 - 101
9 - 106

In base 2**64, you'd need (a lot) more digits to see the repeats, but
they'll still be there.

But just like in decimal, this isn't a repetition in the pattern,
which is what's important.  For example, the rational fraction 1/7 is:

.142857142857142857142857142857...

with the same six digit pattern repeating forever.  There is *no* such
repetition in Pi.

It's expected that Pi ultimately contains all shorter sequences, in
whatever base you're computing it in, although I don't think that's
been proven.  For example, at about 36,356,643 digits in, you'll find
the pattern 99999999, and then at 66,780,106, and so on.  Eight
consecutive zero can be found 172,330,851 an then at 184,688,989, and
so on.

The (very) old idea that you could compress data by simply pointing to
the string in Pi is flawed because the pointer must, on average, be at
least as long as the string, and worse, since Pi is not very regular,
the distance into Pi needed to find the average string is rather
higher than an optimally constructed string, so the pointer needs to
longer than the string to be compressed.

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

#1054

On Feb 10, 11:53 pm, Robert Wessel <robertwess...@yahoo.com> wrote:
> On Fri, 10 Feb 2012 23:29:59 -0800 (PST), Ernst
>
>
>
> <Ernst_B...@sbcglobal.net> wrote:
> >On Feb 10, 6:31 pm, stan <smo...@exis.net> wrote:
> >> Ernst wrote:
> >> > On Feb 8, 10:14 am, stan <smo...@exis.net> wrote:
>
> >> >> Are you using factoring as a preprocessing step in a compression
> >> >> scheme or are you simply posting off topic factoring threads in the
> >> >> compressions newsgroup. From your words you claimed factoring was
> >> >> attractive because is gave a longer string of bits (see below). You
> >> >> never clearly stated what would happen next even when asked. So I ask
> >> >> now. Does this factoring have anything to do with you compression
> >> >> idea?
>
> >> <snip>
>
> >> > I am simply interacting for social gratification.
>
> >> I see. I was having a hard time figuring out what your plan or goal
> >> could be and I figured I was just missing it. So it's good to see you
> >> don't actually have a plan or goal; I wasn't "missing" anything.
>
> >> I do applaud your direct honesty in admitting your purpose is
> >> trolling. It really is a time saver.
>
> >> >  If you don't like it go suck an egg.
>
> >> I'll go out on a limb with a prediction. Your lack of understanding of
> >> what usenet is and is not will lead to your continued frustration and
> >> will further erode both your manners and behavior.
>
> >> I further predict that your barking orders at people will never lead
> >> to any measureable result.
>
> >Fuck that.
>
> > Pi has to repeat!~
>
> > Think about this: Given probability and domain sampling of say 64 bit
> >lengths but that is arbitrary,
>
> > Just how many times a 64bit pattern can be expressed is bounded.
>
> >Pi repeats!
>
> >Just thinking that is.
>
> Sure, Pi repeats any given digit an infinite number of times.  And the
> selection of digits is obviously dependent on the based used to
> represent Pi.  In decimal, the first thousand digits of Pi contain:
>
> 0 - 93 times
> 1 - 116
> 2 - 103
> 3 - 102
> 4 - 93
> 5 - 97
> 6 - 94
> 7 - 95
> 8 - 101
> 9 - 106
>
> In base 2**64, you'd need (a lot) more digits to see the repeats, but
> they'll still be there.
>
> But just like in decimal, this isn't a repetition in the pattern,
> which is what's important.  For example, the rational fraction 1/7 is:
>
> .142857142857142857142857142857...
>
> with the same six digit pattern repeating forever.  There is *no* such
> repetition in Pi.
>
> It's expected that Pi ultimately contains all shorter sequences, in
> whatever base you're computing it in, although I don't think that's
> been proven.  For example, at about 36,356,643 digits in, you'll find
> the pattern 99999999, and then at 66,780,106, and so on.  Eight
> consecutive zero can be found 172,330,851 an then at 184,688,989, and
> so on.
>
> The (very) old idea that you could compress data by simply pointing to
> the string in Pi is flawed because the pointer must, on average, be at
> least as long as the string, and worse, since Pi is not very regular,
> the distance into Pi needed to find the average string is rather
> higher than an optimally constructed string, so the pointer needs to
> longer than the string to be compressed.

 Well, what I have read over the years is echoed here.

 I will use the transcendental number just as it is, in a practical
way.
 No magic compression functions from Pi my friends.
 I hope saying that will stop the howling dogs of comp.compression
from circling.

 You and the guys are always so knowledgeable. It's worth taking on
all fighters here in this Gladiator school of data compression to have
a chat.

Ernst

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

#1058

Ernst wrote:
<snip>

>  No magic compression functions from Pi my friends.

That actually goes without saying, it's pretty fundamental stuff.

>  I hope saying that will stop the howling dogs of comp.compression
> from circling.
>
>  You and the guys are always so knowledgeable. It's worth taking on
> all fighters here in this Gladiator school of data compression to have
> a chat.

Again, you really misunderstand usenet; this isn't a chat room. 

1. The topic is compression.
2. Your ideas will be judged on their merits.
3. Your behavior will dictate how others respond.

Those aren't my ideas by the way.

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

#1061

On Feb 11, 9:46 am, stan <smo...@exis.net> wrote:
> Ernst wrote:
>
> <snip>
>
> >  No magic compression functions from Pi my friends.
>
> That actually goes without saying, it's pretty fundamental stuff.
>
> >  I hope saying that will stop the howling dogs of comp.compression
> > from circling.
>
> >  You and the guys are always so knowledgeable. It's worth taking on
> > all fighters here in this Gladiator school of data compression to have
> > a chat.
>
> Again, you really misunderstand usenet; this isn't a chat room.
>
> 1. The topic is compression.
> 2. Your ideas will be judged on their merits.
> 3. Your behavior will dictate how others respond.
>
> Those aren't my ideas by the way.

Then explain yourself.


-------------------------------------------

For the rest of you all.

 tinyPi.c seems to work.

Here is the output :

141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349999998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001927876611195909216420198938

Here is the code.  I wasn't worried about the stdio thing I believe
main(j) was about.  I admit I have not thought that way.

So for my contribution to the discussion on Pi. From my level of
understanding. In a way that I am able. I a tone that is appropriate.
Here is tinyPi by Gjerrit Meinsma.

From g.meinsma@math.utwente.nl Mon Dec 11 00:32:03 2000
Date: Tue, 08 Aug 2000 14:28:37 -0100
From: gjerrit meinsma <g.meinsma@math.utwente.nl>
To: jasonp@isr.umd.edu
Subject: pishort.c

I've read your pi-pages and it seems
you have been busy with getting tiny code
for pi. That's interesting.

Perhaps you have comments on my little C-program.
It takes 141 characters, so not as much as the
"standard" calculate-pi.c program. Of course
it is not as tiny as the assembler code on your page.

It calculates 1000 decimals of pi (could easily do more)
in about two seconds:

  long k=4e3,p,a[337],q,t=1e3;
  main(j){for(;a[j=q=0]+=2,--k;)
  for(p=1+2*k;j<337;q=a[j]*k+q%p*t,a[j++]=q/p)
  k!=j>2?:printf("%.3d",a[j-2]%t+q/p/t);}


Groeten,
Gjerrit Meinsma.

-------------------------------------------------------------

Here is how I modified it to run under GCC C

#include <stdio.h>
#include <stdlib.h>

main()
{
 unsigned long long int j = 2000;
 long k=4e3,p,a[337],q,t=1e3;
 // main(j){
  { for(;a[j=q=0]+=2,--k;)
  for(p=1+2*k;j<337;q=a[j]*k+q%p*t,a[j++]=q/p)
  k!=j>2?:printf("%.3d",a[j-2]%t+q/p/t);}
}

/* tinyPi by gjerrit meinsma <g.meinsma@math.utwente.nl>
 *  long k=4e3,p,a[337],q,t=1e3;
 *    main(j){for(;a[j=q=0]+=2,--k;)
 *      for(p=1+2*k;j<337;q=a[j]*k+q%p*t,a[j++]=q/p)
 *        k!=j>2?:printf("%.3d",a[j-2]%t+q/p/t);}
 */
~

Lets see now if the output matches another list for Pi.
141592653589793238462643383279502884197169399375105820974944592307816406286
208998628034825342117067982148086513282306647093844609550582231725359408128481
117450284102701938521105559644622948954930381964428810975665933446128475648233
786783165271201909145648566923460348610454326648213393607260249141273724587006
606315588174881520920962829254091715364367892590360011330530548820466521384146
951941511609433057270365759591953092186117381932611793105118548074462379962749
567351885752724891227938183011949129833673362440656643086021394946395224737190
702179860943702770539217176293176752384674818467669405132

 My old eyes think it does.

 Any comments on tinyPi.c?

 I think Gjerrit Meinsma is brilliant.  I thought the recursive
modulus loop was tight but that is wonderfully tight code.

 On the lingering topic of I am not worthy.. Get lost.

On the utility of discussing Pi at this time for me, priceless.

Thanks for this wonderful topic and may all who read this enjoy
Gjerrit Meinsma's tinyPi.c

Ernst

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

#1063

On Feb 11, 10:21 am, Ernst <Ernst_B...@sbcglobal.net> wrote:


 Hey friends..

  I am looking at tinyPi.c and it seems to scale some but it doesn't
match up with a list off the internet of 100,000 digits of Pi  for
runs longer than a couple thousand digits.
 It could be my miss-understanding on how to scale that.

 I may not be seeing the right way to scale that so I am open to
suggestions on tinyPi.c or other link.

Oh well it sure works for a few thousand digits that is true.
If anyone is able to scale that towards infinity I can stand some
advice.

Forget the j = 2000;  I was simply initializing it for no good
reason.


Alrighty then..

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

#1067

Ernst wrote:
> On Feb 11, 10:21 am, Ernst <Ernst_B...@sbcglobal.net> wrote:

> Oh well it sure works for a few thousand digits that is true.
> If anyone is able to scale that towards infinity I can stand some
> advice.

I would try a math group or even a math faq for current ideas on how
to generate digits of pi. I didn't verify but I seem to remember
something in Numerical Recipes (a book).

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

#1068

On Sat, 11 Feb 2012 11:15:25 -0800 (PST), Ernst
<Ernst_Berg@sbcglobal.net> wrote:

>On Feb 11, 10:21 am, Ernst <Ernst_B...@sbcglobal.net> wrote:
>
>
> Hey friends..
>
>  I am looking at tinyPi.c and it seems to scale some but it doesn't
>match up with a list off the internet of 100,000 digits of Pi  for
>runs longer than a couple thousand digits.
> It could be my miss-understanding on how to scale that.
>
> I may not be seeing the right way to scale that so I am open to
>suggestions on tinyPi.c or other link.
>
>Oh well it sure works for a few thousand digits that is true.
>If anyone is able to scale that towards infinity I can stand some
>advice.
>
>Forget the j = 2000;  I was simply initializing it for no good
>reason.


If you want to compute many digits of Pi, some variant of Gauss'
arithmetic-geometric mean function (AGM) is the preferred approach:


// Gauss' AGM to compute Pi
#include <stdlib.h>
#include <math.h>

int main()
{
    int i;
    double a, b, c, s, t, pi;

    a = 1;
    b = 1/sqrt(2.0);
    s = .5;

    for (i=1; i<10; i++)
        {
        t = a;
        a = (a+b)/2;
        b = sqrt(t*b);
        c = (a-t)*(a-t);
        s = s-(c*pow(2,i));

        // following two lines only needed after last iteration
        pi = (a+b)*(a+b)/(2*s);
        printf("iteration %i, pi=%.16f\n", i, pi);
        }

   return 0;
}


Obviously the actual operations need to be done with a bignum library
(excise left to the reader), but this is very, very fast as these
things go.  The number of accurate digits of Pi basically double each
iteration through the loop, and 40 iterations will get you over a 1.3
trillion digits.  The code above using a double hits the limits of a
double after three iterations.

The Schönhage variant is slightly faster, and uses less storage, but
is a little more complex to understand in terms of the
arithmetic-geometric mean function


// Schönhage variant of Gauss' AGM to compute Pi
#include <stdlib.h>
#include <math.h>

int main()
{
    int i;
    double a, b, A, B, s, t, pi;

    a = 1;
    A = 1;
    B = .5;
    s = .5;

    for (i=1; i<10; i++)
        {
        t = (A+B)/4;
        b = sqrt(B);
        a = (a+b)/2;
        A = a*a;
        B = (A-t)*2;
        s = s+((B-A)*pow(2,i));

        // following two lines only needed after last iteration
        pi = (A+B)/s;
        printf("iteration %i, pi=%.16f\n", i, pi);
        }

   return 0;
}

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

#1071

On Feb 11, 2:01 pm, Robert Wessel <robertwess...@yahoo.com> wrote:
> On Sat, 11 Feb 2012 11:15:25 -0800 (PST), Ernst
>
>
>
> <Ernst_B...@sbcglobal.net> wrote:
> >On Feb 11, 10:21 am, Ernst <Ernst_B...@sbcglobal.net> wrote:
>
> > Hey friends..
>
> >  I am looking at tinyPi.c and it seems to scale some but it doesn't
> >match up with a list off the internet of 100,000 digits of Pi  for
> >runs longer than a couple thousand digits.
> > It could be my miss-understanding on how to scale that.
>
> > I may not be seeing the right way to scale that so I am open to
> >suggestions on tinyPi.c or other link.
>
> >Oh well it sure works for a few thousand digits that is true.
> >If anyone is able to scale that towards infinity I can stand some
> >advice.
>
> >Forget the j = 2000;  I was simply initializing it for no good
> >reason.
>
> If you want to compute many digits of Pi, some variant of Gauss'
> arithmetic-geometric mean function (AGM) is the preferred approach:
>
> // Gauss' AGM to compute Pi
> #include <stdlib.h>
> #include <math.h>
>
> int main()
> {
>     int i;
>     double a, b, c, s, t, pi;
>
>     a = 1;
>     b = 1/sqrt(2.0);
>     s = .5;
>
>     for (i=1; i<10; i++)
>         {
>         t = a;
>         a = (a+b)/2;
>         b = sqrt(t*b);
>         c = (a-t)*(a-t);
>         s = s-(c*pow(2,i));
>
>         // following two lines only needed after last iteration
>         pi = (a+b)*(a+b)/(2*s);
>         printf("iteration %i, pi=%.16f\n", i, pi);
>         }
>
>    return 0;
>
> }
>
> Obviously the actual operations need to be done with a bignum library
> (excise left to the reader), but this is very, very fast as these
> things go.  The number of accurate digits of Pi basically double each
> iteration through the loop, and 40 iterations will get you over a 1.3
> trillion digits.  The code above using a double hits the limits of a
> double after three iterations.
>
> The Schönhage variant is slightly faster, and uses less storage, but
> is a little more complex to understand in terms of the
> arithmetic-geometric mean function
>
> // Schönhage variant of Gauss' AGM to compute Pi
> #include <stdlib.h>
> #include <math.h>
>
> int main()
> {
>     int i;
>     double a, b, A, B, s, t, pi;
>
>     a = 1;
>     A = 1;
>     B = .5;
>     s = .5;
>
>     for (i=1; i<10; i++)
>         {
>         t = (A+B)/4;
>         b = sqrt(B);
>         a = (a+b)/2;
>         A = a*a;
>         B = (A-t)*2;
>         s = s+((B-A)*pow(2,i));
>
>         // following two lines only needed after last iteration
>         pi = (A+B)/s;
>         printf("iteration %i, pi=%.16f\n", i, pi);
>         }
>
>    return 0;
>
> }

Thanks Robert,

 I have tucked your example away for now.  I do wish to have proper
Transcendental numbers in time so knowing how to generate Pi,e and
more I read is important; however, what I am more interested in is a
large array of data to use a data set. tinyPi is small,fast and at
this point adapted to generate a data set.

 tinyPi seems to fail at some distance but it dose generate  enough
data and I can do the development of this program with it even if it
isn't truly Pi.  It's not critical.

 Again Thank You.  These are simple topics for some but I have never
looked into generating such data in earnest before.

 I am not saying I will compress anything but I have an idea that may
do such a thing.  I do not know until I get further along with the
program writing.
 So in case anyone is worried this is for a data compression effort.
 First comes the data encoding then we shall see what kind of encoding
it is.

 A wise person here told me a long time ago that data compression is
just a class of data encoding where the encoded is smaller than the
source.
 So we all must open our eyes to all types of data encoding and some
of it cannot be called compression and it is not a sin.

 Ernst

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

#1066

Ernst wrote:
>> Again, you really misunderstand usenet; this isn't a chat room.
>>
>> 1. The topic is compression.
>> 2. Your ideas will be judged on their merits.
>> 3. Your behavior will dictate how others respond.
>>
>> Those aren't my ideas by the way.
>
> Then explain yourself.

What's confusing you?

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.compression

csiph-web