Talk:number subgrammar
Archived Tiki forum discussion for number subgrammar. Original authors, UTC times, and post IDs are retained below.
number subgrammar (Tiki thread #1674)
Re: Number subgrammar
xorxes · 2004-07-10 20:18 UTC · Tiki post #1675 (reply to #1674)
Number subgrammar
xorxes · 2004-07-10 20:35 UTC · Tiki post #1676 (reply to #1674)
> 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!
Number subgrammar
rab.spir · 2004-07-11 12:26 UTC · Tiki post #1677 (reply to #1674)
> 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 SpeerNumber subgrammar
xorxes · 2004-07-12 11:17 UTC · Tiki post #1678 (reply to #1674)
> 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.
About pi'e and pi
rlpowell · 2004-07-13 07:18 UTC · Tiki post #1679 (reply to #1674)
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?
-RobinNumber subgrammar
xorxes · 2004-07-13 14:22 UTC · Tiki post #1680 (reply to #1674)
> > -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_mailNumber subgrammar
rlpowell · 2004-07-13 16:19 UTC · Tiki post #1683 (reply to #1674)
> > > 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.
-RobinNumber subgrammar
xorxes · 2004-07-13 18:16 UTC · Tiki post #1684 (reply to #1674)
> 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_mailNumber subgrammar
rlpowell · 2004-07-13 18:16 UTC · Tiki post #1685 (reply to #1674)
> 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?
<chortle>
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
-RobinNumber subgrammar
JohnCowan · 2004-07-13 18:16 UTC · Tiki post #1686 (reply to #1674)
> 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: [email protected]] 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.comAnd rhymes that didn't force me to frowan." [overpacked line!] --Michael Kay
Number subgrammar
rab.spir · 2004-07-13 22:53 UTC · Tiki post #1687 (reply to #1674)
> > 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 SpeerNumber subgrammar
xorxes · 2004-07-13 22:53 UTC · Tiki post #1688 (reply to #1674)
> 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!
Number subgrammar
rlpowell · 2004-07-13 22:53 UTC · Tiki post #1689 (reply to #1674)
> 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 [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.
-RobinNumber subgrammar
rlpowell · 2004-07-13 22:53 UTC · Tiki post #1690 (reply to #1674)
> 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.
-RobinNumber subgrammar
Anonymous · 2004-07-13 22:54 UTC · Tiki post #1691 (reply to #1674)
> 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 <[email protected]> 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."Number subgrammar
xod · 2004-07-13 22:54 UTC · Tiki post #1692 (reply to #1674)
> 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".
--
Number subgrammar
xorxes · 2004-07-13 22:54 UTC · Tiki post #1693 (reply to #1674)
> 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.
Number subgrammar
xorxes · 2004-07-13 22:54 UTC · Tiki post #1694 (reply to #1674)
> 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_mailNumber subgrammar
rlpowell · 2004-07-13 22:54 UTC · Tiki post #1695 (reply to #1674)
> > > (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)
-RobinNumber subgrammar
Anonymous · 2004-07-13 22:54 UTC · Tiki post #1696 (reply to #1674)
> "Bigit"? "Bigit" is an archaic synonym for "bit".
In this context, it's a lujvo for "big digit".
-- John Cowan [email protected] 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 TeverGod gave gums; God'll give granary --Version by Mat McVeagh
Number subgrammar
Anonymous · 2004-07-13 22:54 UTC · Tiki post #1697 (reply to #1674)
> 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 <[email protected]> someone had played the ace. http://www.ccil.org/~cowan
--Eugene Field http://www.reutershealth.comNumber subgrammar
xorxes · 2004-07-13 22:54 UTC · Tiki post #1698 (reply to #1674)
> > > > > > 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_mailNumber subgrammar
rlpowell · 2004-07-14 20:36 UTC · Tiki post #1704 (reply to #1674)
> 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 <number> mod <base>, and that's what negative numbers do in a module context.
-RobinNumber subgrammar
xorxes · 2004-07-14 20:36 UTC · Tiki post #1705 (reply to #1674)
> > 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 <number> > mod <base>, 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.
Number subgrammar
Anonymous · 2004-07-20 22:55 UTC · Tiki post #1715 (reply to #1674)
> 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 paNumber subgrammar
rlpowell · 2004-07-20 22:56 UTC · Tiki post #1716 (reply to #1674)
> 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 > > <number> mod <base>, 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.
-RobinNumber subgrammar
Anonymous · 2004-07-20 22:56 UTC · Tiki post #1717 (reply to #1674)
> 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 paNumber subgrammar
rlpowell · 2004-07-20 22:56 UTC · Tiki post #1718 (reply to #1674)
> 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!"Number subgrammar
xorxes · 2004-07-21 12:02 UTC · Tiki post #1720 (reply to #1674)
> 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!
Number subgrammar
Anonymous · 2004-07-22 10:38 UTC · Tiki post #1736 (reply to #1674)
> 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 paNumber subgrammar
rlpowell · 2004-07-22 10:38 UTC · Tiki post #1737 (reply to #1674)
> 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.
-RobinNumber subgrammar
Anonymous · 2004-08-06 21:12 UTC · Tiki post #1860 (reply to #1674)
> 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<minre: minre=z.real if z.real>maxre: maxre=z.real if z.imag<minim: minim=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 paNumber subgrammar
rlpowell · 2004-08-10 23:35 UTC · Tiki post #1971 (reply to #1674)
> 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
