Grammar of letterals and numerals in {li}

[Gleki Arxokuna]

Namely, that mixed lerfu/number strings should be banned.

xorxe's vision quoted at the end of this message.

2015-05-31 20:51 GMT+03:00 Jorge Llambías <jjlla...@gmail.com>:

On Sun, May 31, 2015 at 2:09 PM, Spheniscine (la zipcpi) <sphen...@gmail.com> wrote:

I've not heard of that proposal. Wouldn't that just break all uses of {xy pa} when talking about the definitions of words? 

Those are "xy xi pa".

The contexts where we don't want digits and lerfu to mix (e.g. ".abu za'u re'u cusku", "by re mei", "lo re bolci zo'u pa by xunre .i je pa by blanu", "xy xi pa dunda xy xi re xy xi ci" etc. are much much more common than the need for mixed strings, and having to use "boi" for those is a pain.

So they are to be currently:

abu boi za'u re'u cusku 

i by boi re mei 

i lo re bolci zo'u pa boi by xunre 

.i je pa boi by blanu 

i xy xi pa dunda xy xi re boi xy xi ci 

I can agree that it can be a pain so this proposal may sound reasonable.

Besides, {me'o} still works, paralleling the use of strings for entry of ISO dates in programming languages. I just prefer {li} because

• It's shorter
• Dates and periods technically *are* numbers in a certain sense; arithmetic can be performed on them, despite the fact that in some ways they don't act like real-numbers, due to the varying length of months and years.

"me'o" and "li" are in the same selma'o, so the issue is the same for both.

I can't agree with changing anything within {li}, however. {li} is for mekso which is a special subset of Lojban with its own grammar.

{by} as a anaphorical marker and {by} within {li} are two different entities.

Terminating {li} with {boi} or {lo'o} isn't that hard IMO.

But how would "(n+1.3)^(3.15*r^2)" be expressed under this new xorxe's proposal then?

[Alex Burka]

Agreed, the biggest question for me (beyond whether this is a good idea at all, zo'o zo'o nai) is what changes would be made to the grammar of LI? Would it be able to take a pure-lerfu string, a pure-digit string, but not a mixture? Or would we leave LI alone but create two new gadri selma'o that take pure-lerfu and pure-digit, respectively?

mu'o mi'e durkavore

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

[Jorge Llambías]

On Tue, Jun 2, 2015 at 6:33 AM, Gleki Arxokuna <gleki.is...@gmail.com> wrote:

But how would "(n+1.3)^(3.15*r^2)" be expressed under this new xorxe's proposal then?

The proposal is not at all new, it is quite ancient.

That expression does not involve any mixed digit/lerfu string, therefore the proposal does not affect it. It involves two one-lerfu strings: "n" and "r", and 3 PA-only strings "1.3", "3.15" and "2". No mixed strings.

mu'o mi'e xorxes

[Jorge Llambías]

On Tue, Jun 2, 2015 at 11:47 AM, Alex Burka <dur...@gmail.com> wrote:

Agreed, the biggest question for me (beyond whether this is a good idea at all, zo'o zo'o nai) is what changes would be made to the grammar of LI?

None. It only affects "number" and "lerfu-string" directly. li-clause remains the same:

li-clause <- LI-clause free* mex LOhO-clause? free* 

Would it be able to take a pure-lerfu string, a pure-digit string, but not a mixture?

Among other things, yes. It still takes any mex.

 

Or would we leave LI alone but create two new gadri selma'o that take pure-lerfu and pure-digit, respectively?

We leave LI alone and we don't create anything new.

[Alex Burka]

Ah, I didn't realize that "mex" was separate from "number+lerfu string". So I guess this is entirely orthogonal to la zipcpi's detri1 proposal, even though that thread got hijacked, .u'i.

[Jorge Llambías]

On Tue, Jun 2, 2015 at 5:38 PM, Alex Burka <dur...@gmail.com> wrote:

Ah, I didn't realize that "mex" was separate from "number+lerfu string". So I guess this is entirely orthogonal to la zipcpi's detri1 proposal, even though that thread got hijacked, .u'i.

The proposal to separate of digits and lerfu in strings is not orthogonal to the detri proposal, because the the detri proposal uses numbers that contain lerfu. But both proposals are (relatively) orthogonal to MEX, which is what "li" takes as an argument. 

[Alex Burka]

I remain confused. {li pa} contains a number or mex, or both? {li R2D2}? {li pa su'i pa}? {li pa su'i abu}? And which ones would be killed?

[Jorge Llambías]

On Tue, Jun 2, 2015 at 5:47 PM, Alex Burka <dur...@gmail.com> wrote:

I remain confused. {li pa} contains a number or mex, or both?

It contains a mex that happens to consist of a single operand that happens to consist of a number that happens to consist of a single digit.

 

{li R2D2}?

It contains a mex that happens to consist of a single operand that happens to consist of a lerfu-string that happens to consist of two lerfu mixed with two digits.

 

{li pa su'i pa}? {li pa su'i abu}?

Those contain mex that involve two operands and an operator.

 

And which ones would be killed?

Only "li R2D2", because "R2D2" would no longer be a valid lerfu-string.  

[Bob LeChevalier]

On 6/2/2015 4:38 PM, Alex Burka wrote:
> Ah, I didn't realize that "mex" was separate from "number+lerfu string".
> So I guess this is entirely orthogonal to la zipcpi's detri1 proposal,
> even though that thread got hijacked, .u'i.

The purpose of MEX was to be able to read off *any* mathematical or
programming or other text/series of symbols, and insofar as possible to
have it reflect whatever meaning/structure is intended to be embedded in
that text (respecting any conventions that may be invoked. If a string
of numbers and lerfu can be strung together on a page/screen, then there
needs to be a way to read it out. And there are strings of mixed
numbers and lerfu found all over the place: 5*10E6 being a simple
example, which might have to be read off as a string, or might have to
be read off as a mathematical expression (which is the interpretation of
that string).

I haven't been following this discussion, but I hope that whoever is
making proposals can deal with translating "Which date convention should
I be using to interpret '6/2/2015', 'D/M/YYYY' or 'M/D/YYYY'"?

lojbab

[Bob LeChevalier]

On 6/2/2015 4:54 PM, Jorge Llambías wrote:
> Only "li R2D2", because "R2D2" would no longer be a valid lerfu-string.

So you are claiming that Lojban would not be usable to translate "Star
Wars"?

If a string can be expressed or written, then it is inherently "valid"
as a string, even if it meaningless.

lojbab

[Jorge Llambías]

On Tue, Jun 2, 2015 at 6:34 PM, Bob LeChevalier <loj...@lojban.org> wrote:

On 6/2/2015 4:54 PM, Jorge Llambías wrote:

Only "li R2D2", because "R2D2" would no longer be a valid lerfu-string.

So you are claiming that Lojban would not be usable to translate "Star Wars"?

Of course I'm not claiming anything like that.  In Spanish, BTW, RTD2 is called "Arturito", not "Erre dos de dos".

If a string can be expressed or written, then it is inherently "valid" as a string, even if it meaningless.

 Not sure what that means, but using "no bu", "pa bu", "re bu", etc to read digits as characters might help there. 

More important to me is actually used stuff, like lerfu pronouns around quantifiers, MOI-selbri, and ROI-tenses.

[guskant]

.ie .ui lo se stidi be do cu simlu lo ka xamgu kei fa'e lo se xanka be mi bei ca lo nu gau la gleki cu co'a casnu la'e dei

.i pe'i ma'a ba'a .ei cmicu'a tezu'e lo nu jdice

[Alex Burka]

I agree the {abu boi reroi broda} thing is annoying, but... it's just a terminator. There are a lot of places in Lojban where you have to remember to un-elide terminators in certain situations. I'm not sure this one is annoying _enough_ to change the grammar.

FWIW, la zipcpi's mid-way proposal would be to do the separation for "bare" lerfu/number strings (btw I guess we have to change the definition of {lerfu} if this goes through) but leave mex alone, so {cy ci .ibu} would be two sumti while {li cy ci .ibu} would be one, in other words {li} would take any number of number-strings and/or lerfu-strings, similar to how {la} takes any number of cmevla. It would avoid any changes to mex and preserve things like that really nice date format proposal. On the other hand it reduces consistency a tiny bit.

mu'o mi'e durkavore

[sphen...@gmail.com]

(btw I guess we have to change the definition of {lerfu} if this goes through)

{vlale'u} vs {nacle'u}? {lerfu} doesn't just refer to the Latin alphabet/Arabic numerals; it also applies to things like Tengwar, Cyrillic, and Greek (and in ancient Greek, letters are also used as numbers).

[Gleki Arxokuna]

2015-06-03 3:15 GMT+03:00 Alex Burka <dur...@gmail.com>:

I agree the {abu boi reroi broda} thing is annoying, but... it's just a terminator. There are a lot of places in Lojban where you have to remember to un-elide terminators in certain situations. I'm not sure this one is annoying _enough_ to change the grammar.

Yes, "the first three cups" is still {ci boi pamoi kabri} and nothing can be done.

[Alex Burka]

This also seems to break (or make much less convenient) many usages of {jo'au}, mu'a one of the given examples {cylylypapi'epa jo'au}. You would have to use {lo'u} or something.

[guskant]

Le mercredi 3 juin 2015 15:11:21 UTC, la durka a écrit :

This also seems to break (or make much less convenient) many usages of {jo'au}, mu'a one of the given examples {cylylypapi'epa jo'au}. You would have to use {lo'u} or something.

.ie .i ku'inai mi ba'a .e'i galfi lo mupli lu cylyly jo'au xi papi'epa li'u .o'o

[Alex Burka]

.u'i fegli milxe .i cikre lo pa mupli .iku'i lo lujmau na se cikre

[Jorge Llambías]

On Wed, Jun 3, 2015 at 11:21 AM, Gleki Arxokuna <gleki.is...@gmail.com> wrote:

Yes, "the first three cups" is still {ci boi pamoi kabri} and nothing can be done.

That's actually "three of the first cups". "The first three cups" (assuming only one of them is the first cup) is more complicated. Maybe "lo ci mei pa moi kabri" or "lo pa moi ci mei kabri".

[guskant]

.i pe'i sa'unai la xorxes cu stidi tu'a di'e i zoi peg

number <- PA-clause (PA-clause)*

lerfu-string <- lerfu-word (lerfu-word)*

peg

.i di'e noi genturfa'i cu tutci co cipra lo selkai be la'e di'u po'o .i la'o urli

http://guskant.github.io/gerna_cipra/camxes_namcu-lerfu.html

urli

[guskant]

.i ta'o ru'e fau lonu gau sepli fa la'o peg PA-clause peg fe la'o peg lerfu-word peg kei

pe'i .ei zo pi'e cu gau cmima ma'oi JOI

.i mu'i bo tu'e 

lo'u 

vei pare pi'e ny pi'e bi ve'o

le'u

cu lakne lo ka fadni

.ije tu'a zo pi'e cu rinka lo nu sepli simxu fa lo remei be lo ba'e sezbanzu namcu noi ka'e simxu co frica fi lo ka jicmu

.ibo va'i ganai zo xy jo'u zo zy gi lo'u xy pi'e zy le'u ji'a cu .ei sinxa pa namcu 

tu'u .i pei

 

[Alex Burka]

ma'oi JOI ji ma'oi VUhU

[Alex Burka]

.iji'a lu li pi'epi'epa tcika li'u mu'a cu cumki .i lo'u joi joi le'u na gendra .i mo (to .iku'i lu li vu'uvu'upa li'u ja'a gendra fi lo ca'irselzau .eba'enai lo cipra toi)

[guskant]

Le jeudi 4 juin 2015 04:50:08 UTC, la durka a écrit :

ma'oi JOI ji ma'oi VUhU

.i la'a na.e

.i mu'ibo tu'e

lo'u

li pi'e 2015xiny 6xily 4xidy joi 4xijydy

le'u

cu simsa tu'a lo se studi be la zipcpi 

gi'e ji'a drani ma'i lo cmaci jo'u lo gerna be fi zo pi'e noi cmavo ma'oi VUhU

.i sa'unai zoi zoi

([li {pi'e <(¹[re {no pa mu}] BOI [xi ny BOI]¹) (¹xa BOI [xi ly BOI]¹) (¹vo BOI [xi dy BOI]¹) (¹joi [vo BOI {xi <jy dy> BOI}]¹)> KUhE} LOhO] VAU) 

zoi 

.i lo nu cuxna ma'oi JOI cu na rinka la'e di'u

tu'u

.i .e'u gau cipra fa lo vrici sepi'o la'e di'e

.i zoizoi

http://guskant.github.io/gerna_cipra/camxes_namcu-lerfu-pihe-vuhu.html

http://guskant.github.io/gerna_cipra/camxes_namcu-lerfu-pihe-joi.html

zoi 

[guskant]

Le jeudi 4 juin 2015 06:21:03 UTC, guskant a écrit :

Le jeudi 4 juin 2015 04:50:08 UTC, la durka a écrit :

ma'oi JOI ji ma'oi VUhU

.i la'a na.e

.i mu'ibo tu'e

lo'u

li pi'e 2015xiny 6xily 4xidy joi 4xijydy

le'u

cu simsa tu'a lo se studi be la zipcpi 

gi'e ji'a drani ma'i lo cmaci jo'u lo gerna be fi zo pi'e noi cmavo ma'oi VUhU

i na'i za'a

lo'u

li 4xijydy joi vei pi'e 2015xiny 6xily 4xidy

le'u 

cu xauzma ma'i lo cmaci

[sphen...@gmail.com]

I just wanted to say this.

I see the problem with the {abu za'u re'u cusku} examples; but all those happen *outside* LI...LOhO. They can be fixed without affecting the grammar *inside* LI...LOhO. 

It isn't just about my date system, but also arbitrary character strings; what if you are trying to spell out a character string like 2164763278536578236z ? You'd start reading it as a number without appending {bu} to everything, but then suddenly run into a mabla vlale'u.

I do not see any advantage to affecting LI...LOhO.

[Jorge Llambías]

Would you read it as a number in English though? "Two sixtillions one hundred and sixty-four quintillions ... two hundred and thirty-six zee" (if you are in the US) or "two quadrillions one hundred and sixty-four thousand seven hundred and sixty-three trillions ... and thirty-six zed". I think if it's an arbitrary string of characters, it makes more sense to read it as characters, not as a number.

I do not see any advantage to affecting LI...LOhO.

One advantage would be not having two separate rules.

[Pierre Abbat]

On Sunday, June 07, 2015 06:50:14 sphen...@gmail.com wrote:
> I just wanted to say this.
>
> I see the problem with the {abu za'u re'u cusku} examples; but all those
> happen *outside* LI...LOhO. They can be fixed without affecting the grammar
> *inside* LI...LOhO.
>
> It isn't just about my date system, but also arbitrary character strings;
> what if you are trying to spell out a character string like
> 2164763278536578236z ? You'd start reading it as a number without appending

> {bu} to everything, but then suddenly run into a *mabla vlale'u*.

>
> I do not see any advantage to affecting LI...LOhO.

I just posted on the beginners' list another reason for allowing letterals in
numeral strings. I am a surveyor and have spent hours looking for a monument
given its coordinates and recording coordinates of traverse points.

mu'omi'e .piier. noi xabju lo julra'o be li cimupivomunobiby. sa'i
birepinobivovovy.
--
When a barnacle settles down, its brain disintegrates.
Já não percebe nada, já não percebe nada.

[Jonathan Soo]

We don't do that in English because it is inconvenient. But Lojban numbers are different; they are read digit-by-digit, so it's actually *harder* to add {bu} to everything.

--
You received this message because you are subscribed to a topic in the Google Groups "BPFK" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bpfk-list/GQ9Mnwieue0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bpfk-list+...@googlegroups.com.

[sphen...@gmail.com]

One advantage would be not having two separate rules.

I don't see why that's such a problem. The grammar of LI...LOhO is already unique; that's why it's its own selma'o. And I don't think there are any serious attempts to combine it with any other selma'o, unlike sumtcita.

(Just declare all words to be in selma'o UI, then there'd be no more problems anymore. zo'o)

But seriously, if LI...LOhO is messed with, breaking the functionality of {me'o} (and {li'ai}, which under your proposal might actually be now needed to quote things like R2D2 {li'ai ry re dy re} instead of using it as a bare sumti), we'd be forced to come up with a new selma'o just so we can quote arbitrary character strings without attaching {bu} to every nacle'u.

[Jorge Llambías]

On Mon, Jun 8, 2015 at 8:57 AM, <sphen...@gmail.com> wrote:

One advantage would be not having two separate rules.

I don't see why that's such a problem. The grammar of LI...LOhO is already unique; that's why it's its own selma'o. And I don't think there are any serious attempts to combine it with any other selma'o, unlike sumtcita.

"number" appears in the following contexts in the grammar:

number ROI

number MOI

number MAI

XI number [BOI]

number [BOI] (= quantifier, which in turn can also be an operand)

"lerfu-string" appears in similar (but not identical) contexts:

lerfu-string MOI

lerfu-string MAI

XI lerfu-string [BOI]

lerfu-string [BOI] (= operand)

lerfu-string [BOI] (= sumti)

(Also TEI lerfu-string FOI, which converts a lerfu-string into a lerfu. I don't remember ever seeing it used though.)

The numbers that appear in LI ... LOhO are mex, which can be a single operand, which can be a quantifier or a lerfu-string.

If I understand correctly, you are proposing that "operand" would no longer be "quantifier" or "lerfu-string" (among other things) but some new mixed entity. Whether this is a problem or not depends on your idea of simplicity, and whether or not it's worth striving for.

But seriously, if LI...LOhO is messed with, breaking the functionality of {me'o} (and {li'ai}, 

which under your proposal might actually be now needed to quote things like R2D2 {li'ai ry re dy re} instead of using it as a bare sumti),

As a bare sumti. it's a pronoun, not a name, so that doesn't seem to change. "li'ai ry re bu dy re bu" for R2D2 would be much like "li'ai ny .a bu sy .a bu" for NASA. 

Under your proposal you would still need "boi" or "lo'o" in cases such as "li'ai R2D2 [boi/lo'o/cu] za'u re'u cusku".

we'd be forced to come up with a new selma'o just so we can quote arbitrary character strings without attaching {bu} to every nacle'u.

We now have to attach "bu" to every vowel, is that so different? Lerfu-strings are relatively rare in usage. I just don't see much need to have special rules for them.

[sphen...@gmail.com]

If I understand correctly, you are proposing that "operand" would no longer be "quantifier" or "lerfu-string" (among other things) but some new mixed entity. Whether this is a problem or not depends on your idea of simplicity, and whether or not it's worth striving for.

The thing is in this particular context, it's causing so many problems. Simplicity is worth it up to a point, but not when it causes so many problems.

Don't get me wrong; I actually support your proposal. I'm just trying to come to a compromise for what I and others see is the part of it that causes the most problems, for the least benefit.

 

We now have to attach "bu" to every vowel, is that so different? Lerfu-strings are relatively rare in usage. I just don't see much need to have special rules for them.

For one thing there is an experimental letteral series that uses a'y, e'y, i'y, o'y, and u'y (however, it's not been decided what to do with y'y under this system). For another thing, it introduces opacity to the Lojban numeral system. They are embarrassingly simple compared to most other languages in that they are read out nacle'u by nacle'u. Having to figure out when {bu} needs to be added to them before reading any character string aloud ruins that simplicity.

It's like this. "abu, ebu" etc are treated as one "word" in people's minds, and represent the letters {a} and {e}. However, deciding when to use {pa} and when to use {pabu}, when both are rendered as the simple numeral {1}, introduces practical usage difficulties.

[Gleki Arxokuna]

2015-06-02 23:23 GMT+03:00 Jorge Llambías <jjlla...@gmail.com>:

On Tue, Jun 2, 2015 at 11:47 AM, Alex Burka <dur...@gmail.com> wrote:

Agreed, the biggest question for me (beyond whether this is a good idea at all, zo'o zo'o nai) is what changes would be made to the grammar of LI?

None. It only affects "number" and "lerfu-string" directly. li-clause remains the same:

li-clause <- LI-clause free* mex LOhO-clause? free* 

Would it be able to take a pure-lerfu string, a pure-digit string, but not a mixture?

Among other things, yes. It still takes any mex.

 

Or would we leave LI alone but create two new gadri selma'o that take pure-lerfu and pure-digit, respectively?

We leave LI alone and we don't create anything new.

mu'o mi'e xorxes

could you please provide the full set of changes to PEG?

--

You received this message because you are subscribed to the Google Groups "BPFK" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bpfk-list+...@googlegroups.com.

[Jorge Llambías]

On Tue, Jun 9, 2015 at 8:04 AM, Gleki Arxokuna <gleki.is...@gmail.com> wrote:

could you please provide the full set of changes to PEG?

I think guskant already did:

   number <- PA-clause (PA-clause / lerfu-word)*

   lerfu-string <- lerfu-word (PA-clause / lerfu-word)*
Become:
   number <- PA-clause+

   lerfu-string <- lerfu-word+

[Jorge Llambías]

On Mon, Jun 8, 2015 at 11:38 PM, <sphen...@gmail.com> wrote:

If I understand correctly, you are proposing that "operand" would no longer be "quantifier" or "lerfu-string" (among other things) but some new mixed entity. Whether this is a problem or not depends on your idea of simplicity, and whether or not it's worth striving for.

The thing is in this particular context, it's causing so many problems. Simplicity is worth it up to a point, but not when it causes so many problems.

I guess I don't really see the many problems. I have fallen, and seen others fall, into the "abu za'u re'u cusku" trap and similar traps many times. I don't recall seeing things like "li 827266128281627362816Z" or even like "li R2D2" much in use. 

Don't get me wrong; I actually support your proposal. I'm just trying to come to a compromise for what I and others see is the part of it that causes the most problems, for the least benefit.

For me even for operands the cost outweighs the benefits.

We now have to attach "bu" to every vowel, is that so different? Lerfu-strings are relatively rare in usage. I just don't see much need to have special rules for them.

For one thing there is an experimental letteral series that uses a'y, e'y, i'y, o'y, and u'y (however, it's not been decided what to do with y'y under this system).

We could have pa'y, re'y, ci'y as well if that was an issue (I am NOT proposing these). 

 

For another thing, it introduces opacity to the Lojban numeral system. They are embarrassingly simple compared to most other languages in that they are read out nacle'u by nacle'u. Having to figure out when {bu} needs to be added to them before reading any character string aloud ruins that simplicity. 

It's like this. "abu, ebu" etc are treated as one "word" in people's minds, and represent the letters {a} and {e}. However, deciding when to use {pa} and when to use {pabu}, when both are rendered as the simple numeral {1}, introduces practical usage difficulties.

Having to decide when digits can be mixed with letters and when they can't would introduce more usage difficulties in my opinion. I just don't see lerfu-strings being used that much, let alone ones containing digits.

[guskant]

.i ke'u gau ro ko cipra fa lo vrici sepi'o la'e di'e .i tu'e

1mai : lo namcu lo lerpoi cu gau frica .i zoi urli

http://guskant.github.io/gerna_cipra/camxes_namcu-lerfu.html

urli .i

2mai : lo namcu lo lerpoi cu gau frica .ije zo pi'e gau cmima ma'oi JOI .i zoi urli

http://guskant.github.io/gerna_cipra/camxes_namcu-lerfu-pihe-joi.html

urli .i

3mai : lo namcu lo lerpoi cu gau frica .ije zo pi'e gau cmima ma'oi VUhU .i zoi urli

http://guskant.github.io/gerna_cipra/camxes_namcu-lerfu-pihe-vuhu.html

urli 

tu'u .i mi tugni lo 3mai se stidi ma'i lo si'o melbi gi'e plixau kei vau mi'e la guskant

[sphen...@gmail.com]

I guess I don't really see the many problems. I have fallen, and seen others fall, into the "abu za'u re'u cusku" trap and similar traps many times. I don't recall seeing things like "li 827266128281627362816Z" or even like "li R2D2" much in use. 

It isn't about how common it is; it is that your proposal will make it such that there aren't any good solutions for arbitrary character strings anymore. Many established and proposed conventions (jo'au*, my proposed date system, Pierre's coordinate system)  also depend on arbitrary character strings, often heavy in digits.

* {jo'au}, under my halfway proposal, could be patched by using {mo'e me'o cylyly pa pi'e pa jo'au}

 

Having to decide when digits can be mixed with letters and when they can't would introduce more usage difficulties in my opinion. I just don't see lerfu-strings being used that much, let alone ones containing digits.

LI...LOhO is the only exception; I don't see what's so difficult to grasp about that. 

[sphen...@gmail.com]

Think of it this way. Your proposal will "evict" arbitrary character strings from most of Lojban grammar. And I'd be among the first to agree that it's for a good reason.

But arbitrary character strings are still useful and need a home. It might as well be LI...LOhO.

[And Rosta]

On 9 Jun 2015 22:18, "Jorge Llambías" <jjlla...@gmail.com> wrote:
>
> On Mon, Jun 8, 2015 at 11:38 PM, <sphen...@gmail.com> wrote:
>> For one thing there is an experimental letteral series that uses a'y, e'y, i'y, o'y, and u'y (however, it's not been decided what to do with y'y under this system).
>
>
> We could have pa'y, re'y, ci'y as well if that was an issue (I am NOT proposing these). 

Why not propose those? Or at least include them among candidate solutions.

--And.

[sphen...@gmail.com]

Why not propose those? Or at least include them among candidate solutions.

It would have much the same problems as converting all numerals in character strings to {pabu} etc. would.

[And Rosta]

On 10 Jun 2015 08:49, <sphen...@gmail.com> wrote:
>>
>> Why not propose those? Or at least include them among candidate solutions.
>
>
> It would have much the same problems as converting all numerals in character strings to {pabu} etc. would.

If I've read you right, the problem is that it's burdensome for speakers to have to remember whether they intend to 'refer' to a numeral or to a digit. But isn't such a distinction what you'd want from a logical language?

An advantage of _pa'y_ is that if speakers think of _abu_ or _a'y_ as one word, and that is good, and of _pabu_ as two, and that is bad, then _pa'y_ makes it all good.

--And.

[sphen...@gmail.com]

The problems with pabu / pa'y are:

• They almost double the length of all character strings that are heavy in digits, e.g. my date system and Pierre's coordinate system.
• As for numeral/number distinction... the problem is that that very distinction is often hazy. Take for example the name of the game TIS-100; do those numbers actually mean "one hundred", or are they just an arbitrary string of numerals?

[guskant]

.u'i .ie .i dei gendra ma'i la zantufa_0.1 

(to zoi zoi http://guskant.github.io/gerna_cipra/zantufa-0.1.html zoi .i zoi zoi _ zoi cu dunli zo xi toi)

.i tu'e

coi Ry2'yDy2'y 

.i dei se ciska te'i li pi'e 2015_ny 06_ly 10_dy 09_cy 56_my xo'e_sy te te'i U'yTyCy

.i zantufa bu jo'au_0.1

tu'u mu'o

 

[sphen...@gmail.com]

I appreciate what you're doing, la .guskant., but it's not a complete fix. Irregular numbers and character strings are ubiquitous in everyday life - addresses, license plate numbers, registration numbers, etc.

[Jorge Llambías]

On Wed, Jun 10, 2015 at 5:10 AM, <sphen...@gmail.com> wrote:

The problems with pabu / pa'y are:

• They almost double the length of all character strings that are heavy in digits, e.g. my date system and Pierre's coordinate system.

I think dates and coordinates shouldn't be mere strings of characters, since the numbers within them have meaning as numbers. The parser should be able to identify those numbers as numbers. Guskant's system makes more sense for those.

• As for numeral/number distinction... the problem is that that very distinction is often hazy. Take for example the name of the game TIS-100; do those numbers actually mean "one hundred", or are they just an arbitrary string of numerals?

Is it pronounced "one hundred" or "one zero zero"? It could mean "eight" even, given the topic. What about the name "7-Eleven"? I think names are a different topic, though.

[And Rosta]

sphen...@gmail.com, On 10/06/2015 09:10:

> The problems with pabu / pa'y are:
>

> * They almost double the length of all character strings that are

> heavy in digits, e.g. my date system and Pierre's coordinate system.

IMO a fundamental principle of BPFK work should be not to obsess about syllables, for two related reasons. The first reason is that we need large usage corpora before we can assess which constructions are most responsible for a potentially avoidable excess of syllables. The second reason is that once equipped with that assessment, we could potentially allocate monosyllabic cmavo in the light of it, tho this wouldn't apply to the PA'y/PAbu cases, where one would want the longer cmavo to be morphologically related to the basic PA.

Syllable counting should be verboten in these discussions. Morpheme counting is okay, tho.

> * As for numeral/number distinction... the problem is that that very

> distinction is often hazy. Take for example the name of the game

> TIS-100 <http://www.zachtronics.com/tis-100/>; do those numbers

> actually mean "one hundred", or are they just an arbitrary string of
> numerals?

Etymologizing and translating names isn't a big issue. Is _Christopher_ _la kristofer_ or _la xriso bevri_? The choice is kind of arbitrary. Ditto with the alternative analyses of _TIS-100_.

--And.

[sphen...@gmail.com]

Again, think about addresses (e.g. 11A; technically is a number - do we have to use pa'ypa'y just because of the A at the end of it?), registration numbers, etc.

We can rework systems like my date system or Pierre's coordinate system to fit whatever Lojban evolves to, since they are meant for Lojbanic use. But we can't rework every irregular numeric system in everyday life.

[And Rosta]

sphen...@gmail.com, On 11/06/2015 04:16:

> Again, think about addresses (e.g. 11A; technically is a number - do
> we have to use pa'ypa'y just because of the A at the end of it?),

"11A" is "eleven ay", even if in English it (especially with longer numbers) might be read as "one one ay" (for instance, I pronounce my address as "one seven two"). It means "Ath unit in 11th plot". If you were translating to a language that uses a different number base, you'd translate to that language's term for "eleven", not to that language's term for whichever number is represented by digit string "11". Consulting my meagre knowledge of natural languages, when rendering House number 11 in languages other than English, you'd use that language's conventions for rendering house numbers, which may exclude the "one one" option (as I vaguely think Italian does).

All of which is to say, the rendering of "11A" in Lojban should be something that includes the number Eleven.

OTOH, there is a different sense of "postal address" as a character string such that if written on an envelope it will reliably get sent to the right address. That is just a sequence of letters and numerals.

--And.