Nope. No crossbars on the capital "i." I don't know why anyone opts for a font with this flaw. If you can't tell a capital "i" from a lower-case "L," the font is no good.
You can tell apart a capital "I" from a lowercase "L". The lowercase "L" has a tail on the end. Granted the capital "I" doesn't have a crossbars, but that's usually reserved for serif fonts, not san-serif.
The crossbars on the capital "i" are not serifs. Serif fonts have serifs on the crossbar.
Only sometimes does the lower-case L have a tail. And even if it does, there's no way to know that unless it happens to appear in the same text as a capital "i."
The vast majority of Sans Serif fonts do not use crossbars in the I[1]. But yes, we agree with you that it is important to distinguish the two characters, which is why we have, as Tobias noted.
But in what textual situations do you think it is important to have that clarity when the text does not have both characters? That's the situation where I think it is actually useful. If it is only one or the other, context should be sufficient.
I've attached a paragraph of text using SN Pro[2] that has copious Ls and Is of both cases. Please give it a read, I would genuinely like to know if you feel that our tails are not sufficient (not necessarily perfect, but sufficient).
Thanks for your reply. I’m on a phone at the moment but will check it out later.
In the meantime I’ll say that the ambiguous capital I is indeed rampant in sans fonts, but that’s not a reason to perpetuate it. Why have any ambiguity ever, when every schoolchild knows how to make a capital I? There is no benefit in doing so, and there are drawbacks.
I built an iOS app alone, from the ground up, in Objective-C. This was after I left Apple, where I mostly used C++. I hated Objective-C less than I expected, and the app was functional and reliable.
Then I built an iOS app for a consumer-electronics company alone, from the ground up. I learned Swift and wrote the whole app in it. I liked it a lot. Once I had the language down, I was very productive and able to implement almost any change that management requested in a few days at most.
SwiftUI, however, is a very different story. It's a half-assed, often brain-dead environment that has made building my own application from the ground up PAINFUL. Not only has it taken months to do what should have taken weeks, but SwiftUI and the attempted "reactive" paradigm it's supposedly optimized for are so full of holes that Apple's recommended practices simply don't work. "One source of truth" my ass; SwiftUI and the absurdly incomplete observation framework it relies on make that impossible.
I usually blame myself for just not having read enough, but with SwiftUI my research has far too often concluded with a finding that, "Oh yeah, that doesn't work."
Wasn't there a post on here recently about OSM going to vector-based tiles? I did a quick search and it seems like this is already a widely-offered option. Can anyone jog our memory on what the change is?
The OSM Foundation is building out a stack to generate 'minutely' vector tiles -- meaning the if you edit the map, it'll be reflected in the vector tiles within a few minutes.
Most vector tile sets today generated from OSM are hours behind the current state of the map data in the best case, much more commonly they are months behind.
Not to mention that all the new "small" trucks force you to get a giant four-door cab, which results in a puny bed. I guess the manufacturers have determined that everyone who wants a small truck is a poser.
Meanwhile, TicketMaster/LiveNation/(scalping thing) has demonstrated a textbook consumer-harming monopoly for DECADES with impunity. DECADES.
And politicians and agencies wave hands over "inflation" while the four U.S. meat producers report 90% profit increases (after whining about a "labor shortage"). NINETY PERCENT increases.
Corporate toadies in Congress sit back and pretend that the Fed's feckless interest-rate hikes are all we can do. Disgusting.
"Hallucination" is a widely understood and accepted term in the LLM industry. If you want to change that, replying to my comment doesn't seem to be the most effective place to start. I don't know that it's the best term, but it seems better than re-explaining the issue in detail every time.
"Incorrect output" is broader, encompassing other failure modes. If you ask an LLM to respond in JSON with a list of common foods, and it instead writes a paragraph of text that contains a list of common foods, then that would not qualify as a "hallucination" by my understanding of the accepted definition, but it is still "incorrect output".
"Incorrect output" is still correct to describe the cited behavior. "Hallucination" isn't. If a human behaves the same way when asked a question, we do not say he's hallucinating.
One way to devalue incorrect terminology is to call it out when you see it, and use something accurate instead. That's how people learn.
