Talk:Endianness

"Bytesex" listed at Redirects for discussion

An editor has identified a potential problem with the redirect Bytesex and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 November 25#Bytesex until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Veverve (talk) 15:39, 25 November 2022 (UTC)

It was relisted several times, ending up at Wikipedia:Redirects for discussion/Log/2022 December 9#Bytesex, which indicates it was closed as "Keep". Guy Harris (talk) 22:49, 7 January 2023 (UTC)

Bytesex?

Does the term "byte sex" deserve to be in the first sentence? It has about 60,000 bing hits, and most of the first page isn't even discussing it in the endian sense. I've never heard the term before. 2A00:23C5:321B:BB01:241C:9873:FD0F:C101 (talk) 21:26, 7 January 2023 (UTC)

As above, it is in active discussion. Yes, I suspect it shouldn't be in the first sentence, if at all. Gah4 (talk) 22:24, 7 January 2023 (UTC)

The removal of the "bytesex" redirect is no longer under active discussion. It was relisted several times, ending up at Wikipedia:Redirects for discussion/Log/2022 December 9#Bytesex, which indicates it was closed as "Keep". Guy Harris (talk) 22:48, 7 January 2023 (UTC)

Just because the term 'byte sex' can redirect here doesn't mean this article should discuss it in the first paragraph. This is a bit of obscure historical jargon which is no longer in current use. At best it belongs in a footnote. –jacobolus (t) 18:18, 9 January 2023 (UTC)

For all practical purposes the term is extinct, most younger practitioners will not recognize it, linux.bytesex.org notwithstanding, and we are WP:NOTDICT, so the lead is a bad place for this synonym (I have no objections against the redirect, and, most likely, some anchor in the text). I agree that even now the term is WP:UNDUE that high in the article, unless the section is expanded to cover much more widespread terms: "network byte order" is currently relegated to mid-article, "host order" is even lower and has no coherent definition whatsoever. Dimawik (talk) 05:28, 11 January 2023 (UTC)

No objection for a month to the removal from the lead. Per Guy Harris I am changing it to an anchor so that the redirect will stay operational. Dimawik (talk) 08:43, 23 February 2023 (UTC)

Bit endianness

Regarding the removal of "bit endianness": the term is easy to find in the literature (e.g., [1], a book by Springer). The deleted text about the error-correcting codes was also factually correct (I expect it to be hard to find a source for the latter, though). I happen to like the new text more, and think that the error correction minutiae are out of scope here altogether, but, probably, it is worth adding back the "bit endianness" term somewhere in the text (not in the section header)? Pinging @Kvng: Dimawik (talk) 03:58, 25 April 2023 (UTC)

Bit endianness is less of a problem, but still exists. Some hardware has the ability to address bytes. Even when it doesn't, hardware descriptions don't always number bits the same way. Yes it happens at a lower level, but for those working at that level, it is important. Gah4 (talk) 05:06, 25 April 2023 (UTC)

Yes, anyone who tried to code bit fields in a portable way knows the problem well. The issue here is a terminological one: should we mention the term "bit endianness" or be happy with a more popular "bit order"? Dimawik (talk) 07:25, 25 April 2023 (UTC)

Thanks for the comments. We do have a Bit endianness redirect (which I broke) so I should restore that (with a ref). There is Dimawik's question about preferred terminology here. Any opinions?

There is discussion of bit order (and byte order) at Cyclic redundancy check so I think it would be valuable to restore that tie in. ~Kvng (talk) 13:49, 25 April 2023 (UTC)

Potentially problematic edits

Thumperward has recently made some bold edits. Some of these don't appear to be well justified. I have not reverted any of this yet.

1. cite quotes are almost always pointless. I assume they're helpful to readers who don't have ready access to the cited source. What's the harm?
2. one day people will get over this completely wrong-headed notion that any time a term might ever possibly refer to the current article, it needs to be bolded. Some of the boldface is per MOS:BOLDSYN and should be restored.
3. ascii art is a bad way of representing anything, and the text should be clear enough already, likewise. text does a perfectly good job here. These are tables, not ASCII art. It is very often useful to have both visual and written descriptions as different presentations work better for different readers.
4. just link this. I don't see a problem summarizing a closely-related topic here.
5. more jargon file crap. A quick search finds NUXI problem in fairly widespread use. This may need to be tagged for a better citation. I don't think it should be removed. This bold edit also draws into question some of the work done a little earlier in ...remove "byte-sex" nonsense from ESR's jargon file, which is nothing more than ESR's own list of personal neologisms.
6. cite needed, not code. So let's find a citation. Meanwhile, let's keep the code as provides some level of verifiability to anyone who knows the language in question. WP:DEMOLISH.

~Kvng (talk) 15:37, 8 December 2023 (UTC)

Let's go through these in order.

• The "harm" is massing up both wikitext and article text with large paragraphs which by definition simply repeat what is in the article. A citation should point the reader to the relevant source. Unless it is lost to time, including the actual content here is overkill. There may occasionally be grounds for this but that should be the exception.
• BOLDSYN refers to the article's lead, and very very very very very very obviously does not justify bolding the phrase "big" 75% of the way through this article.
• Any table content not intelligible with a screen reader is harmful, and the meaning of these tables can (as demonstrated) be perfectly encapsulated in text form without causing readability issues to unsighted readers.
• Disambiguation belongs in the article headers. Occasionally a similar but distinct topic might deserve some coverage in the body, but this was overkill for what is basically a dissimilar concept that happens to occasionally be known by a similar name.
• If there are good, reliable sources for NUXI then so be it. Removing content which is sourced solely to Eric Raymond's Jargon File, which is pretty much the definition of an unreliable source (it is a self-published work which pretends to be authoritative, and has legions of examples of pushing ESR's own opinions) should not be controversial.
• Using uncited material to verify a fact is the very definition of original research. The vast majority of readers are not coders, and using code examples is therefore one of the worst ways to provide evidence for a given statement.
• Lastly, WP:DEMOLISH refers to the notion that articles should not be subject to the same rigorous standards as established articles during their creation. This article is fully 21 years old, making it more than mature enough to finally receive some serious editing (which by necessity will involve removing pieces of it).

Feel free to attempt to suggest alternative solutions to the issues highlighted. I do appreciate that they weren't reverted. Chris Cunningham (user:thumperward) (talk) 04:25, 10 December 2023 (UTC)

• The harm you see and the benefit I (and presumably the editor that added these quotes) see need to be balanced somehow.
• There is a mix of good and bad in your edits. That's why they have not been reverted. Do you agree we should restore bold to redirected terms?
• OK so there's potential harm and benefit here too. These are standard wiki tables. I was not aware there was a screen reader issue with these.
• You think it is overkill. I think a bare link is overly terse. Maybe we can find some middle ground.
• Yes, I'm happy to find a source for NUXI but I'm currently busy arguing with you. It's a common pattern on Wikipedia and not much fun for me.

~Kvng (talk) 16:09, 10 December 2023 (UTC)

The mantra that redirected terms must be bolded has metastasised into something it was never meant to be. If a term is unique and commonplace, then it should be bolded in the lead. It is categorically not necessary to treat article subsections as if they were mini-leads and to apply this all over again. And the subject of whether or not various minor synonyms deserved placement in the lead was already settled in previous discussion. So if a random search term happens to have a redirect to an anchor in an article, there is no mandate to bold it. Never was.

I am aware that the subject might benefit from a graphical demonstration, but it is very important to be sensitive on this front. Readers might not be using desktop browsers. They might be using screen readers. The article might be in audiobook format. Or any number of other issues. This is why we try to avoid presenting material in images or tables if there are alternative options. This article previously swung too far in the opposite direction. That's been holding it back.

With regards to NUXI, this (not a reliable source, but still) does claim it predates Raymond. Though to be quite honest, any source from that period would almost certainly be more valuable for general discussion of this article's content than specifically for one synonym. Chris Cunningham (user:thumperward) (talk) 03:46, 11 December 2023 (UTC)

So where do we stand? To me it looks like we're at 0 for 6 toward resolution of these issues. Hopefully we'll get some comments from other editors to help us through this. ~Kvng (talk) 14:55, 11 December 2023 (UTC)

Wow! I just discovered what a major mess the article, or at least its intro, has become. A lot of rework or restoration is needed. Here I'll limit my comments to the items raised at the top of this section:

• cite quotes are almost always pointless. The quote deletion is not a major issue, but I think this short quote should be restored. If the reader isn't interested, she can ignore it, otherwise it is a useful presentation that shows the nature of the invention of the term, often saving the annoyance of dealing with the whole of the source.
• one day people will get over this completely wrong-headed notion that any time a term might ever possibly refer to the current article, it needs to be bolded. The alternate names bolding, as per MOS, is very important. Here, it's essential that big-endian and little-endian be bold, especially since these are the usual terms, unlike the article title, which is less common. "BE" and "LE" should not be bold: that's very poor overbolding. (The other changes seem okay.)
• ascii art is a bad way of representing anything, and the text should be clear enough already: This section needs a diagram as for many readers it quickly makes clear the confused nature of the mixed- or middle-endian form; for those readers, prose is a barrier to understanding. For consistency, if nothing else, an SVG like half of the (to be restored) File:32bit-Endianess.svg would be desirable, but unless such appears, the table-based diagram is needed here. However, the table-based form should have the title/caption "Storage of a 32-bit integer, 0x0A0B0C0D, on a PDP-11" removed from the table and instead be given as a prose introduction preceding the diagram provided by the table.
  • likewise. text does a perfectly good job here. Text can do an adequate job with this, and I think removal of these diagrams is warranted. This whole subject is peripheral to endianness, as it has only to do with treating multiple characters within an integer (or at least non-string) data type. I believe this section doesn't deserve significant space. The text that was substituted does not yet clearly explain the nature of the relationship of text in integers vs native strings.
• just link this. No, the link is inadequate because the linked article doesn't cover the described aspects nearly as well as the text that was removed, nor does it try to make the relationship to endianness apparent. The "article" Bit order is just a redirect to Bit numbering, which is almost entirely concerned with labeling of bits (with numbers) rather than physical ordering of bits as in serial transmission.
• more jargon file crap. I believe the NUXI Problem deserves mention, and the pre-change text seems appropriate.
• cite needed, not code. A citation is needed, but at least until present I think the code is of interest and perhaps useful to the reader.

--R. S. Shaw (talk) 00:47, 13 December 2023 (UTC)

Amusingly I've just had a comment posted on my own talk saying that the reorg was overdue, so obviously this is polarising. Nevertheless, the notion that it's more of a mess now than previously just doesn't stand up to any scrutiny.

• That quote adds practically no value. Not only does it basically just reiterate what was just said in the text, it is irrelevant to this subject. It does not matter in the slightest what "big-endian" happened to mean in Gulliver's Travels because the term only transferred over as a homage and not due to any actual similarities in the notions being discussed.
• I'm not opposed to a single re-bolding of the specific terms "big-endian" and "little-endian" in the introduction sentence if it satisfies all parties.
• I'd be happy for this particular niche matter to be removed entirely, but felt that retaining a brief summary sans overbearing tables was a reasonable compromise for now.
• When dealing with bits rather than bytes, this subject is simplified to "one end or the other" and is deeply banal. The only reason it warrants a full article to itself at byte-level is due to the complications that introduces.
• Again, happy for it to be re-added if sourced to something less notoriously unreliable and prone to making up its own terms.
• I will categorically state that there is no overlap between the set of people who can read Verilog and the set of people who are going to gain actual value from reading an article on endianness. Code examples are massively overused on Wikipedia and frequently pulled directly from the heads of their authors. We don't accept that sort of content for other topics. This is implementational trivia and its only hope of remaining here at all is with a secondary source.

Chris Cunningham (user:thumperward) (talk) 13:09, 13 December 2023 (UTC)

Reading that talk page posting, I wouldn't put Barometz in your column on the issues we're discussing here. Barometz does appear to oppose your removal at least one of the diagrams. R. S. Shaw seems to be a bit disparaging but I have not voiced complaints about reorganization. Your edits here are a mixed bag so there are certainly things to appreciate about them. ~Kvng (talk) 14:17, 14 December 2023 (UTC)

And as I've replied there, if restoring one of the images stops people complaining about the lack of diagrams without having to re-add ASCII art, so be it. It's not a matter of a binary yes/no on these changes: it's a case of where we go from here. Chris Cunningham (user:thumperward) (talk) 18:20, 15 December 2023 (UTC)

It would be nice if we could come to a consensus rather than starting an WP:RFC and muscling through it. You seemed pretty immovable on 11 December. Are you coming around at all? ~Kvng (talk) 23:39, 15 December 2023 (UTC)

You raised a half-dozen points, all of which were individually trivial. This doesn't need an RFC. It needs for you to discuss said points individually instead of raising them as "should we revert all this user's edits". Chris Cunningham (user:thumperward) (talk) 03:44, 18 December 2023 (UTC)

You and I did one round of discussion and it doesn't look like either of us moved. R. S. Shaw and Barometz joined the discussion, didn't appear to be too impressed with your edits and suggested some potential compromises and you begrudgingly offered that we could restore a diagram a small amount of boldface. It doesn't feel like we're headed toward consensus with the current participants. What other ideas do you have besides an RFC? ~Kvng (talk) 04:14, 19 December 2023 (UTC)

What we normally do on Wikipedia is find common ground and then edit the article accordingly, which is much more productive than endlessly talking around things. To that effect I've made the two requested changes that there is consensus on (bolding BE and LE in the lead, and re-adding a diagram). Now, will you discuss your remaining concerns? Chris Cunningham (user:thumperward) (talk) 15:35, 19 December 2023 (UTC)

I appreciate the gesture, but don't appreciate this edit that followed. Will you revert that so we don't have to deal with moving targets in discussion? ~Kvng (talk) 20:17, 19 December 2023 (UTC)

Done, but only on the understanding that this is a matter of diplomacy. That this article is chock-full of unsourced, tangential distractions which are not actually key to the subject matter is still a core concern, and I expect that whole section to be substantially edited in future. Chris Cunningham (user:thumperward) (talk) 00:34, 20 December 2023 (UTC)

Thanks and sorry for the delay. Let's try point #3 again. I say text and tables/diagrams together are good to support different comprehension styles and provide visual anchors for readers. You say only text is required and tables/diagrams create and WP:ACCESSIBILITY issue. Am I missing anything?

What specifically is the accessibility issue you're concerned about? I have reviewed WP:ACCESSIBILITY and see some concerns about large tables, font size, coloring; I don't see that any of that applies here. There is WP:DTAB which explains how to make tables accessible. I believe the tables you removed already follow that and if not, we should be able to correct them without removing them. ~Kvng (talk) 16:37, 23 December 2023 (UTC)

"Avoid using tables for visual positioning of non-tabular content". Chris Cunningham (user:thumperward) (talk) 03:44, 11 January 2024 (UTC)

I'm pretty sure that's referring to layout hacks like using a table with invisible cell boundaries to adjust text position. ~Kvng (talk) 12:58, 11 January 2024 (UTC)

Nothing in the wording of the guideline suggests this. In the absence of such qualifiers, the most obvious solution would be to follow what is actually written. There is no contradictory guideline suggesting that using ASCII markup for diagrams is acceptable. Chris Cunningham (user:thumperward) (talk) 23:21, 30 January 2024 (UTC)

The section you link to is titled Layout tables and starts with Avoid using tables for visual positioning of non-tabular content. I don't think you have much to stand on. As for your claim that we can't know what is intended, I think a discussion at Wikipedia talk:Manual of Style/Accessibility would clarify things pretty quickly. ~Kvng (talk) 00:33, 31 January 2024 (UTC)

Then... start one? MOS:LTAB only mentions data tables and layout tables (and has lots of strong wording discouraging the latter) for a reason: using tables to draw diagrams is not acceptable. See also the omission of this use in MOS:TABLES. I'm entirely confident that "don't use tables for drawing squares" is the consensus already; the burden of proof there is for the person who has no more to go on than gainsaying. Chris Cunningham (user:thumperward) (talk) 15:33, 1 February 2024 (UTC)

Alright, done. ETA: I'm away from computers for the next few days and may not be able to check in or respond to anything until next week. ~Kvng (talk) 15:59, 1 February 2024 (UTC)

Wikipedia_talk:Manual_of_Style/Accessibility#When_are_tables_an_accessibility_problem? appears to have reached consensus. I was able to easily revert one of these edits. The other is more complicated and I'm hoping Thumperward can help restore the tables here. ~Kvng (talk) 17:35, 17 February 2024 (UTC)

That this has consensus is an egregious lie. This has worsened this article for the sake of an editor considering himself to have won a dispute. I've utterly no interest in cooporating with the furtherance of that petty little war, and will ensure that eventually this is rolled back. Chris Cunningham (user:thumperward) (talk) 23:34, 17 February 2024 (UTC)

Editors in the discussion have been willing to accept the version I presented with column and row headings. No one has expressed support for the original version without headings that was re-introduced. isaacl (talk) 00:17, 18 February 2024 (UTC)

@Isaacl, A simple revert is not the intended final state but it is the place to start and I didn't see any objections when I proposed this approach. ~Kvng (talk) 01:15, 18 February 2024 (UTC)

I've objected several times. isaacl (talk) 01:22, 18 February 2024 (UTC)

@Isaacl, how would you like to proceed? ~Kvng (talk) 01:28, 18 February 2024 (UTC)

I've added the column and row headings, as per the discussion on the manual of style talk page. isaacl (talk) 01:30, 18 February 2024 (UTC)