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
But each error has different length in the str form
SO IN A TYPICAL SCENARIO U'D CHEK DA LENGTH, ALLOCATE A BUFFER OF DA CORRECT SIZE, DEN CALL strerror_s(buffer, errcode). NO NEED 2 PASS A MAXIMUM SIZE TO strerror_s. U ALREADY KNOW HOW MANY BYTES IT'LL COPY, N IT CAN GO AHED N COPY EM WITHOUT HAVIN 2 ENSURE DAT IT DOESN'T EXCEED DA SIZE U PASSED. SIMPLER 4 DA CALLER (PROVIDING DEY ARENT RETOIDS WHO LIKE TRUNCATED ERROR MESSAGES), SIMPLER 4 DA IMPLEMENTER. OF COURSE IT'S SIMPLEST JUST 2 USE strerror.
DER'S REALLY LITTLE DIFFERENCE BETWEEN:
char *s = strerror(errno); AND const char *s = strerror(errno);
UR FUCKED IF U MODIFY *s IN EITHER CASE. UNDEFINED BEHAVIOUR IF DA STORAGE POINTED TO BY strerror's RETURN VALUE IS MODIFIED. UNDEFINED BEHAVIOUR IF U MODIFY ANY STORAGE WITH A const-QUALIFIED TYPE. IF strerror RETURNED A const char *, DA FIRST EXAMPLE WUD REQUIRE A CAST. DAT'S DA ONLY DIFFERENCE.
Name:
Anonymous2014-07-23 6:49
>>41 Yes, you are right about strerror_s getting 3 arguments
UR FUCKED IF U MODIFY *s IN EITHER CASE. UNDEFINED BEHAVIOUR IF DA STORAGE POINTED TO BY strerror's RETURN VALUE IS MODIFIED. UNDEFINED BEHAVIOUR IF U MODIFY ANY STORAGE WITH A const-QUALIFIED TYPE. IF strerror RETURNED A const char *, DA FIRST EXAMPLE WUD REQUIRE A CAST. DAT'S DA ONLY DIFFERENCE.
The difference is that if strerror returns a char * it usualy uses a static array and modifies the buffer, unlike the const char * where it would not have the need to do that
The difference is that if strerror returns a char * it usualy uses a static array and modifies the buffer, unlike the const char * where it would not have the need to do that
DER'S NO PROBLEM WITH RETURNING A const char * OR A char * IN EITHER CASE.
if (e >= 0 && e < NERRORS) return (char *) _error_message[e]; sprintf(s, "invalid error code: %d", e); return s; }
Name:
L. A. Calculus!jYCj6s4P.g2014-07-23 7:29
CALLER'S CODE WUD LOOK SOMETHING LIKE DIS:
char *a; const char *b;
a = strerror(errno); a = (char *) strerror_nextstandard(errno); b = strerror(errno); b = strerror_nextstandard(errno);
U CUD BASICALLY USE ANY ONE U WANT. DA const QUALIFIER IN strerror_nextstandard SEEMED 2 BE DA ONLY DIFFERENCE FROM strerror IN UR PROPOSITION. DA STORAGE POINTED TO BY DA RETURN VALUE OF strerror IS ALREADY IMMUTABLE (MODIFYING IT HAS UNDEFINED BEHAVIOUR) ALTHOUGH U CUD ARGUE DAT char * DOESNT MAKE DAT OBVIOUS. EITHER WAY IT AIN'T ALL DAT SIGNIFICANT. MAIN ARGUMENT FOR const-QUALIFIED RETURN TYPE IS DAT IT MAKES IT OBVIOUS DAT IT SHUDN'T BE MODIFIED BY DA CALLER. MAIN ARGUMENT FOR UNQUALIFIED RETURN TYPE IS DAT IT PLAYS NICE WITH QUALIFIED AND UNQUALIFIED VERSIONS OF DA SAME TYPE (DOESNT NEED A CAST).
Name:
Anonymous2014-07-23 7:36
>>44 The strerror_nextstandard (as I defined it) does not change the buffer that's returned a = strerror(errno); /* something that changes errno */ b = strerror(errno); in that case the value pointed by a may have been changed by strerror, unlike my strerror_nextstandard where it does not return a static buffer
Name:
L. A. Calculus!jYCj6s4P.g2014-07-23 7:37
O, I THINK I GET DA POINT OF UR strerror_nextstandard NOW. IT AIN'T RELEVANT TO DA RETURN TYPE, BUT U'D ESSENTIALLY REQUIRE DAT DA STORAGE POINTED 2 BY strerror'S RETURN VALUE IS NOT MODIFIED BY SUBSEQUENT CALLS 2 strerror.
U DAMN YUPPIES R ALWAYS THINKIN ABOUT UR THREDS!
Name:
Anonymous2014-07-23 7:58
Yes, sorry for not being clean. I also made the horrible assumation that you are able to change the returned value of strerror and the reason because it returns char * is this
Name:
Anonymous2014-07-23 8:08
What would you use instead of threads then?
Name:
Anonymous2014-07-23 8:41
>>48 IN WAT SITUATION WUD U CONSIDER USING THREDS? OR DO U JUST RANDOMLY USE DEM IN ALL UR PROGRAMS?
Name:
Anonymous2014-07-23 8:45
>>49 In a program like a http server where I have to serve multiple people at the same time
Name:
L. A. Calculus!jYCj6s4P.g2014-07-23 8:59
>>50 U CUD USE fork, OR IF U WANT TO KEEP IT IN ONE PROCESS, U CUD USE select
Name:
Anonymous2014-07-23 9:03
>>51 fork is more expencive and select can't make it parallel
>>45 The problem with this is that it prohibits the implementation from constructing the error string dynamically. For example, glibc strerror can return an error string that includes the error number ("Unknown error %d"); this is not possible if the return type of strerror is const char *.
The real solution is to provide a means for the error string function to inform the caller of the length of the string beforehand, like sprintf does:
/* Return the length of the error string for the given error number. * The contents of the error string will be placed in str, provided that it is * not NULL. */ int sprinterr(char *str, int errnum);
/* Lazy example; don't worry about len being negative */
int len; char *buf;
len = sprinterr(NULL, errno); buf = malloc(len); sprinterr(buf, errno);
>>46 I don't grok your distaste for threading in C. If you want to implement a kernel in C, you must use threads. I don't see any good reason to prefer thread unsafe behavior in userspace code just because it's possible to get away with it there.
Name:
Anonymous2014-07-24 5:15
>>59 Inderesting example, so something like strerror_s is the future
EVEN IF strerror IS REQUIRED 2 NOT MODIFY DA STORAGE POINTED TO BY ANY OF ITS RETURN VALUES AFTER DEY'VE BEEN RETURNED (COMPLETELY DIFFERENT FROM MAKIN DA RETURN TYPE const char *), U CAN STILL RETURN DOSE KINDS OF ERROR STRINGS. U CUD, FOR EXAMPLE, ALLOCATE STORAGE FOR DA STRING, sprintf IT, DEN RETURN A POINTER TO IT. IT'S INEFFICIENT, BUT IT SURE AS FUK IS POSSIBLE.
The real solution is to provide a means for the error string function to inform the caller of the length of the string beforehand, like sprintf does:
sprintf DOESNT DO DAT. YAINT RED DA FUKIN STANDARD, HAV YA?
I don't grok your distaste for threading in C.
DA DAM FAT CATS AT DA ISO WANNA MAKE DA LANGUAGE FAT N BLOATED LIKE C++. MOST PROGRAMS DONT USE THREDS N DONT NEED THRED SAFETY. DA EXAMPLE U LISTED, KERNELS, DON'T REQUIRE THREDS EITHER. DER MAY BE SOME CASES WHERE DEY'RE A GOOD DESIGN OPTION, SURE, BUT 2 SUGGEST DAT U CANNOT WRITE A KERNEL WITHOUT DEM IS SUMFIN A HOT-SHOT YUPPY WUD SAY. JUST COS HTML5'S DA KOOL NEW THING DONT MEAN YA CANT WRITE A FUCKIN WEB PAGE WITHOUT IT.
Name:
L. A. Calculus!jYCj6s4P.g2014-07-24 6:55
IF U GUYS WANT A GOOD SUGGESTION, IT WUD MAKE SENSE 2 IMPLEMENT ERROR STRINGS AS A FORMAT SPECIFIER 4 DA printf FAMILY. DAT WAY U WONT NEED TO CLUTTER DA LANGUAGE WITH EXTRA BULLSHIT, AND IT'S A FUK-LOAD MORE USEFUL THAN DA SHIT U HAD BEFORE. DA PROBLEM U DO GET, THO, IS DAT U BREAK COMPATIBILITY WITH OLDER CODE, SO DA FEATURE WUD BE ABOUT AS USEFUL AS rsize_t. BUT DAT'S NOT TO SAY SOME1 CUDNT REPLACE DA STANDARD C LIBRARY, ENTIRELY, WITH DER OWN CREATION DAT AINT GOVERNED BY A BUNCH OF GREEDY FAT CATS.
SO LET'S CALL IT DA 'r' SPECIFIER. (I THINK PLAN9 USED A SIMILAR METHOD IN DER C LIBRARY, I CANT FUCKIN REMEMBER)
U CAN GET DA LENGTH WITH: snprintf(NULL, 0, "%r", errno)
COPY WITH: sprintf(buf, "%r", errno);
HALF DA TIME U JUST WRITE DESE FUCKIN ERROR MESSAGES TO stderr THO, SO U CUD JUST DO:
fprintf(stderr, "%s: %r\n", program_name, errno);
U WONT EVEN NEED A FUCKIN strerror/perror FUNCTION ANYMORE.
Name:
Anonymous2014-07-24 7:05
>>63 Why not suggest it to the committee? It's a nice idea.
Name:
L. A. Calculus!jYCj6s4P.g2014-07-24 7:07
>>64 COS DEYRE HYENAS WHO WANNA RUIN DA LANGUAGE DEANIS RICKY LOVED
Name:
Anonymous2014-07-24 7:16
>>65 If you don't send your idea to them, then I will do it, and I will send it exacly as you wrote it (with the uppercase everywhere)
Name:
L. A. Calculus!jYCj6s4P.g2014-07-24 7:24
>>66 I LOOK FORWARD TO DA REEDING DA RESPONSE DEY GIVE U. SOMETHIN ALONG DA LINES OF "PLEEZ FORWARD DIS REQUEST 2 DA C++ COMMITTEE: NOWADAYS WE JUST COPY DER CHANGES"
Name:
L. A. Calculus!jYCj6s4P.g2014-07-24 7:32
>>66 N IF U TAKE DER ADVICE DA C++ COMMITTEE WILL RESPOND WITH: "WAT DA FUCK DOES DIS HAV 2 DO WITH OOP, POLYMOOFISM, OR MICROSOFT FUCKIN SAM? N DEN DEY'LL LAUGH AT U WEN U SAY U CAME FROM DA C COMMITTEE AND DEY'LL TELL U TO COME BACK WHEN U PUT A FEW THOUSAND PAGES ON UR FUCKIN STANDARD.
Name:
L. A. Calculus!jYCj6s4P.g2014-07-24 7:37
IT'S ALL FUCKIN POLITICS. DA C COMMITTEE MAKES DER LANGUAGE FAT N BLOATED TO TRY N GAIN ACCEPTANCE OF DA C++ COMMITTEE. MEANWHILE DA C++ COMMITTEE ARE SHOVIN LIVING CATS N DOGS INTO DER STANDARD LIKE TARRARE IN AN ANIMAL SHELTER. IT AINT GONNA STOP TILL DA FAT CATS IN DA C COMMITTEE GET SCARED N GO ON A FUCKIN DIET AS A RESULT OF DA C++ COMMITTEE DYING OF A FUCKIN HEART ATTACK.
Name:
Anonymous2014-07-24 8:24
Sadly I may have to agree, some nice things were added in C11 and C99 but they filled them with shit (example: // comments, *_s niggering, etc)
IF U GUYS WANT A GOOD SUGGESTION, IT WUD MAKE SENSE 2 IMPLEMENT ERROR STRINGS AS A FORMAT SPECIFIER 4 DA printf FAMILY.
s/sprintf/snprintf/
We are proposing nearly the same thing, then. glibc already has something close - it allows you to use 'm' as a conversion specifier to get the error string for the current value of errno. Yours is obviously better since it allows printing values other than the one in errno.
DA PROBLEM U DO GET, THO, IS DAT U BREAK COMPATIBILITY WITH OLDER CODE
Only if the older code expects that format strings containing the new conversion specifier will be printed verbatim. Most existing code will hopefully use the '%' conversion specifier where a literal '%' is expected in the output. In practice you already can't rely on implementations not defining nonstandard conversion specifiers.
New code can just check __STDC_VERSION__.
KERNELS, DON'T REQUIRE THREDS EITHER. DER MAY BE SOME CASES WHERE DEY'RE A GOOD DESIGN OPTION, SURE, BUT 2 SUGGEST DAT U CANNOT WRITE A KERNEL WITHOUT DEM IS SUMFIN A HOT-SHOT YUPPY WUD SAY.
And saying threads are a special case is something a curmudgeon would say. Today SMP is the norm nearly everywhere.
