Re: replies mainly re "ka"

[jorge@PHYAST.PITT.EDU]

And:
>          lo [feature] be koha cu frica lo [feature] be kohe (ziho)
>
> which is free of sumti-raising, and rather to be preferred, in my view.

I don't dispute the expression with the x3 of frica zihoed off, but the
point of this discussion (out of which I'm getting a lot) is to find out
how to fill the x3 of frica.

Other selbri with similar requirements are: zmadu, mleca, dunli, simsa.

> > Say the feature is colour(). Then:
> >        ko'a ko'e frica *colour()*
> >        Koha and kohe differ in colour.
> > means that colour(koha) is not equal to colour(kohe), i.e. the function
> > colour() takes different values for the arguments koha and kohe.
>
> Rather: X is not equal to Y, where colour(X,koha) and colour(Y,kohe).

But you are using color(,) as a selbri, and we need a sumti to put in x3.

> > This means that x3 is not the actual difference between x1 and x2, but
> > the characteristic in which they differ.
>
> Exactly. But since x1 and x2 differ with respect to this characteristic
> the x3 has to refer to both the characteristic of x1 and the
> characteristic of x2.

And that is what I mean by an unevaluated function. It refers to the
characteristic of any possible argument, in particular what is in x1 and
what is in x2.

> Certainly this would be the case if we rendered
>
>     koha and kohe differ in colour
>
> as
>
>    koha kohe frica lo se skari be koha e. kohe

but {lo se skari be ko'a e ko'e} is a colour that they share. You are
putting a value in x3, not an open function. I think we can't escape
from having a place holder in x3, to never be replaced by what is in x1
and x2. What goes in x3 must keep the place open, you can't actually
fill it with either x1 or x2 or anything else.

> > Then something like:
> >        ko'a ko'e frica le se skari
> > would be wrong, because what is in x3 is not a function but a specific
> > colour (the one the speaker has in mind).
>
> I don't see this as wrong, but it is, as I said above, look like
> ugly sumti-raising. Mind you, if you translate it as "colours differentiate
> koha and kohe", it doesn't seem at all bad.

What do you mean "colours differentiate"? Say ko'a is blue and ko'e red.
Does "red" differentiate ko'a and ko'e?

> > To get a function, I would use:
> >        ko'a ko'e frica le ka ke'a skari makau
> >        Koha and ko'e differ in what colour they are.
>
> I see how it works. I've already objected to keha and makau in contexts
> like these, so I won't go into that again.

Do you at least agree that we need an unevaluated function there?

> How about:
>    koha kohe frica lo [selbri abstractor] skari be fi ziho bei fo ziho

and how do you know which is the input (i.e. where ko'a and ko'e would go)
and which the output (the values that are not equal). Unless it is order
(first input then output) then you couldn't distinguish "ko'a and ko'e
differ in colour" from "ko'a and ko'e differ in what they are colours of".

In my notation:

       ko'a ko'e frica le ka ke'a skari makau
       ko'a ko'e frica le ka makau skari ke'a

> > I can think of redness either as a binary function (or feature), taking
> > values "red" and "non-red" (then the redness of a blue object would be
> > "non-red"), or as a multivalued function with values crimson, vermilion,
> > and what have you. I would probably understand this last one in the
> > sentence "A and B differ in redness", i.e. the function redness()
> > evaluates to something different for A than for B.
>
> Okay. So on the one hand you have red1: red1(X,yes), red1(X,no). And
> on the other hand you have red2: red2(X,crimson), red2(X,vermillion).

You insist on using selbri when I want to use a sumti. Your red1(X,yes) is
a statement with a truth value. My red1(X) is a function, that can take
two values. This is the type of thing we need to put in the x3 of frica.
We can't do anything with a statement.

> > I see {le ka ke'a xunre} as the function redness(), where {ke'a}
> > simbolizes the variable, so that the function is not evaluated.
>
> I'm not clear what arguments redness() is supposed to have.

Objects that can have that property or not. Basically, anything that
can sensibly fill the x1 slot of xunre. It is NOT a statement.

> Say {le ka keha xunre} is the properties responsible for red things
> being categorizable as red.  That would mean that
>
>    koha kohe frica lo ka keha xunre
>
> means "the properties responsible for red things being categorizable
> as red differentiate koha and kohe". Okay.

Great.

> > {le ka ko'a xunre} on the other hand, is the value that the function
> > redness() takes for the argument koha.
>
> That would be {le ka [keha] xunre kei be koha}.

Yes. I don't need to use {le ka ko'a xunre} with frica anyway.

I think {le ka ko'a xunre} is still valid, but it can't be used for places
like the x3 of frica, where an unevaluated function is required. I wouldn't
have a problem with things like {le ka ko'a xunre cu pluka mi} because
the x1 of pluka does not require an unevaluated function

> > > > > "Differ" needs a feature (e.g. size) as x3, not a feature value.
> > > > Agreed.
> > > Right. So I don't think "lo ka broda" is adequate as x3 of "differ".
> > How else can you get an unevaluated function there?
>
> This discussion makes me think (a) we haven't found a way to get the
> x3 to refer to a feature (i.e. to a selbri),

It has to be a sumti. There's no way you can put a selbri there.

> but (b) I was wrong,
> and an x3 referring to feature values work, if we gloss frica as
> "x3 is a difference between x1 and x2".

Referring to feature values, but not being the values themselves, because
you can't put a value there.

> Since noone is going to agree to change the selmaho of ka and lihi, I
> would suggest the rule:
>   x2 of ka/lihi is identical to the first vacant tersumti, and if no
>   tersumti is vacant then it is {dohe}.
> To identify x2 of ka/lihi with a modal place, perhaps {lo ka bai fai broda}
> - does the grammar allow that?

I think you want {lo ka jai bai broda}, which brings the bai place to
the x1.

> If this would work, no change would need to be made to the syntax.

That works, but using {ke'a} (or any other lambda variable) is equivalent,
and allows a bit more flexibility.

> > {goi} assigns a value to an assignable  pro-sumti. I don't know how you
> > interpret {ta goi ti}, but it has to be some generalization of that which is
> > not obvious to me.
>
> I'd interpret it as "you know what {ta} refers to; well, {ti} refers to
> the same thing. That thing is this thing."

But ta and ti already refer to the things I'm pointing to, which normally
are different things. It's like {lo gerku goi lo mlatu}, it's meaninglesss.
{goi} requires one of the sumti to be assignable. What you give as the
meaning of {ta goi ti} is really the meaning of {ta no'u ti}.

> I don't see how you restrict {le ka keha clani} to tall/non-tall.
> Why can't it be tallish/gigantic?

This depends on something else. What is the truth value of {ko'a clani}?
If it can only be 0 or 1, then {le ka ke'a clani} can only be tall/non-tall.
If it can have any value between 0 and 1, then {le ka ke'a clani} also
has a range of possible values matching the truth values.

> This said, I don't see why we need ni. {lo lahu fai} seems to do the
> job perfectly well.

I think you mean {lo jai la'u}. I agree it works (except for things like
the x3 of frica where you need open functions) but you lose flexibility:
you are forced to use be-beis and you are forced to have all the sumti
after the selbri. It is a more awkward re-writing of {lo ni}.

> For that matter, {lo fau fai} could replace nu.
> I desist from continuing: ni & nu are going to stay.
> --------
> And
>
> xamti damti sa tonda vo
> xamti damti xa dagre fo
> .o da kinzo se zando da kizme
> ku danpu xamti tu ge da ra ge

It doesn't parse...

Jorge