[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Weird numeric predicates?



   Date: Tue, 21 Mar 89 23:31 EST
   From: Alan Bawden <Alan@AI.AI.MIT.EDU>

   Now, if you would like to argue with the given that the arithmetic
   primitives accept mixed exact and inexact arguments, we can do that.  You
   might even find that you can convince me.  But I don't want anyone to lose
   track of what I originally said because someone stigmatized it by using the
   word "DWIM" in its presence.  I was not proposing anything that could be
   described as DWIM, and in fact I was not proposing anything at all.  I was
   pointing out the consequences of two different implementations of the
   arithmetic comparison predicates.  Consequences, I might add, that most
   implementors seem to be unaware of.

My sincere apologies for the unclear prose.  Indeed, I should have
said I wasn't responding to your point directly but, as you say,
arguing with a given, one which had simply been brought to my
attention by your comments.  My only defense is that, while this idea
has been forming in my head for a while, this is the first time I've
attempted to express it.

However, the given I was arguing with is not exactly "that the
arithmetic primitives accept mixed exact and inexact arguments".  It
is that the arithmetic primitives are mode-generic: the mode in which
the operation is performed (exact or inexact) is dependent on the
exactness or inexactness of the arguments.  This is the characteristic
that I am attempting to stigmatize with the word "DWIM".

I am suggesting, as an alternative, that the primitives be bifurcated
into exact and inexact versions and that the mode in which the
operation is performed be dependent only on which primitive is
involved.  I am *not* suggesting that the primitives not accept mixed
exact and inexact arguments.

Thus, an exact primitive would coerce all arguments to be exact before
performing the operation, even if *all* of said arguments were
supplied in inexact form; conversely for inexact primitives.

Apologies again.  Is this making sense yet?

Scott