Re: Hexadecimal never again
Curtis Clark, Caviar, 10kg, FEED Heh, heh... Don't you mean: Caviar, Akg, FEED ;-) Rick
Re: [OT] Hexadecimal never again
From: Rick McGowan [EMAIL PROTECTED] Curtis Clark, Caviar, 10kg, FEED Heh, heh... Don't you mean: Caviar, Akg, FEED And why not this menu: BEEFFACE VINAIGRETTE WINE OF BOURGOGNE A0C (3/4L)
Re: Hexadecimal never again
Philippe. Les messages non sollicités (spams) ne sont pas tolérés. Tout abus sera signalé automatiquement à vos fournisseurs de service. - Original Message - From: Jim Allan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 21, 2003 2:54 AM Subject: Re: Hexadecimal never again Ben Dougall wrote about what is used for hex characters: which'll be whatever characters happen to be used to represent those sections of the character set on their machines: 0x30 - 0x39, 0x41 - 0x46 and 0x61 - 0x66. Not in EBCDIC (and other older character sets) they aren't. There are a lot of mainframe systems still using EBCDIC encodings. And probably some remaining devices using 5-bit or 6-bit encodings... Unicode does not specify encodings out of the UTF-* series. I do think that there may also exist some EBCDIC-based transform for Unicode similar to UTF-8, except that the UTF-8 bytes are remapped to their basic EBCDIC codes (those that do not depend on locale variants, and correspond to ASCII bytes and a few EBCDIC C1 codes), using the holes to remap the missing byte values needed to represent the full range of UTF-8 encoding byte values 0x00 to 0xFB.
Re: Hexadecimal never again
Philippe Verdy verdy_p at wanadoo dot fr wrote: And probably some remaining devices using 5-bit or 6-bit encodings... Unicode does not specify encodings out of the UTF-* series. SCSU: http://www.unicode.org/reports/tr6/ BOCU-1: (just a Technical Note, may not count as a Unicode specification) http://www.unicode.org/notes/tn6/ I do think that there may also exist some EBCDIC-based transform for Unicode similar to UTF-8, except that the UTF-8 bytes are remapped to their basic EBCDIC codes (those that do not depend on locale variants, and correspond to ASCII bytes and a few EBCDIC C1 codes), using the holes to remap the missing byte values needed to represent the full range of UTF-8 encoding byte values 0x00 to 0xFB. UTF-EBCDIC: http://www.unicode.org/reports/tr16/ -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/
Re: Hexadecimal never again
[EMAIL PROTECTED] wrote: Thanks, but not good enough. What guarantee do I have that other Unicode characters will not be added in the future which have the property Hex_Digit? One solution is to join the consortium and be able to vote against such a thing happening! If it is a concern you can still implement your algorithm to allow the hex digits to be separately or externally specifiable, perhaps using John's chart. (With perhaps a slight attendant security risk... ;-) ) From a practical standpoint, I think it is more likely that the base will change rather than the hex characters. After all, digits have been constant for a long time, but the base has changed. Initially it was binary, then it was octal, and now hex arithmetic is common. It seems more likely to me that we might switch to another base (32? 64?) as platforms expand, before we started adding redundant characters to hex arithmetic. Somewhere, someday, some wristwatch-sized, space-deprived display device manufacturer will be complaining that he doesn't have enough room on his device to show the hex codes for the combining sequence of unicode characters missing in his font, and so instead of hex, he wants to use base64 characters, but only if the characters are defined in the standard (Guess I am showing my age to be recalling flipping binary switches...) ;-) All your base are belong to us! tex
RE: Hexadecimal never again
From a practical standpoint, I think it is more likely that the base will change rather than the hex characters. After all, digits have been constant for a long time, but the base has changed. Initially it was binary, then it was octal, and now hex arithmetic is common. No, first it was binary, then it was binary and now its binary. Different human-readable formats have been (and continue to be) used to represent this. It seems more likely to me that we might switch to another base (32? 64?) as platforms expand, before we started adding redundant characters to hex arithmetic. What human-readability advantages (the only reason we use hex) would base 32 or base 64 representations have over hex? They aren't matched by a nice number of bits for most systems; the reason for using hex rather than octal is that 2 hex digits can exactly represent the range of a octet (the most common size of bytes these days) and by extension of any word composed of an integral number of octets. The next base to have that quality is base 256, which would require us to ransack a few different alphabets and then maybe create a few symbols in order for us to represent it.
Re: Hexadecimal never again
On 20/08/2003 06:45, Jon Hanna wrote: ... The next base to have that quality is base 256, which would require us to ransack a few different alphabets and then maybe create a few symbols in order for us to represent it. No, we could just use Ethiopic. Plenty of characters there. We could even put some logic in the system e.g. by use the vowel parts of the glyphs to indicate the lower three bits. I'm sure most people would learn quickly. And if we used Ethiopic letters to define Unicode symbols it might stop some people complaining that Unicode isn't African enough. ;-) -- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
Re: Hexadecimal never again
Jon Hanna wrote: From a practical standpoint, I think it is more likely that the base will change rather than the hex characters. After all, digits have been constant for a long time, but the base has changed. Initially it was binary, then it was octal, and now hex arithmetic is common. No, first it was binary, then it was binary and now its binary. Different human-readable formats have been (and continue to be) used to represent this. It seems more likely to me that we might switch to another base (32? 64?) as platforms expand, before we started adding redundant characters to hex arithmetic. What human-readability advantages (the only reason we use hex) would base 32 or base 64 representations have over hex? They aren't matched by a nice number of bits for most systems; Only density. You are right 256 would be a more convenient base. Fortunately with Unicode ransacking alphabets is easy! Jon I was mostly being tongue in cheek and contrasting that relative to needing new hex digits, a base change was more likely. However, I wasn't saying that a base change is likely. tex the reason for using hex rather than octal is that 2 hex digits can exactly represent the range of a octet (the most common size of bytes these days) and by extension of any word composed of an integral number of octets. The next base to have that quality is base 256, which would require us to ransack a few different alphabets and then maybe create a few symbols in order for us to represent it. -- - Tex Texin cell: +1 781 789 1898 mailto:[EMAIL PROTECTED] Xen Master http://www.i18nGuy.com XenCrafthttp://www.XenCraft.com Making e-Business Work Around the World -
RE: Hexadecimal never again
Jon I was mostly being tongue in cheek and contrasting that relative to needing new hex digits, a base change was more likely. However, I wasn't saying that a base change is likely. And I was being tongue in cheek (and ignorant of Ethiopian script) in suggesting the use of base 256. However we both had serious points and my serious point disagrees with yours. Hexadecimal is used for good reasons; and while I'm not convinced about Jill's point I'm not convinced otherwise either. What do hackers with non Latin-based languages use for hex anyway?
Re: RE: Hexadecimal never again
What do hackers with non Latin-based languages use for hex anyway? They use 0-9, A-F, and a-f. Hex is used mostly by programmers, mostly for computing, and mostly in programming languages that have the digits and Latin letters built-in, and that's what compilers expect to see. Hex doesn't have an independent existence out in non-computing culture for, e.g., signs in the market place or monetary values. Rick
Re: Hexadecimal never again
On Wednesday, August 20, 2003, at 07:03 pm, Rick McGowan wrote: What do hackers with non Latin-based languages use for hex anyway? They use 0-9, A-F, and a-f. which'll be whatever characters happen to be used to represent those sections of the character set on their machines: 0x30 - 0x39, 0x41 - 0x46 and 0x61 - 0x66. Hex is used mostly by programmers, mostly for computing, and mostly in programming languages that have the digits and Latin letters built-in, and that's what compilers expect to see. Hex doesn't have an independent existence out in non-computing culture for, e.g., signs in the market place or monetary values. Rick
Re: Hexadecimal never again
Ben Dougall wrote about what is used for hex characters: which'll be whatever characters happen to be used to represent those sections of the character set on their machines: 0x30 - 0x39, 0x41 - 0x46 and 0x61 - 0x66. Not in EBCDIC (and other older character sets) they aren't. There are a lot of mainframe systems still using EBCDIC encodings. Jim Allan
Re: Hexadecimal never again
on 2003-08-20 11:03 Rick McGowan wrote: Hex doesn't have an independent existence out in non-computing culture for, e.g., signs in the market place or monetary values. Caviar, 10kg, FEED -- Curtis Clark http://www.csupomona.edu/~jcclark/ Mockingbird Font Works http://www.mockfont.com/
