WikiDiscuss

WikiDiscuss


Number subgrammar

posts: 1912
Use this thread to discuss the Number subgrammar page.
posts: 1912


Rob:

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

posts: 1912

> 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


posts: 152

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



posts: 1912

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


posts: 14214


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

posts: 1912


> 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


posts: 14214

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


posts: 1912

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


posts: 14214

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?

<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

-Robin


posts: 149

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


posts: 152

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




posts: 1912

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


posts: 14214

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 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


posts: 14214

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 <jcowan@reutershealth.com> 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."


posts: 143

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.




posts: 1912

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


posts: 1912

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


posts: 14214

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 <jcowan@reutershealth.com>
someone had played the ace. http://www.ccil.org/~cowan
--Eugene Field http://www.reutershealth.com


posts: 1912


> > > > (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


posts: 14214

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 <number>
mod <base>, and that's what negative numbers do in a module context.

-Robin


posts: 1912

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?

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


posts: 14214

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
> > <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.

-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


posts: 14214

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!"


posts: 1912

> 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


posts: 14214

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


  1. !/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 pa


posts: 14214

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