[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lojban] numeric bases


On 14/08/2015 00:25, Ben Lubar wrote:
This discussion came up in IRC, starting about the pronunciation of the lojban definition of y'y.bu, {lu y'y.bu li'u bu'ivla zoi ly.h.ly.}, specifically the {zoi ly.h.ly.} part. Because there is no word "h" in any language I know of, that definition would be impossible for a native lojban speaker to pronounce without knowing another language.

There is the English word written "H" and pronounced "aich".

Here are possible ways to read out a written {zoi ly. h .ly}:
• {zoi ly. .ly noi sa'a sinxa lo latmo lerfu pe lo .y'y zei zunsna}
• {zoi ly. .ly noi sa'a sinxa lo se .aski be lu'i li xa bi ju'u bi bi'e te'a re}
• {zoi ly. .ly noi sa'a sinxa lo se .aski be lu'i li pa mu no ju'u bi}

An alternative definition could be made using {se'e li panovo} or {se'e li xabi}, but the former could refer to "Ą" and the latter to "D". Let's try to solve that problem by adding {ju'u}.

Now we have {se'e li panovo ju'u pano} for base ten and {se'e li xabi ju'u paxa} for base sixteen.

However, {li pano ju'u paxa} (10 in base sixteen) is the same as {li paxa} (16), and {ju'u} is an operator and can therefore be chained.

Now we have {se'e li xabi ju'u pano ju'u paxa} for base sixteen.

And because we have no default base, we can make one or both of the {ju'u PA*} implicit, and any {ju'u} with a second argument that is more than one digit long is ambiguous.

I can say {se'e li xabi ju'u vei vai su'i pa ve'o} to be unambiguous, but that's quite a lot longer than the English equivalent of "U+0068".

There are two ways this could be solved that I can think of:
  • make {se'e} have a default base (hexadecimal?)
  • make {ju'u} have a default base (decimal?)

I don't like much the fact that {ju'u} is an operator though; I think it would have been better for it to be a digit particle. If mekso operators operate on abstract numbers, then {ju'u} should rather be a digit particle like {pi'e} or {ji'i}, because it acts at the digit string level, before an abstract number is extracted from the symbolic digit string.

First you have a sequence of digit symbols representing the positional notation of an abstract number with a set of digits, whose size is the number base/radix. In order to extract a number from a digit string, you need to know which number radix it is encoded with (the radix may either be explicitly part of the number symbolic notation or otherwise be inferred from context, for example if there is a previously specified or traditional default radix).

It's why I think the device for indicating the number radix should be part of the number symbol (so a PA cmavo) and not some operator that would take abstract numbers as an input (such as VUhU cmavo).

The current grammar of {ju'u} allows for things like {vei pa bi'e su'i dau ju'u re} and {ca'e li ny du li gai .i ma du li vei ny ju'u re}, which seem nonsensical to me.


As for the default base, I wouldn't much like it to defaults to ten by definition, as it wouldn't be culturally neutral (although ten is by far the most common number radix nowadays, some cultures do use other radices for encoding their numbers). I'd be in favor of adding a cmavo of class MAI for specifying the default number radix for the following text until another default is given; in lack of any default and explicit radix, the number radix would be inferred from context (for example the standard default in effect where and when the text has been produced).


mi'e la .ilmen. mu'o


--
You received this message because you are subscribed to the Google Groups "lojban" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lojban+unsubscribe@googlegroups.com.
To post to this group, send email to lojban@googlegroups.com.
Visit this group at http://groups.google.com/group/lojban.
For more options, visit https://groups.google.com/d/optout.