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