# Talk:number subgrammar

Rob:

> digit digits thousand whole decimal2 decimal1 decimal digitplace tuple real indef component fraction complex quantity range fuzzy number

> Re: Number subgrammar > > Rob: > > > digit digits thousand whole decimal2 decimal1 decimal digitplace > tuple real indef component fraction complex quantity range fuzzy > number

I don't understand how what I wrote turned into that. Second try:

> digit <- NO / TUhO > digits <- digit+ > thousand <- digits KIhO > whole <- thousand+ digits > decimal2 <- whole (PI digits (RAhE digits)?)? / PAI

What happens to {ki'o} without leading digits? What about {ki'o} after {pi} to separate thousandths?

> decimal1 <- MAhU? decimal2 / MAhU > decimal <- decimal1 CEhI? > digitplace <- decimal PIhE? > tuple <- digitplace+ > real <- decimal / tuple > indef <- PI? RO / TUhO > component <- real / indef > fraction <- component FIhU fraction / component

What about {fi'u} without anything in front?

> complex <- fraction? KAhO fraction? / fraction > quantity <- component / fraction / DAhA quantity > range <- SUhO quantity?

What about {da'a su'o ci}, "all but at least three"?

> fuzzy <- complex JIhI complex > number <- quantity / complex / fuzzy / range / indef number

I would allow two quantities/ranges in a row. The meaning would be:

1- When the two ranges intersect, the intersection:

za'ucime'iso = more than three and less than nine.

2- When the two ranges don't intersect, the union:

me'ivoza'uvo = less than four or more than four (i.e. other than four).

3- When one of the quantities is definite and the other indefinite, they are identified:

rauci = three, which is enough roci = all three

CLL does not mention 1 or 2 (I think) but it does have examples of 3.

mu'o mi'e xorxes

'''''''''''''''''''''''''''''''''''''''''''** __ **
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

On Sat, Jul 10, 2004 at 01:34:04PM -0700, Jorge Llamb?as wrote: > What happens to {ki'o} without leading digits? > What about {ki'o} after {pi} to separate thousandths?

I don't know what happens to ki'o without leading digits. Any suggestions?

I also don't know what happens after {pi}. The book's examples are bizarre.

3.9) pi ki'o re re point comma two two .022

So did the digits back up? When would they start going to the right again? Or did the first ki'o only add a single zero?

3.10) pi pa ki'o pa re ki'o pa point one comma one two comma one .101012001

Where did the fourth 1 come from? How in the world are we supposed to determine what places are being jumped to?

I suppose I could allow {ki'o} after {pi} and assume someone will come up with a consistent system.

> > decimal1 <- MAhU? decimal2 / MAhU > > decimal <- decimal1 CEhI? > > digitplace <- decimal PIhE? > > tuple <- digitplace+ > > real <- decimal / tuple > > indef <- PI? RO / TUhO > > component <- real / indef > > fraction <- component FIhU fraction / component > > What about {fi'u} without anything in front?

I thought I had question marks there. I must have shuffled some rules around and forgotten them. That was certainly my intention.

> > complex <- fraction? KAhO fraction? / fraction > > quantity <- component / fraction / DAhA quantity > > range <- SUhO quantity? > > What about {da'a su'o ci}, "all but at least three"?

Darn. Guess I'll need to allow either DAhA or SUhO at two different levels.

> > fuzzy <- complex JIhI complex > > number <- quantity / complex / fuzzy / range / indef number > > I would allow two quantities/ranges in a row. The meaning would be: > > 1- When the two ranges intersect, the intersection: > > za'ucime'iso = more than three and less than nine. > > 2- When the two ranges don't intersect, the union: > > me'ivoza'uvo = less than four or more than four (i.e. other than four).

Useful. I'll account for that.

> 3- When one of the quantities is definite and the other indefinite, they > are identified:

Yeah, that's what the "indef number" part does (though I have to move it forward in the list, or else the parser never gets there. There are other problems like that in this version, too, such as "re" before "rei".)

-- Rob Speer

Rob: > I don't know what happens to ki'o without leading digits. Any suggestions?

ki'o is 1,000. ki'opa is 1,001 ki'oreki'ocino is 1,002,030

> I also don't know what happens after {pi}. The book's examples are bizarre. > > 3.9) pi ki'o re re > point comma two two > .022

I would have said that was .000,22

> So did the digits back up? When would they start going to the right again? Or > did the first ki'o only add a single zero?

In my view, ki'o marks the thousands/thousadths, so

pireki'o = .002 picimuki'o = .035 piki'ore = .000,2 (piki'o = .001)

> 3.10) pi pa ki'o pa re ki'o pa > point one comma one two comma one > .101012001 > > Where did the fourth 1 come from? How in the world are we supposed to > determine what places are being jumped to?

I would have said:

..001,012,1

> I suppose I could allow {ki'o} after {pi} and assume someone will come up > with > a consistent system.

The ki'o always indicates three positions from pi or from the next ki'o. The only question is where the fill in zeroes go. I would guess ki'o to the left of pi fills in zeroes to its right, a ki'o to the right fills in zeroes to the left.

mu'o mi'e xorxes

'''''''''''''''''''''''''''''''''''''''''''** __ **
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

I'm not sure I understand the pi'e / pi thing correctly.

In your current version, let's say we're dealing with base 20 numbers.

pa no pi re pi'e pa re pi mu == (11.2 * 20) + (12.5 * 1) == 236.5, correct?

In the CLL version, the above is illegal, but:

pa no pi'e pa re pi mu == (11 * 20) + (12 * 1) + (5 * (1/20)) == 232, correct?

My question is, is there a way to get the second one in your system?

-Robin

> My question is, is there a way to get the second one in your system? > > -Robin

Hmmm...

The problem is that Rob and I are defining pi'e more broadly than as a high base digit separator. We allow pi'e for any tuple, where the components can be signed numbers, I even allow fractions and complex numbers as tuple components. This means that {pi} cannot separate more strongly than {pi'e}. Maybe we could define {pipi} as the integer part separator for tuples? General tuples seem more useful than high base numbers.

mu'o mi'e xorxes

'''''''''''''''''''''''''''''''''''''''''''** __ **
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

On Tue, Jul 13, 2004 at 06:47:20AM -0700, Jorge Llamb?as wrote: > > > My question is, is there a way to get the second one in your system? > > > > -Robin > > Hmmm... > > The problem is that Rob and I are defining pi'e more broadly than as a > high base digit separator. We allow pi'e for any tuple, where the > components can be signed numbers, I even allow fractions and complex > numbers as tuple components.

OK. John has made it very clear that this is *not* the purpose of pi'e, that jo'i is the general tuple creator.

> This means that {pi} cannot separate more strongly than {pi'e}. Maybe > we could define {pipi} as the integer part separator for tuples? > General tuples seem more useful than high base numbers.

Seems like the easiest thing is to call LfB's usage of pi'e wrong (it's not even a finished book, so this is no problem) and jump on jo'i.

-Robin

Robin: > OK. John has made it very clear that this is *not* the purpose of pi'e, > that jo'i is the general tuple creator.

I changed my grammar accordingly. Now pi'e can mix freely with the digits and with ki'o. I think {ki'o} should bind closer than {pi'e}, so there would be no grouping comma for high base macro-digits. Or maybe it should be the other way around? What are more frequent, less-than-four-digit numbers in bases higher than 1000, or more-than-three-digit numbers in bases higher than 16? Probably both are so infrequent that it is not worth having a rule for this. Let's just say that combining ki'o and pi'e is bad.

mu'o mi'e xorxes

'''''''''''''''''''''''''''''''''''''''''''** __ **
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

On Tue, Jul 13, 2004 at 09:32:14AM -0700, Jorge Llamb?as wrote: > What are more frequent, less-than-four-digit numbers in bases higher > than 1000, or more-than-three-digit numbers in bases higher than 16?

Which is more common, unicorns or truly honest men?

> Probably both are so infrequent that it is not worth having a rule for > this. Let's just say that combining ki'o and pi'e is bad.

..ie sai

-Robin

Jorge Llamb?as scripsit: > Robin: > > OK. John has made it very clear that this is *not* the purpose of pi'e, > > that jo'i is the general tuple creator. > > I changed my grammar accordingly. Now pi'e can mix freely with the > digits and with ki'o. I think {ki'o} should bind closer than {pi'e}, > so there would be no grouping comma for high base macro-digits. Or > maybe it should be the other way around? What are more frequent, > less-than-four-digit numbers in bases higher than 1000, or > more-than-three-digit numbers in bases higher than 16? Probably both > are so infrequent that it is not worth having a rule for this.

Probably, but I should say that long numbers in low bases are more likely than extremely high bases. I have used base 1000 myself, but nothing higher.

-- A poetical purist named Cowan that's me: cowan@ccil.org Once put the rest of us dowan. on xml-dev "Your verse would be sweeter http://www.ccil.org/~cowan If it only had metre http://www.reutershealth.com And rhymes that didn't force me to frowan." overpacked line! --Michael Kay

On Tue, Jul 13, 2004 at 09:17:54AM -0700, Robin Lee Powell wrote: > > Hmmm... > > > > The problem is that Rob and I are defining pi'e more broadly than as a > > high base digit separator. We allow pi'e for any tuple, where the > > components can be signed numbers, I even allow fractions and complex > > numbers as tuple components. > > OK. John has made it very clear that this is *not* the purpose of pi'e, > that jo'i is the general tuple creator.

Okay. So should we learn to say times like: lijo'i pamu boi cize cu ca tcika instead of: li pamu pi'e cize ca tcika ?

(And why in the world does jbofi'e require {cu} there?)

Dates and times really are tuples, not weird bases. We don't think of the components of a time as being digits. Dates aren't even in a consistent base. And even outside of Lojban, you can express a very precise time with a decimal point after the seconds, and people understand exactly what you mean.

When expressing times and dates, we sometimes elide numbers in a different way than you would expect based on where the mixed-base decimal point is. For dates, the numbers even go in the wrong direction half the time.

If pi'e cannot be a tuple, then times and dates would need to use jo'i.

I think that using jo'i here is too wordy. I would prefer an alternate convention: {pi} is allowed inside a {pi'e} part, except that {pipi'e} is a mixed-base decimal point. (Incidentally, few people realize you can have a decimal point er, radix point in any base other than 10, let alone would want to use one for base 17 or above, so I think the extra syllable is justified.)

So my interpretation is that {pi'e} has been taken over to make a tuple, and that the way we can express numbers in large bases is with a pi'e-tuple.

The alternative is to keep the shorter form reserved only for speaking in actual bases above 16, which nobody uses.

-- Rob Speer

Rob: > Okay. So should we learn to say times like: > lijo'i pamu boi cize cu ca tcika > instead of: > li pamu pi'e cize ca tcika > ? > > (And why in the world does jbofi'e require {cu} there?)

Because {ca} could be the beginning of a third operand for jo'i: {ca gi pa gi re}. Presumably Robin's parser can do without {cu} there.

> If pi'e cannot be a tuple, then times and dates would need to use jo'i.

CLL says that the base of each digit can be "vague", so times where the digits after the decimal point are decimal seconds, and even dates might still qualify, stretching the sense of base a bit. But we couldn't use pi'e fore tuples of signed numbers, fractions or complex numbers.

> I think that using jo'i here is too wordy. I would prefer an alternate > convention: {pi} is allowed inside a {pi'e} part, except that {pipi'e} is a > mixed-base decimal point.

That could work.

> So my interpretation is that {pi'e} has been taken over to make a tuple, and > that the way we can express numbers in large bases is with a pi'e-tuple.

I'm not convinced one way or the other at this point. Dates and times are not definitory for me because they can be accomodated into the base scheme, even if it's a bit of a stretch. Are there other interesting uses for tuples that we would want to have covered by pi'e?

mu'o mi'e xorxes

'''''''''''''''''''''''''''''''''''''''''''** __ **
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

On Tue, Jul 13, 2004 at 04:02:07PM -0400, Rob Speer wrote: > On Tue, Jul 13, 2004 at 09:17:54AM -0700, Robin Lee Powell wrote: > > > Hmmm... > > > > > > The problem is that Rob and I are defining pi'e more broadly than > > > as a high base digit separator. We allow pi'e for any tuple, where > > > the components can be signed numbers, I even allow fractions and > > > complex numbers as tuple components. > > > > OK. John has made it very clear that this is *not* the purpose of > > pi'e, that jo'i is the general tuple creator. > > Okay. So should we learn to say times like: > > lijo'i pamu boi cize cu ca tcika > > instead of: > > li pamu pi'e cize ca tcika > > ?

Only if you're using "pi" with your times, I would say.

> (And why in the world does jbofi'e require {cu} there?)

I have no idea. Mine doesn't, of course.

> Dates and times really are tuples, not weird bases.

I agree.

> We don't think of the components of a time as being digits. Dates > aren't even in a consistent base.

Yep.

> And even outside of Lojban, you can express a very precise time with a > decimal point after the seconds, and people understand exactly what > you mean.

Yep.

> When expressing times and dates, we sometimes elide numbers in a > different way than you would expect based on where the mixed-base > decimal point is. For dates, the numbers even go in the wrong > direction half the time.

Yep.

> If pi'e cannot be a tuple, then times and dates would need to use jo'i.

Yep.

> I think that using jo'i here is too wordy.

Because of the need for boi? That's the only change, in terms of wordiness.

> I would prefer an alternate convention: {pi} is allowed inside a > {pi'e} part, except that {pipi'e} is a mixed-base decimal point. > (Incidentally, few people realize you can have a decimal point [http://www.lojban.org/tiki/er,%3Cbr%20/%3E%3E%20radix%20point er, > radix point] in any base other than 10, let alone would want to use > one for base 17 or above, so I think the extra syllable is justified.)

That seems very reasonable to me, but it is unquestionably a change to what's described in the CLL.

> So my interpretation is that {pi'e} has been taken over to make a > tuple, and that the way we can express numbers in large bases is with > a pi'e-tuple.

That means we have two ways to do the same thing, which isn't necessarily a problem.

> The alternative is to keep the shorter form reserved only for speaking > in actual bases above 16, which nobody uses.

Yep.

-Robin

On Tue, Jul 13, 2004 at 02:03:07PM -0700, Jorge Llamb?as wrote: > Rob: > > Okay. So should we learn to say times like: lijo'i pamu boi cize cu > > ca tcika instead of: li pamu pi'e cize ca tcika ? > > > > (And why in the world does jbofi'e require {cu} there?) > > Because {ca} could be the beginning of a third operand for jo'i: {ca > gi pa gi re}.

That's a valid mex argument? Apparently. Ick.

> Presumably Robin's parser can do without {cu} there.

Indeed.

> > If pi'e cannot be a tuple, then times and dates would need to use > > jo'i. > > CLL says that the base of each digit can be "vague", so times where > the digits after the decimal point are decimal seconds, and even dates > might still qualify, stretching the sense of base a bit. But we > couldn't use pi'e fore tuples of signed numbers, fractions or complex > numbers.

Which was why I said that you only need to use jo'i if you actually need pi internal to the number.

-Robin

Rob Speer scripsit:

> Okay. So should we learn to say times like: > lijo'i pamu boi cize cu ca tcika > instead of: > li pamu pi'e cize ca tcika > ?

No. Lojbanic times aren't tuples, they are numbers written in base 60 representing either minutes (when there are two bigits) or seconds (when there are three). Dates are likewise numbers, but written to a so-called "compound base"; that is, one that varies from bigit to bigit.

> (And why in the world does jbofi'e require {cu} there?)

Ya got me. The official parser does not.

-- John Cowan http://www.reutershealth.com "But no living man am I! You look upon a woman. Eowyn I am, Eomund's daughter. You stand between me and my lord and kin. Begone, if you be not deathless. For living or dark undead, I will smite you if you touch him."

John Cowan wrote:

> Dates are likewise numbers, but written to a >so-called "compound base"; that is, one that varies from bigit to bigit. > >

"Bigit"? "Bigit" is an archaic synonym for "bit".

--
Though the tomb itself will be off-limits, the general public will be allowed access to a nearby altar and a bronze idol of Reagan, where Republican pilgrims may come to worship the former president and petition his intervention in prayer.

John Cowan: > Lojbanic times aren't tuples, they are numbers written in base 60 > representing either minutes (when there are two bigits) or seconds > (when there are three).

The hour bigit is base 24, of course. And in either case, after the matrix point {pi} we switch to base ten, with no pi'e separator for the decimal digits.

> Dates are likewise numbers, but written to a > so-called "compound base"; that is, one that varies from bigit to bigit.

The base for the day bigit is a function of the month bigit, and I don't know what the base for the year bigit is.

> > (And why in the world does jbofi'e require {cu} there?) > > Ya got me. The official parser does not.

Does the official parser handle {li ca gi pa gi re}?

mu'o mi'e xorxes

'''''''''''''''''''''''''''''''''''''''''''** __ **
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

Robin Lee Powell: > On Tue, Jul 13, 2004 at 02:03:07PM -0700, Jorge Llamb?as wrote: > > CLL says that the base of each digit can be "vague", so times where > > the digits after the decimal point are decimal seconds, and even dates > > might still qualify, stretching the sense of base a bit. But we > > couldn't use pi'e fore tuples of signed numbers, fractions or complex > > numbers. > > Which was why I said that you only need to use jo'i if you actually need > pi internal to the number.

So you would not want to allow, for example {li paso pi'e mi'u pamu} for "a quarter to seven"?

mu'o mi'e xorxes

'''''''''''''''''''''''''''''''''''''''''''** __ **
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

On Tue, Jul 13, 2004 at 02:35:34PM -0700, Jorge Llamb?as wrote: > > > (And why in the world does jbofi'e require {cu} there?) > > > > Ya got me. The official parser does not. > > Does the official parser handle {li ca gi pa gi re}?

({li <[ca gi] [pa BOI] gi [re BOI]> LO'O} VAU)

-Robin

xod scripsit:

> "Bigit"? "Bigit" is an archaic synonym for "bit".

In this context, it's a lujvo for "big digit".

-- John Cowan jcowan@reutershealth.com www.reutershealth.com ccil.org/~cowan Dievas dave dantis; Dievas duos duonos --Lithuanian proverb Deus dedit dentes; deus dabit panem --Latin version thereof Deity donated dentition; deity'll donate doughnuts --English version by Muke Tever God gave gums; God'll give granary --Version by Mat McVeagh

Jorge Llamb?as scripsit:

> The hour bigit is base 24, of course.

It can be, but doesn't have to be: an elapsed time may be 222 hours 22 minutes 22 seconds.

> And in either case, after the > matrix point {pi} we switch to base ten, with no pi'e separator for > the decimal digits.

So we do. Convention is everything.

> The base for the day bigit is a function of the month bigit, and > I don't know what the base for the year bigit is.

Quite so.

> Does the official parser handle {li ca gi pa gi re}?

Yes.

-- He played King Lear as though John Cowan someone had played the ace. http://www.ccil.org/~cowan --Eugene Field http://www.reutershealth.com

> > > > (And why in the world does jbofi'e require {cu} there?) > > > > > > Ya got me. The official parser does not. > > > > Does the official parser handle {li ca gi pa gi re}? > > ({li <[ca gi] [pa BOI] gi [re BOI]> LO'O} VAU)

Then I don't know why jbofi'e requires {cu} there.

mi'e xorxes

'''''''''''''''''''''''''''''''''''''''''''** __ **
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

On Tue, Jul 13, 2004 at 02:41:04PM -0700, Jorge Llamb?as wrote: > Robin Lee Powell: > > On Tue, Jul 13, 2004 at 02:03:07PM -0700, Jorge Llamb?as wrote: > > > CLL says that the base of each digit can be "vague", so times > > > where the digits after the decimal point are decimal seconds, and > > > even dates might still qualify, stretching the sense of base a > > > bit. But we couldn't use pi'e fore tuples of signed numbers, > > > fractions or complex numbers. > > > > Which was why I said that you only need to use jo'i if you actually > > need pi internal to the number. > > So you would not want to allow, for example {li paso pi'e mi'u pamu} > for "a quarter to seven"?

Did you mean ni'u there?

I have no problems with that; numbers in any base boil down to mod , and that's what negative numbers do in a module context.

-Robin

Robin: > > So you would not want to allow, for example {li paso pi'e mi'u pamu} > > for "a quarter to seven"? > > Did you mean ni'u there?

Yes, sorry.

> I have no problems with that; numbers in any base boil down to > mod , and that's what negative numbers do in a module context.

But {ni'u} normally applies to the whole string of digits, just like {pi}. If you allow {ni'u} for a single digit, why not {pi} as well?

What would you do with {ni'u} on the first digit, does it reverse the whole number, or just that digit?

mu'o mi'e xorxes

'''''''''''''''''''''''''''''''''''''''''''** __ **
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo

On Tuesday 13 July 2004 12:32, Jorge "Llambías" wrote: > I changed my grammar accordingly. Now pi'e can mix freely with the > digits and with ki'o. I think {ki'o} should bind closer than {pi'e}, > so there would be no grouping comma for high base macro-digits. Or > maybe it should be the other way around? What are more frequent, > less-than-four-digit numbers in bases higher than 1000, or > more-than-three-digit numbers in bases higher than 16? Probably both > are so infrequent that it is not worth having a rule for this. Let's > just say that combining ki'o and pi'e is bad.

Should we have a convention that ki'o in certain bases groups by fours? Hex numbers are more commonly grouped in four nybbles than three.

Some peoples (such as Japanese and Ancient Greek) group digits in fours in decimal (Ancient Greeks didn't have Arabic numerals, but they spoke in myriads). And the Indians write 2,14,74,83,647 and have names for odd powers of 10. But Lojban, like English, counts by thousands in base 10.

phma -- li fi'u vu'u fi'u fi'u du li pa

On Wed, Jul 14, 2004 at 12:15:25PM -0700, Jorge Llamb?as wrote: > Robin: > > > So you would not want to allow, for example {li paso pi'e mi'u > > > pamu} for "a quarter to seven"? > > > > Did you mean ni'u there? > > Yes, sorry. > > > I have no problems with that; numbers in any base boil down to > > mod , and that's what negative numbers do in a module > > context. > > But {ni'u} normally applies to the whole string of digits, just like > {pi}. If you allow {ni'u} for a single digit, why not {pi} as well?

I guess we can't allow that, then, without using jo'i.

-Robin

On Wednesday 14 July 2004 15:15, Jorge "Llambías" wrote: > But {ni'u} normally applies to the whole string of digits, just like > {pi}. If you allow {ni'u} for a single digit, why not {pi} as well? > > What would you do with {ni'u} on the first digit, does it reverse > the whole number, or just that digit?

What about negative bases? Numbers in base -10 don't need ni'u; they go like this: ...., 20, 21, 22, ..., 29, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 190, 191, 192, ... 199, 180, 181, ... I once played Lego with a neighborhood kid and got him to count like that.

It is also possible to express imaginary numbers in base 1-i, without using ni'u or ka'o. (1+i doesn't work. Why?)

phma -- li fi'u vu'u fi'u fi'u du li pa

On Tue, Jul 20, 2004 at 06:43:44PM -0400, Pierre Abbat wrote: > It is also possible to express imaginary numbers in base 1-i, without > using ni'u or ka'o. (1+i doesn't work. Why?)

"1+i" doesn't work in what sense?

-Robin

-- http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ Reason #237 To Learn Lojban: "Homonyms: Their Grate!"

> Should we have a convention that ki'o in certain bases groups by fours? Hex > numbers are more commonly grouped in four nybbles than three.

Makes sense.

> Some peoples (such as Japanese and Ancient Greek) group digits in fours in > decimal (Ancient Greeks didn't have Arabic numerals, but they spoke in > myriads). And the Indians write 2,14,74,83,647 and have names for odd powers > of 10. But Lojban, like English, counts by thousands in base 10.

I guess the grouping conventions of ki'o can be left to context, or specified in each case. It doesn't really affect my grammar, only its interpretation.

mu'o mi'e xorxes

'''''''''''''''''''''''''''''''''''''''''''** __ **
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

On Tuesday 20 July 2004 18:49, Robin Lee Powell wrote: > On Tue, Jul 20, 2004 at 06:43:44PM -0400, Pierre Abbat wrote: > > It is also possible to express imaginary numbers in base 1-i, without > > using ni'u or ka'o. (1+i doesn't work. Why?) > > "1+i" doesn't work in what sense?

I think you're asking the same thing I'm asking. The representation is binary in base 1+i or 1-i; base 1-i works, but base 1+i doesn't.

phma -- li fi'u vu'u fi'u fi'u du li pa

On Wed, Jul 21, 2004 at 10:59:16PM -0400, Pierre Abbat wrote: > On Tuesday 20 July 2004 18:49, Robin Lee Powell wrote: > > On Tue, Jul 20, 2004 at 06:43:44PM -0400, Pierre Abbat wrote: > > > It is also possible to express imaginary numbers in base 1-i, > > > without using ni'u or ka'o. (1+i doesn't work. Why?) > > > > "1+i" doesn't work in what sense? > > I think you're asking the same thing I'm asking. The representation is > binary in base 1+i or 1-i; base 1-i works, but base 1+i doesn't.

I'm sorry, I have *NO* idea what you're talking about. It might help if you showed me actual examples, maybe even in Lojban.

-Robin

On Thursday 22 July 2004 00:02, Robin Lee Powell wrote: > On Wed, Jul 21, 2004 at 10:59:16PM -0400, Pierre Abbat wrote: > > On Tuesday 20 July 2004 18:49, Robin Lee Powell wrote: > > > On Tue, Jul 20, 2004 at 06:43:44PM -0400, Pierre Abbat wrote: > > > > It is also possible to express imaginary numbers in base 1-i, > > > > without using ni'u or ka'o. (1+i doesn't work. Why?) > > > > > > "1+i" doesn't work in what sense? > > > > I think you're asking the same thing I'm asking. The representation is > > binary in base 1+i or 1-i; base 1-i works, but base 1+i doesn't. > > I'm sorry, I have *NO* idea what you're talking about. It might help if > you showed me actual examples, maybe even in Lojban.

Sorry for the braino, I meant i-1. The reason is that only half the complex integers have a representation in base i+1; in particular, there is no set of powers of 1+i whose sum is 3. Base i-1 does not have this problem; li re du li papanono ju'u ni'upaka'opa .ije li ci du li papanopa ju'u ni'upaka'opa. Below is a Python program that draws the numbers expressible in 16 bits in base i-1.

phma

- !/usr/bin/env python

import sets import sys

minre=maxre=minim=maxim=0 graph=sets.Set()

def base(a,b): pow=1+0j tot=0+0j while a: if a&1: tot+=pow pow*=b a/=2 return tot

for i in range(65536): z=base(i,-1+1j) if z.real if z.real>maxre: maxre=z.real if z.imag if z.imag>maxim: maxim=z.imag graph.add(z) for i in range(maxim,minim-1,-1): for r in range(minre,maxre+1): if (complex(r,i) in graph): if (r==0): if (i==0): sys.stdout.write('+') else: sys.stdout.write('|') else: if (i==0): sys.stdout.write('-') else: sys.stdout.write('*') else: sys.stdout.write(' ') sys.stdout.write('\n')

-- li fi'u vu'u fi'u fi'u du li pa

On Fri, Aug 06, 2004 at 03:10:55PM -0400, Pierre Abbat wrote: > On Thursday 22 July 2004 00:02, Robin Lee Powell wrote: > > On Wed, Jul 21, 2004 at 10:59:16PM -0400, Pierre Abbat wrote: > > > On Tuesday 20 July 2004 18:49, Robin Lee Powell wrote: > > > > On Tue, Jul 20, 2004 at 06:43:44PM -0400, Pierre Abbat wrote: > > > > > It is also possible to express imaginary numbers in base 1-i, > > > > > without using ni'u or ka'o. (1+i doesn't work. Why?) > > > > > > > > "1+i" doesn't work in what sense? > > > > > > I think you're asking the same thing I'm asking. The > > > representation is binary in base 1+i or 1-i; base 1-i works, but > > > base 1+i doesn't. > > > > I'm sorry, I have *NO* idea what you're talking about. It might > > help if you showed me actual examples, maybe even in Lojban. > > Sorry for the braino, I meant i-1. The reason is that only half the > complex integers have a representation in base i+1; in particular, > there is no set of powers of 1+i whose sum is 3. Base i-1 does not > have this problem; li re du li papanono ju'u ni'upaka'opa .ije li ci > du li papanopa ju'u ni'upaka'opa. Below is a Python program that draws > the numbers expressible in 16 bits in base i-1.

I'm sorry, I simply can't understand what "base i-1" or "base i+1" mean. My math isn't up to it anymore.

-Robin