9 ms·

Lowercase letters save data

217 points by zdw 3y ago

edfletcher_t137 3y ago
Yes but they greatly enhance readability and are carriers of information. Don't throw the baby out with the bath water. Just because you can doesn't mean you should. There are so many cliches that apply here.
- jraph 3y ago
  I'm surprised by the strength of your comment. The article doesn't argue for lowercasing everything, and cites several cases (ah!) where it shouldn't hurt. Including case insensitive languages where case doesn't carry any information by definition and where it's already common practice and uncontroversial to lowercase everything, and English title case. With this in mind, my next question is: > they greatly enhance readability Do you have any evidence for this? My native language is not English and we use the Latin alphabet. The case for titles is the same as for regular sentences. We are doing fine. I would even say that the English title case feels somewhat odd and confusing. Titles are also virtually always set apart / rendered differently as normal text so I fail to see how normal case for titles loses information and how title case helps in any way. Actually, I even believe that title case sometimes loses information. Capital letters mark (Mark, btw :-)) proper names, this marking is lost with title case and this may sometimes bring ambiguity.
  - toast0 3y ago
    > Do you have any evidence for this? US street and highway signage went from all caps to mixed case in the past 30 years. I believe the US Department of Transportation did studies and found mixed case was easier to read. Although they use a non-standard font.
    - olah_1 3y ago
      this is because we recognize most words by shape. capital case is all single-height while lowercase is mixed height (it has letters that ascend and descend). for situations like road signs, being able to scan and see the “shape” of a word quickly is very helpful. so that is an argument in favor of using lowercase.
      - thaumasiotes 3y ago
        This is just a myth.
        redundantly 3y ago
        While the word shape meme is a myth [1] there are some half truths to it. It is known that mixed casing does disrupt reading [2], which gives some weight to the idea that the shapes of words and letters does affect reading. For myself I know that my reading speed and comprehension suffers when reading title cased sentences. This leads me to always "fix" [3] documents I update or otherwise contribute to at work when others do it for headings, subheadings, headers and footers. [1] https://www.mrc-cbu.cam.ac.uk/people/ https://www.mrc-cbu.cam.ac.uk/people/ [2] https://pubmed.ncbi.nlm.nih.gov/9293635/ https://pubmed.ncbi.nlm.nih.gov/9293635/ [3] I say "fix" because I know it's a generally acceptable formatting method when writing, I just don't like it.
        lupire 3y ago
        Link 1 is wrong
        redundantly 3y ago
        Thank you for pointing that out! Correct link: https://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/ https://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/
        olah_1 3y ago
        > In this paper, Pelli and colleagues show that when reading words that have been distorted by presenting each letter in visual noise (like an out of tune television), readers do not perform as well as an 'ideal observer' who can recognise words based on their shape alone I said being able to see the word shape is very helpful. I did not say that you can read based on the word shape alone.
    - jraph 3y ago
      Interesting, though one could as well conclude from this that all caps is not very readable. We need to know the actual motivation behind this change, not a supposition. My question would be from title case to normal case for titles. We already know that normal case is readable, that's what we use for normal text. We also know (?) that people speaking another language with a Latin alphabet don't have trouble reading titles.
      - chrisan 3y ago
        Heyo, just curious what language(s) use the latin alphabet without case?
        jraph 3y ago
        We have case, but we don't have title case. We write titles using normal case, with an upper case letter at the start and for proper names but no other words. (French, but I think that's also true for Spanish, Italian and many other languages. I don't know if German have a specific case for titles like English but they have an upper case letter for common nouns).
        teo_zero 3y ago
        Correct. Sentence case in Spanish: "El ingenioso hidalgo don Quijote de la Mancha" and Italian: "Il nome della rosa". Sentence case also in German, with the usual rule that all nouns are capitalized: "Kritik der reinen Vernunft". Same for Russian (non-latin of course): "Война и мир". I suspect English is the only language to use special, though not standardized, rules for titles.
- thaumasiotes 3y ago
  > Yes but they greatly enhance readability No they don't. It is true that modern readers read lowercase text more quickly than they read capitalized text. And it's also true that, after a small amount of practice reading capitalized text, the difference in reading speed becomes zero. There is no benefit of any kind to the lowercase letters.
- Waterluvian 3y ago
  I agree, but it has me wondering about a semantic-based compression approach. If we know a period is often followed by a space and a capital, can we compressed based on “which periods to reapply this rule to”?
- a2800276 3y ago
  The whole premise of the article is infuriating. The author claims using only lowercase _enhances_ legibility, maybe for them, but this is subjective at best, and incorrect for the general population of literate adults. Also lowercase compresses just as well as USING ONLY UPPER CASE would. You would get better compression result yet, f y lft t ll th vwls frm yr sntncs.
  - mrmanner 3y ago
    But the premise isn’t that using only lowercase increases legibility. The Premise is that Not Using Title Case Improves Compression and Also Increases Legibility for Author of Article.
- alpaca128 3y ago
  At least in titles I think "falsifying" the case of random words actually hurts readability. It can get confusing sometimes, especially when it includes a person's name that also happens to be a noun.
- makeitdouble 3y ago
  Readability is a complex matter in that it depends a lot on the reader, their expectations, and how well they handle some cases vs others. On title case in particular, I wonder how you would feel if it was applied to everything in the text, and not just the title. Would it be more readable ? For me personally it absolutely wouldn't and I'd be infuriated after three lines. Then if most people were on the opposite side, I'd think we'd have at least a few prominent use cases where all the text would be in title case, and I can't think of any. Is title case's point to just make it clear it's a title ? If so, we have so many better ways to convey that (bold, underlining, spacing, positionning, bullets and markers etc.). On the baby and the bath water saying, the more I think of it the more I see Title case as just a relic of some old practice I'm not sure why we cling to in this day and age...what's the baby, what am I missing ?
- jacknews 3y ago
  i don't agree that capital letters greatly enhance readability if they do at all, the benefit is not worth having an entire second alphabet to learn, and deal with, imho (i.m.h.o. i-m-h-o, etc) there are many other, and better, ways to improve readability
LegionMammal978 3y ago
Case-folded names in academic journals happen to be a pet peeve of mine. When the author is listed only as "VINCENT VAN GOGH", is the name rightly spelled with "van" or "Van"? Often, there's no real way to know, short of searching for the author's other works! Some online metadata lists the name with normal capitalization, but sometimes the spelling was entered by someone whose guess is just as good as yours.
- hackernewds 3y ago
  why would you spell as van? the English language and coding format is Van
  - stilist 3y ago
    You’d do it lowercase in van Goch’s name because it’s the correct way to write it for him. See https://en.wikipedia.org/wiki/Tussenvoegsel https://en.wikipedia.org/wiki/Tussenvoegsel
    - LegionMammal978 3y ago
      Of course, for someone so well-known, it's easy just to look it up; I was just using that name as an example. But in general, particles in names like "van", "von", "de", etc. might be properly capitalized one way or the other, and it can be impossible to tell which without a close understanding of the author's nationality (which in turn can very difficult to determine).
  - wahnfrieden 3y ago
    No it’s not
  - breakingcups 3y ago
    Yeah, surely the author can't be Dutch or Flemish? Where the van prefix originates?
  - deleted 3y ago
    [deleted]
olah_1 3y ago
i would also like to say that latin capital letters are for the most part a set of totally different, but related, shapes. so our alphabet is really more like 52 letters. and for what?
- Zanni 3y ago
  For readability. Compare to Cyrillic, where lowercase letters are basically half-height uppercase letters, so everything looks like it's rendered in small caps (this is more true for handprinted lettering, but mostly true for typeset stuff too).
  - wqweto 3y ago
    Probably true for Russian cyrillic alphabet tradition but not so much for Bulgarian and other cyrillic ancestry where lowercase letters differ almost for every letter with few exceptions, no matter if handwritten, cursive, italic or normal.
  - nekasrbenda 3y ago
    It's why God invented cursive.
    - TRiG_Ireland 3y ago
      Have you seen Cyrillic cursive?
- teaearlgraycold 3y ago
  Helps you scan for sentence beginnings and proper nouns I suppose
laserbeam 3y ago
That is gorgeous click bait! Love it. Using a somewhat surprising effect of compression to explain it is brilliant. Obviously, no one should consider a couple bytes of compression when actually writing text, and I know the article doesn't advocate for that.
chrismorgan 3y ago
> Also I don't like how they force all the titles into title case (edit: actually I think I'm wrong about this.) In many cases (not sure of the rules), it fiddles with the case, as it does various other title manglings. If it does mangle things, the submitter can edit them back the way they were and it won’t mangle again. I strongly dislike the title mangler and would fain see it removed. I feel like I disagree with its modifications most of the time, and even the ones that have some justification like removing numbers at the start as a declickbaiting measure (“400 ways to do X” → “Ways to do X”) very often harm the sense, and I dislike these cases more than I dislike its improvements. (But maybe if the mangler were disabled I would realise that people are doing a terrible job of entering titles and it is actually fixing a lot of stuff.)
chrismorgan 3y ago
On <!DOCTYPE html> versus <!doctype html>: it’s actually not so simple. If you’re using gzip, you might manage to save as much as a few bytes (though typically only 1–2), but if you’re using Brotli, it’ll actually compress something like 2–4 bytes worse, because Brotli includes a static dictionary based on a popularity contest of largely-not-optimised content. This is a thing I dislike about Brotli: it encourages you to follow the herd, rather than doing what would otherwise be more optimal. (Sure, the encouragement is just a byte here, a byte there, but it’s the principle of the thing.) Here are sizes based on running `‹brotli or gzip› --stdout <<<'‹doctype›‹charset›' | wc -c`: ┌─────────────────┬────────────────────────┬──────────────────────┐ │ BROTLI │ <meta charset="utf-8"> │ <meta charset=utf-8> │ ├─────────────────┼────────────────────────┼──────────────────────┤ │ <!DOCTYPE html> │ 19 │ 27 │ │ <!doctype html> │ 23 │ 29 │ └─────────────────┴────────────────────────┴──────────────────────┘ ┌─────────────────┬────────────────────────┬──────────────────────┐ │ GZIP │ <meta charset="utf-8"> │ <meta charset=utf-8> │ ├─────────────────┼────────────────────────┼──────────────────────┤ │ <!DOCTYPE html> │ 58 │ 56 │ │ <!doctype html> │ 58 │ 56 │ └─────────────────┴────────────────────────┴──────────────────────┘ In practice, when you add more content, predominantly lowercase, doctype tends to save a byte or two compared to DOCTYPE. So gzip gravitates to the bottom left corner—that removing unnecessary characters and matching case where case-insensitive is good. But Brotli was made by popularity contest, and so the inferior representation actually ends up compressing better than the superior, because most people did things the inferior way!
- lifthrasiir 3y ago
  But the static dictionary is not used as is, but transformed with a lot of options. For example both `<!DOCTYPE html>` and `<!doctype html>` appear in the dictionary, and the transform 43 (FermentAll) will turn them into `<!DOCTYPE HTML>`. (No transform would generate `<!doctype HTML>` though.) Therefore Brotli is not only following the herd, so to say. And the static dictionary only improves a very short input---any long-term pattern will be captured regardless of the static dictionary.
Tommah 3y ago
I used this effect in my chess trainer (the link is in my profile). I have a file with 800 compressed chess positions, and I used a lot of tricks to get the file as small as I could. One trick was to invert the color of every piece on White's side of the board. In a typical position outside of the endgame, White's pieces will tend to be on his side of the board, and Black's will tend to be on his side. By inverting the piece colors on one side, I ended up with positions where almost all of the pieces are black, and here and there you'll have a white piece. It's similar to how most of the letters in text are lowercase, and occasionally you'll see an uppercase letter. I think I shrank the file by 5% or so this way.
- thrw21 3y ago
  Here is how I would it Board is 8x8, which is 6 bits. 4 piece type (rook, queen, knight, bishop. I will represent others (king and pawn) in a special way) is 2 bits. So 8 bits in total per piece I would not use a bit to represent piece color but instead use a seperator to seperate one player's piece from another. Repeating the same position as the last piece can act as a separator since two pieces can't share same square Kings are special that they must exist, so you don't have to specify their type Pawns are special, most likely you will have 1 pawn (of each color) in one column and they can be on rows 2 to 7, or they can be dead or they can be "irregular" which means the pawn moved to another column and there are two pawns in that column now. This data is 3 bits per pawn so 48 bits in total. After that data you can put position of all irregular pawns (additional 6 bits for each irregular pawn). If a pawn promotes, it is represented as a regular piece (and can be considered dead in this 48 bit pawn data) So a chess state is Pawn data (48 bits) Irregular pawns (6 bit each but I can't tell how many there can be at max. 8 maybe?) White king pos (6 bits) White pieces (6 bits for pos + 2 bits for type \* number of pieces) Seperator (6 bits) Black King pos (6 bits) Black pieces (same as white) Seperator (6 bits, represents end of data) I think the worst case scenario is there are 8 promotions which would make it add up 248 bits If number of pawns on board is small, it might worth representing them using their full positions and using a bit to decide which representation you picked
  - IanCal 3y ago
postepowanieadm 3y ago
Cool, but just think about how much data (and co2) you may save by skipping vovels!
weinzierl 3y ago
And this is another case where our world is culturally biased to "the West". It doesn't stop at the lowercase letters saving data when compressed and being at an advantage. Take UTF-8, for example, and think about the difference between latin and other scripts. And then there is the whole Pandoras Box of Han Unification...
- lioeters 3y ago
  For others like me who might be curious about the Han Unification controversy: https://en.wikipedia.org/wiki/Han_unification#Rationale_and_controversy https://en.wikipedia.org/wiki/Han_unification#Rationale_and_... > In 1993, the Japan Electronic Industries Development Association (JEIDA) published a pamphlet titled "未来の文字コード体系に私達は不安をもっています" (We are feeling anxious for the future character encoding system JPNO 20985671), summarizing major criticism against the Han Unification approach adopted by Unicode.
  - lifthrasiir 3y ago
    And yet the same criticism is now directed to the Japan government, because Japan is trying to define the unified character set for name characters and that necessarily demands some sort of unifications [1]. [1] https://mainichi.jp/articles/20231231/k00/00m/040/131000c https://mainichi.jp/articles/20231231/k00/00m/040/131000c (Japanese, also paywalled but at least the first portion is visible)
chrismorgan 3y ago
The SVG path shown is broken, showing slightly why this would be a dodgy approach to apply here. Shown are these: <path d="M 1 1 L 1 -1 Z" /> <path d="m 1 1 L 2 0 z" /> But these are inconsistent. These show what I think was intended (a line from (1,1) to (2,0)): <path d="M 1 1 L 2 0 Z" /> <path d="m 1 1 l 1 -1 z" /> When you look at realistic illustrations, “lowercase everything” is fairly obviously not a good approach in path data: sometimes absolute coordinates will be shorter, other times relative coordinates will be shorter; and the difference, raw or compressed, will normally be more than the case difference. No, if you’re trying to compress, you should be taking the holistic approach, adjusting not just case, but the entire path data. For example, one of these two solutions, dropping the superfluous whitespace and removing the line-to opcode which is implied after an opening move-to: <path d="M1 1 2 0z"/> <path d="m1 1 1-1z"/> You can also contemplate whether you actually want to close the path. In this trivial case, it’ll only make a difference if you have exactly one of stroke-linejoin and stroke-linecap set to round.
the_mitsuhiko 3y ago
In most cases uppercase vs lowercase doesn’t matter. Compression work either well. An interesting exception are QR codes. They are substantially smaller if you only use upper case characters because there is a more efficient encoding for them.
- tronster 3y ago
  I've only dabbled with QR codes but they are interesting. Do you have any links that go into more detail about uppercase making them smaller?
  - the_mitsuhiko 3y ago
    https://www.thonky.com/qr-code-tutorial/alphanumeric-mode-encoding https://www.thonky.com/qr-code-tutorial/alphanumeric-mode-en...
  - lifthrasiir 3y ago
    In addition to mitsuhiko's link, there is even a dedicated binary-to-text encoding suitable for the alphanumeric mode of QR codes: https://datatracker.ietf.org/doc/html/rfc9285 https://datatracker.ietf.org/doc/html/rfc9285
lifthrasiir 3y ago
This is only true because DEFLATE is very old---it handles duplicates well but ignores everything else---it doesn't even handle simple sequences like `00 01 02 ... ff`. Modern browsers support Brotli as an additional content encoding, and it can actually detect and handle such cases better. Of course such modelling can be done as a preprocessing step as well, PNG notably uses filtering in addition to DEFLATE.
remoquete 3y ago
What I find interesting here is how the effect of using lowercase would add up and reduce carbon production significantly. It reminds me of Gerry McGovern's articles on the use of images and the environmental impact that that has. https://gerrymcgovern.com/books/world-wide-waste/ https://gerrymcgovern.com/books/world-wide-waste/
- lupire 3y ago
  That page lowered my IQ 10 points.
avgcorrection 3y ago
Thanks to Endtimes for this interesting article. I hope that the Collapse (Tech) Subculture in general is more interested in improving compression algorithms than they are in making less legible content. (But if they think the legibility is fine then sure, do the latter.)
faiD9Eet 3y ago
If you ever happen to study computer science, you may come across a subject called "coding theory". It introduces you to compression as well as many other topics such as error correction (Reed-Solomon, used in RAID5, RAID6 and ECC-RAM), line coding (sometimes you need to flip bits to keep the clock on both sides in sync, no clock-signal for a long time may cause clock loss) and a lot of wonderful but weird stuff. Let us go into detail on compression: There is a representation. US-ASCII uses 8 bits per latin letter, UTF-32 uses 4 bits per latin letter. It is just a temporal representation to the machine -- usually in memory only, it does have the same amount of information, you can save it more efficiently to disk. You would not want to save either format to disk, it is a waste of space. Information content (I hope my translation is correct, scan Wikipedia for details) cannot be compressed. But it can be calculated. The more seldom a letter, the more information its occurence carries. As soon as each letter is not equally frequent (compare space and "q") the information density drops. Calculation is quite simple: Count the occurence of each letter, count the caracters used (if there is no "q" in the text, you got to save one letter and its encoding) and apply some math https://en.wikipedia.org/wiki/Entropy_(information_theory) https://en.wikipedia.org/wiki/Entropy_(information_theory) For some easy examples, think of morse code and Huffman coding -- not every letter needs to be encoded using the same amount of bits. > How much data can lowercase save? # Nothing. Either there is (almost) no information to it in the first place, in that case compression will take care of it for you. There could only be information to it if uppercase letters were equally likely as lowercase letters > How much data can lowercase save? # Why do you even stop at letters? You could build a dictionary of words and compress references to it. The compression efficiancy would only depend on the amount of words, regardless of case and regardless of character set. That is why entropy depends on "symbols" instead of "letters"
em-bee 3y ago
ok, that's my new excuse for why i am writing in all lowercase ;-)
rplnt 3y ago
Not using title case also removes ambiguity in some cases and is generally much easier to read. Not sure how or why is it so popular around here.
Puts 3y ago
On the other hand, lowercase letters tend to be more complex using more bezier anchor points. So if your priority is not bandwidth but work memory you should maybe stick to uppercase? :D
- flohofwoe 3y ago
  Just use an 8x8 raster font. 8 bytes per character are hard to beat, still perfectly readable, and who needs fancy smooth outlines anyway ;)
alx__ 3y ago
BY THAT LOGIC SWITCHING TO ALL CAPS IS JUST AS EFFICIENT. I PROMISE I AM NOT YELLING.
- gvx 3y ago
  CONVERTING EVERYTHING TO UPPERCASE SHOULD HAVE THE SAME EFFECT ON COMPRESSION STOP IT EVEN MAKES YOUR WEBSITE LOOK LIKE A TELEGRAM STOP
einpoklum 3y ago
tl;dr: 1. It doesn't save data, it loses data. 2. If you drop the uppercase, you can compress the remaining text farther.
alanfranz 3y ago
TL;DR: dropping non relevant information from a message saves data. Slightly misleading title and article. Nothing about lowercase saves data. Not having two (or more) different letter cases saves data; if you had ALL UPPERCASE DATA the effect would be the same. And, the fewer other chars you use, the best - stay on lowercase or uppercase ascii only, and your compression will be better. Having "A" versus "a" conveys information; if you drop that information, your message can be naturally smaller. What if you actually needed to differentiate jack from Jack? Only using lowercase letter you may be forced to do something like _j_ack, which would probably take _more space_. (information theory discusses those topics, especially the information enthropy concept).
- gvx 3y ago
  > What if you actually needed to differentiate jack from Jack? Especially if Jack's your uncle and he's on a horse...
mhd 3y ago
Wild shot, but does anyone have data sets on how different languages compress in a similar manner? It would be an interesting mix of letters/phonemes used, word length etc.
pseudocomposer 3y ago
THERE MIGHT BE ANOTHER WAY ABOUT THIS.
skrebbel 3y ago
I use smaller font sizes for the same reason
jacknews 3y ago
uppercase characters seem to be almost entirely superfluous to me, or at least, the benefits do not justify having an entire second alphabet of characters which everyone has to learn, machines have to process, etc.
- ahoka 3y ago
  They add one bit of information, hardly superfluous.
  - jacknews 3y ago
    tEchniCalLy, oNe biT PeR cHaRAcTER, bUT iN reALITy, nOT MuCH mORe aCTuAL iNForMaTIon
- tmtvl 3y ago
  I thought so too, until I needed to help my uncle Jack off a horse.
deleted 3y ago
[deleted]
tonmoy 3y ago
Wouldn't a perfect compression algorithm know that spaces are followed by Uppercase letter and take that into account?
moritzwarhier 3y ago
I disagree that it's not intuitive (reason comes to mind pretty easily, no?), but it is still a great and interesting thing to write about!
croes 3y ago
If it's about text compression can't you say the same in the favor of upper case?
- MrGilbert 3y ago
  I'd think so, yes. But at least for me, reading all-caps is really annoying. For me, it feels like yelling. I also find it harder to read. Uppercase letters tend to use more space, physically. So it makes a page feel really crowded if everything is in uppercase.
  - Cthulhu_ 3y ago
    But all lowercase gets annoying as well; at least CSS can be used to kind of straighten it?
    - MrGilbert 3y ago
      Not for me, personally. As long as punctuation rules are in place.
ww520 3y ago
Better title - mixed case text takes up more space when compressed.
nsalerno 3y ago
It's not that lowercase saves data. It's that normalization saves data. You can normalize to uppercase and get the same effect. In fact, the argument to use uppercase for normalization is that lowercase does not round trip. You are assuming ASCII content (or UTF-8 content that happens to only be ASCII). Throw Unicode into the mix and you get problems to deal with. Separately, after normalization, to decompress the data you are assuming every sentence must be capitalized and anything that appears to be a title or proper name must be title cased. I imagine that for some pages this isn't 100% so after decompression you will probably make have a letter be uppercase where it was originally not. Thus, your technique must be classified as a lossy algorithm.
- KTibow 3y ago
  >You can normalize to uppercase and get the same effect. This isn't quite true. Most HTML, JS, and user content can't be uppercased. >Thus, your technique must be classified as a lossy algorithm. I think you might be misunderstanding some parts of this. The article is just suggesting changing the case to sentence case everywhere, whether transferred or displayed. The compression comes from separate lossless algorithms.
  - calibas 3y ago
    Converting everything to lowercase for the purposes of saving space when zipping is technically a lossy compression algorithm. It's an algorithm for saving space, and it doesn't recreate a perfect copy of the original data.
- tmtvl 3y ago
  > In fact, the argument to use uppercase for normalization is that lowercase does not round trip. I believe neither upper or lower case round trips properly, which is why Unicode invented fold case. Whenever this topic comes up I like to refer to one of my favourite talks on the topic: A Million Billion Squiggly Characters by Ricardo Signes: <https://www.youtube.com/watch?v=TmTeXcEixEg https://www.youtube.com/watch?v=TmTeXcEixEg>. Whilst nominally about Unicode handling in Perl, it's general enough that anyone using any language can learn something from it.
buildbuildbuild 3y ago
The “saving X bytes saves Y emitted carbon” trope is a pet peeve of mine. Nobody knows how much carbon a request’s full internet transmission path, storage, and possible 24/7 availability of a server consume. Stacks are too different, equipment widely varies, international internet traffic likely consumes more. I’m typing this using wind energy that I pay extra for. But who knows what my ISP’s equipment and onward are using. If you carbon-optimize your content so much that I have to make multiple requests or paste it into ChatGPT to understand it, you did not reduce your footprint. There’s no direct byte to carbon conversion.
- croemer 3y ago
  Saying you use wind energy you pay extra for is a pet peeve of mine :) You're not really using wind energy. The electrons don't know who is pushing them. You just increase the share of non-wind that others get, but as long as there are fewer wind subscribers than there is wind energy it doesn't change thing. Premium goes entirely to your energy provider, their profits and marketing department. Happy to be proved wrong in your case if you have a link to your plan.
  - IshKebab 3y ago
    This is an oversimplification. I assume you're both talking about REGOs. Electrons are fungible so you're sort of right in that you aren't using the exact electrons that come from a wind turbine. But you're wrong that the extra money just goes straight to profits and has zero effect on green energy generation. Imagine two scenarios: 1. Everyone believes your comment so nobody pays extra for green energy. Therefore the market value of RIGOs is 0. This means green energy generators get paid exactly the same market price per kWh as brown (?) generators. 2. Some people (not necessarily everyone) pay for 100% green energy. This increases the market value of RIGOs so now green suppliers get paid a bit more. Green energy is now worth more than brown energy, which changes the supply/demand curve so you get more green energy overall. The RIGO market is a very elegant market solution to selling the "greenness" of green energy. The fact that it isn't a dumb 1:1 connection that people naively expect doesn't mean it is a scam.
helsinki 3y ago
Isn't the same true for uppercase letters, too? What about binary encoded text? Probably true if you translate the page to ones and zeros, as well.
jawns 3y ago
About 15 years ago, I got frustrated that the National Weather Service issued its alerts in all caps. So I built a service, IntelliCAPS, that attempts to convert all caps to mixed case using both a custom dictionary and user-submitted feedback. It worked pretty well! I could convert most of the NWS bulletins to a more readable format with about 98% accuracy. I bet LLMs could probably do way better these days.
franga2000 3y ago
A very vaguely related thing that might be useful to someone: in QR codes, using ALL-CAPS actually saves you data, making the QR code less "dense" and so easier to read at smaller sizes. The trick is in the "alphanumeric" encoding mode of the QrR standard, which lets you encode 3 character per 11 bit (as opposed to 1 character per 8 bits) if you limit yourself to just numbers, uppercase letters and a few common URL symbols [0]. Besides making the code less dense, you can also add more error correction at the same density, making the code more resilient to wear, damage and reflections. For more QR code trivia, see this excellent demo: https://www.nayuki.io/page/creating-a-qr-code-step-by-step https://www.nayuki.io/page/creating-a-qr-code-step-by-step [0] https://www.thonky.com/qr-code-tutorial/alphanumeric-table https://www.thonky.com/qr-code-tutorial/alphanumeric-table
1vuio0pswjnm7 3y ago
And yet in the past, when space was at an even greater premium, code was written in all uppercase. The title seems to imply that uppercase is worse than lowercase in terms of data usage. Truthfully, it is "same case" that allows for less data usage. The case could be all lower, or all upper.
- Narishma 3y ago
  The article is arguing against title case, not all uppercase.

217 points by zdw 3y ago

Yes but they greatly enhance readability and are carriers of information. Don't throw the baby out with the bath water. Just because you can doesn't mean you should. There are so many cliches that apply here.

jraph 3y ago
I'm surprised by the strength of your comment. The article doesn't argue for lowercasing everything, and cites several cases (ah!) where it shouldn't hurt. Including case insensitive languages where case doesn't carry any information by definition and where it's already common practice and uncontroversial to lowercase everything, and English title case. With this in mind, my next question is: > they greatly enhance readability Do you have any evidence for this? My native language is not English and we use the Latin alphabet. The case for titles is the same as for regular sentences. We are doing fine. I would even say that the English title case feels somewhat odd and confusing. Titles are also virtually always set apart / rendered differently as normal text so I fail to see how normal case for titles loses information and how title case helps in any way. Actually, I even believe that title case sometimes loses information. Capital letters mark (Mark, btw :-)) proper names, this marking is lost with title case and this may sometimes bring ambiguity.
- toast0 3y ago
  > Do you have any evidence for this? US street and highway signage went from all caps to mixed case in the past 30 years. I believe the US Department of Transportation did studies and found mixed case was easier to read. Although they use a non-standard font.
  - olah_1 3y ago
    this is because we recognize most words by shape. capital case is all single-height while lowercase is mixed height (it has letters that ascend and descend). for situations like road signs, being able to scan and see the “shape” of a word quickly is very helpful. so that is an argument in favor of using lowercase.
    - thaumasiotes 3y ago
      This is just a myth.
      - redundantly 3y ago
        While the word shape meme is a myth [1] there are some half truths to it. It is known that mixed casing does disrupt reading [2], which gives some weight to the idea that the shapes of words and letters does affect reading. For myself I know that my reading speed and comprehension suffers when reading title cased sentences. This leads me to always "fix" [3] documents I update or otherwise contribute to at work when others do it for headings, subheadings, headers and footers. [1] https://www.mrc-cbu.cam.ac.uk/people/ https://www.mrc-cbu.cam.ac.uk/people/ [2] https://pubmed.ncbi.nlm.nih.gov/9293635/ https://pubmed.ncbi.nlm.nih.gov/9293635/ [3] I say "fix" because I know it's a generally acceptable formatting method when writing, I just don't like it.
        lupire 3y ago
        Link 1 is wrong
        redundantly 3y ago
        Thank you for pointing that out! Correct link: https://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/ https://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/
        olah_1 3y ago
        > In this paper, Pelli and colleagues show that when reading words that have been distorted by presenting each letter in visual noise (like an out of tune television), readers do not perform as well as an 'ideal observer' who can recognise words based on their shape alone I said being able to see the word shape is very helpful. I did not say that you can read based on the word shape alone.
  - jraph 3y ago
    Interesting, though one could as well conclude from this that all caps is not very readable. We need to know the actual motivation behind this change, not a supposition. My question would be from title case to normal case for titles. We already know that normal case is readable, that's what we use for normal text. We also know (?) that people speaking another language with a Latin alphabet don't have trouble reading titles.
    - chrisan 3y ago
      Heyo, just curious what language(s) use the latin alphabet without case?
      - jraph 3y ago
        We have case, but we don't have title case. We write titles using normal case, with an upper case letter at the start and for proper names but no other words. (French, but I think that's also true for Spanish, Italian and many other languages. I don't know if German have a specific case for titles like English but they have an upper case letter for common nouns).
        teo_zero 3y ago
        Correct. Sentence case in Spanish: "El ingenioso hidalgo don Quijote de la Mancha" and Italian: "Il nome della rosa". Sentence case also in German, with the usual rule that all nouns are capitalized: "Kritik der reinen Vernunft". Same for Russian (non-latin of course): "Война и мир". I suspect English is the only language to use special, though not standardized, rules for titles.
thaumasiotes 3y ago
> Yes but they greatly enhance readability No they don't. It is true that modern readers read lowercase text more quickly than they read capitalized text. And it's also true that, after a small amount of practice reading capitalized text, the difference in reading speed becomes zero. There is no benefit of any kind to the lowercase letters.
Waterluvian 3y ago
I agree, but it has me wondering about a semantic-based compression approach. If we know a period is often followed by a space and a capital, can we compressed based on “which periods to reapply this rule to”?
a2800276 3y ago
The whole premise of the article is infuriating. The author claims using only lowercase _enhances_ legibility, maybe for them, but this is subjective at best, and incorrect for the general population of literate adults. Also lowercase compresses just as well as USING ONLY UPPER CASE would. You would get better compression result yet, f y lft t ll th vwls frm yr sntncs.
- mrmanner 3y ago
  But the premise isn’t that using only lowercase increases legibility. The Premise is that Not Using Title Case Improves Compression and Also Increases Legibility for Author of Article.
alpaca128 3y ago
At least in titles I think "falsifying" the case of random words actually hurts readability. It can get confusing sometimes, especially when it includes a person's name that also happens to be a noun.
makeitdouble 3y ago
Readability is a complex matter in that it depends a lot on the reader, their expectations, and how well they handle some cases vs others. On title case in particular, I wonder how you would feel if it was applied to everything in the text, and not just the title. Would it be more readable ? For me personally it absolutely wouldn't and I'd be infuriated after three lines. Then if most people were on the opposite side, I'd think we'd have at least a few prominent use cases where all the text would be in title case, and I can't think of any. Is title case's point to just make it clear it's a title ? If so, we have so many better ways to convey that (bold, underlining, spacing, positionning, bullets and markers etc.). On the baby and the bath water saying, the more I think of it the more I see Title case as just a relic of some old practice I'm not sure why we cling to in this day and age...what's the baby, what am I missing ?
jacknews 3y ago
i don't agree that capital letters greatly enhance readability if they do at all, the benefit is not worth having an entire second alphabet to learn, and deal with, imho (i.m.h.o. i-m-h-o, etc) there are many other, and better, ways to improve readability

LegionMammal978 3y ago

Case-folded names in academic journals happen to be a pet peeve of mine. When the author is listed only as "VINCENT VAN GOGH", is the name rightly spelled with "van" or "Van"? Often, there's no real way to know, short of searching for the author's other works! Some online metadata lists the name with normal capitalization, but sometimes the spelling was entered by someone whose guess is just as good as yours.

hackernewds 3y ago
why would you spell as van? the English language and coding format is Van
- stilist 3y ago
  You’d do it lowercase in van Goch’s name because it’s the correct way to write it for him. See https://en.wikipedia.org/wiki/Tussenvoegsel https://en.wikipedia.org/wiki/Tussenvoegsel
  - LegionMammal978 3y ago
    Of course, for someone so well-known, it's easy just to look it up; I was just using that name as an example. But in general, particles in names like "van", "von", "de", etc. might be properly capitalized one way or the other, and it can be impossible to tell which without a close understanding of the author's nationality (which in turn can very difficult to determine).
- wahnfrieden 3y ago
  No it’s not
- breakingcups 3y ago
  Yeah, surely the author can't be Dutch or Flemish? Where the van prefix originates?
- deleted 3y ago
  [deleted]

olah_1 3y ago

i would also like to say that latin capital letters are for the most part a set of totally different, but related, shapes. so our alphabet is really more like 52 letters. and for what?

Zanni 3y ago
For readability. Compare to Cyrillic, where lowercase letters are basically half-height uppercase letters, so everything looks like it's rendered in small caps (this is more true for handprinted lettering, but mostly true for typeset stuff too).
- wqweto 3y ago
  Probably true for Russian cyrillic alphabet tradition but not so much for Bulgarian and other cyrillic ancestry where lowercase letters differ almost for every letter with few exceptions, no matter if handwritten, cursive, italic or normal.
- nekasrbenda 3y ago
  It's why God invented cursive.
  - TRiG_Ireland 3y ago
    Have you seen Cyrillic cursive?
teaearlgraycold 3y ago
Helps you scan for sentence beginnings and proper nouns I suppose

laserbeam 3y ago

That is gorgeous click bait! Love it. Using a somewhat surprising effect of compression to explain it is brilliant. Obviously, no one should consider a couple bytes of compression when actually writing text, and I know the article doesn't advocate for that.

chrismorgan 3y ago

> Also I don't like how they force all the titles into title case (edit: actually I think I'm wrong about this.) In many cases (not sure of the rules), it fiddles with the case, as it does various other title manglings. If it does mangle things, the submitter can edit them back the way they were and it won’t mangle again. I strongly dislike the title mangler and would fain see it removed. I feel like I disagree with its modifications most of the time, and even the ones that have some justification like removing numbers at the start as a declickbaiting measure (“400 ways to do X” → “Ways to do X”) very often harm the sense, and I dislike these cases more than I dislike its improvements. (But maybe if the mangler were disabled I would realise that people are doing a terrible job of entering titles and it is actually fixing a lot of stuff.)

chrismorgan 3y ago

On <!DOCTYPE html> versus <!doctype html>: it’s actually not so simple. If you’re using gzip, you might manage to save as much as a few bytes (though typically only 1–2), but if you’re using Brotli, it’ll actually compress something like 2–4 bytes worse, because Brotli includes a static dictionary based on a popularity contest of largely-not-optimised content. This is a thing I dislike about Brotli: it encourages you to follow the herd, rather than doing what would otherwise be more optimal. (Sure, the encouragement is just a byte here, a byte there, but it’s the principle of the thing.) Here are sizes based on running `‹brotli or gzip› --stdout <<<'‹doctype›‹charset›' | wc -c`: ┌─────────────────┬────────────────────────┬──────────────────────┐ │ BROTLI │ <meta charset="utf-8"> │ <meta charset=utf-8> │ ├─────────────────┼────────────────────────┼──────────────────────┤ │ <!DOCTYPE html> │ 19 │ 27 │ │ <!doctype html> │ 23 │ 29 │ └─────────────────┴────────────────────────┴──────────────────────┘ ┌─────────────────┬────────────────────────┬──────────────────────┐ │ GZIP │ <meta charset="utf-8"> │ <meta charset=utf-8> │ ├─────────────────┼────────────────────────┼──────────────────────┤ │ <!DOCTYPE html> │ 58 │ 56 │ │ <!doctype html> │ 58 │ 56 │ └─────────────────┴────────────────────────┴──────────────────────┘ In practice, when you add more content, predominantly lowercase, doctype tends to save a byte or two compared to DOCTYPE. So gzip gravitates to the bottom left corner—that removing unnecessary characters and matching case where case-insensitive is good. But Brotli was made by popularity contest, and so the inferior representation actually ends up compressing better than the superior, because most people did things the inferior way!

lifthrasiir 3y ago
But the static dictionary is not used as is, but transformed with a lot of options. For example both `<!DOCTYPE html>` and `<!doctype html>` appear in the dictionary, and the transform 43 (FermentAll) will turn them into `<!DOCTYPE HTML>`. (No transform would generate `<!doctype HTML>` though.) Therefore Brotli is not only following the herd, so to say. And the static dictionary only improves a very short input---any long-term pattern will be captured regardless of the static dictionary.

Tommah 3y ago

I used this effect in my chess trainer (the link is in my profile). I have a file with 800 compressed chess positions, and I used a lot of tricks to get the file as small as I could. One trick was to invert the color of every piece on White's side of the board. In a typical position outside of the endgame, White's pieces will tend to be on his side of the board, and Black's will tend to be on his side. By inverting the piece colors on one side, I ended up with positions where almost all of the pieces are black, and here and there you'll have a white piece. It's similar to how most of the letters in text are lowercase, and occasionally you'll see an uppercase letter. I think I shrank the file by 5% or so this way.

thrw21 3y ago
Here is how I would it Board is 8x8, which is 6 bits. 4 piece type (rook, queen, knight, bishop. I will represent others (king and pawn) in a special way) is 2 bits. So 8 bits in total per piece I would not use a bit to represent piece color but instead use a seperator to seperate one player's piece from another. Repeating the same position as the last piece can act as a separator since two pieces can't share same square Kings are special that they must exist, so you don't have to specify their type Pawns are special, most likely you will have 1 pawn (of each color) in one column and they can be on rows 2 to 7, or they can be dead or they can be "irregular" which means the pawn moved to another column and there are two pawns in that column now. This data is 3 bits per pawn so 48 bits in total. After that data you can put position of all irregular pawns (additional 6 bits for each irregular pawn). If a pawn promotes, it is represented as a regular piece (and can be considered dead in this 48 bit pawn data) So a chess state is Pawn data (48 bits) Irregular pawns (6 bit each but I can't tell how many there can be at max. 8 maybe?) White king pos (6 bits) White pieces (6 bits for pos + 2 bits for type \* number of pieces) Seperator (6 bits) Black King pos (6 bits) Black pieces (same as white) Seperator (6 bits, represents end of data) I think the worst case scenario is there are 8 promotions which would make it add up 248 bits If number of pawns on board is small, it might worth representing them using their full positions and using a bit to decide which representation you picked
- IanCal 3y ago

postepowanieadm 3y ago

Cool, but just think about how much data (and co2) you may save by skipping vovels!

weinzierl 3y ago

And this is another case where our world is culturally biased to "the West". It doesn't stop at the lowercase letters saving data when compressed and being at an advantage. Take UTF-8, for example, and think about the difference between latin and other scripts. And then there is the whole Pandoras Box of Han Unification...

lioeters 3y ago
For others like me who might be curious about the Han Unification controversy: https://en.wikipedia.org/wiki/Han_unification#Rationale_and_controversy https://en.wikipedia.org/wiki/Han_unification#Rationale_and_... > In 1993, the Japan Electronic Industries Development Association (JEIDA) published a pamphlet titled "未来の文字コード体系に私達は不安をもっています" (We are feeling anxious for the future character encoding system JPNO 20985671), summarizing major criticism against the Han Unification approach adopted by Unicode.
- lifthrasiir 3y ago
  And yet the same criticism is now directed to the Japan government, because Japan is trying to define the unified character set for name characters and that necessarily demands some sort of unifications [1]. [1] https://mainichi.jp/articles/20231231/k00/00m/040/131000c https://mainichi.jp/articles/20231231/k00/00m/040/131000c (Japanese, also paywalled but at least the first portion is visible)

chrismorgan 3y ago

The SVG path shown is broken, showing slightly why this would be a dodgy approach to apply here. Shown are these: <path d="M 1 1 L 1 -1 Z" /> <path d="m 1 1 L 2 0 z" /> But these are inconsistent. These show what I think was intended (a line from (1,1) to (2,0)): <path d="M 1 1 L 2 0 Z" /> <path d="m 1 1 l 1 -1 z" /> When you look at realistic illustrations, “lowercase everything” is fairly obviously not a good approach in path data: sometimes absolute coordinates will be shorter, other times relative coordinates will be shorter; and the difference, raw or compressed, will normally be more than the case difference. No, if you’re trying to compress, you should be taking the holistic approach, adjusting not just case, but the entire path data. For example, one of these two solutions, dropping the superfluous whitespace and removing the line-to opcode which is implied after an opening move-to: <path d="M1 1 2 0z"/> <path d="m1 1 1-1z"/> You can also contemplate whether you actually want to close the path. In this trivial case, it’ll only make a difference if you have exactly one of stroke-linejoin and stroke-linecap set to round.

the_mitsuhiko 3y ago

In most cases uppercase vs lowercase doesn’t matter. Compression work either well. An interesting exception are QR codes. They are substantially smaller if you only use upper case characters because there is a more efficient encoding for them.

tronster 3y ago
I've only dabbled with QR codes but they are interesting. Do you have any links that go into more detail about uppercase making them smaller?
- the_mitsuhiko 3y ago
  https://www.thonky.com/qr-code-tutorial/alphanumeric-mode-encoding https://www.thonky.com/qr-code-tutorial/alphanumeric-mode-en...
- lifthrasiir 3y ago
  In addition to mitsuhiko's link, there is even a dedicated binary-to-text encoding suitable for the alphanumeric mode of QR codes: https://datatracker.ietf.org/doc/html/rfc9285 https://datatracker.ietf.org/doc/html/rfc9285

lifthrasiir 3y ago

This is only true because DEFLATE is very old---it handles duplicates well but ignores everything else---it doesn't even handle simple sequences like `00 01 02 ... ff`. Modern browsers support Brotli as an additional content encoding, and it can actually detect and handle such cases better. Of course such modelling can be done as a preprocessing step as well, PNG notably uses filtering in addition to DEFLATE.

remoquete 3y ago

What I find interesting here is how the effect of using lowercase would add up and reduce carbon production significantly. It reminds me of Gerry McGovern's articles on the use of images and the environmental impact that that has. https://gerrymcgovern.com/books/world-wide-waste/ https://gerrymcgovern.com/books/world-wide-waste/

lupire 3y ago
That page lowered my IQ 10 points.

avgcorrection 3y ago

Thanks to Endtimes for this interesting article. I hope that the Collapse (Tech) Subculture in general is more interested in improving compression algorithms than they are in making less legible content. (But if they think the legibility is fine then sure, do the latter.)

faiD9Eet 3y ago

If you ever happen to study computer science, you may come across a subject called "coding theory". It introduces you to compression as well as many other topics such as error correction (Reed-Solomon, used in RAID5, RAID6 and ECC-RAM), line coding (sometimes you need to flip bits to keep the clock on both sides in sync, no clock-signal for a long time may cause clock loss) and a lot of wonderful but weird stuff. Let us go into detail on compression: There is a representation. US-ASCII uses 8 bits per latin letter, UTF-32 uses 4 bits per latin letter. It is just a temporal representation to the machine -- usually in memory only, it does have the same amount of information, you can save it more efficiently to disk. You would not want to save either format to disk, it is a waste of space. Information content (I hope my translation is correct, scan Wikipedia for details) cannot be compressed. But it can be calculated. The more seldom a letter, the more information its occurence carries. As soon as each letter is not equally frequent (compare space and "q") the information density drops. Calculation is quite simple: Count the occurence of each letter, count the caracters used (if there is no "q" in the text, you got to save one letter and its encoding) and apply some math https://en.wikipedia.org/wiki/Entropy_(information_theory) https://en.wikipedia.org/wiki/Entropy_(information_theory) For some easy examples, think of morse code and Huffman coding -- not every letter needs to be encoded using the same amount of bits. > How much data can lowercase save? # Nothing. Either there is (almost) no information to it in the first place, in that case compression will take care of it for you. There could only be information to it if uppercase letters were equally likely as lowercase letters > How much data can lowercase save? # Why do you even stop at letters? You could build a dictionary of words and compress references to it. The compression efficiancy would only depend on the amount of words, regardless of case and regardless of character set. That is why entropy depends on "symbols" instead of "letters"

em-bee 3y ago

ok, that's my new excuse for why i am writing in all lowercase ;-)

rplnt 3y ago

Not using title case also removes ambiguity in some cases and is generally much easier to read. Not sure how or why is it so popular around here.

Puts 3y ago

On the other hand, lowercase letters tend to be more complex using more bezier anchor points. So if your priority is not bandwidth but work memory you should maybe stick to uppercase? :D

flohofwoe 3y ago
Just use an 8x8 raster font. 8 bytes per character are hard to beat, still perfectly readable, and who needs fancy smooth outlines anyway ;)

alx__ 3y ago

BY THAT LOGIC SWITCHING TO ALL CAPS IS JUST AS EFFICIENT. I PROMISE I AM NOT YELLING.

gvx 3y ago
CONVERTING EVERYTHING TO UPPERCASE SHOULD HAVE THE SAME EFFECT ON COMPRESSION STOP IT EVEN MAKES YOUR WEBSITE LOOK LIKE A TELEGRAM STOP

einpoklum 3y ago

tl;dr: 1. It doesn't save data, it loses data. 2. If you drop the uppercase, you can compress the remaining text farther.

alanfranz 3y ago

TL;DR: dropping non relevant information from a message saves data. Slightly misleading title and article. Nothing about lowercase saves data. Not having two (or more) different letter cases saves data; if you had ALL UPPERCASE DATA the effect would be the same. And, the fewer other chars you use, the best - stay on lowercase or uppercase ascii only, and your compression will be better. Having "A" versus "a" conveys information; if you drop that information, your message can be naturally smaller. What if you actually needed to differentiate jack from Jack? Only using lowercase letter you may be forced to do something like _j_ack, which would probably take _more space_. (information theory discusses those topics, especially the information enthropy concept).

gvx 3y ago
> What if you actually needed to differentiate jack from Jack? Especially if Jack's your uncle and he's on a horse...

mhd 3y ago

Wild shot, but does anyone have data sets on how different languages compress in a similar manner? It would be an interesting mix of letters/phonemes used, word length etc.

pseudocomposer 3y ago

THERE MIGHT BE ANOTHER WAY ABOUT THIS.

skrebbel 3y ago

I use smaller font sizes for the same reason

jacknews 3y ago

uppercase characters seem to be almost entirely superfluous to me, or at least, the benefits do not justify having an entire second alphabet of characters which everyone has to learn, machines have to process, etc.

ahoka 3y ago
They add one bit of information, hardly superfluous.
- jacknews 3y ago
  tEchniCalLy, oNe biT PeR cHaRAcTER, bUT iN reALITy, nOT MuCH mORe aCTuAL iNForMaTIon
tmtvl 3y ago
I thought so too, until I needed to help my uncle Jack off a horse.

deleted 3y ago

[deleted]

tonmoy 3y ago

Wouldn't a perfect compression algorithm know that spaces are followed by Uppercase letter and take that into account?

moritzwarhier 3y ago

I disagree that it's not intuitive (reason comes to mind pretty easily, no?), but it is still a great and interesting thing to write about!

croes 3y ago

If it's about text compression can't you say the same in the favor of upper case?

MrGilbert 3y ago
I'd think so, yes. But at least for me, reading all-caps is really annoying. For me, it feels like yelling. I also find it harder to read. Uppercase letters tend to use more space, physically. So it makes a page feel really crowded if everything is in uppercase.
- Cthulhu_ 3y ago
  But all lowercase gets annoying as well; at least CSS can be used to kind of straighten it?
  - MrGilbert 3y ago
    Not for me, personally. As long as punctuation rules are in place.

ww520 3y ago

Better title - mixed case text takes up more space when compressed.

nsalerno 3y ago

It's not that lowercase saves data. It's that normalization saves data. You can normalize to uppercase and get the same effect. In fact, the argument to use uppercase for normalization is that lowercase does not round trip. You are assuming ASCII content (or UTF-8 content that happens to only be ASCII). Throw Unicode into the mix and you get problems to deal with. Separately, after normalization, to decompress the data you are assuming every sentence must be capitalized and anything that appears to be a title or proper name must be title cased. I imagine that for some pages this isn't 100% so after decompression you will probably make have a letter be uppercase where it was originally not. Thus, your technique must be classified as a lossy algorithm.

KTibow 3y ago
>You can normalize to uppercase and get the same effect. This isn't quite true. Most HTML, JS, and user content can't be uppercased. >Thus, your technique must be classified as a lossy algorithm. I think you might be misunderstanding some parts of this. The article is just suggesting changing the case to sentence case everywhere, whether transferred or displayed. The compression comes from separate lossless algorithms.
- calibas 3y ago
  Converting everything to lowercase for the purposes of saving space when zipping is technically a lossy compression algorithm. It's an algorithm for saving space, and it doesn't recreate a perfect copy of the original data.
tmtvl 3y ago
> In fact, the argument to use uppercase for normalization is that lowercase does not round trip. I believe neither upper or lower case round trips properly, which is why Unicode invented fold case. Whenever this topic comes up I like to refer to one of my favourite talks on the topic: A Million Billion Squiggly Characters by Ricardo Signes: <https://www.youtube.com/watch?v=TmTeXcEixEg https://www.youtube.com/watch?v=TmTeXcEixEg>. Whilst nominally about Unicode handling in Perl, it's general enough that anyone using any language can learn something from it.

buildbuildbuild 3y ago

The “saving X bytes saves Y emitted carbon” trope is a pet peeve of mine. Nobody knows how much carbon a request’s full internet transmission path, storage, and possible 24/7 availability of a server consume. Stacks are too different, equipment widely varies, international internet traffic likely consumes more. I’m typing this using wind energy that I pay extra for. But who knows what my ISP’s equipment and onward are using. If you carbon-optimize your content so much that I have to make multiple requests or paste it into ChatGPT to understand it, you did not reduce your footprint. There’s no direct byte to carbon conversion.

croemer 3y ago
Saying you use wind energy you pay extra for is a pet peeve of mine :) You're not really using wind energy. The electrons don't know who is pushing them. You just increase the share of non-wind that others get, but as long as there are fewer wind subscribers than there is wind energy it doesn't change thing. Premium goes entirely to your energy provider, their profits and marketing department. Happy to be proved wrong in your case if you have a link to your plan.
- IshKebab 3y ago
  This is an oversimplification. I assume you're both talking about REGOs. Electrons are fungible so you're sort of right in that you aren't using the exact electrons that come from a wind turbine. But you're wrong that the extra money just goes straight to profits and has zero effect on green energy generation. Imagine two scenarios: 1. Everyone believes your comment so nobody pays extra for green energy. Therefore the market value of RIGOs is 0. This means green energy generators get paid exactly the same market price per kWh as brown (?) generators. 2. Some people (not necessarily everyone) pay for 100% green energy. This increases the market value of RIGOs so now green suppliers get paid a bit more. Green energy is now worth more than brown energy, which changes the supply/demand curve so you get more green energy overall. The RIGO market is a very elegant market solution to selling the "greenness" of green energy. The fact that it isn't a dumb 1:1 connection that people naively expect doesn't mean it is a scam.

helsinki 3y ago

Isn't the same true for uppercase letters, too? What about binary encoded text? Probably true if you translate the page to ones and zeros, as well.

jawns 3y ago

About 15 years ago, I got frustrated that the National Weather Service issued its alerts in all caps. So I built a service, IntelliCAPS, that attempts to convert all caps to mixed case using both a custom dictionary and user-submitted feedback. It worked pretty well! I could convert most of the NWS bulletins to a more readable format with about 98% accuracy. I bet LLMs could probably do way better these days.

franga2000 3y ago

A very vaguely related thing that might be useful to someone: in QR codes, using ALL-CAPS actually saves you data, making the QR code less "dense" and so easier to read at smaller sizes. The trick is in the "alphanumeric" encoding mode of the QrR standard, which lets you encode 3 character per 11 bit (as opposed to 1 character per 8 bits) if you limit yourself to just numbers, uppercase letters and a few common URL symbols [0]. Besides making the code less dense, you can also add more error correction at the same density, making the code more resilient to wear, damage and reflections. For more QR code trivia, see this excellent demo: https://www.nayuki.io/page/creating-a-qr-code-step-by-step https://www.nayuki.io/page/creating-a-qr-code-step-by-step [0] https://www.thonky.com/qr-code-tutorial/alphanumeric-table https://www.thonky.com/qr-code-tutorial/alphanumeric-table

1vuio0pswjnm7 3y ago

And yet in the past, when space was at an even greater premium, code was written in all uppercase. The title seems to imply that uppercase is worse than lowercase in terms of data usage. Truthfully, it is "same case" that allows for less data usage. The case could be all lower, or all upper.

Narishma 3y ago
The article is arguing against title case, not all uppercase.