ODIL: An attempt at defining language efficiency

Principles #1 and 2 of my essay "On the design of an ideal language"
(http://community.livejournal.com/conlangs/14524.html) say that a
language should be maximally easy to use, and/but also be maximally
dense semantically.

This requires some measure of a language's 'efficiency', which I'm
attempting here.

Action = {production or (pe)reception}
Effort(s, action) = calories expended in doing action for sentence s
Efficiency(action) = average[effort(S, action) * frequency(S)], for
all possible sentences S
Efficiency(language) = average[efficiency(action) * weight(action)],
for all possible actions, with weighting at the discretion of the
designer

Effort is a bit of a kludge I think; I'm not sure if e.g. mouth
configurations that are obviously intuitively more 'effortful' do
expend more calories, or if that scales appropriately - it might
require log(calories) or somesuch other transform. E.g. is it an
appropriate measure for measuring how difficult it is to comprehend
something? Should there also be a time factor?

Frequency does imply context, and that's intentional; one cannot
calculate efficiency without that. A next-gen language efficiency-wise
would need to have a way to be context-sensitive for efficiency, as I
don't think it can be effectively be done using merely "human
purposees" as context. E.g. it could perhaps adapt to being in the
context of "linguistic discussion" vs "ordering fast food" so that
they're equally efficient. That's a separate issue of course, though I
have a couple tentative ideas how it could be done.

Yes, "all possible sentences" is infinite; that is perfectly fine, as
we're taking what is essentially a limit. It does imply another
question - i.e. do you want the actual limit or just a 99%-frequency
cutoff, or IOW do you want to burden the most common stuff just to be
able to produce very uncommon ones semi-decently, or is it OK to make
those really a pain to gain some savings with the common bits. Again,
I leave that undefined intentionally, as I consider it a configuration
parameter.

Part of what this implies practically is that for every mode you'd
have some sort of list of the possible actions - e.g. sounds and sound
clusters - and a measure of the effort required to produce or
(pe)receive each. Then the easier ones can be used for common items,
and the harder ones for less common ones.

Obviously as always this is intented to be a principle that is
balanced by / opposed to other principles of design such as
aesthetics; here I'm just focusing on this aspect.

Comments?

- Sai