Bytecount rule for *k prods (4k, 40k, 64k...)
category: general [glöplog]
Quote:
Yeah, kB looks so ugly.
Hey, leave kb alone!
Quote:
kernel who??On the other hand kelvin-bytes would make every 256 byte prod zero-cool.
Most of the categories are a pow2 number of bytes, except 40K which probably has some technical reason for it not being pow2..
Quote:
For extra impressive flex, make an entry that's 4096.5 bytes long and argue that IEEE round-to-nearest-even gives 4096.
You can do create a 4096.5 bytes demo if you host it online yourself and append one extra byte at random every time you serve it... (best with a JS demo, but not only). Then, on average, the intro WILL BE 4096.5 bytes ^__^
i see no problem in doing a prod in exactly 32772 bits.
I see no problem in doing a prod in exactly 32775 bits if you argue that IEEE uses directed round-to-zero. This gives 4096 from 4096.875 bytes by truncation towards zero.
Hehe, new ideas for party compos :)
Quote:
Most of the categories are a pow2 number of bytes, except 40K which probably has some technical reason for it not being pow2..
afair the 40k intros came from Amiga, so there's probably some executable size limit there or something.
Quote:
afair the 40k intros came from Amiga, so there's probably some executable size limit there or something.
There's no technical 40k or 40KiB barrier for anything on the Amiga. IIRC this was completely arbitrary in what seemed "reasonably small to pass as an intro", and I'd tend to think it was meant as 40000 bytes, not 40960.
Quote:
i see no problem in doing a prod in exactly 32772 bits.
The data produced by compressors is usually an arbitrary number of bits. So it's common for the decompressor to ignore some number of bits of the last byte in the file.
Crinkler takes advantage of the fact that the memory after the loaded data is guaranteed to be zero. It trims away any trailing zero bits from the compressed stream before rounding it up to bytes. So the actual compressed data may sometimes extend slightly beyond the end of the file. 4096.5 bytes intros are definitely a thing. :)
Quote:
I dunno, those rows-by-columns memory matrix based 2^N byte-sizes only ever made sense in a computer's directly addressable memory.a kilobyte used to be universally regarded as 1024 bytes until storage device manufacturers started to quibble about it and put misleading capacity numbers on their media
Anything else would be bitstream-based (storage, network), so totally fine with the more real-worldy radix-10 interpretation of those prefixes. =)
On the other hand...
Quote:
I love how this is so arbitrary that it MUST mean 40,000 bytes.There's no technical 40k or 40KiB barrier for anything on the Amiga. IIRC this was completely arbitrary in what seemed "reasonably small to pass as an intro", and I'd tend to think it was meant as 40000 bytes, not 40960.
IMO, the biggest problem with "kibibyte" etc. is that they are clunky to pronounce, with the two b-syllables in a row.
I hereby propose that we rename the prefixes to use "di" (for "digital") instead of "bi".
Admit it, "kidibyte", "medibyte", "gidibyte" etc. are much easier to pronounce, and evoke rather cute associations too. :)
I hereby propose that we rename the prefixes to use "di" (for "digital") instead of "bi".
Admit it, "kidibyte", "medibyte", "gidibyte" etc. are much easier to pronounce, and evoke rather cute associations too. :)
Quote:
I'd tend to think it was meant as 40000 bytes, not 40960.
There were entries with more than 40,000 bytes in early 40k compos like The Party 92 and Assembly 93.
Quote:
Admit it, "kidibyte", "medibyte", "gidibyte" etc. are much easier to pronounce, and evoke rather cute associations too. :)
I´d rather propose KiwiByte, MawiByte, GuwiByte, TiwiByte, ExiByte,...
Gargaj basically ended the thread with his first reply.
This is incorrect. There are hundreds of Amiga 40Ks that are above 40000 bytes. Orgas can make mistakes out of ignorance, of course. If this would result in disqualification, I would probably... raise my voice. If that didn't work I would take more extreme measures.
Haha :) All that said, it's good with precise language, and I am the first to adopt decimal notation (for 40000 bytes intro compos). It is a bit Scientific, but not Computer Scientific.
One short sentence in the rules will clarify all: "Here, K means KiB and M means MiB."
More curious is why the arbitrary 40KiB limit was chosen on Amiga over 64KiB. It's not bad, and IDK the answer, but technically 64KiB allows full 16-bit PC-relative addressing, and you could extend it by your largest chunk of data at the end, and it would still be an intro in the tight meaning, whereas different meanings for intro have come along, before and after intro competitions.
Quote:
For Amiga 40k intros, I think 40k meant whatever size Directory Opus showed as less than 40k.
This is incorrect. There are hundreds of Amiga 40Ks that are above 40000 bytes. Orgas can make mistakes out of ignorance, of course. If this would result in disqualification, I would probably... raise my voice. If that didn't work I would take more extreme measures.
Haha :) All that said, it's good with precise language, and I am the first to adopt decimal notation (for 40000 bytes intro compos). It is a bit Scientific, but not Computer Scientific.
One short sentence in the rules will clarify all: "Here, K means KiB and M means MiB."
More curious is why the arbitrary 40KiB limit was chosen on Amiga over 64KiB. It's not bad, and IDK the answer, but technically 64KiB allows full 16-bit PC-relative addressing, and you could extend it by your largest chunk of data at the end, and it would still be an intro in the tight meaning, whereas different meanings for intro have come along, before and after intro competitions.
