From thinkit8@lycos.com Wed Oct 03 04:34:48 2001 Return-Path: X-Sender: thinkit8@lycos.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-7_4_1); 3 Oct 2001 11:34:48 -0000 Received: (qmail 43238 invoked from network); 3 Oct 2001 11:34:48 -0000 Received: from unknown (10.1.10.26) by l7.egroups.com with QMQP; 3 Oct 2001 11:34:48 -0000 Received: from unknown (HELO n28.groups.yahoo.com) (10.1.2.136) by mta1 with SMTP; 3 Oct 2001 11:34:48 -0000 X-eGroups-Return: thinkit8@lycos.com Received: from [10.1.10.67] by n28.groups.yahoo.com with NNFMP; 03 Oct 2001 11:34:46 -0000 Date: Wed, 03 Oct 2001 11:34:46 -0000 To: lojban@yahoogroups.com Subject: Re: periodic hexadecimal reminder Message-ID: <9pet4m+giko@eGroups.com> In-Reply-To: <9pd59l+ubtg@eGroups.com> User-Agent: eGroups-EW/0.82 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Length: 3353 X-Mailer: eGroups Message Poster X-Originating-IP: 24.5.121.32 From: thinkit8@lycos.com rafsi for the hexadecimal numbers have already been proposed and are in the wiki. despite infighting, most agree that rafsi are needed. as for specifying bases, that would be a complete waste of a cmavo. since hexadecimal is default (unless overridden by an irrational adherence to tradition), it's easy. decimal is ju'u dau, and the default is ju'u pano, or something like ju'u no'o. --- In lojban@y..., hfroark@b... wrote: > My first attempt to send this message didn't work for some > reason. > > mark@k... wrote: > > > And no, I don't think we should change the default > > base. I can't think of any advantage to hexadecimal outside of > > computer work and a few specialized related settings (the same can > > also be said for fibonacci base and base-7 (the specialized settings > > part)). > > Incidentally, balanced ternary > ( http://perun.hscs.wmin.ac.uk/~jra/ternary/ternary.html ) > has its applications too. > > But I'm not going to deal with weird bases. One suggestion > noted was using base one. Well one actually can: "pano ju'u > vei pa su'i pa su'i pa su'i pa su'i pa ve'o" that is > "10 base (1+1+1+1+1)" or expressing the base in decimal > "10 base 5" or expressing the base in binary "10 base 101". > My point is that if one feels compelled to be unambiguous > one can; pa is 1 in every base and adding 1's always gives > the same number in any base, even if it may be written in > different ways. One could allow a cmavo to be used so that > one wouldn't have to write all those "pa su'i"'s, but I > don't think that it is common enough to use a cmavo. > > Regarding James Carter's suggestion of expressing the base > by using the radix-1; that is easy to accomplish too: base > two is "ju'i vei pa su'i pa ve'o"; base five, "vo su'i pa"; > base eight, "ze su'i pa"; base ten, "so su'i pa"; base > twelve, "fei su'i pa"; base sixteen, "vai su'i pa". > > However, I like the idea of being able to use dau - vai in > the base directly: This makes base two is "ju'i re"; base > five, "mu"; base eight, "bi"; base ten, "dau"; base > twelve, "gai"; base sixteen, we don't have one. Since > sixteen is the highest (relataively) common base (because > of computers), I'd like to propose that a single cmavo be > added which can be used as an R-expression for "ju'i" that > indicates base sixteen. Considering that in base ten, > sixteen is expressed as paxa. I've thought of using pa'a or > xa'a, for this purpose. Since pa'a is already assigned that > would leave xa'a as my suggestion. > > I do think that consideration should be given to giving the > numbers A - F rafsi. > > There is one other mechanism I would like to see considered: > a way to assign a sticky base, so that one could define a > base at the beginning of a document or section, and have > the later numbers interpreted as the base in question. > Since, this wouldn't be a common operation, I don't think > that a cmavo needs to be assigned for that purpose. > > The most radical part of my suggestion is creating a new > cmavo for use in ju'i to indicate base sixteen. I would not > suggest allowing that cmavo to be used in base seventeen > numbers; indeed my suggested cmavo differs from the other > number cmavo by being polysyllabic. The rest is an obvious > extension of already used mechanisms.