Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Posted Sep 1, 2020 15:01 UTC (Tue) by nybble41 (subscriber, #55106)In reply to: Software and hardware obsolescence in the kernel by marcH
Parent article: Software and hardware obsolescence in the kernel
Are you being deliberately obtuse? If I sent you a picture of some digits I wrote left-to-right and some digits I wrote right-to-left, "reading" is not going to be enough to tell them apart. Here, I'll demonstrate:
1234
1234
To simulate physical writing I filled both lines with spaces and then overwrote the spaces with digits. One line was filled in left-to-right, and the other line right-to-left. Please tell me, which one was written left-to-right?
Posted Sep 1, 2020 16:28 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (1 responses)
I thought you were.
Natural languages are all about context, that's why computers need Unicode bidi = a bit more help. This has been well discussed and explained in several other places in this thread (thanks to all those who did) but if not obtuse you are definitely not receptive. Never mind.
Posted Sep 2, 2020 3:51 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link]
Indeed, natural language is all about context. I get the feeling that we are talking about two completely different things and getting frustrated because the other person's answers make no sense in the context of what we each thought the conversation was about. I have been trying to describe how the terms "big-endian" or "little-endian" would apply to the *visual* layout of Arabic numerals *at rest*, for example as symbols written on paper—akin to the individual bytes of an integer field which is part of a larger structure stored in RAM or a file on disk. You seem to be interpreting my statements in the context of data which is *being* written, or read, or typed into a computer—a *serialization* of the data. Or perhaps you are referring to the particular way that the digits would be serialized as Unicode code points in a text file. Naturally my statements would seem like nonsense when taken that way; they were not intended for that context.
For data at rest there is no "time" component; all that matters is the relationships between the addresses or coordinates where each of the digits is stored. For digits written in a single line on paper this corresponds to linear physical coordinates; a digit may appear either to the left or the right of another symbol. In terms of the analogy to the storage of an array of multi-byte integers in computer memory, a system in which the most-significant digit of each number in a list of numbers is physically located on the same side as the first element of the list is "big-endian" and a system in which the least-significant digit is physically closest to the first element of the list is "little-endian". Any given serialization of the data (the process of reading or writing, for example) may employ a different "endianness" independent of the visual layout, and indeed that is the case for Arabic numerals: they are stored or rendered (on paper or other visual medium) as little-endian, but read, written, typed, or spoken aloud with the most significant digit first, in big-endian format.
Anyway, this debate is almost as pointless as the fictional conflict from which we get the terms "big-endian" and "little-endian".[1] I only replied in hopes of conveying that we are arguing *past* each other more than we are actually disagreeing about anything of substance.
[1] https://www.ling.upenn.edu/courses/Spring_2003/ling538/Le...
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel