So if we say a zipped program we want to send is a stream of numbers but one large number, how can we compress it if it is already compressed? So then add 3 zeros to its length as a large number using power of 10 so as an example 1,000 it has to have a 1 and all zeros, 10 to the power of 40 million as an example, now divide the large number into that and use exponential notation every time you make your large number or refer to it. As you create your formula that will recreate that large number as its result or answer.

So this is a fun math project for math hungry people.

Hint? Adjust the number as part of the formula so that it falls into an algorithmic pattern that can use exponential notation. All theory at this point.
Have fun and spread this puzzle to your friends.

I inwented it, I am the Rickest Rick of all the Ricks if anyone wants to know who inwented it.

To do this math you need to write a program that multiplies and divides in columns like a normal human does with a pencil.
Or get calculator guy to do it in his head I suppose.

I am not going to name the conjecture because you will then be able to conjecture all over the place yourselves.
Given there are so many ways to approach this problem.

For instance your approach might be to tackle the first 1000 digits if it is 128 bit then that's 3 numbers in that data stream if the number is 121 for instance. So you have to piece together that number using files at first and do long math at first using the computer.

And you might say well this is a large number so I want to remove as many primary digits in that line as possible first.
Or you might say well if I chop that string of digits into 3 sections and approach each individually I am dealing with smaller numbers.

Or if I search the string for close comparisons using a known repetitive algorithm then that plus the remainder and I have shrunk that file.
Lots of ways to approach it.
As many ways perhaps as there are to approach the Riemann hypothesis.

To create a formula whose result is x, a long string of digits in a computer program file that is normally a zipped file rar etc.
Lay out the data in a stream that is a large number. Create a formula that results in that number.
Using algebra.

On Friday, July 2, 2021 at 12:55:20 PM UTC-7, Kcir wrote:
> I am not going to name the conjecture because you will then be able to conjecture all over the place yourselves.
> Given there are so many ways to approach this problem.

You might Google

Matthew Roberts random compression

and carefully study the work he has done on compressing things that already appear to be compressed

On Friday, July 2, 2021 at 1:07:45 PM UTC-7, bwr fml wrote:
> On Friday, July 2, 2021 at 12:55:20 PM UTC-7, Kcir wrote:
> > I am not going to name the conjecture because you will then be able to conjecture all over the place yourselves.
> > Given there are so many ways to approach this problem.
> You might Google
>
> Matthew Roberts random compression
>
> and carefully study the work he has done on compressing things that already appear to be compressed

HEYYY he just time traveled and stole my shit.

I demand a recount.

Actually he has not got the same idea at all.

We are talking about merely taking a 40 million digit number called x.

(a*b) +(c/d) +432 = x

Like that.
Or using notation that you yourself write in a program to say the square root of x plus some repetitive number like (10/3) power of 40million.

So you lay out the digits in any file to make one long number.

So then is it even? You divide by 2.

Is it still even? no? you subtract 1

So then is it even? You divide by 2.

Is it still even? no? you subtract 1
....

For the win.
You just write down when you remove a digit for your formula looks like this.

div 2 , div 2, minus 1, div 2, div 2, minus 1 , div 2.
Can it div 4 can it div 5 equally?

So in your code you could say div 2, 8 times minus 1 div 2, 47 times, minus 1

Or similar

You see how your notation how many times to div 2 will result in a much smaller formula than the long number.
Any large number zipped or otherwise. But who knows if there is a benefit to using unzipped files compared to zipped files.

My guess is the zipped file would be an easier number to work with and in the case of a very large file then you could even cut the file into 3 so that you are not using too much RAM memory.

So since if you wrote div 2 every time in the file it would of course bulk it up so you want to consider how you code the div and the minus 1 in order to find it when you decompress your file so the program knows how to recreate the original number.

So you code if you use 5 is more like this

If the last 2 digits are not divisible equally by 5, then minus the amount that will make it divisible by 5.

Example div 5, minus 2, div 5, div 5, div 5 minus 3

Then you zip that file up and call it Miller time.

Suppose you randomly choose some 128 digit number,
perform your method on that, find the resulting size of that,
and repeat this with 999 other 128 digit numbers

Then do a really nice histogram showing the sizes that you ended up with.

If you used really really high quality random numbers then that might give
you more insight into the expected behavior than anything else. Yes, that
would probably miss some cases with fantastic compression and miss
some cases with horrible compression, but it should quickly give you an
idea of roughly what to expect and everyone could see that at a glance.

I'm biased, I'd really really like to see Robert's methods used on whatever
size data he would like and see how that graphs with a thousand cases.

A much simpler method.

Huge number div 5
Huge number minus 4 div 5
Huge number div 5
Huge number div 5
Huge number div 5
Huge number minus 2
Huge number div 5
Huge number minus 4
Huge number div 5

So how many statements are there there? So then how different are those statements?
So now we compress that by assigning those possible statements in that set a symbol.

So a,b,c,d,e,f,

a2,b1,c5,a3,

2 repetitions of a, one of b, 5 of c, 3 again of a

reducing the large number no matter if it is random.
This takes an extraordinary amount of processor time perhaps but if you write your own program to do the math in columns it wouldn't take long with a modern pc.
It is just theory and quantum computers are coming so things will get faster soon enough.

On Friday, July 2, 2021 at 2:52:28 PM UTC-7, Kcir wrote:
> A much simpler method.
>
>
> Huge number div 5
> Huge number minus 4 div 5
> Huge number div 5
> Huge number div 5
> Huge number div 5
> Huge number minus 2
> Huge number div 5
> Huge number minus 4
> Huge number div 5
>
> So how many statements are there there? So then how different are those statements?
> So now we compress that by assigning those possible statements in that set a symbol.
>
> So a,b,c,d,e,f,
>
> a2,b1,c5,a3,
>
> 2 repetitions of a, one of b, 5 of c, 3 again of a
>
> reducing the large number no matter if it is random.

So then we put that into a file and then we start over since that is again a large number.
So what am I doing?
Using a backwards chaining inference engine to reverse engineer a chain reaction.

On Friday, July 2, 2021 at 12:14:48 PM UTC-7, Kcir wrote:
> So if we say a zipped program we want to send is a stream of numbers but one large number, how can we compress it if it is already compressed? So then add 3 zeros to its length as a large number using power of 10 so as an example 1,000 it has to have a 1 and all zeros, 10 to the power of 40 million as an example, now divide the large number into that and use exponential notation every time you make your large number or refer to it. As you create your formula that will recreate that large number as its result or answer..
>
> So this is a fun math project for math hungry people.
>
> Hint? Adjust the number as part of the formula so that it falls into an algorithmic pattern that can use exponential notation. All theory at this point.
> Have fun and spread this puzzle to your friends.
>
> I inwented it, I am the Rickest Rick of all the Ricks if anyone wants to know who inwented it.

How do you know it is real?
Who told you?

Mitchell Raemsch

This first since I just made history.

Rick1234567S
6 minutes ago (edited)
For your consideration...
So we consider a zip or RAR file as a large number. If it is 128 bit then the number 121 takes up 3 digits.
So then we apply our formula which is to divide that large number by 5.
And when it is not divisible by 5 we remove the amount needed so that it is.
And we write those instructions using computer code.

Huge number div 5
Huge number minus 4 div 5
Huge number div 5
Huge number div 5
Huge number div 5
Huge number minus 2
Huge number div 5
Huge number minus 4
Huge number div 5

So how many statements are there there? So then how different are those statements?
So now we compress that by assigning those possible statements in that set a symbol.

So a,b,c,d,e,f,

a2,b1,c5,a3,

2 repetitions of a, one of b, 5 of c, 3 again of a

reducing the large number no matter if it is random.

So then we put that into a file and then we start over since that is again a large number.
So what am I doing?
Using a backwards chaining inference engine to reverse engineer a chain reaction.

I will call this reverse chain reaction compression or rcRC

How do I know that anything is real?

If it consistently measures the same it is real.

Look at a wooden table, look again, you have measured it with your mind, your eyes, the color etc.
Does that mean it is real? You need to measure some more with a ruler if you don't think it is real.
Come back tomorrow measure it again.

Now we make assumptions that when we see copper that it is copper just by looking at it. But if we want to be sure we need to get it tested.

So anything that consistently measures the same way or the same amount within reason and we can attribute the changes to things we can make the claim it is real.

So anything that is within the laws of physics and can be consistently measured.

Lights in the sky are real, they are real lights in the sky.

On Friday, July 2, 2021 at 3:20:33 PM UTC-7, Kcir wrote:

> So we consider a zip or RAR file as a large number. If it is 128 bit then the number 121 takes up 3 digits.
> So then we apply our formula which is to divide that large number by 5.
> And when it is not divisible by 5 we remove the amount needed so that it is.
> And we write those instructions using computer code.
> Huge number div 5
> Huge number minus 4 div 5
> Huge number div 5
> Huge number div 5
> Huge number div 5
> Huge number minus 2
> Huge number div 5
> Huge number minus 4
> Huge number div 5
>
> So how many statements are there there? So then how different are those statements?
> So now we compress that by assigning those possible statements in that set a symbol.
>
> So a,b,c,d,e,f,
>
> a2,b1,c5,a3,
>
> 2 repetitions of a, one of b, 5 of c, 3 again of a
>
>
> reducing the large number no matter if it is random.
>
> So then we put that into a file and then we start over since that is again a large number.

So there are 2 ways to divide 5 using 10, and always removing the number to make it divide by 5 is only one step.

So when you write your formula you will Huge number div 5 more often than minus x.
So you can use short form notation by using symbols.
to reverse an imaginary chain reaction to arrive at your large number which in this case is a zip file on disk.
But it could be any file at all.

On Friday, July 2, 2021 at 3:50:16 PM UTC-7, Kcir wrote:
> On Friday, July 2, 2021 at 3:20:33 PM UTC-7, Kcir wrote:
>
> > So we consider a zip or RAR file as a large number. If it is 128 bit then the number 121 takes up 3 digits.
> > So then we apply our formula which is to divide that large number by 5.
> > And when it is not divisible by 5 we remove the amount needed so that it is.
> > And we write those instructions using computer code.
> > Huge number div 5
> > Huge number minus 4 div 5
> > Huge number div 5
> > Huge number div 5
> > Huge number div 5
> > Huge number minus 2
> > Huge number div 5
> > Huge number minus 4
> > Huge number div 5
> >
> > So how many statements are there there? So then how different are those statements?
> > So now we compress that by assigning those possible statements in that set a symbol.
> >
> > So a,b,c,d,e,f,
> >
> > a2,b1,c5,a3,
> >
> > 2 repetitions of a, one of b, 5 of c, 3 again of a
> >
> >
> > reducing the large number no matter if it is random.
> >
> > So then we put that into a file and then we start over since that is again a large number.
> So there are 2 ways to divide 5 using 10, and always removing the number to make it divide by 5 is only one step.
>
> So when you write your formula you will Huge number div 5 more often than minus x.
> So you can use short form notation by using symbols.
> to reverse an imaginary chain reaction to arrive at your large number which in this case is a zip file on disk.
> But it could be any file at all.

Going further any gains you make like repeating Huge Number div 5 which we will say is symbol a here,
will result in compression.
Given a number that ends in 9 like 456789
So if you instead of minus 4 you minus 9, so that the number ends in zero you are guaranteed to have 2 divisions of 5 follow it.
So then you can assume, that after you minus your number you will have two divisions of 5 so you needn't write that in that strip of instructions in your file. It is assumed that after every number you minus you will be making two operations of div 5.

Isn't this fun?
lol

On 7/2/2021 12:14 PM, Kcir wrote:
> So if we say a zipped program we want to send is a stream of numbers but one large number, how can we compress it if it is already compressed? So then add 3 zeros to its length as a large number using power of 10 so as an example 1,000 it has to have a 1 and all zeros, 10 to the power of 40 million as an example, now divide the large number into that and use exponential notation every time you make your large number or refer to it. As you create your formula that will recreate that large number as its result or answer.
>
> So this is a fun math project for math hungry people.
>
> Hint? Adjust the number as part of the formula so that it falls into an algorithmic pattern that can use exponential notation. All theory at this point.
> Have fun and spread this puzzle to your friends.
>
> I inwented it, I am the Rickest Rick of all the Ricks if anyone wants to know who inwented it.
>

Here is a little toy experimental program I made for fun that stores
data in complex numbers using a Julia set. It can generate some huge
numbers, but they are floating point.

http://fractallife247.com/test/rifc_cipher

For instance, the following complex number encodes my name:

real:

-0.70928383564905214400491843078452104082710295997209875060333681255435334699521962691343068404279561138607296289815362070140579962

imag:

0.75006448767684071252250159734912475298989657994192333528788266765351648099327204708007723341215421128937413101480606378377592858

;^)

This just for fun.

Can you compress that complex number?

large program file laid out as a large number =x

....

(((x-6)/ 5) /5) is represented as m6 m here would represent div by 5 and the number -6 comes next.

So what do we find?

We find that div 2 and minus 1 is going to cause div 2 to repeat more than div 5.

So our code to represent div 2 we will say is 'a'
When the code executes it will multiply by 2 otherwise it will add the number.

So the idea again is to build a chain reaction and so when we write out our file based on that large number it will look like this.

aaa5a8aaaaa9aaa2aa3a4a5aaaaa7

and if it is not an a we add that number as we parse that line and if it is an a we will multiply by 2.

So now from a random number we have a compressible file once again if it was a zip file.
We can also substitute C for 3 repetitions and insert a C in the data stream or just compress the a's as is.
That resulting zip file once again is a large number and so repeat the process.

-0.70928383564905214400491843078452104082710295997209875060333681255435334699521962691343068404279561138607296289815362070140579962

So then to compress that number well that is not a file so it starts with a decimal. And it is a negative number.

So we would need rules in our new program to identify the number to first turn it into a whole number.
Then lastly we would add the sign and the decimal place by writing an instruction that would appear as a symbol.

So firstly to write this program you want to write a method of doing the math.
And I am suggesting you do it as you do it by hand with a pencil.
So working from the left to the right through your file, you will need to div 2 every time you see an 'a'.
So you would want to have lots of RAM.

With this number it will easily and quickly write a small file each pass if you wanted.

Kcir's profile photo
Kcir
unread,
5:28 PM (now)
to
-0.70928383564905214400491843078452104082710295997209875060333681255435334699521962691343068404279561138607296289815362070140579962

So then to compress that number well that is not a file so it starts with a decimal. And it is a negative number.

So we would need rules in our new program to identify the number to first turn it into a whole number.
Then lastly we would add the sign and the decimal place by writing an instruction that would appear as a symbol.

So firstly to write this program you want to write a method of doing the math.
And I am suggesting you do it as you do it by hand with a pencil.
So working from the right to the left through your number.
When you decompress it and start your chain reaction to recreate the number you will need to multiply by 2 every time you see an 'a'.
So you would want to have lots of RAM.

With this number it will easily and quickly write a small file each pass if you wanted.
So here that number can go into a file, then do the math in columns, div 2 and minus the last digit by 1 if it is an odd number and not an even number.

So if we are only doing div 2 and minus 1 then
our code will look like

aaaaabaababaaaaabaaababababaaa

where b represents -1

For the win.

And I will write the program later and compress that for you using a chain reaction.

On 7/2/2021 5:28 PM, Kcir wrote:
> -0.70928383564905214400491843078452104082710295997209875060333681255435334699521962691343068404279561138607296289815362070140579962
>
> So then to compress that number well that is not a file so it starts with a decimal. And it is a negative number.
>
> So we would need rules in our new program to identify the number to first turn it into a whole number.
> Then lastly we would add the sign and the decimal place by writing an instruction that would appear as a symbol.
>
> So firstly to write this program you want to write a method of doing the math.
> And I am suggesting you do it as you do it by hand with a pencil.
> So working from the left to the right through your file, you will need to div 2 every time you see an 'a'.
> So you would want to have lots of RAM.
>
> With this number it will easily and quickly write a small file each pass if you wanted.
>
>

My main program can be found here for my experimental RIFC cipher toy thing:

http://fractallife247.com/test/rifc_cipher/ct_main.js

Any suggestions?

I also have it here in C++, however it does not use arbitrary precision:

https://github.com/ChrisMThomasson/fractal_cipher/blob/master/RIFC/cpp/ct_rifc_sample.cpp

Wrote about the basic element of it here, how to store data in complex
numbers:

https://groups.google.com/g/comp.lang.c++/c/bB1wA4wvoFc/m/GdzmMd41AQAJ

On 7/2/2021 5:31 PM, Kcir wrote:
> Kcir's profile photo
> Kcir
> unread,
> 5:28 PM (now)
> to
> -0.70928383564905214400491843078452104082710295997209875060333681255435334699521962691343068404279561138607296289815362070140579962
>
> So then to compress that number well that is not a file so it starts with a decimal. And it is a negative number.

Well, this number can be stored as a file, then we can create a number
using its hexbytes, or whatever encoding you desire.

>
> So we would need rules in our new program to identify the number to first turn it into a whole number.
> Then lastly we would add the sign and the decimal place by writing an instruction that would appear as a symbol.
>
> So firstly to write this program you want to write a method of doing the math.
> And I am suggesting you do it as you do it by hand with a pencil.
> So working from the right to the left through your number.
> When you decompress it and start your chain reaction to recreate the number you will need to multiply by 2 every time you see an 'a'.
> So you would want to have lots of RAM.
>
> With this number it will easily and quickly write a small file each pass if you wanted.
> So here that number can go into a file, then do the math in columns, div 2 and minus the last digit by 1 if it is an odd number and not an even number.
>

On 7/2/2021 12:14 PM, Kcir wrote:
> So if we say a zipped program we want to send is a stream of numbers but one large number, how can we compress it if it is already compressed? So then add 3 zeros to its length as a large number using power of 10 so as an example 1,000 it has to have a 1 and all zeros, 10 to the power of 40 million as an example, now divide the large number into that and use exponential notation every time you make your large number or refer to it. As you create your formula that will recreate that large number as its result or answer.
>
> So this is a fun math project for math hungry people.
>
> Hint? Adjust the number as part of the formula so that it falls into an algorithmic pattern that can use exponential notation. All theory at this point.
> Have fun and spread this puzzle to your friends.
>
> I inwented it, I am the Rickest Rick of all the Ricks if anyone wants to know who inwented it.
>

Here is an encryption in hexbytes of my name using my HMAC cipher:

http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1/

with the default key:

17b7fbaed7cfc97f9641c3e7a0730456dfe136caa14dc182f5619755d40b65b7bf6263b1916aee7da6a385a6b627c8ec12a2a5a373cc97d2e42662753aca401e3ad6a997fb4f93836b48af37f349fce2e08a22c2d5bad411930899b623697b6eb8ea79c0dddfcd44d42af398d7069806ff5f6caa

Here is a link that automatically goes to my site, puts in the hexbytes
and decrypts the message as a pure convenience. Keep in mind that this
message was encrypted using the default key:

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

The hexbytes can be stored in a raw file quite easily using 8-bit
unsigned integers.

I use hexbytes in order to be able to send a binary message as text
across the internet. Thats the only reason.

On 7/2/2021 7:36 PM, Chris M. Thomasson wrote:
> On 7/2/2021 5:31 PM, Kcir wrote:
>> Kcir's profile photo
>> Kcir
>> unread,
>> 5:28 PM (now)
>> to
>> -0.70928383564905214400491843078452104082710295997209875060333681255435334699521962691343068404279561138607296289815362070140579962
>>
>>
>> So then to compress that number well that is not a file so it starts
>> with a decimal. And it is a negative number.
>
> Well, this number can be stored as a file, then we can create a number
> using its hexbytes, or whatever encoding you desire.
>
>>
>> So we would need rules in our new program to identify the number to
>> first turn it into a whole number.
>> Then lastly we would add the sign and the decimal place by writing an
>> instruction that would appear as a symbol.
>>
>> So firstly to write this program you want to write a method of doing
>> the math.
>> And I am suggesting you do it as you do it by hand with a pencil.
>> So working from the right to the left through your number.
>> When you decompress it and start your chain reaction to recreate the
>> number you will need to multiply by 2 every time you see an 'a'.
>> So you would want to have lots of RAM.
>>
>> With this number it will easily and quickly write a small file each
>> pass if you wanted.
>> So here that number can go into a file, then do the math in columns,
>> div 2 and minus the last digit by 1 if it is an odd number and not an
>> even number.
>>
>

Some more info about my HMAC cipher:

http://funwithfractals.atspace.cc/ct_cipher/