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

*To*: Jens Axel Søgaard <jensaxel@xxxxxxxxxxxx>*Subject*: Re: vector compare*From*: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>*Date*: Fri, 10 Jun 2005 08:10:20 +0200*Cc*: srfi-67@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-67@xxxxxxxxxxxxxxxxx*In-reply-to*: <42A86397.7040806@xxxxxxxxxxxx> (Jens Axel Søgaard's message of "Thu, 09 Jun 2005 17:43:19 +0200")*References*: <OF7B1F9CDE.F4ED119E-ONC125701B.0027F89A-C125701B.002840B7@xxxxxxxxxxx> <42A7F6CF.2090106@xxxxxxxxxxx> <42A86397.7040806@xxxxxxxxxxxx>*User-agent*: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5-b20 (berkeley-unix)

Jens Axel Søgaard <jensaxel@xxxxxxxxxxxx> writes: > As Sebastian argues, there not 1 natural order of vectors, but the > ordering in the srfi is /a/ natural order. But, as Per and Donovan and myself are arguing, the one you picked *isn't* a natural order, at least by our nature. > A concrete > example is the sorting of polynomials: > > x^3 > x^2 + 1 > x^2 > 42 > > A concrete representation in terms of vectors yields: > > #(3 0 0 0) > #(2 0 1) > #(2 0 0) > #(42) But it doesn't extend to leading 0 coefficients. > In this scenerio the order used in the srfi is better > efficiencywise than the lexicographical order -- and not > only by a constant factor. I'm personally gladly willing to pay that price. I'd rather be slow than surprised. (And, of course, the efficiency argument only holds for one particular implementation of vectors that isn't guaranteed by R5RS.) -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

**References**:**Re: vector compare***From:*Sebastian Egner

**Re: vector compare***From:*Per Bothner

**Re: vector compare***From:*Jens Axel Søgaard

- Prev by Date:
**Re: vector compare** - Next by Date:
**Re: vector compare** - Previous by thread:
**Re: vector compare** - Next by thread:
**Re: vector compare** - Index(es):