RE: [lojban] Re: noxemol ce'u

["And Rosta" <a.rosta@dtn.ntl.com>]

pc:
> a.rosta@dtn.ntl.com writes: 
>   ce'u is in the main clause in {broda le mamta be ce'u}. I thought you 
>   were wanting to say that that meant "broda the mother-of function". 
> 
>   > But I see your problem: you take 
>   > {ko'a broda le brode be ce'u} as a main clause occurrence, which I 
>   > explicitly deny. 
> 
>   Right. I'm pretty certain that you're the one out on a limb here... 
> 
>   > In your terminology, {ce'u} is here bound to the 
>   > {le} just as in {ka makau mamta ce'u} it is bound to the {ka} 
>   > (thought the binding is rather different. 
> 
>   I know that's how you want it to be. But you're inventing rules that 
>   conflict with a lot of established canon, and for no good reason 
>   that I can see. Hopefully if you will follow steps (a) and (b) above, 
>   we will all find it easier to reach agreement. 
> 
> I can't find this established canon you speak of. 

Although I didn't read your exchange with Jorge in this thread very
carefully, I did observe several times that the views he was expressing
are the received wisdom, and uncontroversial until your contributions
to the thread. 

I'm not complaining about you wanting to challenge the received wisdom,
but at times you give them impression that you're doing it accidentally
while blindly charging around in search of a way to express functions.

I'm probably mistaken in forming that impression, but all the same you
could avoid it if you were at pains to separate your aims (expressing
functions vs. exploring ce'u vs. challenging sundry received wisdoms).

> To be sure, I 
> can't find any {ce'u} not in a NU clause of one sort or another, but 
> I also can't find any rule prohibiting it -- and they are called 
> lambda variables.  As for the [ce'u} in {le mamta be ce'u} not being 
> in the main clause, it is more thoroughly subordinated the the {kea} 
> in {poi mamta kea}, so that {ke'a} is presumably a mainclause usage.  
> It is totally compatible with its subordinate usage -- if it has one 
> -- and so not a problem.  The same should then apply to {le mamta be ce'u} 

???

> <Okay. Rather than quibble, I'll say this: You need to (a) come up with a 
> small corpus of example sentences that show that we need to be able to 
> talk about functions, and (b) propose a provisional method for talking 
> about functions that doesn't interfere with existing grammar (i.e. it 
> should use experimental cmavo or lujvo or whatever).> 
> 
> I don't see that I need to show that we NEED to talk about functions 
> -- I don't think we do, anymore than we NEED to talk about properties 
> or relations or things, come to that.  But we do want to from time to 
> time and it is handy to have devices for doing this.  

Well give us an indication of how pressing the need is, so we can judge
how much baby we can allow to be thrown out with the bathwater in the
search for a way to talk about them.

> As for a corpus 
> of example sentences -- I assume you mean in English, 

yes

> although you do 
> shift around on this a lot. Since I am not clear what you mean by 
> "function" in this context, esepcially since all of the examples I 
> have given have not counted as cases, apparently (even though they 
> are generally your examples with minor modifications), 

I mean whatever you mean -- whatever it is that you think we have no
agreed way of rendering in Lojban.

> I don't know how to answer.  
[1]> "Bobby, recite your times tables"? 
[2]> "Sum is symmetric but power is not"?  
[3]>"Hyperpower is hard to define, since the 0 case is undetermined."?  
[4]>"They differ in their mothers"?  
[5]> "They are interchangeable in their friends"? 

So if we could find ways to lojban these, we'd satisfy you?

For [1], I'd say the recitee is the extension of tu'odu'u ce'u -timestable.

For [2] and [3] I'd render Sum, Power and Hyperpower by tu'odu'u ce'u -sum
ce'u, etc.

For [4] and [5] I don't yet understand how functions are necessarily
involved; certainly you and I have agreed that certain functionless
logical renditions are in themselves adequate.

> b) goes against my basic philosophy in Lojban and I see yet no reason 
> for changing: why invent a new device when we have an unused one 
> handy?  I know you would rather invent a new one for every quirky 
> variant than dig for a way to do it in the given, but that is not my choice. 

Because you end up mixing together separate issues and, to the extent that
your aim is to persuade other people to agree with you, shooting yourself
in the foot. Your unused device appears to require the demolition of
sundry canonical notions, such as that le sumti can export to the main
bridi, that sumti within sumti 'belong to' the same bridi, that the
intepretation of an unsubordinated bridi is the same as when the bridi
is subordinated, and so on.

If you would fight just one battle at a time, you might win some. 

> <For (b), I will start you off by suggesting a lujvo: 
> 
> x1 is a -function from x1 to x2 
> 
> e.g. 
> 
> da poi ro da ke'a se -function ro mamta be ro nei> 
> 
> Sounds like a useful predicate, once corrected: "from x2 to x3" , but 
> what does it have to do with your following line -- the vacuous {da} 
> and {ke'a} make it hard to interpret so I am not even sure what it 
> was *meant* to mean.  Is this suppose to be the mother-of function?  
> da poi ke'a function ro de le mamta be de?  It seems you have 
> something else in mind, but it keeps back to things like the mother 
> of the function. 

"da poi ro de ke'a se -function ro mamta be ro nei"

is meant as a suggestion of how to say "the mother-of function". {note
correction to "de") You don't have to agree with it or even take the
trouble to demolish it, so long as you offer an improved version;
after all, you have a clearer idea of what you want to say in lojban.

If you accept a lujvo like "x1 is a function from x2 to x3", then
hopefully the "How do we talk about functions?" issue is solved. You
could then press on with your indagations into ce'u, while Jorge and
I strive to make sure you don't demolish more than you add.

--And.