Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Infinite Compression Explained

Name: FrozenVoid 2009-06-24 10:03

Because most of you don't read my blog,(i don't read random blogs as well) and have so much questions about what i'm doing with my programs, i'll write it here:
All of the programs(about 6 developed so far) despite wildly varying routines are targeted to generate large integers.
These integers are not files. Following transformations occurs:
encode
1.file is converted to large integer X(arbitrary length).
2.X multiplied by some scale factor e.g. 10e1000 to get a lower bound
2.(X+1)by some scale factor e.g. 10e1000 to get an uppper bound
3.a search is performed for finding numbers inside that range which are easy to represent via formula.
4.if number(s) found its saved to a file.
decode:
1.a formula is supplied with number(s) and filesize
2.the formula generates an integer/float, which is then divided by scale factor(e.g. 10e1000).
3.the first filesize bytes are then written to output.

the proces isn't perfected yet, because the formulas currently used in my programs either too slow to search or cuttoff at float precision(for non-integer parameters)
________________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

Name: Anonymous 2009-06-24 10:50

>>6
each byte is converted to decimal and multiplied by 256^position in file.

Bytes are converted to decimal? What? Do you store its decimal representation in a string then? What does it mean to convert a byte to decimal? Why do you have to do this to multiply the bytes value with 256^position? Do you know what you're talking about?

In current programs it takes 1 second per 100 bytes.

Irrelevant. This is a non-working algorithm, so you're either lying or you're mistakingly interpreting the results of your code as correct.

I'm searching for any numbers which fit inside the range. floats, integers,etc

I do understand the algorithm. You suppose there's a number k between i and j which can be represented by an expression smaller than the representation of the value v, which is i/d.

Formal proof for this? Your whole algorithm is based on this logic. Can you prove this is true? In fact, it's not. You can give up now, or waste more of your time.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List