Talk:BPFK: Difference between revisions

From Lojban
Jump to navigation Jump to search
No edit summary
m (Mukti moved page Talk:baupla fuzykamni to Talk:BPFK)
 

Latest revision as of 19:15, 16 May 2015

Posted by rlpowell on Sun 13 of Feb., 2005 21:41 GMT posts: 14214

On Sun, Feb 13, 2005 at 05:41:23PM +0100, Philip Newton wrote: > On Fri, 11 Feb 2005 12:04:27 -0800, webmaster@lojban.org > wrote: > > By my count, we have chekpointed 108 words; > > Typo? ("checkpointed") > > I'd fix it myself, but the page is locked.

Fixed.

Have you tried unlocking it? I'm not sure if you'd be able to or not.

-Robin

-- http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ Reason #237 To Learn Lojban: "Homonyms: Their Grate!" Proud Supporter of the Singularity Institute - http://singinst.org/

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by Anonymous on Mon 14 of Feb., 2005 07:03 GMT

On Sun, 13 Feb 2005 13:18:43 -0800, Robin Lee Powell wrote: > Have you tried unlocking it?

No, I didn't, since I didn't think I'd be allowed to. *tries* I do seem to be able to lock and unlock it, though.

mu'o mi'e .filip. --

Philip Newton
Posted by rlpowell on Fri 20 of Aug., 2004 19:59 GMT posts: 14214

(I'm using this for general BPFK discussion; feel free to do the same)

OK, we need a pro-sumti for "here", as in "near to the speaker". Seriously.

I'm aware it's possible to say "here", but the shortest form I'm aware of is "le diklo be mi". This is Zipfeanilly *ridiculous*. It's five syllables, FFS!

Note that "vi mi" and "vi ku" and such tricks don't count; I need something to put in a sumti place (the x2 of muvdu is how this rant got formed).

My question is, where and how is the best place to propose such a thing?

The Right Way, IMO, is a sumti to convert sumtcita phrases to things that can fill sumti places; call it xai. This gives us "xai vi ku", which is still too damned many syllables, but lets us stick with the three space descriptions we already have, without sucking three KOhA cmavo.

If it were to be a KOhA cmavo set, I don't know which KOhA group we'd put it in.

Comments? Questions? Yells for me to STFU?

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

rlpowellPosted by rlpowell on Fri 27 of Aug., 2004 20:53 GMT posts: 14214

"mi .e do joi da" ==

(mi .e do) joi da

or

mi .e (do joi da) ?

I don't know the answer. John doesn't know the answer. This is scary.

Anyone?

What about for "mi .e do .a da" ?

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by xorxes on Mon 08 of Nov., 2004 23:16 GMT posts: 1912

Robin: > OK, we need a pro-sumti for "here", as in "near to the speaker". Seriously.

You can use {ti} for this. The place near the speaker.

mu'o mi'e xorxes


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

Score: 0.00 Vote:
1 2 3 4 5
top of page

rlpowellPosted by rlpowell on Mon 08 of Nov., 2004 23:16 GMT posts: 14214

On Fri, Aug 20, 2004 at 01:28:24PM -0700, Jorge Llamb?as wrote: > Robin: > > OK, we need a pro-sumti for "here", as in "near to the speaker". > > You can use {ti} for this. The place near the speaker.

No, you can't, for two reasons:

1. You can point to the area around you; it's in all possible directions, and you can only point in one.

2. You can't use it in virtual contexts; this originally came up in the context of the MUD I'm writing.

  1. 1 is much, much more important than #2.

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by xorxes on Mon 08 of Nov., 2004 23:16 GMT posts: 1912

> No, you can't, for two reasons: > > 1. You can point to the area around you; it's in all possible > directions, and you can only point in one.

Of course you can: point with your finger about 45 degrees downwards and make a circular motion. But you don't have to take "pointing" so literally in any case.

> 2. You can't use it in virtual contexts; this originally came up in the > context of the MUD I'm writing.

Why not?

> #1 is much, much more important than #2.

Then there's no problem.

mu'o mi'e xorxes


'''''''''''''''''''''''''''''''''''''___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

Score: 0.00 Vote:
1 2 3 4 5
top of page

rlpowellPosted by rlpowell on Mon 08 of Nov., 2004 23:16 GMT posts: 14214

On Fri, Aug 20, 2004 at 01:37:35PM -0700, Jorge Llamb?as wrote: > > --- Robin Lee Powell wrote: > > No, you can't, for two reasons: > > > > 1. You can point to the area around you; it's in all possible > > directions, and you can only point in one. > > Of course you can: point with your finger about 45 degrees downwards > and make a circular motion.

That describes a circle at my feet. It does not point at everything in the immediate area.

> But you don't have to take "pointing" so literally in any case.

Why the bloody hell not? If I didn't want to take things literally, I wouldn't be studying Lojban!

However, you do bring up a possible solution, which is to define ti, ta and tu as "something near/medium/far from the speaker, possibly pointed at". I think that's what the Founders wanted anyways, although they can speak for themselves.

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by Anonymous on Mon 08 of Nov., 2004 23:16 GMT

Robin Lee Powell scripsit:

> However, you do bring up a possible solution, which is to define ti, ta > and tu as "something near/medium/far from the speaker, possibly pointed > at". I think that's what the Founders wanted anyways, although they can > speak for themselves.

I think that's about right; the main restriction on ti is that it has to be something physically localized, not a speech act or a Lojban abstraction.

-- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan "You cannot enter here. Go back to the abyss prepared for you! Go back! Fall into the nothingness that awaits you and your Master. Go!" --Gandalf

Score: 0.00 Vote:
1 2 3 4 5
top of page

rlpowellPosted by rlpowell on Mon 08 of Nov., 2004 23:16 GMT posts: 14214

On Fri, Aug 20, 2004 at 04:46:26PM -0400, John Cowan wrote: > Robin Lee Powell scripsit: > > > However, you do bring up a possible solution, which is to define ti, > > ta and tu as "something near/medium/far from the speaker, possibly > > pointed at". I think that's what the Founders wanted anyways, > > although they can speak for themselves. > > I think that's about right; the main restriction on ti is that it has > to be something physically localized, not a speech act or a Lojban > abstraction.

Interestingly enough, this is pretty close to the current cmavo list definition. This is not the only place the cmavo list and the CLL have a cage match.

ti tif this here pro-sumti: this here; immediate demonstrative it; indicated thing/place near speaker

Oh. Nevermind.

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by xorxes on Mon 08 of Nov., 2004 23:16 GMT posts: 1912

> > Of course you can: point with your finger about 45 degrees downwards > > and make a circular motion. > > That describes a circle at my feet. It does not point at everything in > the immediate area.

"Pointing" does not just mean "follow a straight line from the tip of my finger and whatever the line impinges upon that's the pointed at thing". There are many ways of pointing. You can point with a gesture of your head, for example, you can point just with your eyes, etc. It's very culturally dependent, pointing with your finger can be considered rude in some cultures.

> > But you don't have to take "pointing" so literally in any case. > > Why the bloody hell not? If I didn't want to take things literally, I > wouldn't be studying Lojban!

People without hands or with their hands otherwise occupied can still use ti, ta, tu.

> However, you do bring up a possible solution, which is to define ti, ta > and tu as "something near/medium/far from the speaker, possibly pointed > at". I think that's what the Founders wanted anyways, although they can > speak for themselves.

Actually it's more like:

ti something near the speaker ta something near the audience tu something far from both speaker and audience

BTW, on possible way of converting a tag into a sumti is {lo tag du}as in {lo vi du}.

mu'o mi'e xorxes


'''''''''''''''''''''''''''''''''''''___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

Score: 0.00 Vote:
1 2 3 4 5
top of page

rlpowellPosted by rlpowell on Mon 08 of Nov., 2004 23:16 GMT posts: 14214

On Fri, Aug 20, 2004 at 01:52:18PM -0700, Jorge Llamb?as wrote: > BTW, one possible way of converting a tag into a sumti is > {lo tag du}as in {lo vi du}.

Heh. Only three syllables; yay! :-)

Good trick, though.

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

arjPosted by arj on Mon 08 of Nov., 2004 23:16 GMT posts: 953

On Fri, 20 Aug 2004 wikidiscuss@lojban.org wrote:

> OK, we need a pro-sumti for "here", as in "near to the speaker". Seriously. > > I'm aware it's possible to say "here", but the shortest form I'm aware of is "le diklo be mi". This is Zipfeanilly *ridiculous*. It's five syllables, FFS! > > Comments? Questions? Yells for me to STFU?

"le jai bu'u". HTH. HAND. STFU.

-- Arnt Richard Johansen http://arj.nvg.org/ "My speech recognition software may have trouble with ordinary words, but not with ketoprofen." --Magnus Itland

Score: 0.00 Vote:
1 2 3 4 5
top of page

rlpowellPosted by rlpowell on Mon 08 of Nov., 2004 23:16 GMT posts: 14214

On Sat, Aug 21, 2004 at 03:03:06AM +0200, Arnt Richard Johansen wrote: > On Fri, 20 Aug 2004 wikidiscuss@lojban.org wrote: > > >OK, we need a pro-sumti for "here", as in "near to the speaker". > >Seriously. > > > >I'm aware it's possible to say "here", but the shortest form I'm > >aware of is "le diklo be mi". This is Zipfeanilly *ridiculous*. > >It's five syllables, FFS! > > > >Comments? Questions? Yells for me to STFU? > > "le jai bu'u". HTH. HAND. STFU.

1. That's still 4 syllables.

2. All three parsers say it doesn't work. I already tried.

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by lojbab on Mon 08 of Nov., 2004 23:17 GMT posts: 162

At 12:59 PM 8/20/04 -0700, you wrote: >Re: baupla fuzykamni >(I'm using this for general BPFK discussion; feel free to do the same) > >OK, we need a pro-sumti for "here", as in "near to the speaker". Seriously. > >I'm aware it's possible to say "here", but the shortest form I'm aware of >is "le diklo be mi". This is Zipfeanilly *ridiculous*. It's five >syllables, FFS! > >Note that "vi mi" and "vi ku" and such tricks don't count; I need >something to put in a sumti place (the x2 of muvdu is how this rant got >formed). > >My question is, where and how is the best place to propose such a thing? > >The Right Way, IMO, is a sumti to convert sumtcita phrases to things that >can fill sumti places; call it xai. This gives us "xai vi ku", which is >still too damned many syllables, but lets us stick with the three space >descriptions we already have, without sucking three KOhA cmavo.

da pe vi

and I don't care if it is too many syllables (syllable count never was a major design characteristic in Loglan/Lojban unless there was a Zipf issue, which I don't think there is here)

>If it were to be a KOhA cmavo set, I don't know which KOhA group we'd put >it in. > >Comments? Questions? Yells for me to STFU?

In the absence of pointing, "ti" is something (in this case a place) relatively near the speaker, and that is what I would likely use.


-- lojbab lojbab@lojban.org Bob LeChevalier, Founder, The Logical Language Group (Opinions are my own; I do not speak for the organization.) Artificial language Loglan/Lojban: http://www.lojban.org

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by lojbab on Mon 08 of Nov., 2004 23:17 GMT posts: 162

At 01:52 PM 8/20/04 -0700, Jorge "Llambías" wrote: >--- Robin Lee Powell wrote: > > > Of course you can: point with your finger about 45 degrees downwards > > > and make a circular motion. > > > > That describes a circle at my feet. It does not point at everything in > > the immediate area. > >"Pointing" does not just mean "follow a straight line from the tip >of my finger and whatever the line impinges upon that's the pointed >at thing".

Anyone with a cat knows that. I point, and the cat focuses on (or investigates) the end of my finger.

> > > But you don't have to take "pointing" so literally in any case. > > > > Why the bloody hell not? If I didn't want to take things literally, I > > wouldn't be studying Lojban! > >People without hands or with their hands otherwise occupied can >still use ti, ta, tu.

More importantly, ti/ta/tu have been defined for use in phonecons, where pointing is impossible.


-- lojbab lojbab@lojban.org Bob LeChevalier, Founder, The Logical Language Group (Opinions are my own; I do not speak for the organization.) Artificial language Loglan/Lojban: http://www.lojban.org

Score: 0.00 Vote:
1 2 3 4 5
top of page

rlpowellPosted by rlpowell on Mon 08 of Nov., 2004 23:17 GMT posts: 14214

On Sat, Aug 21, 2004 at 08:18:58AM -0400, Bob LeChevalier wrote: > At 12:59 PM 8/20/04 -0700, you wrote: > >OK, we need a pro-sumti for "here", as in "near to the speaker". > >Seriously. > > da pe vi

That's not bad. Thanks.

> and I don't care if it is too many syllables (syllable count never was > a major design characteristic in Loglan/Lojban unless there was a Zipf > issue, which I don't think there is here)

I don't see how anything could *more* clearly be a Zipf issue, but I'm not worried about it anymore given the "ti" discussion.

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

rlpowellPosted by rlpowell on Mon 08 of Nov., 2004 23:17 GMT posts: 14214

On Sat, Aug 21, 2004 at 08:23:35AM -0400, Bob LeChevalier wrote: > More importantly, ti/ta/tu have been defined for use in phonecons, > where pointing is impossible.

What is a 'phonecon'?

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by Anonymous on Mon 08 of Nov., 2004 23:18 GMT

On Saturday 21 August 2004 17:19, Robin Lee Powell wrote: > On Sat, Aug 21, 2004 at 08:23:35AM -0400, Bob LeChevalier wrote: > > More importantly, ti/ta/tu have been defined for use in phonecons, > > where pointing is impossible. > > What is a 'phonecon'?

phone conversation?

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

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by Anonymous on Tue 09 of Nov., 2004 00:33 GMT

Robin Powell scripsit:

> Re: baupla fuzykamni > "mi .e do joi da" == > > (mi .e do) joi da > > or > > mi .e (do joi da) ? > > I don't know the answer. John doesn't know the answer. This is scary.

CLL 14.7.6 shows that the answer is the first one; afterthought connectives always group to the left. If you want anything else, use forethought.

-- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan "The exception proves the rule." Dimbulbs think: "Your counterexample proves my theory." Latin students think "'Probat' means 'tests': the exception puts the rule to the proof." But legal historians know it means "Evidence for an exception is evidence of the existence of a rule in cases not excepted from."

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by xorxes on Tue 09 of Nov., 2004 00:34 GMT posts: 1912

> > (mi .e do) joi da > > > > or > > > > mi .e (do joi da) ? > > CLL 14.7.6 shows that the answer is the first one; afterthought connectives > always group to the left. If you want anything else, use forethought.

Or {bo}. Or {ke}-{ke'e}. But forethought is better.

mu'o mi'e xorxes


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

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by lojbab on Tue 09 of Nov., 2004 00:39 GMT posts: 162

At 01:53 PM 8/27/04 -0700, you wrote: >Re: baupla fuzykamni >"mi .e do joi da" == > >(mi .e do) joi da > >or > >mi .e (do joi da) ? > >I don't know the answer. John doesn't know the answer. This is scary. > >Anyone? > >What about for "mi .e do .a da" ?

Left grouping, always, by default, for both cases. I thought that was inherent to LALR1 grammars where there is no rule to the contrary. That .e and joi are different selma'o shouldn't change that default, since the same grammar rule (joik_ek_421) is used for both.

lojbab

-- lojbab lojbab@lojban.org Bob LeChevalier, Founder, The Logical Language Group (Opinions are my own; I do not speak for the organization.) Artificial language Loglan/Lojban: http://www.lojban.org

Score: 0.00 Vote:
1 2 3 4 5
top of page

rlpowellPosted by rlpowell on Wed 17 of Nov., 2004 06:10 GMT posts: 14214

People have not been putting See Also clauses in their definitions. Please start doing so ASAP. cmavo should have references to closely related cmavo (not necessarily all others in the selma'o, although that would be fine) and to their terminators, if any.

If no-one objects, I'll clean this up when I import things into jbovlaste as well, since it's purely stylistic.

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

rlpowellPosted by rlpowell on Sun 09 of Jan., 2005 09:08 GMT posts: 14214

Bah.

Jay just noticed that CEI wasn't anywhere on the Sections page.

If someone could please check for any other omissions, I'd really, really appreciate it.

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

rlpowellPosted by rlpowell on Mon 10 of Jan., 2005 16:56 GMT posts: 14214

On Sun, Jan 09, 2005 at 01:08:30AM -0800, wikidiscuss@lojban.org wrote: > If someone could please check for any other omissions, I'd really, really appreciate it.

Did it myself. We seem to be fine.

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by Anonymous on Wed 12 of Jan., 2005 00:25 GMT

Re: baupla fuzykamni (I'm using this for general BPFK discussion; feel free to do the same)

OK, we need a pro-sumti for "here", as in "near to the speaker". Seriously.

I'm aware it's possible to say "here", but the shortest form I'm aware of is "le diklo be mi". This is Zipfeanilly *ridiculous*. It's five syllables, FFS!

Note that "vi mi" and "vi ku" and such tricks don't count; I need something to put in a sumti place (the x2 of muvdu is how this rant got formed).

My question is, where and how is the best place to propose such a thing?

The Right Way, IMO, is a sumti to convert sumtcita phrases to things that can fill sumti places; call it xai. This gives us "xai vi ku", which is still too damned many syllables, but lets us stick with the three space descriptions we already have, without sucking three KOhA cmavo.

If it were to be a KOhA cmavo set, I don't know which KOhA group we'd put it in.

Comments? Questions? Yells for me to STFU?

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by Anonymous on Wed 12 of Jan., 2005 00:27 GMT

Re: baupla fuzykamni "mi .e do joi da" ==

(mi .e do) joi da

or

mi .e (do joi da) ?

I don't know the answer. John doesn't know the answer. This is scary.

Anyone?

What about for "mi .e do .a da" ?

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by Anonymous on Wed 12 of Jan., 2005 00:28 GMT

Re: baupla fuzykamni People have not been putting See Also clauses in their definitions. Please start doing so ASAP. cmavo should have references to closely related cmavo (not necessarily all others in the selma'o, although that would be fine) and to their terminators, if any.

If no-one objects, I'll clean this up when I import things into jbovlaste as well, since it's purely stylistic.

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by Anonymous on Wed 12 of Jan., 2005 00:28 GMT

Re: baupla fuzykamni Bah.

Jay just noticed that CEI wasn't anywhere on the Sections page.

If someone could please check for any other omissions, I'd really, really appreciate it.

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

rlpowellPosted by rlpowell on Wed 09 of Feb., 2005 18:35 GMT posts: 14214

A propsal:

This is only half in jest. Maybe less than half.

I suggest that in the BPFK's re-write of the CLL, we excise the word "if" from http://lojban.org/publications/reference_grammar/chapter14.html(external link) entirely. Or at least where it's used to describe na ja and ja nai and such. "ja nai" doesn't mean "first is true if second is true", it means "either (the first is true) or (neither the first nor the second is true)" (the truth table being TTFT) and using the "standard" logical term of "if" has lead to one of the most common purely semantic Lojban errors.

-Robin

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by pycyn on Thu 10 of Feb., 2005 22:48 GMT posts: 2388

Well, I see the point, but going against a couple thousand years of tradition — in logic and (though for a shorter time) programming languages -- militates against the change. As usual, we need to think about what we mean before we speak. If we want some counterfactual conditional, then we don't want {janai}, but that doesn't mean that {janai} is not "if," just that it is not that "if." Lojban is not English and so we should not expect that every English word gets a one-on-one Lojban one. It doesn't help, of course, that the correct Lojban expression for the other English "if" has never been authoritatively specified (it is presumably {da'i} in some construction but the details are fuzzy).


> Re: baupla fuzykamni > A propsal: > > This is only half in jest. Maybe less than > half. > > I suggest that in the BPFK's re-write of the > CLL, we excise the word > "if" from > http://lojban.org/publications/reference_grammar/chapter14.html(external link) > entirely. Or at least where it's used to > describe na ja and ja nai > and such. "ja nai" doesn't mean "first is true > if second is true", > it means "either (the first is true) or > (neither the first nor the > second is true)" (the truth table being TTFT) > and using the > "standard" logical term of "if" has lead to one > of the most common > purely semantic Lojban errors. > > -Robin > > > > >

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by xorxes on Thu 10 of Feb., 2005 22:49 GMT posts: 1912

> Well, I see the point, but going against a couple > thousand years of tradition — in logic and > (though for a shorter time) programming languages > — militates against the change.

I'm not sure about programming languages. For example in the instruction:

IF a=1 THEN SET b = 0

"IF ... THEN ..." can hardly be {ga nai ... gi ... }. If a=1 is false we don't want to let the computer to set b = 0 if it pleases, which {ganai ... gi ...} presumably would. So the "if" of programming languages, if it can be compared to a logical connective given the modalities involved, would have to be iff, {go ... gi ...}.

mu'o mi'e xorxes


'''''''''''''''''''''''''''''''''''''''''''__ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by Anonymous on Thu 10 of Feb., 2005 22:49 GMT

Jorge Llamb���)B�as scripsit:

> "IF ... THEN ..." can hardly be {ga nai ... gi ... }. > If a=1 is false we don't want to let the computer to > set b = 0 if it pleases, which {ganai ... gi ...} > presumably would. So the "if" of programming languages, > if it can be compared to a logical connective given the > modalities involved, would have to be iff, {go ... gi ...}.

What's more, it's a conditional imperative.

Prolog's if (spelled "-:") is an exception: it's anai.

-- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan No man is an island, entire of itself; every man is a piece of the continent, a part of the main. If a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a manor of thy friends or of thine own were: any man's death diminishes me, because I am involved in mankind, and therefore never send to know for whom the bell tolls; it tolls for thee. --John Donne

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by pycyn on Fri 11 of Feb., 2005 05:21 GMT posts: 2388

I don't know how programming languages are working these days (it's been about a decade since I learned my latest one) but in the old days IF was pretty generally a Boolean valued function would return True (though not do anything else) if the antecedent were false (and, if the antecedent were true, would make the consequent true — and return True). I have some trouble imagining anything else being called IF (as opposed to, say, IFF). Your suggestion seems just perverse, since it amounts (apparently) to just an _un_conditional setting b = 0.


wrote:

> > --- John E Clifford wrote: > > Well, I see the point, but going against a > couple > > thousand years of tradition — in logic and > > (though for a shorter time) programming > languages > > — militates against the change. > > I'm not sure about programming languages. For > example > in the instruction: > > IF a=1 THEN SET b = 0 > > "IF ... THEN ..." can hardly be {ga nai ... gi > ... }. > If a=1 is false we don't want to let the > computer to > set b = 0 if it pleases, which {ganai ... gi > ...} > presumably would. So the "if" of programming > languages, > if it can be compared to a logical connective > given the > modalities involved, would have to be iff, {go > ... gi ...}.

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by xorxes on Fri 11 of Feb., 2005 05:21 GMT posts: 1912

> I don't know how programming languages are > working these days (it's been about a decade > since I learned my latest one)

Me too.

> but in the old > days IF was pretty generally a Boolean valued > function would return True (though not do > anything else) if the antecedent were false (and, > if the antecedent were true, would make the > consequent true — and return True). I have some > trouble imagining anything else being called IF > (as opposed to, say, IFF).

I have trouble imagining anything else being called IF in a programming language, too, but that was not the issue. The issue was, does that correspond to inaja?

When the antecedent is false, the consequent could also be true and still satisfy {inaja}, but the computer never does that.

> Your suggestion seems > just perverse, since it amounts (apparently) to > just an _un_conditional setting > b = 0.

No, that would be {iseju}, which requires the second part to be true no matter what the first part is.

{ijo} requires the conditional setting of b = 0 when the antecedent is true and only then. It requires to not set b = 0 when the antecedent is false. (Assuming that a command is "true" when it is fulfilled and "false" when it is not fulfilled.)

mu'o mi'e xorxes


> --- Jorge Llambías > wrote: > > > > > --- John E Clifford wrote: > > > Well, I see the point, but going against a > > couple > > > thousand years of tradition — in logic and > > > (though for a shorter time) programming > > languages > > > — militates against the change. > > > > I'm not sure about programming languages. For > > example > > in the instruction: > > > > IF a=1 THEN SET b = 0 > > > > "IF ... THEN ..." can hardly be {ga nai ... gi > > ... }. > > If a=1 is false we don't want to let the > > computer to > > set b = 0 if it pleases, which {ganai ... gi > > ...} > > presumably would. So the "if" of programming > > languages, > > if it can be compared to a logical connective > > given the > > modalities involved, would have to be iff, {go > > ... gi ...}. >


'''''''''''''''''''''''''''''''''''''''''''__ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by pycyn on Fri 11 of Feb., 2005 18:59 GMT posts: 2388

We seem to be at cross purposes here. {inaja} returns True if the antecedent is False or the consequent True. {ijo} returns True if antecedent and consequent have the same value. Neither of these have anything to do with imperative forms per se. The imperative format is apparently that, for IF, if the antecedent is True, then the change commanded is made; if the antecedent is False, the change is not made (and the whole in any case returns True.) To say that, if the antecedent is False, then the change commanded in the consequent is made is to confuse the truth of the consequence (the conditional) with the truth of the consequent (the second sentence). And, of course, is to make the change required in the second sentence unconditionally (since it presumably will be done if the antecedent is True). The point is that the computer evaluates an IF line as True when the antecedent is False, regardless of what happens with the consequent. The exact mechanism for doing this varies from language to language, I seem to recall (I am not generally too interested in how those evaluations are done, so I may have the details wrong) sometimes by comparison (antecedent less than or equal to consequent), sometimes by artithmetical moves (which my ultimately be the same thing). In any case, the function is just material implication, {inaja}. Or was a few years ago, when IF still was a respectable bit of programming. (ijo) plays less of a role in imperatives, of course, since it will only work when there are exactly two possible values: one for antecedent True and the other for antecedent False.


wrote:

> > --- John E Clifford wrote: > > I don't know how programming languages are > > working these days (it's been about a decade > > since I learned my latest one) > > Me too. > > > but in the old > > days IF was pretty generally a Boolean valued > > function would return True (though not do > > anything else) if the antecedent were false > (and, > > if the antecedent were true, would make the > > consequent true — and return True). I have > some > > trouble imagining anything else being called > IF > > (as opposed to, say, IFF). > > I have trouble imagining anything else being > called > IF in a programming language, too, but that was > not the > issue. The issue was, does that correspond to > inaja? > > When the antecedent is false, the consequent > could also > be true and still satisfy {inaja}, but the > computer > never does that. > > > Your suggestion seems > > just perverse, since it amounts (apparently) > to > > just an _un_conditional setting > > b = 0. > > No, that would be {iseju}, which requires the > second part > to be true no matter what the first part is. > > {ijo} requires the conditional setting of b = 0 > when the antecedent > is true and only then. It requires to not set b > = 0 when the > antecedent is false. (Assuming that a command > is "true" when it > is fulfilled and "false" when it is not > fulfilled.) > > mu'o mi'e xorxes > > > > --- Jorge Llambías > > > wrote: > > > > > > > > --- John E Clifford wrote: > > > > Well, I see the point, but going against > a > > > couple > > > > thousand years of tradition — in logic > and > > > > (though for a shorter time) programming > > > languages > > > > — militates against the change. > > > > > > I'm not sure about programming languages. > For > > > example > > > in the instruction: > > > > > > IF a=1 THEN SET b = 0 > > > > > > "IF ... THEN ..." can hardly be {ga nai ... > gi > > > ... }. > > > If a=1 is false we don't want to let the > > > computer to > > > set b = 0 if it pleases, which {ganai ... > gi > > > ...} > > > presumably would. So the "if" of > programming > > > languages, > > > if it can be compared to a logical > connective > > > given the > > > modalities involved, would have to be iff, > {go > > > ... gi ...}. > > > > > > '''''''''''''''''''''''''''''''''''''''''''__ > Do you Yahoo!? > Read only the mail you want - Yahoo! Mail > SpamGuard. > http://promotions.yahoo.com/new_mail > > >

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by xorxes on Fri 11 of Feb., 2005 18:59 GMT posts: 1912

> We seem to be at cross purposes here. {inaja} > returns True if the antecedent is False or the > consequent True. {ijo} returns True if antecedent > and consequent have the same value.

No doubt.

> Neither of > these have anything to do with imperative forms > per se.

But programming languages deal basically with imperative forms. If the IF of programming languages has nothing to do with inaja or ijo then why were programming languages mentioned at all?

> The imperative format is apparently > that, for IF, if the antecedent is True, then the > change commanded is made; if the antecedent is > False, the change is not made (and the whole in > any case returns True.)

Correct. That matches {ijo}:

go abu du li pa gi ko ciska zo coi IF a = 1 THEN PRINT "coi".

We want for antecedent true, command carried out, for antecedent false, command not carried out.

> To say that, if the > antecedent is False, then the change commanded in > the consequent is made is to confuse the truth of > the consequence (the conditional) with the truth > of the consequent (the second sentence).

With inaja, when the antecedent is false, the command can be carried out or not to the discretion of the listener. For example if you say to someone:

ganai abu du li pa gi ko ciska zo coi If a = 1, then write "coi".

and a is not equal to 1, and the person writes "coi" anyway, they are carrying out the command correctly. But that is not how IF ... THEN ... works in programming languages.

> And, of > course, is to make the change required in the > second sentence unconditionally (since it > presumably will be done if the antecedent is > True).

You seem to be confusing what the computer does, which satisfies both {ganai ... gi ...} and {go ... gi ...}, with what it is commanded to do. If the computer were to randomly decide whether to carry out the consequent when the antecedent is false it would still satisfy {ganai... gi...}, but not {go...gi...}.

> The point is that the computer evaluates > an IF line as True when the antecedent is False, > regardless of what happens with the consequent.

But what happens with the consequent is relevant. When the antecedent is false, the computer must not carry out the command in the consequent.

> The exact mechanism for doing this varies from > language to language, I seem to recall (I am not > generally too interested in how those evaluations > are done, so I may have the details wrong) > sometimes by comparison (antecedent less than or > equal to consequent), sometimes by artithmetical > moves (which my ultimately be the same thing). > In any case, the function is just material > implication, {inaja}.

It looks like {ijo} to me.

> Or was a few years ago, > when IF still was a respectable bit of > programming. (ijo) plays less of a role in > imperatives, of course, since it will only work > when there are exactly two possible values: one > for antecedent True and the other for antecedent > False.

There are always exactly two possible values for the consequent too: one is to carry out the command and the other is to not carry it out.

mu'o mi'e xorxes


'''''''''''''''''''''''''''''''''''''''''''__ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by pycyn on Fri 11 of Feb., 2005 18:59 GMT posts: 2388

wrote:

> > --- John E Clifford wrote: > > We seem to be at cross purposes here. > {inaja} > > returns True if the antecedent is False or > the > > consequent True. {ijo} returns True if > antecedent > > and consequent have the same value. > > No doubt. > > > Neither of > > these have anything to do with imperative > forms > > per se. > > But programming languages deal basically with > imperative > forms. If the IF of programming languages has > nothing > to do with inaja or ijo then why were > programming > languages mentioned at all?

Programming languages also contain descriptions of conditions, some of which are in "if... then ...." form (many are, in fact — or used to be before some of the changes of the late eighties). But also, even though truth functional connectives have nothing to do with imperatives per se, theye can be — and are used in imperatives. and in essentially the same way as in declaratives. > > > The imperative format is apparently > > that, for IF, if the antecedent is True, then > the > > change commanded is made; if the antecedent > is > > False, the change is not made (and the whole > in > > any case returns True.) > > Correct. That matches {ijo}: > > go abu du li pa gi ko ciska zo coi > IF a = 1 THEN PRINT "coi". > > We want for antecedent true, command carried > out, > for antecedent false, command not carried out.

But that is not {ijo}. At best, {ijo} would have

condition true — commanded situation made

true, condsition false — commanded situation made false. In the latter case, if b=0 or whatever, the value would have to be changed. This is not what IF does; it rather leaves the value unchanged when the condition is false. But still returns True to the control. I am not sure just what IFF does (and, indeed, don't remember IFF as a control command, but it's been a while — except as a version of IF...THEN...ELSE...).

> > To say that, if the > > antecedent is False, then the change > commanded in > > the consequent is made is to confuse the > truth of > > the consequence (the conditional) with the > truth > > of the consequent (the second sentence). > > With inaja, when the antecedent is false, the > command > can be carried out or not to the discretion of > the > listener. For example if you say to someone: > > ganai abu du li pa gi ko ciska zo coi > If a = 1, then write "coi". > > and a is not equal to 1, and the person writes > "coi" anyway, they are carrying out the command > > correctly. But that is not how IF ... THEN ... > works in programming languages.

Well, yes, the program might perfectly well do the command though not because of the IF command, which simply returns True when the antecedent is False. I think that you are confusing two things: what happens and what truth values are moved around. With IFF, b might be set to (or remain at) 0 even though the condition that for that setting is false but that change would be the result of some other factor, not that command. To be sure, if the identification were made _in the processing of that command_ the process ought to return False and drop into error chasing — a very different result from what happens with IF.

> > And, of > > course, is to make the change required in the > > second sentence unconditionally (since it > > presumably will be done if the antecedent is > > True). > > You seem to be confusing what the computer > does, > which satisfies both {ganai ... gi ...} and > {go ... gi ...}, with what it is commanded to > do. > If the computer were to randomly decide whether > > to carry out the consequent when the antecedent > > is false it would still satisfy {ganai... > gi...}, > but not {go...gi...}.

As noted, you are leaving out the control issues -- the value returned — which would be False with IFF (and error-chasing) but true in the IF case. I suppose we could insert a randomizer for the False antecedent case, but that would not be IF but rather IF...THEN...ELSE.... The point is that the work if IF is done correctly as soon as either the antecdent is found to be False or the state demanded in the consequent is True (and the check is made in that order in most familiar systems). IFF would take a more complex route with different results — not the one asked for.

> > The point is that the computer evaluates > > an IF line as True when the antecedent is > False, > > regardless of what happens with the > consequent. > > But what happens with the consequent is > relevant. > When the antecedent is false, the computer must > not > carry out the command in the consequent. > > > The exact mechanism for doing this varies > from > > language to language, I seem to recall (I am > not > > generally too interested in how those > evaluations > > are done, so I may have the details wrong) > > sometimes by comparison (antecedent less than > or > > equal to consequent), sometimes by > artithmetical > > moves (which my ultimately be the same > thing). > > In any case, the function is just material > > implication, {inaja}. > > It looks like {ijo} to me. > > > Or was a few years ago, > > when IF still was a respectable bit of > > programming. (ijo) plays less of a role in > > imperatives, of course, since it will only > work > > when there are exactly two possible values: > one > > for antecedent True and the other for > antecedent > > False. > > There are always exactly two possible values > for the consequent too: one is to carry out the > command > and the other is to not carry it out. Well, maybe — often there are a range of possible ways not to carry out the command: if the command is to make b=0 then the alternatives are to make b=1, or 2 or .... or to leave it with whatever value it has. Which of these is what is triggered by False antecedent? Any one of them would do until we have some convention (which returns True to control). To be sure — as I suppose you will say — with IF any one of these alternatives could be true with a False antecedent. The difference is that, with IFF, we have to check which one holds (or which is done); with IF the command does nothing beyond identifying the antecedent as False. There is not further step _in that process_. With IFF there is, the consequent has always to be dealt with somehow. (Note, of course, that nothing happens in a program — we hope — unless it is commanded to happen, IF with false antecedent commands nothing to happen, IFF with false antecedent does command something to happen.)

Score: 0.00 Vote:
1 2 3 4 5
top of page

Posted by xorxes on Fri 11 of Feb., 2005 19:00 GMT posts: 1912

> As noted, you are leaving out the control issues > — the value returned — which would be False > with IFF (and error-chasing) but true in the IF > case. I suppose we could insert a randomizer for > the False antecedent case, but that would not be > IF but rather IF...THEN...ELSE....

IF...THEN...ELSE... is a three-way conective, so it couldn't correspond to {inaja} or {ijo}, which are both two-way. In fact, I think there is no way to do IF...THEN...ELSE... in Lojban without reapeating one of the connectands.

> The point is > that the work if IF is done correctly as soon as > either the antecdent is found to be False or the > state demanded in the consequent is True (and the > check is made in that order in most familiar > systems).

How the computer goes about carrying out the instruction is not relevant here. The question is whether the meaning of the programming language instruction "IF...THEN..." corresponds or not to the meaning of {inaja}. It's a linguistic question. From the point of view of this analysis we don't care whether or how the computer carries it out, just what it is that we are instructing. A computer that carries out the instruction in the consequent when the antecedent is false is malfunctioning wrt how we want the instruction to work, but it would be correctly carrying out the command {ganai ... gi ko ...} from a lingustic point of view.

> > There are always exactly two possible values > > for the consequent too: one is to carry out the > > command > > and the other is to not carry it out. > Well, maybe — often there are a range of > possible ways not to carry out the command: if > the command is to make b=0 then the alternatives > are to make b=1, or 2 or .... or to leave it with > whatever value it has.

No, from the point of view that matters here, the only two alternatives are make b = 0 or do nothing (including leaving b = 0 if that was its value).

> Which of these is what is > triggered by False antecedent? Any one of them > would do until we have some convention (which > returns True to control). To be sure — as I > suppose you will say — with IF any one of these > alternatives could be true with a False > antecedent.

There is only one command at stake, namely "set b = 0". With that command, there are only two things the computer can do: carry it out, or not carry it out. Carrying it out corresponds to True, not carrying it out corresponds to False. Other commands such as "set b = 1" are irrelevant for this instruction. The only way the consequent can be false is by NOT carrying out the command, irrespective of the value that the variable b has.

If we were to write a programming language in Lojban, the usual instruction IF...THEN... would have to be go...gi...

mu'o mi'e xorxes


'''''''''''''''''''''''''''''''''''''''''''__ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com