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

This page is part of the web mail archives of SRFI 114 from before July 7th, 2015. The new archives for SRFI 114 contain all messages, not just those from before July 7th, 2015.

*To*: John Cowan <cowan@xxxxxxxxxxxxxxxx>*Subject*: Re: [Scheme-reports] R7RS-large comparators*From*: Alan Manuel Gloria <almkglor@xxxxxxxxx>*Date*: Sat, 13 Jul 2013 07:52:37 +0800*Cc*: Andrew Robbins <andjrob@xxxxxxxxx>, srfi-114@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-114@xxxxxxxxxxxxxxxxx*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k5mpm0/eBzxiLwvAiCFnIba/FM89pcYiiDnijFIpKuU=; b=RTqDJthLU+Q0F3glghQa6yRzVF0RfhalX10dSMiKMfN4tssNBwG3WPVWZvWlxkvoa2 dixa0EsxQYAMmNLmhoCpd9PtXLkCoo/qI38yAp1994nr74CR1hFnHn+/s/9DGDLSxvbt 5Ttvw1ssNSup+ypBvjn3Kj6D4QPQGUXnQXBmi91WOkxwoscA4cg8FXoYv/yM4V5HgmG6 JEU5BQzaTSjbkRmhYJ2qYhKk9/ENNkUk51MGPvVS155W9DAo/khuiys8P3d2dqxeplep iT/4q+g0S+O0uXlg3U8uZL6JXP/eSaOf1dtMnl15BeNmVpmiLN8BaV17fshntCjdSTbL FuHg==*In-reply-to*: <20130712145855.GB29600@xxxxxxxxxxxxxxxx>*References*: <CAAMbixKpsjMJ0SuDHaO19QsDR0Xor91xNQbeRfd6rKxXnbACAw@xxxxxxxxxxxxxx> <20130712145855.GB29600@xxxxxxxxxxxxxxxx>

> General Issues:SRFI 114 does provide a special case for floats. What would be other

> It is my personal opinion that this module should be helpful to anyone

> involved in either total orders or partial orders, such as floating-point

> numbers (which form a total order if you ignore NaNs and -0.0). One way of

> doing this would be to use an exception/condition to express a lack of

> total order, another would be to return something other than -1, 0, 1 from

> the compare procedure (perhaps return +nan.0), which would violate the

> conditions for a compare procedure according to this module as specified so

> far. I'm not sure what the best way to do this is, except to provide

> additional procedures for floating-point numbers, and not handle partial

> orders in a general way. My intuition tells me that a general approach

> would be more valuable in the long term, than to special case floats.

> Treating any and all partial orders that come along as special cases, just

> seems wrong to me.

use cases for partial orders in general?

Subtyping relations are a partial ordering.

Consider:

Numbers >= Complex >= Reals >= Rationals >= Integers >= Naturals

However, consider also:

Numbers >= Complex >= Imaginaries

The Imaginaries type is "incomparable" to the Reals, Rationals, Integers, or Naturals type, because it follows a different branch of subtyping. This forms a partial ordering.

It would be nice to be able to "compare" two type objects and learn if one is a sub-type of the other, is the same type, or are incomparable.

Sets may also be compared (basically, if you consider that subtype == subset, so that "the set of Numbers is a superset of Reals"), and the result may also be "incomparable", i.e. one is not a strict subset of or equal to the other.

For floats, perhaps NaN should return "incomparable" if one side is a NaN and the other is not, or "equal" if both are NaN (this would simplify some uses of hash tables). As for -0.0, perhaps we can consider it as actually being -(epsilon/2), so that it is less than 0.0 but greater than -epsilon, where epsilon is the tiniest representable non-zero float.

**Follow-Ups**:**Re: [Scheme-reports] R7RS-large comparators***From:*Alexey Radul

**References**:**Re: [Scheme-reports] R7RS-large comparators***From:*John Cowan

- Prev by Date:
**Subscribe** - Next by Date:
**Re: [Scheme-reports] R7RS-large comparators** - Previous by thread:
**Re: [Scheme-reports] R7RS-large comparators** - Next by thread:
**Re: [Scheme-reports] R7RS-large comparators** - Index(es):