Received-SPF: pass (google.com: domain of ilmen.pokebip@gmail.com designates 2a00:1450:400c:c05::236 as permitted sender) client-ip=2a00:1450:400c:c05::236;
Message-ID: <55CE0D5A.7050601@gmail.com>
Date: Fri, 14 Aug 2015 17:46:34 +0200
From: Ilmen <ilmen.pokebip@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: lojban@googlegroups.com
Subject: Re: [lojban] numeric bases
References: <2b7db954-e6ee-4816-9e3e-20860508b15f@googlegroups.com>
In-Reply-To: <2b7db954-e6ee-4816-9e3e-20860508b15f@googlegroups.com>
Content-Type: multipart/alternative;
 boundary="------------030602090103030201000407"
Reply-To: lojban@googlegroups.com
Precedence: list
Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com
Sender: lojban@googlegroups.com
X-Spam_score: -1.7
X-Spam_score_int: -16
X-Spam_bar: -

This is a multi-part message in MIME format.
--------------030602090103030201000407
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable


On 14/08/2015 00:25, Ben Lubar wrote:
> This discussion came up in IRC, starting about the pronunciation of=20
> the lojban definition of y'y.bu=20
> <http://jbovlaste.lojban.org/dict/y%27y.bu>, {lu y'y.bu li'u bu'ivla=20
> zoi ly.h.ly.}, specifically the {zoi ly.h.ly.} part. Because there is=20
> no word "h" in any language I know of, that definition would be=20
> impossible for a native lojban speaker to pronounce without knowing=20
> 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}:
=E2=80=A2 {zoi ly. .ly noi sa'a sinxa lo latmo lerfu pe lo .y'y zei zunsna}
=E2=80=A2 {zoi ly. .ly noi sa'a sinxa lo se .aski be lu'i li xa bi ju'u bi =
bi'e=20
te'a re}
=E2=80=A2 {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=20
> {se'e li xabi}, but the former could refer to "=C4=84" and the latter to=
=20
> "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=20
> ju'u paxa} for base sixteen.
>
> However, {li pano ju'u paxa} (10 in base sixteen) is the same as {li=20
> 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=20
> {ju'u PA*} implicit, and any {ju'u} with a second argument that is=20
> 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,=20
> 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=20
would have been better for it to be a digit particle. If mekso operators=20
operate on abstract numbers, then {ju'u} should rather be a digit=20
particle like {pi'e} or {ji'i}, because it acts at the digit string=20
level, before an abstract number is extracted from the symbolic digit=20
string.

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

It's why I think the device for indicating the number radix should be=20
part of the number symbol (so a PA cmavo) and not some operator that=20
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=20
dau ju'u re} and {ca'e li ny du li gai .i ma du li vei ny ju'u re},=20
which seem nonsensical to me.


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


mi'e la .ilmen. mu'o


--=20
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 e=
mail 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.

--------------030602090103030201000407
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <br>
    <div class=3D"moz-cite-prefix">On 14/08/2015 00:25, Ben Lubar wrote:<br=
>
    </div>
    <blockquote
      cite=3D"mid:2b7db954-e6ee-4816-9e3e-20860508b15f@googlegroups.com"
      type=3D"cite">
      <div dir=3D"ltr">This discussion came up in IRC, starting about the
        pronunciation of the lojban definition of=C2=A0<a
          moz-do-not-send=3D"true"
          href=3D"http://jbovlaste.lojban.org/dict/y%27y.bu">y'y.bu</a>,
        {lu y'y.bu li'u bu'ivla zoi ly.h.ly.}, specifically the {zoi
        ly.h.ly.}=C2=A0part. 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.
        <div><br>
        </div>
      </div>
    </blockquote>
    There is the English word written "H" and pronounced "aich".<br>
    <br>
    Here are possible ways to read out a written {zoi ly. h .ly}:<br>
    =E2=80=A2 {zoi ly. .ly noi sa'a sinxa lo latmo lerfu pe lo .y'y zei zun=
sna}<br>
    =E2=80=A2 {zoi ly. .ly noi sa'a sinxa lo se .aski be lu'i li xa bi ju'u=
 bi
    bi'e te'a re}<br>
    =E2=80=A2 {zoi ly. .ly noi sa'a sinxa lo se .aski be lu'i li pa mu no j=
u'u
    bi}<br>
    <br>
    <blockquote
      cite=3D"mid:2b7db954-e6ee-4816-9e3e-20860508b15f@googlegroups.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>An alternative definition could be made using {se'e li
          panovo} or {se'e li xabi}, but the former could refer to "=C4=84"
          and the latter to "D". Let's try to solve that problem by
          adding {ju'u}.<br>
          <br>
          Now we have {se'e li panovo ju'u pano} for base ten and {se'e
          li xabi ju'u paxa} for base sixteen.</div>
        <div><br>
        </div>
        <div>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.</div>
        <br>
        Now we have {se'e li xabi ju'u pano ju'u paxa} for base sixteen.
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>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".</div>
        <div><br>
        </div>
        <div>There are two ways this could be solved that I can think
          of:</div>
        <div>
          <ul>
            <li><span style=3D"line-height: normal;">make {se'e} have a
                default base (hexadecimal?)</span></li>
            <li><span style=3D"line-height: normal;">make {ju'u} have a
                default base (decimal?)</span><br>
            </li>
          </ul>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    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).<br>
    <br>
    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).<br>
    <br>
    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.<br>
    <br>
    <br>
    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).<br>
    <br>
    <br>
    mi'e la .ilmen. mu'o<br>
    <br>
    <br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;lojban&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:lojban+unsubscribe@googlegroups.com">lojban+unsub=
scribe@googlegroups.com</a>.<br />
To post to this group, send email to <a href=3D"mailto:lojban@googlegroups.=
com">lojban@googlegroups.com</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/group/lojban">http:=
//groups.google.com/group/lojban</a>.<br />
For more options, visit <a href=3D"https://groups.google.com/d/optout">http=
s://groups.google.com/d/optout</a>.<br />

--------------030602090103030201000407--