Re: Hexadecimal digits

[Otto Stolz]

Hello Luke-Jr,

you’ve been asking:

Are there any hexadecimal digits in Unicode?


Simply use the digits “0” through “9”, and the
letters “A” through “F”; cf.
.



For example, perhaps the digits used for John W. Nystrom's Tonal System?


I had to consult:
,
to learn about this system.

Apparently, Nystrom's Digits for “9” through “F” are
not encoded in Unicode,
cf. .

I do not know, how successful Nystrom’s proposal has been,
and I cannot assess whether his digits deserve to be
encoded, in Unicode. If you think, these digits need
to be encoded, you are free to propose that; for the
procedure required,
cf. .

In any case, it would be problematic to unify Nystrom’s “9”
through “F” cannot be unified with Unicode “9”, “A” through
“F” (treating them as a glyph-variation, and font-selection,
issue), for two reasons:
• Unicode “A” through “F” are also used for spelling ordinary
  words; this would not be feasable with Nystrom’s glyphs;
• Nystrom’s digit “A” looks exactly as the common, decimal
  digit “9”, which would render any special Nystrom font
  rather misleading to the reader.


Best wishes,
  Otto Stolz

Re: Hexadecimal digits

[Doug Ewell]

Otto Stolz  wrote:


I do not know, how successful Nystroms proposal has been,


The Wikipedia page says, "This first hexadecimal system, proposed in the 
19th century, had no success at all."


--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages @ http://is.gd/2kf0s ­

Re: Hexadecimal digits

[Luke-Jr]

On Friday 04 June 2010 06:32:06 am you wrote:
> Simply use the digits “0” through “9”, and the
> letters “A” through “F”; cf.
> .

This makes it more complex to differentiate between numbers and 
letters/units/etc.

> I do not know, how successful Nystrom’s proposal has been,
> and I cannot assess whether his digits deserve to be
> encoded, in Unicode. If you think, these digits need
> to be encoded, you are free to propose that; for the
> procedure required,
> cf. .

As far as I know, I am currently the only human alive with the intention of 
adopting the Tonal system. I also plan to teach it as the primary numerical 
system in my home-school curriculum (mainly for my own children, of which I 
thus far have four), and vaguely promote it when I have time. While I might be 
able to use the private areas for home, not having standard characters will 
likely interfere with any widescale adoption or mainlining patches (for 
example, adding Tonal units to common UNIX tools such as 'ls'). In this way, I 
see the question of whether they "deserve" to be encoded as a chicken-and-egg 
problem: they will never "deserve" encoding as long as they cannot be encoded.

Re: Hexadecimal digits

[Otto Stolz]

Hello Luke-Jr,

please keep the discussion on the list.

I had written:

Simply use the digits “0” through “9”, and the
letters “A” through “F”;


You have written:

This makes it more complex to differentiate between numbers and
letters/units/etc.


In any case, you have to know the base of every number
you are going to parse. This stems from the fact that
the same digits are used for all number systems. Note
that Unicode is a character-encoding standard, hence
cannot do anything about this sort of ambiguity.

Best wishes,
  Otto Stolz

Re: Hexadecimal digits

[Luke-Jr]

On Friday 04 June 2010 08:51:05 am Otto Stolz wrote:
> In any case, you have to know the base of every number
> you are going to parse. This stems from the fact that
> the same digits are used for all number systems.

But you first need to know if it is a number or a word.
Can you drink cafe coffee?
Am I asking about coffee from a cafe (place), or asking if you can
 handle 51,996 (decimal) cups of coffee?
May I have a fish?
One fish or ten?
Just two examples I can think of offhand that make a-f insufficient.

Re: Hexadecimal digits

[Mark E. Shoulson]

On 06/04/2010 09:58 AM, Luke-Jr wrote:

On Friday 04 June 2010 08:51:05 am Otto Stolz wrote:

In any case, you have to know the base of every number
you are going to parse. This stems from the fact that
the same digits are used for all number systems.


But you first need to know if it is a number or a word.
Can you drink cafe coffee?
Am I asking about coffee from a cafe (place), or asking if you can
 handle 51,996 (decimal) cups of coffee?
May I have a fish?
One fish or ten?
Just two examples I can think of offhand that make a-f insufficient.


Suggestions to encode A-F as digits and not numbers crop up here every 
few years.  This is the first I've heard of the tonal system, but the 
suggestion of encoding the hex digits as distinct characters I have 
definitely seen on this list before.  It doesn't seem any more likely 
now than it did then.


~mark

RE: Hexadecimal digits

[John Dlugosz]

Those things really happen when writing in assembly language.  I recall having 
to write "numbers" that only begin with a decimal digit, so "a fish" is a word, 
and "0ah fish" is a number.  In C and C++, "a" is a word and "0xa" is a number.

> -Original Message-
> From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On
> Behalf Of Luke-Jr
> Sent: Friday, June 04, 2010 8:59 AM
> To: Otto Stolz
> Cc: unicode@unicode.org
> Subject: Re: Hexadecimal digits
> 
> On Friday 04 June 2010 08:51:05 am Otto Stolz wrote:
> > In any case, you have to know the base of every number
> > you are going to parse. This stems from the fact that
> > the same digits are used for all number systems.
> 
> But you first need to know if it is a number or a word.
> Can you drink cafe coffee?
>   Am I asking about coffee from a cafe (place), or asking if you
> can
>handle 51,996 (decimal) cups of coffee?
> May I have a fish?
>   One fish or ten?
> Just two examples I can think of offhand that make a-f insufficient.


TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) 
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, 
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and 
subscription company, and TradeStation Europe Limited, a United Kingdom, 
FSA-authorized introducing brokerage firm. None of these companies provides 
trading or investment advice, recommendations or endorsements of any kind. The 
information transmitted is intended only for the person or entity to which it 
is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.

Re: Hexadecimal digits

[Kenneth Whistler]

> On Friday 04 June 2010 08:51:05 am Otto Stolz wrote:
> > In any case, you have to know the base of every number
> > you are going to parse. This stems from the fact that
> > the same digits are used for all number systems.

Luke-Jr replied:

> 
> But you first need to know if it is a number or a word.

And that is a problem for the character encoding because...?

> Can you drink cafe coffee?
>   Am I asking about coffee from a cafe (place), or asking if you can
>handle 51,996 (decimal) cups of coffee?

For that matter can you drink five cups of coffee?

Is that five = 5(base-10) or is it five(base-36) = 724,298(base-10) cups?

> May I have a fish?
>   One fish or ten?

And that is why prefixes such as "0x" were invented, so as
to disambiguate explicitly in contexts where syntax or
explicit type do not. Ordinary language usage wouldn't ordinarily 
countenance this kind of ambiguity anyway -- it is a completely
artificial example.

> Just two examples I can think of offhand that make a-f insufficient.

ASCII a-f to express hexadecimal digits are standard in every
significant programming language syntax, as well as for numeric
character references that are used ubiquitously now to refer to
characters in HTML and XML. So I'd say they are probably
sufficient for some millions of programmers and some hundreds of
millions of web users.

YMMD, of course.

--Ken

Re: Hexadecimal digits

[Luke-Jr]

On Friday 04 June 2010 09:22:51 am Mark E. Shoulson wrote:
> Suggestions to encode A-F as digits and not numbers crop up here every
> few years.  This is the first I've heard of the tonal system, but the
> suggestion of encoding the hex digits as distinct characters I have
> definitely seen on this list before.  It doesn't seem any more likely
> now than it did then.

How should one deal with the distinct appearances, then? Hexadecimal/tonal 
will never be popularised as long as it can be confused with letters...

Re: Hexadecimal digits

[Luke-Jr]

On Friday 04 June 2010 11:55:55 am John Dlugosz wrote:
> Those things really happen when writing in assembly language.  I recall
>  having to write "numbers" that only begin with a decimal digit, so "a
>  fish" is a word, and "0ah fish" is a number.  In C and C++, "a" is a word
>  and "0xa" is a number.

But I'm not talking about programming languages, just common everyday uses by 
people who have it as their primary (not secondary) system of numbers.

Re: Hexadecimal digits

[Luke-Jr]

On Friday 04 June 2010 12:43:33 pm Kenneth Whistler wrote:
> And that is why prefixes such as "0x" were invented, so as
> to disambiguate explicitly in contexts where syntax or
> explicit type do not. Ordinary language usage wouldn't ordinarily
> countenance this kind of ambiguity anyway -- it is a completely
> artificial example.

The whole point is to get the tonal/hexadecimal number system adopted for 
ordinary everyday use. This kind of ambiguity is an obstacle.

> > Just two examples I can think of offhand that make a-f insufficient.
> 
> ASCII a-f to express hexadecimal digits are standard in every
> significant programming language syntax, as well as for numeric
> character references that are used ubiquitously now to refer to
> characters in HTML and XML. So I'd say they are probably
> sufficient for some millions of programmers and some hundreds of
> millions of web users.

But again, I'm not talking about programming. My four year old can grasp tonal 
just as well as she could decimal had I been teaching that. Now if I were 
using the a-f notation, she would be (reasonably) confused as to why *some* 
numbers are unique, but *other* numbers are also letters.

Re: Hexadecimal digits

[Kenneth Whistler]

> But again, I'm not talking about programming. My four year old can grasp 
> tonal 
> just as well as she could decimal had I been teaching that. Now if I were 
> using the a-f notation, she would be (reasonably) confused as to why *some* 
> numbers are unique, but *other* numbers are also letters.

Well, then, she might be confuzd when her frndz start 2 txt her 2!

--Ken

RE: Hexadecimal digits

[John Dlugosz]

"The green can..." (Adjective Noun?)
"The green can be watered after it has been cut." (Green is noun, Can is aux 
verb!)

It's not limited to numbers.

> -Original Message-
> From: Luke-Jr [mailto:l...@dashjr.org]
> Sent: Friday, June 04, 2010 12:47 PM
> To: unicode@unicode.org
> Cc: John Dlugosz; Otto Stolz
> Subject: Re: Hexadecimal digits
> 
> On Friday 04 June 2010 11:55:55 am John Dlugosz wrote:
> > Those things really happen when writing in assembly language.  I
> recall
> >  having to write "numbers" that only begin with a decimal digit, so
> "a
> >  fish" is a word, and "0ah fish" is a number.  In C and C++, "a" is a
> word
> >  and "0xa" is a number.
> 
> But I'm not talking about programming languages, just common everyday
> uses by
> people who have it as their primary (not secondary) system of numbers.

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) 
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, 
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and 
subscription company, and TradeStation Europe Limited, a United Kingdom, 
FSA-authorized introducing brokerage firm. None of these companies provides 
trading or investment advice, recommendations or endorsements of any kind. The 
information transmitted is intended only for the person or entity to which it 
is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.

Re: Hexadecimal digits

[Rick McGowan]

Luke-jr wrote,


Hexadecimal/tonal will never be popularised as long as it can be confused with 
letters...
   


and


But I'm not talking about programming languages, just common everyday uses by 
people who have it as their primary (not secondary) system of numbers.


Hexadecimal already is popular with programmers in programming 
situations. It's useful enough for dealing with computers that 
programmers have adopted it despite the "shortcoming" of being 
potentially confusable. People use complicated and potentially confusing 
systems all the time because to not use them would mean that (a) they 
can no longer communicate with everyone else and/or (b) they would 
represent an unnecessary discontinuity with all past usage, and thus 
people would lose touch with their history and literature. In the 
absence of cultural disasters, that doesn't typically happen on short 
time scales. (Look, for example, at the Japanese writing system.)


Hexadecimal/tonal will never be popular with ordinary humans for 
ordinary counting in social situations because people don't have ten 
fingers and nobody uses hexadecimal for ordinary counting, nor has any 
significant population ever done so, as far as I know.


Just out of curiosity, why do you think it's useful or important for 
people to use hexadecimal as their primary system of counting? What 
advantages would it confer?


(As usual on this list, this reflects purely my personal opinion.)

Rick

Re: Hexadecimal digits

[Luke-Jr]

Unicode has Roman numerals and bar counting (base 0); why should base 16 be 
denied unique characters?

>From another perspective, the English-language Arabic-numeral world came up 
with ASCII. Unicode was created to unlimit the character set to include  
coverage of other languages' characters. Why shouldn't a variety of numeric 
systems also be supported?

Re: Hexadecimal digits

[Michael Everson]

On 4 Jun 2010, at 20:39, Luke-Jr wrote:

> Unicode has Roman numerals and bar counting (base 0); why should base 16 be 
> denied unique characters?

It isn't. 0123456789ABCDEF. I have calculators which do sums with this notation.

> Unicode has Roman numerals and bar counting (base 0); why should base 16 be 
> denied unique characters?

Because we don't have enough fingers.

> Unicode has Roman numerals and bar counting (base 0); why should base 16 be 
> denied unique characters?

Because both begins with a B.

> From another perspective, the English-language Arabic-numeral world came up 
> with ASCII. Unicode was created to unlimit the character set to include 
> coverage of other languages' characters. Why shouldn't a variety of numeric 
> systems also be supported?

A wide variety of numeric systems ***IS*** supported in the UCS. You can do 
sums in Sumerian and Egyptian and Linear B and Phoenician and lots of other 
numeric systems. 

Michael Everson * http://www.evertype.com/

RE: Hexadecimal digits

[Jonathan Rosenne]

The classic:

"Time flies like an arrow"

http://en.wikipedia.org/wiki/Natural_language_processing

Jony

> -Original Message-
> From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On
> Behalf Of John Dlugosz
> Sent: Friday, June 04, 2010 9:18 PM
> To: Luke-Jr; unicode@unicode.org
> Cc: Otto Stolz
> Subject: RE: Hexadecimal digits
> 
> "The green can..." (Adjective Noun?)
> "The green can be watered after it has been cut." (Green is noun, Can
> is aux verb!)
> 
> It's not limited to numbers.
> 
> > -Original Message-
> > From: Luke-Jr [mailto:l...@dashjr.org]
> > Sent: Friday, June 04, 2010 12:47 PM
> > To: unicode@unicode.org
> > Cc: John Dlugosz; Otto Stolz
> > Subject: Re: Hexadecimal digits
> >
> > On Friday 04 June 2010 11:55:55 am John Dlugosz wrote:
> > > Those things really happen when writing in assembly language.  I
> > recall
> > >  having to write "numbers" that only begin with a decimal digit, so
> > "a
> > >  fish" is a word, and "0ah fish" is a number.  In C and C++, "a" is
> a
> > word
> > >  and "0xa" is a number.
> >
> > But I'm not talking about programming languages, just common everyday
> > uses by
> > people who have it as their primary (not secondary) system of
> numbers.
> 
> TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ
> GS: TRAD) of three operating subsidiaries, TradeStation Securities,
> Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies,
> Inc., a trading software and subscription company, and TradeStation
> Europe Limited, a United Kingdom, FSA-authorized introducing brokerage
> firm. None of these companies provides trading or investment advice,
> recommendations or endorsements of any kind. The information
> transmitted is intended only for the person or entity to which it is
> addressed and may contain confidential and/or privileged material. Any
> review, retransmission, dissemination or other use of, or taking of any
> action in reliance upon, this information by persons or entities other
> than the intended recipient is prohibited. If you received this in
> error, please contact the sender and delete the material from any
> computer.
> 

Re: Hexadecimal digits

[Luke-Jr]

On Friday 04 June 2010 01:28:21 pm Rick McGowan wrote:
> People use complicated and potentially confusing systems all the time
> because to not use them would mean that (a) they can no longer communicate
> with everyone else and/or (b) they would represent an unnecessary
> discontinuity with all past usage, and thus people would lose touch with
> their history and literature.

This is only true if the old system ceases. Most of the world seems to have 
switched to the metric system just fine despite these apparently barriers. 
(and despite the fact that the earlier English system was superior  to metric 
in various ways)

> Hexadecimal/tonal will never be popular with ordinary humans for
> ordinary counting in social situations because people don't have ten
> fingers and nobody uses hexadecimal for ordinary counting, nor has any
> significant population ever done so, as far as I know.

The "ten fingers" argument is, has always been, and will always be flawed. 
Humans have ten *binary digits*, or two *senary digits*, both of which make 
better sense than combining them to create a single decimal digit.

> Just out of curiosity, why do you think it's useful or important for
> people to use hexadecimal as their primary system of counting? What
> advantages would it confer?

John W. Nystrom went over the numerous benefits to the tonal system 
(contrasting it with not only base 10, but also other possible bases) a long 
time ago...
http://www.lulu.com/product/paperback/tonal-system/10991090

Re: Hexadecimal digits

[Luke-Jr]

On Friday 04 June 2010 02:00:34 pm Michael Everson wrote:
> A wide variety of numeric systems ***IS*** supported in the UCS. You can do
>  sums in Sumerian and Egyptian and Linear B and Phoenician and lots of
>  other numeric systems.

Sumerian is basically bar counting, and the others are all base 10. Hardly a 
wide variety, just different symbols meaning the same thing. None of which 
provide 16 digits needed for a hexadecimal numbering system.

Re: Hexadecimal digits

[Michael Everson]

On 4 Jun 2010, at 21:14, Luke-Jr wrote:

>> A wide variety of numeric systems ***IS*** supported in the UCS. You can do 
>> sums in Sumerian and Egyptian and Linear B and Phoenician and lots of other 
>> numeric systems.
> 
> Sumerian is basically bar counting, and the others are all base 10. Hardly a 
> wide variety, just different symbols meaning the same thing. None of which 
> provide 16 digits needed for a hexadecimal numbering system.


One mentioned 0123456789ABCDEF, and the fact that one has software already 
which does sums in this hexadecimal notation. 

Michael Everson * http://www.evertype.com/

Re: Hexadecimal digits

[Michael Everson]

Luke wrote:

> I also plan to teach it as the primary numerical system in my home-school 
> curriculum (mainly for my own children, of which I thus far have four)

What a lovely gift to give your children.

Of course, they'll be unable to balance their chequebooks in that dreadful 
monkey-fingered number system that everyone else uses.

Holy hand grenades of Antioch

M

Re: Hexadecimal digits

[Doug Ewell]

"Luke-Jr"  wrote:

> Unicode has Roman numerals and bar counting (base 0); why should base 16 be 
> denied unique characters?

The Roman numeral characters starting at U+2160 are compatibility
characters.  They exist in Unicode only because they existed in one or
more of the other character sets used as a source for Unicode, so data
can be converted between Unicode and the other set without loss.

People aren't encouraged to use the special Roman numeral characters,
but rather to write Roman numerals using Basic Latin letters.  And yes,
that means the string "mix" out of context could be an ordinary English
word or the Roman representation of decimal 1,009.  Plain text is full
of things that get resolved by rudimentary context.  Hexadecimal numbers
are like that.

A set of hex-digit glyphs like Nystrom's, or like Bruce Martin's (see
Wikipedia "Hexadecimal"), or any other characters for that matter, would
have to see much more popularity than this to be considered for formal
encoding.  If you are interested in a writing system that includes
built-in support for hex digits, see
http://www.evertype.com/standards/csur/ewellic.html .  But do not expect
any part of this writing system, which has been used by maybe four or
five people, to be a candidate for Unicode either.

--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ­

Re: Hexadecimal digits

[Luke-Jr]

On Friday 04 June 2010 02:23:46 pm Michael Everson wrote:
> On 4 Jun 2010, at 21:14, Luke-Jr wrote:
> > Sumerian is basically bar counting, and the others are all base 10.
> > Hardly a wide variety, just different symbols meaning the same thing.
> > None of which provide 16 digits needed for a hexadecimal numbering
> > system.
> 
> One mentioned 0123456789ABCDEF, and the fact that one has software already
>  which does sums in this hexadecimal notation.

That works for software, but not so much for human communication.

Re: Hexadecimal digits

[John H. Jenkins]

Unicode has Roman numerals for compatibility reasons, not for serious use as 
Roman numerals. If you *really* want to work with roman numerals, even in the 
year MMDCCLXIII AUC, use the letters, just like the Romans did.

And in any event, you're undermining your own case, because a *lot* of 
societies have used the same symbols for letters and numerals.  People learn to 
live with it, just the way we live with cough and slough, minute and minute, 
and 1750 hours and 1750 days.  This is where gematria had its start.

從我的 iPhone 傳送

在 Jun 4, 2010 12:39 PM 時，Luke-Jr  寫到：

> Unicode has Roman numerals and bar counting (base 0); why should base 16 be 
> denied unique characters?
> 
> From another perspective, the English-language Arabic-numeral world came up 
> with ASCII. Unicode was created to unlimit the character set to include  
> coverage of other languages' characters. Why shouldn't a variety of numeric 
> systems also be supported?
> 
> 

Re: Hexadecimal digits

[Michael Everson]

On 4 Jun 2010, at 21:35, Luke-Jr wrote:

>> One mentioned 0123456789ABCDEF, and the fact that one has software already 
>> which does sums in this hexadecimal notation.
> 
> That works for software, but not so much for human communication.


At the risk of Her Divine Effulgence's wrath, all I can say to that is 
"Bollocks".

Michael Everson * http://www.evertype.com/

Re: Hexadecimal digits

[Mark Davis ☕]

We don't add nonce characters to the standard just because someone thinks
they'd be a good idea; there needs to be established usage by a substantial
user community. We established a huge range (over 100,000 characters) for
private use. You (or William Overington, for example) are free to define a
range within that area for your specific use. If there develops
a substantial user community for the new characters, you could then create a
proposal for adding them to the Unicode Standard.

So I suggest that you spend your efforts on building such a community if you
want to move this forward; more emails to this list will not accomplish
anything.

Mark

— Il meglio è l’inimico del bene —


On Fri, Jun 4, 2010 at 11:39, Luke-Jr  wrote:

> Unicode has Roman numerals and bar counting (base 0); why should base 16 be
> denied unique characters?
>
> From another perspective, the English-language Arabic-numeral world came up
> with ASCII. Unicode was created to unlimit the character set to include
> coverage of other languages' characters. Why shouldn't a variety of numeric
> systems also be supported?
>
>
>

Re: Hexadecimal digits

[Philippe Verdy]

"Luke-Jr" 
> A : unicode@unicode.org
> Copie à : "John Dlugosz" , "Otto Stolz" 
> 
> Objet : Re: Hexadecimal digits
>
> On Friday 04 June 2010 11:55:55 am John Dlugosz wrote:
> > Those things really happen when writing in assembly language.  I recall
> >  having to write "numbers" that only begin with a decimal digit, so "a
> >  fish" is a word, and "0ah fish" is a number.  In C and C++, "a" is a word
> >  and "0xa" is a number.
>
> But I'm not talking about programming languages, just common everyday uses by
> people who have it as their primary (not secondary) system of numbers.

It's true that we don't need new digits for hexadecimal numbers for
programming, given that for such technical use, we already have
unambiguous notations using prefixes like "0x" or "$" or suffixes like
"H".

The real need would be is we started to count, in our natural life, in
a binary system like hexadecimal: there would still be the need to use
it unambiguously with decimal numbers, so that numbers written like
"10" would still remain unambiguosuly interpreted as ten and not
sixteen: to avoid this problem, we would also need another set of
digits for 0-9. Or we would have to use another additonal notation
such as some diacritic (or prefix/suffix like for programming : but
how are we supposed to ponounce them?).

The other major problem will be linguistic : to make the hexadecimal
convenient, we would also need to have other names than "ten",
"twenty", unless we keep their meaning but forbid combining them in
sequences like "twenty one" which would still be interpreted in a
decimal system. So we would need new names for powers of 16, even if
we keep the names we have for 0..9 and possibly more (ten, eleven,
twelve are possible in English, thirteen would prebably be
disqualified as a unit name; in French we could keep dix, onze, douze,
treize, quatorze, quinze for the hexadecimal units; all other names
for powers of 10 and their multiples would be disqualified in the new
naming as they would not translate easily in the hexadecimal system).

But then people would have to remember at least the order of magnitude
between numbers named in the decimal system and number with the same
numeric value in the hexadecimal system (converting numbers from the
decimal to the hexadecimal system is not trivial after som small
range, it is even a complex algorithm to implement on computers for
high precision numbers...

But let's imagine that such a new naming system exists, it will come
with its own digits ; so they would all be encoded as a complete
separate set of the 16 digits (in 0..15 inclusively), and they would
certinaly have their own distinctive glyphs. There won't be any need
to change the technical notation used in computers using the existing
decimal digits 0..9, letters A..F, and prefixes/suffixes using another
letter or symbol.

So my opinion is then that, if digits were added for hexadecimal
notations, they should all be encoded for the full range 0..15, not
just the range 10..15, and in an unbroken sequence.

In this system, the least significant unit digit (in numbers with
multiple hexadecimal digits) may be freely replaceable by a decimal
digit if it's in 0..9, without creating confusion, for practical
reasons (0 and 1 are too commonly used every day and should not
require any conversion between the two numeric systems).

Implementers could then imagine the distinctive glyphs associated with
those digits, but the glyphs should remain simple, and as narrow as
existing decimal digits, and clearly distinct from existing digits, or
letters in all major scripts already using the existing digits
(otherwise this system will fail immediately and will be even less
convenient than using the technical notations like "0x..." using in
programming. The glyphs should also be mnemonic according to their
value (that's why I suggested a glyph shape near from the shape of
decimal digits, possibly by using some diacritic like a top bar (which
could connect with the bar of the surrounding digits, so that it is
drawn really fast, but this may create confusion with some existing
notations used in maths or engineering).

Another solution would be to borrow for use in Latin the 16 first
glyphs of some other alphabets in other very different script (but in
this script to borrow the glyphs of the Latin alphabet), but this
would require two sets of hexadecimal digits, that would have to be
encoded separately, and it is unlikely that scripts other than Latin
will borrow Latin letters for that usage, given that they frequently
borrow words written in the Latin script (notably trademarks, and on
offocial documents like passports, or when transliterating people
names and postal addresses).

The glyphs would al

Re: Hexadecimal digits

[Luke-Jr]

On Friday 04 June 2010 03:26:45 pm Philippe Verdy wrote:
> The real need would be is we started to count, in our natural life, in
> a binary system like hexadecimal: there would still be the need to use
> it unambiguously with decimal numbers, so that numbers written like
> "10" would still remain unambiguosuly interpreted as ten and not
> sixteen: to avoid this problem, we would also need another set of
> digits for 0-9. Or we would have to use another additonal notation
> such as some diacritic

I agree, but I'm busy enough without having to invent/develop a new system. 
The Tonal system already exists, and works well enough.

> The other major problem will be linguistic : to make the hexadecimal
> convenient, we would also need to have other names than "ten",
> "twenty", unless we keep their meaning but forbid combining them in
> sequences like "twenty one" which would still be interpreted in a
> decimal system. So we would need new names for powers of 16, even if
> we keep the names we have for 0..9 and possibly more (ten, eleven,
> twelve are possible in English, thirteen would prebably be
> disqualified as a unit name; in French we could keep dix, onze, douze,
> treize, quatorze, quinze for the hexadecimal units; all other names
> for powers of 10 and their multiples would be disqualified in the new
> naming as they would not translate easily in the hexadecimal system).

The Tonal system gives new pronunciations to all the digits.

> So my opinion is then that, if digits were added for hexadecimal
> notations, they should all be encoded for the full range 0..15, not
> just the range 10..15, and in an unbroken sequence.

Again, if I were creating my own system, sure... Tonal reencodes 9..15.

> But before that, we would still first need to invent and use new names
> for powers of sixteen, and a rational way to name reasonnably large
> numbers in this system (at least up to 64-bit), including for
> fractions of unity ; this has already started in the metric units used
> in the computing industry, by the adoption of binary-based prefixes
> for measure names (kibi, mebi, gibi, ...) instead of the 10-based
> prefixes (kilo, mega, giga...), and the new recommendation of
> abbreviated symbols for these prefixes for multiples/submultiples
> (appending a lowercase "i" after the initial : "Ki, "Mi, Gi..."
> instead of just "k, M, G...")

The computer industry already has units of 'kilobyte' and such referring to 
powers of 1024. Being a supporter of hexadecimal, I am of course also
anti-metric and anti-SI-- including insisting that 1024 bytes is a KB :)

On a side note, I'm planning to get a new hard drive at least san (this is a 
single digit, but due to deficiencies in Unicode I must spell it out ;) tB 
(tambyte) in size sometime soon.

Re: Hexadecimal digits

[Tim Greenwood]

I was at high school in England a few years prior to the currency
decimalization. A teacher argued that the then current system of 12 pennies
to a shilling and 20 shillings to a pound was superior to the proposed 100
new pence to the pound because 12 was divisible by 2 - 3 - 4 - 6 and 10 only
by 2 and 5. He was as successful in avoiding the change as you will be in
adding new base 16 characters.

Re: Hexadecimal digits

[John H. Jenkins]

On Jun 4, 2010, at 2:48 PM, Luke-Jr wrote:

> The computer industry already has units of 'kilobyte' and such referring to 
> powers of 1024. 
> 

You mean, of course, kibibyte.  A kilobyte is 1000 bytes.  

Re: Hexadecimal digits

[Hans Aberg]

On 4 Jun 2010, at 20:39, Luke-Jr wrote:

Unicode has Roman numerals and bar counting (base 0); why should  
base 16 be

denied unique characters?


Anyway, if you can show these John Nystrom Tonal System glyphs have  
been in textual use, perhaps they should be encoded.


From another perspective, the English-language Arabic-numeral world  
came up
with ASCII. Unicode was created to unlimit the character set to  
include
coverage of other languages' characters. Why shouldn't a variety of  
numeric

systems also be supported?


As for the question of usability, mathematical symbols typically start  
off as some common symbol and gradually evolve being specially  
mathematical. See for example

  http://en.wikipedia.org/wiki/2_(number)#Evolution_of_the_glyph

Right now, there is no particular need for having special hexadecimal  
symbols - the letters A-F work just fine. Also, there is no particular  
with base 16. For example, in GMP  one can use use  
any base, I recall, as long as there are letters. Historically, base  
60 has been in use - we still use it in clocks. Some people (Danish,  
French) use base 20 when counting. Since ancient times, one has used  
binary multiplication Ethiopia. So there are number of different  
number systems already in use.


Hexadecimal representation is only used to give a compact  
representation of binary numbers in connection of computers. In view  
of modern fast computers, one only needs to write out numbers when  
interfacing with humans. Then one can easily make the computer write  
or read what humans are used to. So there is no particular need to  
switch to another base than ten if that is what humans prefer. Base 16  
is easier when one for some reason needs to think about the binary  
representation.


But if humans in the future would use base 16 a lot, it might be  
convenient to have special symbols for them. Then the typical would be  
that glyphs becoming some alteration of A-F.


  Hans

RE: Hexadecimal digits

[Shawn Steele]

Shouldn't this be an FAQ?

-Original Message-
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf 
Of Michael Everson
Sent: Poʻalima, Iune 04, 2010 12:01 PM
To: unicode Unicode Discussion
Subject: Re: Hexadecimal digits

On 4 Jun 2010, at 20:39, Luke-Jr wrote:

> Unicode has Roman numerals and bar counting (base 0); why should base 16 be 
> denied unique characters?

It isn't. 0123456789ABCDEF. I have calculators which do sums with this notation.

> Unicode has Roman numerals and bar counting (base 0); why should base 16 be 
> denied unique characters?

Because we don't have enough fingers.

> Unicode has Roman numerals and bar counting (base 0); why should base 16 be 
> denied unique characters?

Because both begins with a B.

> From another perspective, the English-language Arabic-numeral world came up 
> with ASCII. Unicode was created to unlimit the character set to include 
> coverage of other languages' characters. Why shouldn't a variety of numeric 
> systems also be supported?

A wide variety of numeric systems ***IS*** supported in the UCS. You can do 
sums in Sumerian and Egyptian and Linear B and Phoenician and lots of other 
numeric systems. 

Michael Everson * http://www.evertype.com/

Re: Hexadecimal digits

[Luke-Jr]

On Friday 04 June 2010 04:45:57 pm Hans Aberg wrote:
> Hexadecimal representation is only used to give a compact
> representation of binary numbers in connection of computers. In view
> of modern fast computers, one only needs to write out numbers when
> interfacing with humans. Then one can easily make the computer write
> or read what humans are used to. So there is no particular need to
> switch to another base than ten if that is what humans prefer. Base 16
> is easier when one for some reason needs to think about the binary
> representation.

Base 16 is superior in many various ways, the most obvious being easier 
division (both visibly and numeric). Why assume all humans prefer the same 
thing? This is like assuming everyone knows the same language, uses the same 
characters, etc...

> But if humans in the future would use base 16 a lot, it might be
> convenient to have special symbols for them. Then the typical would be
> that glyphs becoming some alteration of A-F.

While it is natural for glyphs to change, artificial character sets are not 
unheard of. For example, Korean was designed such that each character, 
representing a syllable, was composed of sub-characters representing the 
individual sounds in that syllable. Despite its unnatural origin, numerous 
people use it in their daily lives.

Re: Hexadecimal digits

[Luke-Jr]

On Friday 04 June 2010 04:49:42 pm Shawn Steele wrote:
> Shouldn't this be an FAQ?

If it's Frequent, shouldn't that imply there's enough people who want it to 
warrant inclusion in Unicode? ;)

Re: Hexadecimal digits

[Luke-Jr]

On Friday 04 June 2010 04:16:46 pm John H. Jenkins wrote:
> On Jun 4, 2010, at 2:48 PM, Luke-Jr wrote:
> > The computer industry already has units of 'kilobyte' and such referring
> > to powers of 1024.
> 
> You mean, of course, kibibyte.  A kilobyte is 1000 bytes.

Classical computing has always defined a kilobyte as 1024 bytes.
I reject SI's attempt to force their broken system on what is an established 
de facto standard.

Re: Hexadecimal digits

[Mark E. Shoulson]

On 06/04/2010 03:10 PM, Luke-Jr wrote:

On Friday 04 June 2010 01:28:21 pm Rick McGowan wrote:


Just out of curiosity, why do you think it's useful or important for
people to use hexadecimal as their primary system of counting? What
advantages would it confer?


John W. Nystrom went over the numerous benefits to the tonal system
(contrasting it with not only base 10, but also other possible bases) a long
time ago...
http://www.lulu.com/product/paperback/tonal-system/10991090


For a while I even joined the Dozenal Society, which advocates for 
base-12.  Base-12 has the advantage (over base-10 and base-16) of many 
divisors, so division radix notation (to the right of the radix point) 
is easier.


Not really the point, though.  Unicode's job is not so much to set 
humans free to do *anything*, but to allow them to do the things they've 
been doing all along.


~mark

Re: Hexadecimal digits

[Hans Aberg]

On 5 Jun 2010, at 00:04, Luke-Jr wrote:


On Friday 04 June 2010 04:45:57 pm Hans Aberg wrote:

Hexadecimal representation is only used to give a compact
representation of binary numbers in connection of computers. In view
of modern fast computers, one only needs to write out numbers when
interfacing with humans. Then one can easily make the computer write
or read what humans are used to. So there is no particular need to
switch to another base than ten if that is what humans prefer. Base  
16

is easier when one for some reason needs to think about the binary
representation.


Base 16 is superior in many various ways, the most obvious being  
easier

division (both visibly and numeric).


The Ethiopian binary multiplication is far simpler - it is now used in  
computers. But now, the system is falling out of use, as it is easier  
to let the computers do the arithmetic. (Besides, one has devised  
fast, in the head, multiplication systems for base ten, as well.)



Why assume all humans prefer the same
thing? This is like assuming everyone knows the same language, uses  
the same

characters, etc...


Nobody does, as there are already different systems in use. The  
situation is the opposite: there is no need to promote one basis over  
another as a part of a reform. Just use what is practical.



But if humans in the future would use base 16 a lot, it might be
convenient to have special symbols for them. Then the typical would  
be

that glyphs becoming some alteration of A-F.


While it is natural for glyphs to change, artificial character sets  
are not

unheard of. For example, Korean was designed such that each character,
representing a syllable, was composed of sub-characters representing  
the
individual sounds in that syllable. Despite its unnatural origin,  
numerous

people use it in their daily lives.


Anyway, Unicode just encodes actual usage, with few exceptions. If you  
have some documentation, that may help your cause.


  Hans

Re: Hexadecimal digits

[Michael Everson]

On 5 Jun 2010, at 00:04, Luke-Jr wrote:

> While it is natural for glyphs to change, artificial character sets are not 
> unheard of.

Piffle. All writing systems are artefacts. 

> For example, Korean was designed such that each character, representing a 
> syllable, was composed of sub-characters representing the individual sounds 
> in that syllable. Despite its unnatural origin, numerous 
> people use it in their daily lives.

Unnatural origin? 

This is trollery.

Michael Everson * http://www.evertype.com/

RE: Hexadecimal digits

[Doug Ewell]

"Luke-Jr"  wrote:

>> Shouldn't this be an FAQ?
> 
> If it's Frequent, shouldn't that imply there's enough people who want
> it to warrant inclusion in Unicode? ;)

It means there are enough people who are misinformed about whether a
universal character encoding should be a tool to advance individuals'
social reforms.

--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ­

RE: Hexadecimal digits

[Doug Ewell]

> Classical computing has always defined a kilobyte as 1024 bytes.
> I reject SI's attempt to force their broken system on what is an
> established de facto standard.

This is indeed trollery.  SI and "kilo" and the decimal system have been
around far, far longer than so-called "classical computing."

--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ­

Re: Hexadecimal digits

[David Starner]

On Fri, Jun 4, 2010 at 6:14 PM, Mark E. Shoulson  wrote:
> For a while I even joined the Dozenal Society, which advocates for base-12.
>  Base-12 has the advantage (over base-10 and base-16) of many divisors, so
> division radix notation (to the right of the radix point) is easier.

I once thought of making a proposal for dozenal digits. The problem
was, while I had several sources, and could with some work find a
number more, for the existence of special characters 10 and 11, I
could find no case where the two different sources used similar
glyphs; to unify them would probably be about the widest disparity in
glyphic variation unified into one character in Unicode, and I doubted
it would fly.

-- 
Kie ekzistas vivo, ekzistas espero.

Re: Hexadecimal digits

[Luke-Jr]

On Friday 04 June 2010 05:40:48 pm Doug Ewell wrote:
> "Luke-Jr"  wrote:
> >> Shouldn't this be an FAQ?
> >
> > If it's Frequent, shouldn't that imply there's enough people who want
> > it to warrant inclusion in Unicode? ;)
> 
> It means there are enough people who are misinformed about whether a
> universal character encoding should be a tool to advance individuals'
> social reforms.

Can't even begin using a new character if it doesn't exist. Are you saying all 
new symbols must be popularised on paper before they can be even considered 
for use in digital mediums? Under that rule in modern day, there will never be 
a new symbol, ever.

Why not allow proposals of this nature a "draft" status, and require popular 
use before allowing it to become "standard" or "permanent"?

Since posting to the list, I have become aware of CSUR (ConScript Unicode 
Registry) which sub-standardizes the Private Use Area. It seems to be, in 
practice, used for draft/pre-standard characters which are later forced to be 
remapped when given a standard range. Obviously the remapping is far from 
ideal, but if that is the road to take, perhaps mentioning it in the proposed 
FAQ would be a good start.

On Friday 04 June 2010 05:42:48 pm Doug Ewell wrote:
> SI and "kilo" and the decimal system have been around far, far longer than
> so-called "classical computing."

Sure, SI and "kilo" have, but "kilobyte" has always meant 1024 bytes.

On Friday 04 June 2010 05:28:10 pm Michael Everson wrote:
> Piffle. All writing systems are artefacts.

http://en.wikipedia.org/wiki/Hangul#History

Re: Hexadecimal digits

[CE Whitehead]

 
 
Hi I tend to agree with the arguments of Doug and Hans.
From: Doug Ewell (d...@ewellic.org)
Date: Fri Jun 04 2010 - 14:35:15 CDT 

> "Luke-Jr"  wrote: 

>> Unicode has Roman numerals and bar counting (base 0); why should base 16 be 
>> denied unique characters? 

> The Roman numeral characters starting at U+2160 are compatibility 
> characters. They exist in Unicode only because they existed in one or 
> more of the other character sets used as a source for Unicode, so data 
> can be converted between Unicode and the other set without loss. 

> People aren't encouraged to use the special Roman numeral characters, 
> but rather to write Roman numerals using Basic Latin letters. And yes, 
> that means the string "mix" out of context could be an ordinary English 
> word or the Roman representation of decimal 1,009. Plain text is full 
> of things that get resolved by rudimentary context. Hexadecimal numbers 
> are like that. 
Yes, thanks, my feelings.
> A set of hex-digit glyphs like Nystrom's, or like Bruce Martin's (see 
> Wikipedia "Hexadecimal"), or any other characters for that matter, would 
> have to see much more popularity than this to be considered for formal 
> encoding. If you are interested in a writing system that includes 
> built-in support for hex digits, see 
> http://www.evertype.com/standards/csur/ewellic.html . But do not expect 
> any part of this writing system, which has been used by maybe four or 
> five people, to be a candidate for Unicode either. 
 
> --
> Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
From: Hans Aberg (haber...@telia.com)
Date: Fri Jun 04 2010 - 16:45:57 CDT 

> On 4 Jun 2010, at 20:39, Luke-Jr wrote: 

>> Unicode has Roman numerals and bar counting (base 0); why should 
>> base 16 be 
>> denied unique characters? 

> Anyway, if you can show these John Nystrom Tonal System glyphs have 
> been in textual use, perhaps they should be encoded. 
Thanks.  That's if they have been in textual use -- and sorry; I think it's 
necessary to use the characters you have developed in a small circle first 
somehow, then to propose their encoding in the unicode character sets.

Best wishes in any case,

C. E. Whitehead
cewcat...@hotmail.com
  

Re: Hexadecimal digits

[William_J_G Overington]

On Friday 4 June 2010, Mark Davis ☕  wrote:
 
> You (or William Overington, for example) are free to define a range within 
> that area for your specific use.
 
Well, as it happens I did make some Private Use Area allocations for 
hexadecimal digits back in 2002.
 
http://www.unicode.org/mail-arch/unicode-ml/y2002-m06/0262.html
 
In fact, I implemented a set of 16 equal width glyphs 1..9 and A..F in my Quest 
text font, which font was the first font with a complete alphabet that I ever 
published.
 
I have added to the font at various times over the years, though nothing has 
been changed since 2008.
 
The font is available from the following web page.
 
http://www.users.globalnet.co.uk/~ngo/fonts.htm
 
The font has its own thread in the Gallery forum at the 
http://forum.high-logic.com webspace.
 
http://forum.high-logic.com/viewtopic.php?f=10&t=682
 
Also, the font is used for one of the graphic designs in the following 
collection.
 
http://www.users.globalnet.co.uk/~ngo/usinggraphicsandfonts.htm
 
The particular design being as follows, which design, as it happens, I 
remembered recently when looking through the emoji code chart.
 
http://www.users.globalnet.co.uk/~ngo/moon.PDF
 
It is worth mentioning that no Private Use Area code point allocations are 
binding on anyone else and that just because one person uses a particular 
Private Use Area allocation for some purpose that usage does not mean that 
nobody else will use that code point allocation for something else. 
 
However, within those limits, the Private Use Area can be useful for many 
purposes. For example, I have recently been using the Private Use Area for 
adding some alternate glyphs to a font and I am pleased with the results.
 
The font is Sonnet Calligraphic and is still under development, yet the font is 
available from its own thread in the Gallery forum of the 
http://forum.high-logic.com webspace.
 
http://forum.high-logic.com/viewtopic.php?f=10&t=2957
 
What I like about the font is that good results can be achieved using the font 
with Microsoft WordPad, which is widely available.
 
William Overington
 
5 June 1020
 

Re: Hexadecimal digits

[Otto Stolz]

Am 2010-06-05 00:04, schrieb Luke-Jr:

Base 16 is superior in many various ways, the most obvious being easier
division (both visibly and numeric).


This is a red herring, IMHO.

In the decimal systems, you can easier divide by 2, 5,
and powers of 10, whilst in the hexadekadic system,
you can easier divide by many powers of two, and all
powers of 16.

For arbitrary divisors, the decimal system seems to be
easier, as you would use the same division algorithm,
in both systems, however with different tables (dubbed
“multiplication table” or, less formally, “times table”)
that comprise 100 vs. 256 entries. Hence, the the hexa-
dekadic multiplication table should be 2½ times as hard
to learn, and memorize, as the decimal one.

Of course, a larger base needs less digits (on average)
for any given number; hence divisions for large numbers
tend to take less steps in the hexadekadic system than
in the decimal one; whether this will outweigh the larger
multiplication table to be used, is, I reckon, a matter
of taste. Somewhere, there must be an optimum: I cannot
imagine people to learn, and memorize, e. g., the 3600
entries of the multiplication table for base 60.

This whole deliberation is, of course, purely academic.
In real life, you will have to use the decimal system
as everybody else does, lest you wont be misunderstood.

You may wonder, why I am using the term “hexadekadic”.
This is because, “hexadeka” is the Greek word for 16,
whilst the Latin word ist “sedecim”; there is no language
known that has “hexadecim”, or anything alike, for 16.

Best wishes,
  Otto Stolz

Re: Hexadecimal digits

[Michael Everson]

On 5 Jun 2010, at 16:33, Otto Stolz wrote:

> You may wonder, why I am using the term “hexadekadic”. This is because, 
> “hexadeka” is the Greek word for 16,
> whilst the Latin word ist “sedecim”; there is no language known that has 
> “hexadecim”, or anything alike, for 16.

You may wish to compare "ipsemobile" and "autokineton".

M

Re: Hexadecimal digits

[Luke-Jr]

On Saturday 05 June 2010 09:33:03 am Otto Stolz wrote:
> In the decimal systems, you can easier divide by 2, 5,
> and powers of 10, whilst in the hexadekadic system,
> you can easier divide by many powers of two, and all
> powers of 16.

And 4, and 8. Many repeating fractions also become more accurate with base 16.

> For arbitrary divisors, the decimal system seems to be
> easier, as you would use the same division algorithm,
> in both systems, however with different tables (dubbed
> “multiplication table” or, less formally, “times table”)
> that comprise 100 vs. 256 entries. Hence, the the hexa-
> dekadic multiplication table should be 2½ times as hard
> to learn, and memorize, as the decimal one.

Does anyone seriously memorise multiplication tables...?

> This whole deliberation is, of course, purely academic.
> In real life, you will have to use the decimal system
> as everybody else does, lest you wont be misunderstood.

Only when/if you deal with "everybody else".
And then you need only convert, not use it for your calculations.

> You may wonder, why I am using the term “hexadekadic”.
> This is because, “hexadeka” is the Greek word for 16,
> whilst the Latin word ist “sedecim”; there is no language
> known that has “hexadecim”, or anything alike, for 16.

I prefer "tonal", since "hexadecimal"/"hexadekadic" both imply a decimal base.

RE: Hexadecimal digits

[Peter Constable]

This is a bad idea. 

The best way to make it go away is to just stop discussing it.


Peter

Re: Hexadecimal digits

[Peter Zilahy Ingerman, PhD]

I recall, when the English were finally giving up LSD and switching to 
decimal currency, a letter to The Times from someone who, seriously, 
felt that it would also be a good time to switch to teaching duodecimal 
arithmetic in the schools.


Much of the "hexadecimal digit" commentary would appear to have been 
written by that gentleman or his intellectual companions.


Peter

Re: Hexadecimal digits

[Hans Aberg]

On 5 Jun 2010, at 16:33, Otto Stolz wrote:


You may wonder, why I am using the term “hexadekadic”.
This is because, “hexadeka” is the Greek word for 16, ...


The URL  produces  
δεκαέξι, or dekaexi.


  Hans

Re: Hexadecimal digits

[Doug Ewell]

"Luke-Jr"  wrote:

Why not allow proposals of this nature a "draft" status, and require 
popular use before allowing it to become "standard" or "permanent"?


What would be the effect of encoding characters as "draft"?  Would they 
be allocated space in the Unicode charts, described in the online book, 
but simply marked as "draft" in the way some characters are marked as 
"deprecated"?  How would that be different from simply encoding any 
characters anyone asks for on the public list?


The IETF distinguishes "draft standards" and "proposed standards" and 
"full standards," and the result is that the entire computing industry 
ignores the intended distinction and treats all of these as equivalent 
to "standard."


Since posting to the list, I have become aware of CSUR (ConScript 
Unicode Registry) which sub-standardizes the Private Use Area. It 
seems to be, in practice, used for draft/pre-standard characters which 
are later forced to be remapped when given a standard range. Obviously 
the remapping is far from ideal, but if that is the road to take, 
perhaps mentioning it in the proposed FAQ would be a good start.


CSUR is for invented scripts, so this does seem like a reasonable match.

CSUR is not necessarily for "draft/pre-standard characters which are 
later... given a standard range."  The great majority of characters in 
CSUR will never be formally encoded in Unicode.  Those which have a 
demonstrated user base (which means more than just "one guy and his 
children") may be considered for formal encoding at a later time.  The 
CSUR encoding may be taken into account to determine the level of 
popular usage, and whether any encoding or rendering issues have been 
encountered and resolved.  It is not just an automatic stepping-stone to 
formal encoding.


If it's just you and your kids, the Private Use Area sounds like the way 
to go.


--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages @ http://is.gd/2kf0s ­

Re: Hexadecimal digits

[William J Poser]

>a letter to The Times from someone who, seriously, 
>felt that it would also be a good time to switch to teaching duodecimal 
>arithmetic in the schools.

Many years ago, when I took Number Theory from the late, wonderful N.
James Schoonmaker, he spent some time advocating the virtues of duodecimal
and made us do all calculations for a week in duodecimal. He was, however,
aware that the general public was unlikely to adopt it. He regarded the
failure to use duodecimal more as a lost opportunity.

Bill

Re: Hexadecimal digits

[Luke-Jr]

On Saturday 05 June 2010 11:26:27 am Doug Ewell wrote:
> "Luke-Jr"  wrote:
> > Why not allow proposals of this nature a "draft" status, and require
> > popular use before allowing it to become "standard" or "permanent"?
> 
> What would be the effect of encoding characters as "draft"?  Would they
> be allocated space in the Unicode charts, described in the online book,
> but simply marked as "draft" in the way some characters are marked as
> "deprecated"?  How would that be different from simply encoding any
> characters anyone asks for on the public list?

"Draft" characters would be ones which are not final and can be removed or 
replaced in the future, if they don't in the meantime gain popularity within 
some reasonable timeframe.

> The IETF distinguishes "draft standards" and "proposed standards" and
> "full standards," and the result is that the entire computing industry
> ignores the intended distinction and treats all of these as equivalent
> to "standard."

The difference is in how the standards organisation treats them. It doesn't 
matter what the rest of the industry does, since IETF can still modify their 
draft standards before upgrading them to full.

> If it's just you and your kids, the Private Use Area sounds like the way
> to go.

I've also created a "Hexadecimal / Tonal Mathematics" group on Facebook, to 
promote using it in daily life. ;)

Re: Hexadecimal digits

[Doug Ewell]

"Luke-Jr"  wrote:

"Draft" characters would be ones which are not final and can be 
removed or replaced in the future, if they don't in the meantime gain 
popularity within some reasonable timeframe.


There is no precedent for this in either Unicode or ISO/IEC 10646.  If 
you think it has been difficult persuading people that your characters 
should be encoded in the existing framework, just try suggesting a basic 
architectural change like this.


The IETF distinguishes "draft standards" and "proposed standards" and 
"full standards," and the result is that the entire computing 
industry ignores the intended distinction and treats all of these as 
equivalent to "standard."


The difference is in how the standards organisation treats them. It 
doesn't matter what the rest of the industry does, since IETF can 
still modify their draft standards before upgrading them to full.


The IETF consists of people from the industry.  They are "eating their 
own dog food," as they say.  There are very few "professional 
standardizers" in the traditional sense.


--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages @ http://is.gd/2kf0s ­

Re: Hexadecimal digits

[Rick McGowan]

On 6/5/2010 10:42 AM, Doug Ewell wrote, responding to Luke-jr:


"Draft" characters would be ones which are not final and can be 
removed or replaced in the future, if they don't in the meantime gain 
popularity within some reasonable timeframe.


There is no precedent for this in either Unicode or ISO/IEC 10646.  If 
you think it has been difficult persuading people that your characters 
should be encoded in the existing framework, just try suggesting a 
basic architectural change like this. 


Speaking only with my person opinion on this one poin: Doug is right. 
This won't happen. Once you have characters in real usage because a 
standard was released that contains them, even if the standard called 
them "draft", you'd have data "in the wild" that could potentially 
become non-conformant.


Rick

Re: Hexadecimal digits

[Luke-Jr]

On Saturday 05 June 2010 12:59:34 pm Rick McGowan wrote:
> On 6/5/2010 10:42 AM, Doug Ewell wrote, responding to Luke-jr:
> >> "Draft" characters would be ones which are not final and can be
> >> removed or replaced in the future, if they don't in the meantime gain
> >> popularity within some reasonable timeframe.
> >
> > There is no precedent for this in either Unicode or ISO/IEC 10646.  If
> > you think it has been difficult persuading people that your characters
> > should be encoded in the existing framework, just try suggesting a
> > basic architectural change like this.
> 
> Speaking only with my person opinion on this one poin: Doug is right.
> This won't happen. Once you have characters in real usage because a
> standard was released that contains them, even if the standard called
> them "draft", you'd have data "in the wild" that could potentially
> become non-conformant.

And the alternative is data "in the wild" that never had a chance to be 
conformant because the standard makes them impossible.

Re: Hexadecimal digits

[Doug Ewell]

And the alternative is data "in the wild" that never had a chance to 
be conformant because the standard makes them impossible.


Use the PUA.  That's what it's for.  Done.

--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages @ http://is.gd/2kf0s ­

Re: Hexadecimal digits

[Mark E. Shoulson]

On 06/05/2010 11:29 AM, Luke-Jr wrote:

On Saturday 05 June 2010 09:33:03 am Otto Stolz wrote:

In the decimal systems, you can easier divide by 2, 5,
and powers of 10, whilst in the hexadekadic system,
you can easier divide by many powers of two, and all
powers of 16.


And 4, and 8. Many repeating fractions also become more accurate with base 16.


This makes no sense whatsoever.  How can a repeating fraction become 
"more accurate"?  I suppose this means that the accuracy is higher for 
given number of digits after the radix point.  But that's true just 
because 16 is greater than 10, and we could do better still with base 24 
or base 30.


In point of fact, the divisibility of 16 is pretty lousy, and only 
fractions with denominators that are powers of two can be represented as 
terminating "decimals."  Base ten can handle powers of 2 and 5 (to be 
sure, requiring a few more places before terminating for 4 and 8, etc). 
 Base 12 is better still, since it brings in 3, and there's a good 
argument to be made that thirds are more useful in ordinary life than 
fifths.  (This is really the only advantage to base 12, and it's why I 
joined the Dozenal Society: to see how they could somehow write 
newsletters and such around only one valid point).



You may wonder, why I am using the term “hexadekadic”.
This is because, “hexadeka” is the Greek word for 16,
whilst the Latin word ist “sedecim”; there is no language
known that has “hexadecim”, or anything alike, for 16.


There are a bunch of words in English that have such hybrid derivations. 
 We live with it.


~mark

Re: Hexadecimal digits

[John W Kennedy]

On Jun 4, 2010, at 5:45 PM, Hans Aberg wrote:
> Hexadecimal representation is only used to give a compact representation of 
> binary numbers in connection of computers. In view of modern fast computers, 
> one only needs to write out numbers when interfacing with humans. Then one 
> can easily make the computer write or read what humans are used to. So there 
> is no particular need to switch to another base than ten if that is what 
> humans prefer. Base 16 is easier when one for some reason needs to think 
> about the binary representation.

And that need is much less than it was, say, 40 years ago. We don't normally 
debug from simple dumps anymore.

-- 
John W Kennedy
If Bill Gates believes in "intelligent design", why can't he apply it to 
Windows?

Re: Hexadecimal digits

[John W Kennedy]

On Jun 4, 2010, at 6:42 PM, Doug Ewell wrote:

>> Classical computing has always defined a kilobyte as 1024 bytes.
>> I reject SI's attempt to force their broken system on what is an
>> established de facto standard.
> 
> This is indeed trollery.  SI and "kilo" and the decimal system have been
> around far, far longer than so-called "classical computing."

He's also wrong about computing, which has never ceased to use "kilo-" in its 
correct sense of 1000, as well as in the incorrect sense of 1024. Worse yet, it 
has used "mega-" to mean 100, 1024000, and 1048576.

-- 
John W Kennedy
"Information is light. Information, in itself, about anything, is light."
  -- Tom Stoppard. "Night and Day"

RE: Hexadecimal digits

[John Dlugosz]

 
> ASCII a-f to express hexadecimal digits are standard in every
> significant programming language syntax, as well as for numeric
> character references that are used ubiquitously now to refer to
> characters in HTML and XML. So I'd say they are probably
> sufficient for some millions of programmers and some hundreds of
> millions of web users.
> 
> YMMD, of course.
> 
> --Ken
> 

I find it more of an actual problem with hand written notes, since my 9's and 
a's can look too much alike.

I think the practical problem of knowing what some string, e.g. "23" means is 
no different than the issue with units.  A Mars probe crashed because of a 
units mismatch; a config file that confused hex with decimal would be the same 
kind of issue.





==

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) 
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, 
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and 
subscription company, and TradeStation Europe Limited, a United Kingdom, 
FSA-authorized introducing brokerage firm. None of these companies provides 
trading or investment advice, recommendations or endorsements of any kind. The 
information transmitted is intended only for the person or entity to which it 
is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.

RE: Hexadecimal digits

[John Dlugosz]

> -Original Message-
> From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On
> Behalf Of Luke-Jr
> Sent: Friday, June 04, 2010 12:57 PM
> To: unicode@unicode.org; Kenneth Whistler
> Subject: Re: Hexadecimal digits
> 
> On Friday 04 June 2010 12:43:33 pm Kenneth Whistler wrote:
> > And that is why prefixes such as "0x" were invented, so as
> > to disambiguate explicitly in contexts where syntax or
> > explicit type do not. Ordinary language usage wouldn't ordinarily
> > countenance this kind of ambiguity anyway -- it is a completely
> > artificial example.
> 
> The whole point is to get the tonal/hexadecimal number system adopted
> for
> ordinary everyday use. This kind of ambiguity is an obstacle.
> 
> > > Just two examples I can think of offhand that make a-f
> insufficient.
> >
> > ASCII a-f to express hexadecimal digits are standard in every
> > significant programming language syntax, as well as for numeric
> > character references that are used ubiquitously now to refer to
> > characters in HTML and XML. So I'd say they are probably
> > sufficient for some millions of programmers and some hundreds of
> > millions of web users.
> 
> But again, I'm not talking about programming. My four year old can
> grasp tonal
> just as well as she could decimal had I been teaching that. Now if I
> were
> using the a-f notation, she would be (reasonably) confused as to why
> *some*
> numbers are unique, but *other* numbers are also letters.

Won't your child have problems dealing with other people, reading labels, 
counting money, etc.?

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) 
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, 
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and 
subscription company, and TradeStation Europe Limited, a United Kingdom, 
FSA-authorized introducing brokerage firm. None of these companies provides 
trading or investment advice, recommendations or endorsements of any kind. The 
information transmitted is intended only for the person or entity to which it 
is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.

RE: Hexadecimal digits

[John Dlugosz]

> But if humans in the future would use base 16 a lot, it might be
> convenient to have special symbols for them. Then the typical would be
> that glyphs becoming some alteration of A-F.
> 

That's very good food for thought with respect to handwriting.

--John





TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) 
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, 
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and 
subscription company, and TradeStation Europe Limited, a United Kingdom, 
FSA-authorized introducing brokerage firm. None of these companies provides 
trading or investment advice, recommendations or endorsements of any kind. The 
information transmitted is intended only for the person or entity to which it 
is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.

Re: Hexadecimal digits

[Luke-Jr]

On Monday 07 June 2010 02:37:29 pm John Dlugosz wrote:
> > But again, I'm not talking about programming. My four year old can
> > grasp tonal just as well as she could decimal had I been teaching that.
> > Now if I were using the a-f notation, she would be (reasonably) confused
> > as to why *some* numbers are unique, but *other* numbers are also letters.
> 
> Won't your child have problems dealing with other people, reading labels,
>  counting money, etc.?

That question is based on numerous assumptions:
- That they will interact with people who don't know tonal on a regular basis.
- That they won't also learn decimal and how to convert to and from.
- That currency can only be weighed in decimal units.

One key advantage to teaching them the tonal numeric system is that they will 
grow up mathematically "bilingual", and won't have the basic mental limitation 
of a single number system. In other words, your question might as well be in 
response to if I had said I plan to teach my children Japanese.

RE: Hexadecimal digits

[CE Whitehead]

Hi, I've gotten a bit behind on this discussion; oh well.

It really does seem to be getting circular (and getting away from the concerns 
of encoding) unless Luke comes back with a list of facebook users, his private 
use encoding system, etc. and shows that his system is in use.

 


From: Luke-Jr (l...@dashjr.org)
Date: Sat Jun 05 2010 - 10:29:03 CDT 

On Saturday 05 June 2010 09:33:03 am Otto Stolz wrote: 
>> In the decimal systems, you can easier divide by 2, 5, 
>> and powers of 10, whilst in the hexadekadic system, 
>> you can easier divide by many powers of two, and all 
>> powers of 16. 


> And 4, and 8. Many repeating fractions also become more accurate with base 
> 16. 


>> For arbitrary divisors, the decimal system seems to be 
>> easier, as you would use the same division algorithm, 
>> in both systems, however with different tables (dubbed 
>> “multiplication table” or, less formally, “times table”) 
>> that comprise 100 vs. 256 entries. Hence, the the hexa- 
>> dekadic multiplication table should be 2½ times as hard 
>> to learn, and memorize, as the decimal one. 


> Does anyone seriously memorise multiplication tables...? 
Doing so can speed up test taking for persons who have to pass entrance 
examinations -- not to mention
of course rapid calculations about payments, interest, and more.  
(Indeed memorizing tables through 12 by 12 albeit in base 10 was a requirement 
for promotion to third grade
in my day in school but things have changed I suppose -- for one thing 
candidates are allowed to take calculators to the S.A.T. now)

>> This whole deliberation is, of course, purely academic. 
>> In real life, you will have to use the decimal system 
>> as everybody else does, lest you wont be misunderstood. 


> Only when/if you deal with "everybody else". 
> And then you need only convert, not use it for your calculations. 
You need the decimal system for most college entrance exams, prices in the real 
world (till we change the dollar, get another monetary system -- maybe we need 
to -- but we are not the only country on a system of one's, one-hundreds, etc; 
there is the Mexican peso and more -- but the Mexican peso comes from the base 
8/16 pieces of eight -- maybe they had computers way back then and we just do 
not know -- that info got somehow lost; the British however always did their 
own thing; I'm not a Brit I guess), taxes, etc.


You need the hexadecimal system to 'talk to computers in assembly language' 
(but need to talk in straight base 2 if you are writing machine code -- 
otherwise you need a compiler).


You can also use hexa whatever (don't want to say the 'decimal' part here) in 
books describing assembly language -- books for people even.  (Why not?  
Although it does after all take a human to write the code that makes a computer 
'really foul things up;' my dad who has written some code himself always told 
me that base 16 and base 8 were invented to make it easier for PEOPLE to write 
code for computers -- thus people would not have to write in 1s and 0s.)


IMO an encoding system for hexadecimals -- inspired by an extant private use 
set of encodings, having a definable/identifiable community of users with 
examples of usage online or something -- should fly as a proposal.

 

There is no real perfect base system but base 6 or 12 or some multiple thereof 
would facilitate conversion between base 2 and base 3 tertiary but the circuits 
are going to be complicated.
But base 6 or 12 would make counting on the fingers more difficult.
(But as you've said above people don't memorize tables or use fingers; they all 
have calculators and computers.)
But we've strayed from unicode concerns in this discussion, I think.

(As for isolation, go ahead yourself, but will your children ever mix? If so 
will they need to understand base 10?)


>> You may wonder, why I am using the term “hexadekadic”. 
>> This is because, “hexadeka” is the Greek word for 16, 
>> whilst the Latin word ist “sedecim”; there is no language 
>> known that has “hexadecim”, or anything alike, for 16. 

> I prefer "tonal", since "hexadecimal"/"hexadekadic" both imply a decimal 
> base. 

6 and 10.  I don't know whether the base is meant to be six or ten . . . 

> . . .
From: Luke-Jr (l...@dashjr.org)
Date: Sat Jun 05 2010 - 12:35:36 CDT 
> I've also created a "Hexadecimal / Tonal Mathematics" group on Facebook, to 
> promote using it in daily life. ;) 
Who else goes to your facebook page?  How many friends?  
And what system of encoding have you all agreed on for encoding characters?  
You might develop your case thus; otherwise I fear that any discussion will be 
'circular' and pointless.

 

Best,

C. E. Whitehead
cewcat...@hotmail.com
  

Re: Hexadecimal digits

[André Szabolcs Szelp]

Now if I were
using the a-f notation, she would be (reasonably) confused as to why  
*some*

numbers are unique, but *other* numbers are also letters.



You greatly underestimate the abilities of children. This sentence of  
yours is especially (reasonably) confusing, given that yourself  
attested some sentences above the outstanding mental capabilities of  
your daughter:



My four year old can grasp tonal
just as well as she could decimal had I been teaching that.


Actually, it's quite a common (mis)-conception, often even used as  
arguments for spelling reforms, that children wouldn't be able to cope  
with some idiosynchrasies of certain orthographic systems. Guess how  
they coped that far...


Szabolcs

Re: Hexadecimal digits

[André Szabolcs Szelp]

One mentioned 0123456789ABCDEF, and the fact that one has software  
already

which does sums in this hexadecimal notation.


That works for software, but not so much for human communication.



The main obstacle to use hexadecimal in human communication are not  
the symbols used in its notation, but that every single human language  
uses 10-based numbers in *speech*, with at most minor deviations (e.g.  
eleven, twelve). The overall system is always 10-based. (10, 100,  
1000, (1 in indian and chinese), 100) etc.  have their own  
names, numbers composed are to be understood in the decimal system  
(nine million fivehundred thousand seventy two translates exactly and  
directly to the _decimal_ notation 9500072), whereas it would be  
pretty hard, even with Nyström's numbers (give the poor guy his dots,  
we have Unicode after all) to immediately convert the above number  
into writing.
BTW, this is also the main reason why decimal and SI _is_ more usable  
than any pre-SI system, including the Imperial/English you claim to be  
superior in several respects.


Szabolcs

Re: Hexadecimal digits

[Luke-Jr]

On Tuesday 08 June 2010 01:14:46 am André Szabolcs Szelp wrote:
> BTW, this is also the main reason why decimal and SI _is_ more usable
> than any pre-SI system, including the Imperial/English you claim to be
> superior in several respects.

All you've done is say "people use decimal" in long form. If one writes and 
speaks tonal, and adopts the "overall" tonal system, decimal has no 
advantage... Nystrom addresses all these common (and not so common-- even 
music!) situations in his book, with exception obviously to digital data sizes 
(bytes) which are very trivially adapted in with the rest.

Re: Hexadecimal digits

[Michael Everson]

O Merciful Sarasvati, hear our prayer

On 8 Jun 2010, at 08:21, Luke-Jr wrote:

> On Tuesday 08 June 2010 01:14:46 am André Szabolcs Szelp wrote:
>> BTW, this is also the main reason why decimal and SI _is_ more usable
>> than any pre-SI system, including the Imperial/English you claim to be
>> superior in several respects.
> 
> All you've done is say "people use decimal" in long form. If one writes and 
> speaks tonal, and adopts the "overall" tonal system, decimal has no 
> advantage... Nystrom addresses all these common (and not so common-- even 
> music!) situations in his book, with exception obviously to digital data 
> sizes (bytes) which are very trivially adapted in with the rest.

Michael Everson * http://www.evertype.com/

Re: Hexadecimal digits

[Mark E. Shoulson]

On 06/08/2010 02:21 AM, Luke-Jr wrote:

On Tuesday 08 June 2010 01:14:46 am André Szabolcs Szelp wrote:

BTW, this is also the main reason why decimal and SI _is_ more usable
than any pre-SI system, including the Imperial/English you claim to be
superior in several respects.


All you've done is say "people use decimal" in long form. If one writes and
speaks tonal, and adopts the "overall" tonal system, decimal has no
advantage... Nystrom addresses all these common (and not so common-- even
music!) situations in his book, with exception obviously to digital data sizes
(bytes) which are very trivially adapted in with the rest.


This is really no longer even marginally relevant.  This has become a 
discussion of why hex counting or decimal counting is or is not 
superior, which is not really something that is subject to judgment 
here.  If all you are doing is pointing out why teaching hex counting is 
better or worse, you shouldn't be posting it here.


~mark

Re: Hexadecimal digits

[Joó Ádám]

> Actually, it's quite a common (mis)-conception, often even used as arguments
> for spelling reforms, that children wouldn't be able to cope with some
> idiosynchrasies of certain orthographic systems. Guess how they coped that
> far...

I was just about to point this one out…


Ádám

RE: Hexadecimal digits

[John Dlugosz]

> The main obstacle to use hexadecimal in human communication are not
> the symbols used in its notation, but that every single human language
> uses 10-based numbers in *speech*, with at most minor deviations (e.g.
> eleven, twelve). The overall system is always 10-based. (10, 100,
> 1000, (1 in indian and chinese), 100) etc.  have their own
> names, numbers composed are to be understood in the decimal system

Yes, when discussing values in hex, this is an English problem.  What do I call 
the useful higher powers and groups?  What is the equivalent of "thousands" or 
"millions" to refer to powers of 65536 or 4294967296?

--John






TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) 
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, 
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and 
subscription company, and TradeStation Europe Limited, a United Kingdom, 
FSA-authorized introducing brokerage firm. None of these companies provides 
trading or investment advice, recommendations or endorsements of any kind. The 
information transmitted is intended only for the person or entity to which it 
is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.

Re: Hexadecimal digits

[Luke-Jr]

On Tuesday 08 June 2010 10:53:15 am John Dlugosz wrote:
> Yes, when discussing values in hex, this is an English problem.  What do I
>  call the useful higher powers and groups?  What is the equivalent of
>  "thousands" or "millions" to refer to powers of 65536 or 4294967296?

Seriously, these questions are all answered in the book...

(written using "classical" hexadecimal digits)
0=Noll  1=An2=De3=Te4=Go5=Su
6=By
7=Ra8=Me9=NiA=Kob=HuC=Vyd=La
E=PoF=Fy10=Ton  100=San 1000=Mill   1,=Bong
1,,=Tam 1,,,=Song   1,,,,=Tran
2,8d5b,7E0F=Detam, memill - lasan - suton - hubong, ramill-posanfy

RE: Hexadecimal digits

[Doug Ewell]

"Luke-Jr"  wrote:

>> Yes, when discussing values in hex, this is an English problem.  What do I
>> call the useful higher powers and groups?  What is the equivalent of
>> "thousands" or "millions" to refer to powers of 65536 or 4294967296?
> 
> Seriously, these questions are all answered in the book...
> 
> (written using "classical" hexadecimal digits)
> 0=Noll1=An2=De3=Te4=Go5=Su
> 6=By
> 7=Ra  8=Me9=NiA=Kob=HuC=Vyd=La
> E=Po  F=Fy10=Ton  100=San 1000=Mill   1,=Bong
> 1,,=Tam   1,,,=Song   1,,,,=Tran
> 2,8d5b,7E0F=Detam, memill - lasan - suton - hubong, ramill-posanfy

I agree with Mark Shoulson that this entire line of argument--whether
hex is better or more "natural" than decimal, how to speak the names of
hexadecimal numbers, and such--is outside the scope of this list.  The
purpose of Unicode is to encode characters that have achieved some
agreed-upon level of actual use in the real world.  It is not a venue
for promoting any sort of reform.

Many people on this list may be personally interested in this
discussion--we do have other interests besides Unicode, after all--but
in that case I suggest prepending "[OT]" to the Subject line to
acknowledge that the thread is Off-Topic with respect to Unicode.

--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ­

Re: Hexadecimal digits

[Mark Davis ☕]

This topic is not particularly relevant to Unicode. Could people please
carry on this discussion on a different list? There are internet groups
devoted to hexadecimal and other topics (eg the adoption of Shavian by the
United Nations) where communities of like-minded people can be found.

Mark

— Il meglio è l’inimico del bene —


On Tue, Jun 8, 2010 at 09:22, Luke-Jr  wrote:

> On Tuesday 08 June 2010 10:53:15 am John Dlugosz wrote:
> > Yes, when discussing values in hex, this is an English problem.  What do
> I
> >  call the useful higher powers and groups?  What is the equivalent of
> >  "thousands" or "millions" to refer to powers of 65536 or 4294967296?
>
> Seriously, these questions are all answered in the book...
>
> (written using "classical" hexadecimal digits)
> 0=Noll  1=An2=De3=Te4=Go5=Su
>  6=By
> 7=Ra8=Me9=NiA=Kob=HuC=Vy
>  d=La
> E=PoF=Fy10=Ton  100=San 1000=Mill   1,=Bong
> 1,,=Tam 1,,,=Song   1,,,,=Tran
> 2,8d5b,7E0F=Detam, memill - lasan - suton - hubong, ramill-posanfy
>
>

Re: Hexadecimal digits

[Sarasvati]

Now, having seen several indications that this topic is straying quite
far from the relevant list topics, the thread should now be closed.
Please close discussion of hex digits and their benefits or move the
discussion to another list.

Regards,
-- Sarasvati

Re: Hexadecimal digits

[Philippe Verdy]

 "Mark Davis ☕"  wrote:
> This topic is not particularly relevant to Unicode. Could people please
> carry on this discussion on a different list? There are internet groups
> devoted to hexadecimal and other topics (eg the adoption of Shavian by the
> United Nations) where communities of like-minded people can be found.
> On Tue, Jun 8, 2010 at 09:22, Luke-Jr  wrote:
>
> > On Tuesday 08 June 2010 10:53:15 am John Dlugosz wrote:
> > > Yes, when discussing values in hex, this is an English problem.  What do
> > I
> > >  call the useful higher powers and groups?  What is the equivalent of
> > >  "thousands" or "millions" to refer to powers of 65536 or 4294967296?
> >
> > Seriously, these questions are all answered in the book...
> >
> > (written using "classical" hexadecimal digits)
> > 0=Noll  1=An2=De3=Te4=Go5=Su
> >  6=By
> > 7=Ra8=Me9=NiA=Kob=HuC=Vy
> >  d=La
> > E=PoF=Fy10=Ton  100=San 1000=Mill   1,=Bong
> > 1,,=Tam 1,,,=Song   1,,,,=Tran
> > 2,8d5b,7E0F=Detam, memill - lasan - suton - hubong, ramill-posanfy

This last message is certainly more on topic there, it discusses
existing characters and their usage in some experimental (mostly
written) language (don't know exactly which ones, may be just the
language used by the initial creator of this system), and the related
localization issues (which could also interest CLDR localizers), even
if they are used by a very small minority. It also helps inderstanding
what could be other issues related to other older numeric systems.

And the 8 characters discussed here (for digits 8..15) are certainly
good subjects for a possible proposal for encoding, even if they will
certianly not fit in the BMP (they could easily fit in the SMP, and
their character properties will certainly not be gc=Nd but gc=No). But
I have no opinion if the 8 first digits (for numeric values 0..7)
should also be reencoded.

Also there's no problem in using characters with different gc in the
same numeric system (after all this is already the case in the common
[0-9a-fA-F]* notation where there are gc=Nd, gc=Ll, and gc=Lu, or with
other indic or african scripts where they may also exist additonal
digits with gc=No for fractions of unity).

There's no extra character needed for the three positional powers of
16 and the 4 positional powers of 16^4 used in the number names: this
is not different from the case of powers of 1000 in the decimal
positional system used in European languages, or the powers of 1
used in some Asian languages, but this is not a problem here for
naming the characters).

Note that the glyph used for one of those digits ressembles to digit 9
(with which it is fully confusable), but it has a distinct numeric
value (for this reason, it should be encoded separately, because of
its distinct abstract identity).

However I'm not sure about which script they should assigned to. For
me this should be the same script property as existing digits 0..9 (of
ASCII), with which they are used together in sequences or arbitrary
order. May be they could be encoded as arbitrary hex digits, and the
code positions U+1xxx0..U+1xxx7 should left free, and assigned only
later if there are similar hexadecimal or octal systems and they can
be unified for having the same abstract properties, and that should
also be given gc=No and not gc=Nd, due to their specific usage). But
here this would be a "political decision" (the glyph, even if it is
not mandatory in ots exact form, is still part of the character
identity, when there's limited possibility for variation and
impossiblity to swap them, so other possible cadidate systems could
easily choose to reuse the glyphs existing ASCII digits 8..9 with
their current value, so that this would conflict with the assignment
of these 8 characters for the "Ton-al" system)

This discussion correctly describes what could be candidate names for
the 8 candidate characters to encode as U+1xxx8..U+1xxxF, if this
"Ton-al" system had to be supported (there may be some interest from
some ISO member to do that for use in their public libraries, in their
digitizing efforts). In fact this set is rather complete and well
documented so that there's no real difficulties.

The fact that this system did not have success (in its time) does not
mean it is out of interest (after all, other extinct scripts were
encoded, but because there's an active community using them at least
for linguistic, archeologic or religious researches.) But here, it is
not really need to help understand an old civilization, when the
system has been created and explained in another modern language and
culture that does not need it. But there may be interest for
reproducing the books, publications and products displaying those 8
characters.

And recent inventions were also encoded as well (notably currency
symbols, and soon there will be emojis), so age of 

RE: Hexadecimal digits

[John Dlugosz]

> This last message is certainly more on topic there, it discusses
> existing characters and their usage in some experimental (mostly

I think so too.

> 
> And the 8 characters discussed here (for digits 8..15) are certainly
> good subjects for a possible proposal for encoding, even if they will
> certianly not fit in the BMP (they could easily fit in the SMP, and
> their character properties will certainly not be gc=Nd but gc=No). But
> I have no opinion if the 8 first digits (for numeric values 0..7)
> should also be reencoded.

The keyboard/printer I first learned to type on, in the late 1970s, did not 
encode a separate glyph for "0"!  It didn't have a "1" either, or an "!".  This 
was a mechanical typewriter from earlier in the century, with formed type bars 
pressing against a ribbon, driven by mechanical force of working each lever.

In typed documents, 0 or O was determined by context, as was 1 or l.  The "!" 
was formed by overstriking apostrophe with period.

In the early days of computing, it was obvious to them that they needed to 
encode digits uniquely, even though we didn't need that before.  It means more 
parts for the printer etc. so there is some commercial pressure against it.

So, our unique digits are grandfathered in.  It was in ASCII and in EBCDIC, so 
it's in Unicode.  Sometime later, assemblers and compilers came along.  The 
writers of these tools had little trouble using context or strict rules to 
distinguish A-F between their role as digits or numbers.  We could do without 
separate U+0030 and U+0031 today just as well:  O is a reserved word in C, 
identifiers that look like numbers (beginning with O or l and containing only 
characters that are used to form numeric literals) would be deemed to be parsed 
as numbers, or use a special mark, or whatever.

So it's only history that some glyphs used as digits are separate and others 
(for Computer Science work anyway) are not.  In practice, we don't need unique 
assignments, in general.  There are characters that are used in numeric 
literals and they are a subset of those used for words in general.






TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) 
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, 
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and 
subscription company, and TradeStation Europe Limited, a United Kingdom, 
FSA-authorized introducing brokerage firm. None of these companies provides 
trading or investment advice, recommendations or endorsements of any kind. The 
information transmitted is intended only for the person or entity to which it 
is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.

Re: Hexadecimal digits

[Robert Abel]

On 2010/06/08 21:43, John Dlugosz wrote:

So, our unique digits are grandfathered in.  It was in ASCII and in EBCDIC, so 
it's in Unicode.  Sometime later, assemblers and compilers came along.  The 
writers of these tools had little trouble using context or strict rules to 
distinguish A-F between their role as digits or numbers.  We could do without 
separate U+0030 and U+0031 today just as well:  O is a reserved word in C, 
identifiers that look like numbers (beginning with O or l and containing only 
characters that are used to form numeric literals) would be deemed to be parsed 
as numbers, or use a special mark, or whatever.

So it's only history that some glyphs used as digits are separate and others 
(for Computer Science work anyway) are not.  In practice, we don't need unique 
assignments, in general.  There are characters that are used in numeric 
literals and they are a subset of those used for words in general
From a parsing point of view this might not matter, however, for 
distinguishing characters by glyph this matters a lot:


0O
1l

Were these the same code points it would be pretty hard to read, because 
we know from handwriting that these characters do look different. 
Usually fixed-width fonts that programmers tend to use will make these 
glyphs distinguishable, because they have to be.


Even worse, some cursive/"handwriting" fonts style digits and the 
respective confusable letters differently. You couldn't do this if they 
were encoded as the same character without having to have contextual 
glyphs ready and some text engine that supports it (and even then you 
couldn't type a zero in a word, because it would be a capital O). 
Usually the styles for characters will differ from digits because digits 
are not written as a whole string without breaks, whereas characters 
usually are. Sure, you could still have the same glyph and make it look 
good, but it wouldn't look natural, nor would it be practical.


So I don't think that we _could do without_ those characters having 
different code points today. Even back then it must have seemed like a 
hack to type a lowercase L instead of a 1.
I think this a neat example of why Unicode encodes the character's 
abstract identity rather than it's shape. That's why we have Han 
unification after all, because some characters have the same abstract 
identity which was preserved, while others, such as our digits do not 
share identities with Latin characters.


Robert

Re: Hexadecimal digits

[Luke-Jr]

On Tuesday 08 June 2010 02:43:22 pm John Dlugosz wrote:
> So it's only history that some glyphs used as digits are separate and
>  others (for Computer Science work anyway) are not.  In practice, we don't
>  need unique assignments, in general.  There are characters that are used
>  in numeric literals and they are a subset of those used for words in
>  general.

I see this as saying that we don't need HTML, XML, or any other content-
describing formats, and arguing that we should stick to a format that merely 
describes the appearance (such as PDF or Postscript) since the meaning can be 
implied from how it appears.

Assuming you don't actually believe that-- why should it be any different on 
the character level?

Finally, there are in fact rendering differences between O and 0 (or else 
nobody would understand your history lacking the words "letter", "number", and 
"symbol"), and it is plausable if the tonal system were encoded that a font 
might like to give visual hints as to the difference between a decimal 2 and a 
tonal 2.

RE: Hexadecimal digits

[Peter Constable]

From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf 
Of John Dlugosz

>> This last message is certainly more on topic there, it discusses 
>> existing characters and their usage in some experimental (mostly

> I think so too.

Then please trim the scope of discussion to discuss *only* those characters, 
not the merits of hexadecimal systems; and to availability of evidence of 
attestation of usage in general publications or interchange -- it has been made 
clear that Unicode will not encode characters for which such adoption is 
*already established*. So far, there is no indication that the characters in 
question are attested in anything beyond nonce usage by Nystrom and private 
usage by individuals.



Peter

RE: Hexadecimal digits

[John Dlugosz]

 
> Were these the same code points it would be pretty hard to read,
> because
> we know from handwriting that these characters do look different.
> Usually fixed-width fonts that programmers tend to use will make these
> glyphs distinguishable, because they have to be.
> 
> Even worse, some cursive/"handwriting" fonts style digits and the
> respective confusable letters differently. You couldn't do this if they
> were encoded as the same character without having to have contextual
> glyphs ready and some text engine that supports it (and even then you
> couldn't type a zero in a word, because it would be a capital O).
> Usually the styles for characters will differ from digits because
> digits
> are not written as a whole string without breaks, whereas characters
> usually are. Sure, you could still have the same glyph and make it look
> good, but it wouldn't look natural, nor would it be practical.
> 
> So I don't think that we _could do without_ those characters having
> different code points today. Even back then it must have seemed like a
> hack to type a lowercase L instead of a 1.
> I think this a neat example of why Unicode encodes the character's
> abstract identity rather than it's shape. That's why we have Han
> unification after all, because some characters have the same abstract
> identity which was preserved, while others, such as our digits do not
> share identities with Latin characters.
> 
> Robert

That reads like an argument _for_ having separate encoding for hex digits.  
Then I could use those rather than markup to make hex numbers look good in the 
surrounding text.  What argument applies to 0 that doesn't apply to A ?


(you can stop reading now)

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) 
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, 
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and 
subscription company, and TradeStation Europe Limited, a United Kingdom, 
FSA-authorized introducing brokerage firm. None of these companies provides 
trading or investment advice, recommendations or endorsements of any kind. The 
information transmitted is intended only for the person or entity to which it 
is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.

Re: Hexadecimal digits

[John H. Jenkins]

Both a decimal 2 and a hexadecimal 2 are an ideogram representing the abstract 
concept of "two-ness," and the latter is derived typographically from the 
former (and, indeed, currently looks exactly like it).  This is comparable to a 
Chinese 二 and a Japanese 二, which we've unified.

Unicode encodes characters, not glyphs.  In order to separately encode a 
hexadecimal-2 separately from an decimal-2, you'd either have to show either 
that the two are, in fact, inherently different characters (in which case you'd 
better be prepared to separately encode the octal-2 and the duodecimal-2 et 
al.), or you'd have to two that widespread existing practice treats them as 
distinct or at least draws them distinctly.  

(And before anybody raises the objection, nobody treats the Chinese 二 and 
Japanese 二 as distinct.  There are other sinograms which look different when 
designed for Chinese use and Japanese use and some people would like to treat 
them as distinct for that reason, but historically and in current practice, 
this is not actually done.)

Indeed, current practice universally treats decimal-0 through decimal-9 as 
hexadecimal-0 through hexadecimal-9 and letter-A/a through letter-F/f as 
hexadecimal-10 through hexadecimal-15.  That practice would have to change 
before any serious attempt at encoding "hexadecimal digits" would be 
considered.  And using letters for numerals has a long and distinguished 
history despite the inherent ambiguities, so there is ample precedent for the 
current practice.

Yes, this does create a chicken-and-egg problem, and whether or not this will 
have a long-term impact on the creation or adoption of new alphabets or new 
typographic practice is an interesting one.  That, however, is irrelevant to 
how Unicode does things.  

In re the tonal system specifically, I note that it uses a glyph for 
hexadecimal-10 which looks (to me, at least) identical with a glyph for 
decimal-9.  This IMHO represents a serious impediment  to the system ever being 
adopted.  I will, however, gladly be proven wrong.

=
井作恆
John H. Jenkins
jenk...@apple.com

Re: Hexadecimal digits

[John H. Jenkins]

Both a decimal 2 and a hexadecimal 2 are an ideogram representing the abstract 
concept of "two-ness," and the latter is derived typographically from the 
former (and, indeed, currently looks exactly like it).  This is comparable to a 
Chinese 二 and a Japanese 二, which we've unified.

Unicode encodes characters, not glyphs.  In order to separately encode a 
hexadecimal-2 separately from an decimal-2, you'd either have to show either 
that the two are, in fact, inherently different characters (in which case you'd 
better be prepared to separately encode the octal-2 and the duodecimal-2 et 
al.), or you'd have to two that widespread existing practice treats them as 
distinct or at least draws them distinctly.  

(And before anybody raises the objection, nobody treats the Chinese 二 and 
Japanese 二 as distinct.  There are other sinograms which look different when 
designed for Chinese use and Japanese use and some people would like to treat 
them as distinct for that reason, but historically and in current practice, 
this is not actually done.)

Indeed, current practice universally treats decimal-0 through decimal-9 as 
hexadecimal-0 through hexadecimal-9 and letter-A/a through letter-F/f as 
hexadecimal-10 through hexadecimal-15.  That practice would have to change 
before any serious attempt at encoding "hexadecimal digits" would be 
considered.  And using letters for numerals has a long and distinguished 
history despite the inherent ambiguities, so there is ample precedent for the 
current practice.

Yes, this does create a chicken-and-egg problem, and whether or not this will 
have a long-term impact on the creation or adoption of new alphabets or new 
typographic practice is an interesting one.  That, however, is irrelevant to 
how Unicode does things.  

In re the tonal system specifically, I note that it uses a glyph for 
hexadecimal-10 which looks (to me, at least) identical with a glyph for 
decimal-9.  This IMHO represents a serious impediment  to the system ever being 
adopted.  I will, however, gladly be proven wrong.

=
井作恆
John H. Jenkins
jenk...@apple.com

Re: Hexadecimal digits

[Robert Abel]

On 2010/06/09 18:16, John Dlugosz wrote:

That reads like an argument _for_ having separate encoding for hex digits.  
Then I could use those rather than markup to make hex numbers look good in the 
surrounding text.  What argument applies to 0 that doesn't apply to A ?
   
I think my argument holds. You will usually find the following 
description of hexadecimal notation: Hexadecimal digits include the 
numbers 0 through 9 and the *letters* A through F (and/or a through f 
respectively). Sometimes it will even say that hexadecimal digits 10 
through 15 are *represented* by *letters* A through F (and/or a through 
f respectively).


This actually happens the way I first thought about them and still think 
about them. They keep their letter identity and are therefore not 
different [digit] characters.


Quick google finds:
http://www.oualline.com/style/c03.html
http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html

Re: Hexadecimal digits

[Luke-Jr]

On Wednesday 09 June 2010 01:16:00 pm Robert Abel wrote:
> On 2010/06/09 18:16, John Dlugosz wrote:
> > That reads like an argument _for_ having separate encoding for hex
> > digits.  Then I could use those rather than markup to make hex numbers
> > look good in the surrounding text.  What argument applies to 0 that
> > doesn't apply to A ?
> 
> I think my argument holds. You will usually find the following
> description of hexadecimal notation: Hexadecimal digits include the
> numbers 0 through 9 and the *letters* A through F (and/or a through f
> respectively). Sometimes it will even say that hexadecimal digits 10
> through 15 are *represented* by *letters* A through F (and/or a through
> f respectively).

Tonal digits representing 8, 10..15 have no relation to letters.

RE: Hexadecimal digits

[John Dlugosz]

> Both a decimal 2 and a hexadecimal 2 are an ideogram representing the
> abstract concept of "two-ness," and the latter is derived
> typographically from the former (and, indeed, currently looks exactly
> like it).  This is comparable to a Chinese 二 and a Japanese 二, which
> we've unified.
> ...
> (And before anybody raises the objection, nobody treats the Chinese 二
> and Japanese 二 as distinct.  There are other sinograms which look
> different when designed for Chinese use and Japanese use and some
> people would like to treat them as distinct for that reason, but
> historically and in current practice, this is not actually done.)

What about the special check-writing form of "two" used in China?  Is that 
merely a different font, or logically a different logogram used for a distinct 
purpose?
How about the radio/PA-speak alternatives for some digits.  For example, on a 
bus I heard the announcer say "yo yo yo!" for 111, and writing 1 (in Chinese) 
would not convey that.  They are based on words, like (roughly) "smallest" for 
1 and "turn the corner" for 7, but are now distinct from them.

As for the normal digit 2, it is the same numeral in any base.  I agree that 
"31" for example does not exude the essence of being hex, so maybe that's your 
point?





TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) 
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, 
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and 
subscription company, and TradeStation Europe Limited, a United Kingdom, 
FSA-authorized introducing brokerage firm. None of these companies provides 
trading or investment advice, recommendations or endorsements of any kind. The 
information transmitted is intended only for the person or entity to which it 
is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.

Re: Hexadecimal digits

[John W Kennedy]

On Jun 8, 2010, at 4:20 PM, Robert Abel wrote:
> So I don't think that we _could do without_ those characters having different 
> code points today. Even back then it must have seemed like a hack to type a 
> lowercase L instead of a 1.

It did, young feller, it did, by cracky! And, as a matter of fact, electric 
typewriters had a slightly different keyboard, one including proper 1, 0, and ! 
keys.

-- 
John W Kennedy
"The bright critics assembled in this volume will doubtless show, in their 
sophisticated and ingenious new ways, that, just as /Pooh/ is suffused with 
humanism, our humanism itself, at this late date, has become full of /Pooh./"
  -- Frederick Crews.  "Postmodern Pooh", Preface

Re: Hexadecimal digits

[Hans Aberg]

On 9 Jun 2010, at 19:55, John H. Jenkins wrote:

Unicode encodes characters, not glyphs.  In order to separately  
encode a hexadecimal-2 separately from an decimal-2, you'd either  
have to show either that the two are, in fact, inherently different  
characters (in which case you'd better be prepared to separately  
encode the octal-2 and the duodecimal-2 et al.), or you'd have to  
two that widespread existing practice treats them as distinct or at  
least draws them distinctly.


Mathematically, they are semantically the same. And if they look the  
same, one still cannot convey that contextual information of the base.  
Some numbers of different bases will be homographs, but in language,  
one lets the context convey what is meant.


The use of prefixes or suffixes to convey the base only serves to make  
a context independent representation of the number. It simplifies a  
traditional lexer-parser implementation of computer languages, as one  
can let the lexer parse it.


  Hans

Re: Hexadecimal digits

[Luke-Jr]

On Wednesday 09 June 2010 03:34:34 pm Hans Aberg wrote:
> On 9 Jun 2010, at 19:55, John H. Jenkins wrote:
> > Unicode encodes characters, not glyphs.  In order to separately
> > encode a hexadecimal-2 separately from an decimal-2, you'd either
> > have to show either that the two are, in fact, inherently different
> > characters (in which case you'd better be prepared to separately
> > encode the octal-2 and the duodecimal-2 et al.), or you'd have to
> > two that widespread existing practice treats them as distinct or at
> > least draws them distinctly.
> 
> Mathematically, they are semantically the same. And if they look the
> same, one still cannot convey that contextual information of the base.
> Some numbers of different bases will be homographs, but in language,
> one lets the context convey what is meant.
> 
> The use of prefixes or suffixes to convey the base only serves to make
> a context independent representation of the number. It simplifies a
> traditional lexer-parser implementation of computer languages, as one
> can let the lexer parse it.

"I have 20 cans." How do you convey the base from that context?

Re: Hexadecimal digits

[Andrew West]

On 9 June 2010 20:42, John Dlugosz  wrote:
>
> What about the special check-writing form of "two" used in China?  Is that 
> merely a different font, or logically a different logogram used for a 
> distinct purpose?

The latter.

> How about the radio/PA-speak alternatives for some digits.  For example, on a 
> bus I heard the announcer say "yo yo yo!" for 111, and writing 1 (in Chinese) 
> would not convey that.

That would be 幺幺幺 yāo yāo yāo. 幺 yāo is the regular spoken substitute
for 一 yī for things like telephone numbers and bus routes (I used to
regularly catch the 三幺幺 bus when I was a student in Beijing). But in
my opinion Chinese characters for number are irrelevant to this
thread.

Andrew

Re: Hexadecimal digits

[Hans Aberg]

On 9 Jun 2010, at 22:48, Luke-Jr wrote:


Mathematically, they are semantically the same. And if they look the
same, one still cannot convey that contextual information of the  
base.

Some numbers of different bases will be homographs, but in language,
one lets the context convey what is meant.

The use of prefixes or suffixes to convey the base only serves to  
make

a context independent representation of the number. It simplifies a
traditional lexer-parser implementation of computer languages, as one
can let the lexer parse it.


"I have 20 cans." How do you convey the base from that context?


You cannot - I said the context must be supplied. Prefix, suffix or  
otherwise.


  Hans

Re: Hexadecimal digits

[Mark E. Shoulson]

On 06/09/2010 04:48 PM, Luke-Jr wrote:


"I have 20 cans." How do you convey the base from that context?


"It's 15 degrees outside."  How do you convey temperature scale 
(Fahrenheit vs Celcius) from context?


Is this still relevant to Unicode?

~mark

Re: Hexadecimal digits

[James Cloos]

> "JWK" == John W Kennedy  writes:

JWK> On Jun 8, 2010, at 4:20 PM, Robert Abel wrote:
>> So I don't think that we _could do without_ those characters having
>> different code points today. Even back then it must have seemed like
>> a hack to type a lowercase L instead of a 1.

JWK> It did, young feller, it did, by cracky! And, as a matter of fact,
JWK> electric typewriters had a slightly different keyboard, one
JWK> including proper 1, 0, and ! keys.

Even many mechanical typewriters did.

(My parents' typewriters were both made by the same company; hers had
the 0 and 1 keys whereas his did not.  Having found and tried out hers
first, when I did play with his -- I was 8 or 9 at the time -- I had
no idea how to type 0 or 1.  Using Oh and el did not occur to me.)
(His was early 1950's vintage, hers late 1950's vintage.)

-JimC
-- 
James Cloos  OpenPGP: 1024D/ED7DAEA6

RE: Hexadecimal digits

[John Dlugosz]

> "I have 20 cans." How do you convey the base from that context?

You have to know that cans come 18 to a flat, and you always specify flats/cans 
in positional notation.





TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) 
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, 
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and 
subscription company, and TradeStation Europe Limited, a United Kingdom, 
FSA-authorized introducing brokerage firm. None of these companies provides 
trading or investment advice, recommendations or endorsements of any kind. The 
information transmitted is intended only for the person or entity to which it 
is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.

Re: Hexadecimal digits?

[Mark E. Shoulson]

When I first heard about hexadecimal, I thought that using A-F for 
digits lacked imagination, and risked confusion with letters besides.  I 
made up a set of digits, as I recall, and even names for them.

I'm not completely convinced this is a bad idea.  But it's likely.

~mark

Michael Everson wrote:

http://www.dkuug.dk/jtc1/sc2/wg2/docs/n2677
N2677
Proposal for six Hexadecimal digits
Ricardo Cancho Niemietz - individual contribution
2003-10-21

RE: Hexadecimal digits?

[Simon Butcher]

Hi :)

> http://www.dkuug.dk/jtc1/sc2/wg2/docs/n2677
> N2677
> Proposal for six Hexadecimal digits
> Ricardo Cancho Niemietz - individual contribution
> 2003-10-21


Could be interesting for processing, and I can see a reason for keeping
these unique from U+0041-U+0046 but ultimately I thought the hex "byte
picture" proposal would have been more useful.

 - Simon

Re: Hexadecimal digits?

[Philippe Verdy]

From: "Simon Butcher" <[EMAIL PROTECTED]>

> > http://www.dkuug.dk/jtc1/sc2/wg2/docs/n2677
> > N2677
> > Proposal for six Hexadecimal digits
> > Ricardo Cancho Niemietz - individual contribution
> > 2003-10-21
> 
>
> Could be interesting for processing, and I can see a reason for keeping
> these unique from U+0041-U+0046 but ultimately I thought the hex "byte
> picture" proposal would have been more useful.

Why that? How will you represent hex sequences with variable number of
nibbles?
The purpose of this proposal is to make those extra characters really
numeric and not letters, with only a compatibility equivalence (not a
canonical one) with ASCII letters to which they ressemble.

Something like:
..;HEX DIGIT FIFTEEN;No;...;LATIN LETTER CAPITAL F

If we have hex bytes, we no longer can represent arbitrary lengths of
nibbles, such as in:
U+1 and U+AFFFD
where the number of digits is odd...

Also, the "hex bytes" are introducing the idea of a bounding box surrounding
them. If full justification (thai style) is applied, we would get such
rendering:
  U  +  [FF]  [FD]
where surrounding boxes could also appear, delimiting bytes.

If odd numbers of digits is not supported, one would have to use a mix of
ASCII letters and "hex bytes", producing unpleasant things like:
  U  +  A  [FF]  [FD]
with differnt styles for digits...

The suggestion of making hex digits presentation forms is good, as well as
ordering them for collation just after the numeric digit 9, and not with
Latin letters, given their expected usage.

RE: Hexadecimal digits?

[Simon Butcher]

Hi Philippe,

> > > http://www.dkuug.dk/jtc1/sc2/wg2/docs/n2677
> > > N2677
> > > Proposal for six Hexadecimal digits
> > > Ricardo Cancho Niemietz - individual contribution
> > > 2003-10-21
> > 
> >
> > Could be interesting for processing, and I can see a reason 
> for keeping
> > these unique from U+0041-U+0046 but ultimately I thought 
> the hex "byte
> > picture" proposal would have been more useful.
> 
> Why that? How will you represent hex sequences with variable number of
> nibbles?
> The purpose of this proposal is to make those extra characters really
> numeric and not letters, with only a compatibility equivalence (not a
> canonical one) with ASCII letters to which they ressemble.


Of course, and I agree with you entirely when you're dealing with an arbitrary number 
of nibbles, and I support this proposal for the same reasons you do.

However personally, when dealing with a octet, or an arbitrary number of octets, I 
believe the byte-pictures would be much easier to deal with (especially when dealing 
with a lot of raw data).

 - Simon

Re: Hexadecimal digits?

[Philippe Verdy]

From: "Simon Butcher" <[EMAIL PROTECTED]>
> However personally, when dealing with a octet, or an arbitrary number
> of octets, I believe the byte-pictures would be much easier to deal with
> (especially when dealing with a lot of raw data).

Except that it would require 256 new codepoints, instead of just 6 for the
proposed HEX DIGIT characters.

What is complicate, when dealing with lot of raw data, to convert it to
nibbles then coded with numeric code points, rather than converting
bytes to code points? You just add a shift and mask operation to output
2 code points rather than just adding each byte as an offset of a base
code point. Still, you need to convert your raw data to suitable code
points to display the HEX BYTE characters.

In fact this shift & mask operation is coded since long and does not
cause any problem to any software, even for performance reasons,
as you still need to allocate an external buffer to store the converted
HEX character sequence.

What you propose is NOT a complementary set of digits for base 16,
but a complete new set of numbers in base 256, so that a glyph
like [00] will be displayed instead of just 0 (this is a disunification
of all the existing ASCII digits, as if it was a new script using its own
numbering system)...

Other historic numbering systems are used today and better suited
for representation, notably the compound base (12, 5), when
people where counting the first digit in one hand with the first finger
pointing on the 3 phallanges of the 4 other fingers, and the other
hand was used to count the second order digit by raising each of
its 5 fingers.

This tradition has survived when counting time
(seconds in minute, hours in day, months in year), and it was an
enhancement of the Roman system where people were counting
fingers (not phallanges) in a compound base (5,2).

The other historic numbering system used a similar compound
base (20, 5), and still survives in the French spelling (in France) of
base numbers 60 and 80 (where it is explicit in its name
"quatre-vingt"). It comes from a medieval tradition, where all
subdivisions of 100 was not 10, but 20, and there were distinctive
names for all numbers from 1 to 19, added to the base-20
subdivision multiple.

Going to base 10 has come very late, when the zero digit was
finally admitted in Europe and borrowed from the Arabic "zifer"
tradition, which created a specific glyph for the 0 (first it was a
simple dot), this inheriting from the Indian tradition where 0 was
represented by a space (but with possible confusion between
101 and 1001, as they where both written as "1 1", and
interpreted contextually).

The _number_ 0 (and negative numbers) only came after
(before, it was simply not written, or a word was used...), when
merchants needed to align their figures in tables to facilitate their
accounting work and were not satisfied by leaving a blank space.