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

Re: comparison operators and *typos



 | Date: Tue, 28 Jun 2005 02:38:14 -0400
 | From: Paul Schlie <schlie@xxxxxxxxxxx>
 | 
 | > From: Aubrey Jaffer <agj@xxxxxxxxxxxx>
 | >  | Date: Mon, 27 Jun 2005 18:09:04 -0400
 | >  | From: Paul Schlie <schlie@xxxxxxxxxxx>
 | >  | 
 | >  | > From: Aubrey Jaffer <agj@xxxxxxxxxxxx>
 | >  | >  | Date: Mon, 27 Jun 2005 02:29:12 -0400
 | >  | >  | From: Paul Schlie <schlie@xxxxxxxxxxx>
 | >  | >  | ...
 | >  | >  | Thereby one could define that an unsigned 0 compares = to signed 0's
 | >  | >  | to preserve existing code practices which typically compare a value
 | >  | >  | against a sign-less 0. i.e.:
 | >  | >  | 
 | >  | >  |  (= 0 0.0 -0 -0.0) => #t
 | >  | >  |  (= 0 0.0 +0 +0.0) => #t
 | >  | >  | 
 | >  | >  |  (= -0 -0.0 +0 +0.0) => #f
 | >  | > 
 | >  | > The `=' you propose is not transitive, which is a
 | >  | > requirement of R5RS.
 | >  | 
 | >  | - then alternatively one could define:
 | >  | 
 | >  |   (= -0 -0.0 0 0.0 +0 +0.0) => #t
 | >  | 
 | >  |   while retaining the remaining relationships, as it seems
 | >  |   that = and < relationships need not be mutually exclusive?
 | > 
 | > R5RS says:
 | > 
 | >   -- procedure: = z1 z2 z3 ...
 | >   -- procedure: < x1 x2 x3 ...
 | >   -- procedure: > x1 x2 x3 ...
 | >   -- procedure: <= x1 x2 x3 ...
 | >   -- procedure: >= x1 x2 x3 ...
 | >       These procedures return #t if their arguments are (respectively):
 | >       equal, monotonically increasing, monotonically decreasing,
 | >       monotonically nondecreasing, or monotonically nonincreasing.
 | > 
 | >       These predicates are required to be transitive.
 | > 
 | > Equal cannot be monotonically increasing.
 | 
 | - why not? I was under the impression that the transitive requirement
 |   applied to the elements of a particular predicate, but not
 |   necessarily apply across distinct predicates?

Sorry for the confusion; this doesn't have to do with transitivity.
The relevant sentence is "These procedures return #t if ...".

 |   As the ordering which may exist for = need not apply to <=, nor
 |   are the ordered members of <= necessarily valid for = ? (however
 |   the context of the thought was to enable the comparison of 0
 |   against other zeros as being = as a possible means of preserving
 |   existing code practices while allowing the introduction of
 |   alternate forms of 0 with more specific meanings)

The additive identity is central to the structure of the integer ring
and the rational field.  It cannot be split without breaking
properties of the ring and field.  So the important questions are:

* Which properties of the integer ring and rational field will the
  inclusion of infinitesimals break?

* Is the inclusion of infinitesimals worth the mathematical damage?

 | ...
 | >  |   (all arithmetic functions should always return values).
 | > 
 | > Always returning a value is a stronger requirement than R5RS or
 | > SRFI-70, which gives the implementation a choice between returning 0/0
 | > and signaling an error for (/ 0.0 0.0). Can you justify that mandate?
 | 
 | - only on the basis that errors/exceptions are by their nature
 | disruptive to both the expressed (and presumably intended) code
 | and/or otherwise control flow of the program, therefore all
 | standard functions should be defined to yield values, which may be
 | checked explicitly as may desired for application specific
 | expectations within the applications code itself, or encapsulated
 | in corresponding application specific wrappers which may then throw
 | exceptions, and/or shape the results to the applications more
 | specific needs and/or expectations. (but as noted above, I think
 | its reasonable to define a mechanism by which an implementation to
 | optionally enable functions to report and/or throw warnings/errors,
 | but not in lieu of their returning values by default).

Switches controlling the behavior of built-in procedures are
time-bombs for library modules.  Except for the optional procedures
WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE, Scheme has avoided this
approach to controls.

 | > Do you consider QUOTIENT, MODULO, and REMAINDER arithmetic?
 | 
 | - yes, and believe all should return values by default (even for invalid
 |   operands, where by default it could be defined that a function may
 |   return a <void> type or something similar by default, or signal an error
 |   when explicitly enabled to do so; which I know is a bit different)
 | 
 |   i.e. (car 3) => <void>

That would be a sea change for Scheme.

 | > ...
 | > SRFI-73 is about exact numbers.  EXPT will only return exact numbers
 | > for exact arguments.  Loss of precision means inexact numbers.
 | 
 | - yes I apologize for going off on a tangent, I was considering
 | inexact values. (however in the context of exact values, it seems
 | that the only way to generate +-inf or +-0, would be directly from
 | the literal use of such an abstract value in an expression itself,
 | as it would seem impossible to generate an exact infinite value as
 | a function of finite value expressions?)

Agreed.  Unlike inexact infinities completing the real number line,
exact infinities are isolated transcendental elements which barely
connect to the rationals.

The remainder of the discussion is about inexacts; I am redirecting it
to srfi-70@xxxxxxxxxxxxxxxxx