WikiDiscuss

WikiDiscuss


baupla fuzykamni

posts: 953
Use this thread to discuss the baupla fuzykamni page.
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

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

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


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


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


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


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


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

<voice imitation="Gilda Radner">Oh. Nevermind.</voice>

-Robin


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


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


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


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


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




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




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


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


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


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


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


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




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

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

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


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



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



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



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



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

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



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


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


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



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 <jjllambias2000@yahoo.com.ar>
> 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


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
> <jjllambias2000@yahoo.com.ar>
> > 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
>
>
>



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


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


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