Definition of Order in S29
In the definition of cmp, S29 says the function "returns |Order::Increase|, |Order::Decrease|, or |Order::Same| (which numify to -1, 0, +1)". Shouldn't the enumerations and their numerical values be listed in the same order? Joe Gottman
Re: Definition of Order in S29
Joe Gottman wrote: In the definition of cmp, S29 says the function "returns |Order::Increase|, |Order::Decrease|, or |Order::Same| (which numify to -1, 0, +1)". Shouldn't the enumerations and their numerical values be listed in the same order? Joe Gottman The enumerations and the numerical values are both in correct order. Since "abc" is less than "xyz", "abc" cmp "xyz" is being invoked with its arguments in increasing order, So it returns Order::Increase. That numifies to -1 because that's how "less-than" is usually encoded. =thom -- I wanna hang a map of the world in my house. Then I'm gonna put pins into all the locations that I've traveled to. But first, I'm gonna have to travel to the top two corners of the map so it won't fall down. -- Mitch Hedberg
Re: Definition of Order in S29
At 11:37 AM -0700 1/24/08, Thom Boyer wrote: Joe Gottman wrote: In the definition of cmp, S29 says the function "returns |Order::Increase|, |Order::Decrease|, or |Order::Same| (which numify to -1, 0, +1)". Shouldn't the enumerations and their numerical values be listed in the same order? The enumerations and the numerical values are both in correct order. Since "abc" is less than "xyz", "abc" cmp "xyz" is being invoked with its arguments in increasing order, So it returns Order::Increase. That numifies to -1 because that's how "less-than" is usually encoded. Thom, I don't think you understood Joe's more obvious question. AFAIK, the Order values are supposed to numify like this: Order::Increase -> -1 Order::Same -> 0 Order::Decrease -> +1 The above quoted text shows the numify in the order [-1,0,1], but the Order values are not in the corresponding sequence. To fix the problem, the S29 text should probably say: returns |Order::Increase|, |Order::Same|, or |Order::Decrease| (which numify to -1, 0, +1) That way, reading the S29 text makes more sense. This is, I believe, what Joe was pointing out needed to be fixed. -- Darren Duncan
Re: Definition of Order in S29
On 2008-01-24 Thom Boyer <[EMAIL PROTECTED]> wrote: > Joe Gottman wrote: > > In the definition of cmp, S29 says the function "returns > > |Order::Increase|, |Order::Decrease|, or |Order::Same| (which > > numify to -1, 0, +1)". Shouldn't the enumerations and their > > numerical values be listed in the same order? > > > > Joe Gottman > The enumerations and the numerical values are both in correct order. > Since "abc" is less than "xyz", "abc" cmp "xyz" is being invoked > with its arguments in increasing order, So it returns > Order::Increase. That numifies to -1 because that's how "less-than" > is usually encoded. Correct about Increase. But would ::Decrease numify to 0, and ::Same to +1? :) -- Dakkar - GPG public key fingerprint = A071 E618 DD2C 5901 9574 6FE2 40EA 9883 7519 3F88 key id = 0x75193F88 That's one small step for a man; one giant leap for mankind. -- Neil Armstrong signature.asc Description: PGP signature
Re: Definition of Order in S29
Thom Boyer wrote: > The enumerations and the numerical values are both in correct order. > Since "abc" is less than "xyz", "abc" cmp "xyz" is being invoked with > its arguments in increasing order, So it returns Order::Increase. That > numifies to -1 because that's how "less-than" is usually encoded. Others have pointed out Joe's actual intent in asking the question; so I won't belabor the point. Instead, I'll say that the idea that Order::Increase numifies to -1 is going to take some getting used to. While I understand the reasoning behind it, my intuition would have been to numify it to +1 for an increase and -1 for a decrease. If C<"abc" cmp "xyz"> must numify to -1, could we please choose something like 'Order::Before' and 'Order::After' instead of 'Order::Increase' and 'Order::Decrease'? Not only does this make more intuitive sense, but it also pairs the Order values more closely with the type-neutral comparison operators ('before' and 'after'). (Which brings up another point, which I'll freely admit I'm too lazy to look up at the moment: do we already have a type-neutral operator that corresponds to 'Order::Same'? I suspect that '===' is it; but my grasp of the plethora of equivalence operators is somewhat shaky. If not - and possibly even if so, depending on which paradigm is the most important one to reinforce - I might recommend using 'same' to complete the 'before'/'after' set of operators.) -- Jonathan "Dataweaver" Lang
Re: Definition of Order in S29
At 7:20 PM -0800 1/24/08, Jonathan Lang wrote: Instead, I'll say that the idea that Order::Increase numifies to -1 is going to take some getting used to. While I understand the reasoning behind it, my intuition would have been to numify it to +1 for an increase and -1 for a decrease. I don't see this as being a problem since I expect very few users deal directly with the numbers anyway, and they're just a background implementation and/or legacy detail. The main place I would understand the actual numbers having any semantic effect is if you want to chain comparators such as "$^a.foo <=> $^b.foo or $^a.bar <=> $^b.bar" (I may have spelled wrong), sort first by .foo then by .bar; that's counting on the result boolifying to false when the 2 comparands are equal, and boolifying to true when not; this isn't different in your suggestion vs otherwise. So I recommend not changing this. If C<"abc" cmp "xyz"> must numify to -1, could we please choose something like 'Order::Before' and 'Order::After' instead of 'Order::Increase' and 'Order::Decrease'? Not only does this make more intuitive sense, but it also pairs the Order values more closely with the type-neutral comparison operators ('before' and 'after'). By contrast, at least looking at Order on its own, I think Increase|Decrease works better than Before|After. Part of the reason is that the first 2 work well for both prefix and infix notations, while the second 2 just work for infix. Take for example "there is an increase from foo to bar" or "foo increases to become bar", versus "foo is before bar". At least this aspect is a preference of mine, as I prefer standardizing on prefix notation for all routine/operator calls where possible. Still, I suppose I may not complain too loudly if the change you suggest was made. I'd be more interested in hearing what precedents if any exist in this regard. What do other languages call the same concepts? -- Darren Duncan
Re: Definition of Order in S29
On Jan 24, 2008, at 23:23 , Darren Duncan wrote: I'd be more interested in hearing what precedents if any exist in this regard. What do other languages call the same concepts? data Ord = LT | EQ | GT -- Haskell -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH