I've been experimenting with infinitely efficient compression algorithm. I think I finally got it working. The algorithm quarantees at least one byte reduction of the input.
I've created a reference implementation. It consists of two programs, "pack" and "extract". It's written in C.
int main ( int arg ,char** argv ) { FILE_T _file; int __buf[512] = {0}; int _len; __integer __data_len; CHARPTR data; _file = stdin; _len = READ(_file); data = __buf; data[0] = _len; DO_EXTRACT(data); __data_len = _len + 1; WRITE(stdout);
return MAIN_SUCCESS_CODE; }
_EXTRACTCALL_ __EXTRACT__SUCCKESS_CODE __extract__ ( _EXTRACTER_DATA_TYPE __data ) { //here we define mini language /* that makes it easier to implement the algorithm */ #define Xor(a,b) a^b #define Fmap(_DAT) \ while( * ptr); \ { *ptr = F( * ptr);\ ptr++\ ; \ } #define F(_tok) \ Xor(\ _tok\ , Y) char Y; CHARPTR _rmag = "\x22\x22"; char time(void*);
/* REVERSE SECOND PASS */ Y = _rmag[1]; CHARPTR ptr = __data+1; Fmap(__data);
/* REVERSE FIRST PASS */ ptr = __data+1; Y = _rmag[0]; //Fmap(__data);
/* FINALISE */ __data[__data[0] + 4] = time(0); }
It works the same as pack.c, except it does the opposite.
What I would still need, is some review of the algorithm and implementation code before I take this to my colleagues. I was wondering if some hackers at /prog/ could do this? You'd get your names to computer history book.
Name:
Anonymous2014-07-22 7:12
The algorithm quarantees at least one byte reduction of the input.
Impossible. You claim have a function from the integers to the integers that is strictly decreasing and 1-1 (i.e. has an inverse). Then what is the image of the set {0, 1}?
TOO BAD! They are now in the standard (thanks G-d, it's optional) But strerror_s/strerrorlen_s are better than strerror (because they are thread safe/don't need static buffer), same goes for getenv_s and strtok_s that is a million times better than strtok (we have strtok_r form posix anyway but still). qsort_s allows you to pass a user-defined function to the function too, something that I find nice.
The fact that these functions return the error number instead of storing it in a globar variable is cool but annoying. Some of these functions (the ones I said + one or two string handling functions) seem to be the old functions done right
But strerror_s/strerrorlen_s are better than strerror (because they are thread safe/don't need static buffer)
Y DA FUK WUD U USE THREDS? N Y DA FUK DOES strerror_s HAVE A maxsize PARAMETER? N Y DA FUK IS IT rsize_t INSTED OF size_t? TELL ME DIS. Y DA FUK WUD U WANT A TRUNCATED ERROR MESSAGE? WHO ON DIS FUCKIN PLANET WANTS A MESSAGE DAT'S BEEN CHOPPED IN HALF?
strtok_s that is a million times better than strtok
YA FUKIN YUPPIES AINT RED K&R2. IF YA HAD, YA'D KNO A THING OR 2 ABOUT WRITIN STATE MACHINES AROUND getc. DAT'S WHERE U DO UR TOKENISATION, JUNIOR. BUT U WANT UR LINES HANDED TO U. U WANT DEM STORED NICELY IN STRINGS. DEN U MIGHT WANT TO CHOP DEM UP INTO CUTE LITTLE TOKENS. AND DEN U'LL TRAVERSE EACH TOKEN IN UR CUTE LITTLE LINE AND DO SOMETHING 'MAGICAL'.
I KNO WAT GETS U FUKIN YUPPIES OFF. IT'S U DAM YUPPIES DAT RUINED DA LANGUAGE DEANIS RICKY LOVED. IT'S U DAM YUPPIES DAT SAID "LET'S PUT THREDS IN C COS DEYRE CUTE N KOOL". TELL ME. WATS NEXT? QUATERNIONS IN C? DYNAMIC TYPES? CURRYING? DA CAT IN DA FUCKIN HAT?!
ONE THINGS 4 DAM SURE. UR A FUCKIN YUPPY AND YA WUDNT KNO A GUD DESIGN CHOICE IF IT HIT YA IN DA FUKIN FACE.
AS FOR >>1, HE'S A STAK BOI RETOID N A FAILED ABORTION. HE'S 1 OF DOSE RUSSIANS LIKE NIKITA WHO ENTER DER CARS HEAD FIRST N DRIVE AROUND WITH DER LEGS HANGIN OUT OF DA FUKIN ROOF. LET'S JUST LEEV IT AT DAT. U KNO SOME1'S PROGRAM'S SHIT WHEN U CAN ONLY REED IT *AFTER* U RUN IT THROUGH cpp.
AHAHA! HOW FUNNY IS DAT? MILKY BOI WANTS TO EXPRESS HIS OPINION 2!
Name:
Anonymous2014-07-22 12:02
>>17 It uses rsize_t because it is made by retards, rsize_t is defined as size_t in the standard
Y DA FUK WUD U WANT A TRUNCATED ERROR MESSAGE? WHO ON DIS FUCKIN PLANET WANTS A MESSAGE DAT'S BEEN CHOPPED IN HALF?
This is why you have to use strerrorlen_s
It would be better if we just had a function did something like const char *strerror_nextstandard (int err) { static const char *const errorToStr[] = { ... };
Infinite compression is provably impossible because the power set of the span of the Cantor sets is not injective to the endotensor product of the monadic reduction function.
HE'S 1 OF DOSE RUSSIANS LIKE NIKITA WHO ENTER DER CARS HEAD FIRST N DRIVE AROUND WITH DER LEGS HANGIN OUT OF DA FUKIN ROOF
I don't get this, please someone explain.
Name:
Anonymous2014-07-22 17:51
>>22 I hope you're just trying to be funny because I'll have you know that this does not make sense at all.
Name:
Anonymous2014-07-22 18:13
Truly infinite compression would allow you to compress any file into a single bit. But as we know, a bit can only represent two things, 0 or 1. And because there are more than two possible files, infinite compression is impossible.
>>28 I can't tell if you're trolling, God help me, so I'll explain this to you. Including the dictionary, you haven't compressed infinitely. Since the bit is useless without the dictionary, it needs to be included.
>>26 Then two bits (a byte) would be the result of ``truly'' infinite compression.
Name:
Anonymous2014-07-23 0:12
This is an excellent infinity decompression algorithm I have discovered. It is guaranteed to increase the input by at least one byte. For infinite compression, just use the endotensor inverse of this function. #include <void.h> #include <infinity.h> into main(void /* how about you take the standard and shove it up your fucking dick hole I will take a shit right on Dennis Rickie's grave */) char *data = (char*)malloc(getinfinity(COUNTABLE)); gets(data); data[strlen(data)+1] = rand()%255; puts(data); return(SUCCESS); }
Name:
Anonymous2014-07-23 4:01
>>32 But that just takes a line from stdin and adds the same byte to it every time. Also, gets is unsafe.
Name:
Anonymous2014-07-23 4:24
>>26 Use a trit then, I have no idea why people stopped using these nice Soviet products
Name:
Anonymous2014-07-23 4:33
>>32 gets was removed in ISO/IEC 9899:2011 afted declared as deprecated by ISO/IEC 9899:1999 Cor. 3:2007
<void.h> and <infinity.h> are not keywords
Using a cast to the result of malloc is considered bad practice, void * gets automaticaly translated into the right pointer type
You don't seem to define into, getinfinity, SUCCESS and COUNTABLE nor they are part of the standard
You have forgot to include the headers <stdlib.h> that declares malloc and rand, the header <stdio.h> that declares gets (until ISO/IEC 9899:2011) and puts
YEA, BUT DAT ELIMINATES DA NEED FOR A maxsize PARAMETER. maxsize JUST COMPLICATES DA IMPLEMENTATION 4 DA strerror_s FUNCTION, WEN U CUD HAVE: char *strerror_s(char *s, int err)
EEEEH EEEEEEH EEEEEH!
DEN IT'S AS SIMPLE AS: return strcpy(s, strerror(err));
BUT DOSE FATCATS AT DA ISO WANNA MAKE DA LANGUAGE AS RETOIDED AS POSSIBLE
I DONT THINK IT'S ALL DAT NECESSARY 2 RETURN A const char * INSTED OF A char *. IT MEANS U NEED A CAST IF U WANT TO STORE DA RETURN VALUE IN A char *. BUT, IT AINT REALLY ALL DAT IMPORTANT.
YEA, BUT DAT ELIMINATES DA NEED FOR A maxsize PARAMETER. maxsize JUST COMPLICATES DA IMPLEMENTATION 4 DA strerror_s FUNCTION, WEN U CUD HAVE: char *strerror_s(char *s, int err)
But each error has different length in the str form
IT MEANS U NEED A CAST IF U WANT TO STORE DA RETURN VALUE IN A char *
It actually it's as easy but safer, there is no need to store it directly in char *, if you want to modify it use strcpy (s, strerror(err)); or something like this (strdup in POSIX comes to mind). I like a const char * strerror because it does not overwrite the buffer unlike the char * form
