On 25/09/2011, at 18:20, Chris Smith wrote:
class Ord a = Range a where
rangeFromTo :: a - a - [a] -- subsumes Ix.range / Enum.enumFromTo
rangeFromThenTo :: a - a - a - [a]
inRange :: (a, a) - a - Bool
-- Does have instances for Float/Double. List ranges desugar to this.
-- Also
On 29 September 2011 07:56, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
On 25/09/2011, at 18:20, Chris Smith wrote:
class Ord a = Range a where
rangeFromTo :: a - a - [a] -- subsumes Ix.range / Enum.enumFromTo
rangeFromThenTo :: a - a - a - [a]
inRange :: (a, a) - a - Bool
--
On 28/09/2011, at 23:23, Ivan Lazar Miljenovic wrote:
On 29 September 2011 07:56, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
On 25/09/2011, at 18:20, Chris Smith wrote:
class Ord a = Range a where
rangeFromTo :: a - a - [a] -- subsumes Ix.range / Enum.enumFromTo
rangeFromThenTo
On Mon, Sep 26, 2011 at 10:50 AM, Chris Smith cdsm...@gmail.com wrote:
On Mon, 2011-09-26 at 18:53 +0200, Lennart Augustsson wrote:
If you do [0.1, 0.2 .. 0.3] it should leave out 0.3. This is floating
point numbers and if you don't understand them, then don't use them.
The current behaviour
On 23/09/2011, at 4:06 PM, Chris Smith wrote:
On Fri, 2011-09-23 at 11:02 +1200, Richard O'Keefe wrote:
I do think that '..' syntax for Float and Double could be useful,
but the actual definition is such that, well, words fail me.
[1.0..3.5] = [1.0,2.0,3.0,4.0] Why did anyone ever
Chris Smith wrote:
class Ord a = Range a where...
Before adding a completely new Range class, I would suggest
considering Paul Johnson's Ranged-sets package:
http://hackage.haskell.org/package/Ranged-sets
Ranges have many more natural operations, and interactions
with other classes, than you
If you do [0.1, 0.2 .. 0.3] it should leave out 0.3. This is floating point
numbers and if you don't understand them, then don't use them. The current
behaviour of .. for floating point is totally broken, IMO.
-- Lennart
On Fri, Sep 23, 2011 at 6:06 AM, Chris Smith cdsm...@gmail.com wrote:
I totally agree with you. Haskell is very broken when it comes to [x..y]
for floating point.
It's an attempt to make it more friendly for naive users, but there is no
way FP can be made friendly. Any such attempts will fail, so make it usable
for people who understand FP instead.
-- Lennart
On Mon, 2011-09-26 at 18:53 +0200, Lennart Augustsson wrote:
If you do [0.1, 0.2 .. 0.3] it should leave out 0.3. This is floating
point numbers and if you don't understand them, then don't use them.
The current behaviour of .. for floating point is totally broken, IMO.
I'm curious, do you
On Mon, 2011-09-26 at 18:52 +0300, Yitzchak Gale wrote:
Chris Smith wrote:
class Ord a = Range a where...
Before adding a completely new Range class, I would suggest
considering Paul Johnson's Ranged-sets package:
Well, my goal was to try to find a minimal and simple answer that
doesn't
On 26/09/2011, at 11:08 AM, Daniel Fischer wrote:
And: distinguish NaNs or identify them all?
I lean towards identifying them all, I've never cared for whether they come
from 0/0, Infinity - Infinity or what, but I could be convinced.
There are very many bit patterns that count as NaNs,
On 27/09/2011, at 6:50 AM, Chris Smith wrote:
On Mon, 2011-09-26 at 18:53 +0200, Lennart Augustsson wrote:
If you do [0.1, 0.2 .. 0.3] it should leave out 0.3. This is floating
point numbers and if you don't understand them, then don't use them.
The current behaviour of .. for floating
Would it be an accurate summary of this thread that people are asking
for (not including quibbles about naming and a few types):
class Ord a = Enum a where
succ :: a - a
pred :: a - a
fromEnum :: a - Int(eger)
toEnum :: Int(eger) - a
-- No instance for Float/Double
class Ord a =
On Sunday 25 September 2011, 19:20:52, Chris Smith wrote:
Would it be an accurate summary of this thread that people are asking
for (not including quibbles about naming and a few types):
Not quite, I'm afraid.
class Ord a = Enum a where
succ :: a - a
pred :: a - a
fromEnum ::
Don't mix range and arithmetic sequences. I want arithmetic sequences for
Double, Float and Rational, but not range.
(For Float and Double one could implement range [all values between the
given bounds, in increasing order, would be the desired/expected semantics
for that, I think?],
On Sunday 25 September 2011, 23:13:47, Chris Smith wrote:
Don't mix range and arithmetic sequences. I want arithmetic sequences
for Double, Float and Rational, but not range.
(For Float and Double one could implement range [all values between
the given bounds, in increasing order, would be
On 21/09/2011, at 11:42 PM, Jake McArthur wrote:
With fixed point numbers, it makes sense to have an Enum instance.
What is the use case?
Enumeration is reasonable because most applications for fixed point
arithmetic do *not* want to pretend that they are real numbers;
But that does not
On Thu, Sep 22, 2011 at 7:02 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote:
On 21/09/2011, at 11:42 PM, Jake McArthur wrote:
With fixed point numbers, it makes sense to have an Enum instance.
What is the use case?
I'm not quite sure how to answer this. I'm speaking in a fairly general sense.
On Fri, 2011-09-23 at 11:02 +1200, Richard O'Keefe wrote:
I do think that '..' syntax for Float and Double could be useful,
but the actual definition is such that, well, words fail me.
[1.0..3.5] = [1.0,2.0,3.0,4.0] Why did anyone ever think
_that_ was a good idea?
In case you meant
If you can clear this up with a better explanation of the properties,
great! But if you can't, then we ought to reject the kind of thinking
that would remove useful behavior when it doesn't fit some theoretical
properties that looked nice until you consider the edge cases.
It's not just
Daniel Fischer daniel.is.fisc...@googlemail.com writes:
Btw, -0.0 can be problematic too.
How so? As far as I can tell Ord and Eq treat it as equal to 0.0 in
every way,
Yes. Which can be inconvenient if you are interested in whether you got a
-0.0, so if that's the case, you can't simply
From: Casey McCann c...@uptoisomorphism.net
CAJ5riwLLu=wAFXm8VPnqRG2Daxxgf=upgxzchydmebgngix...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Sep 20, 2011 at 8:20 PM, Daniel Fischer
daniel.is.fisc...@googlemail.com wrote:
However, nowadays I tend to think that
On Tue, Sep 20, 2011 at 11:29 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote:
On 21/09/2011, at 2:59 AM, Chris Smith wrote:
On Mon, 2011-09-19 at 22:09 -0700, Evan Laforge wrote:
Then I tried switching to a fixed point format, and discovered my
mistake. Enum is supposed to enumerate every
On Tue, Sep 20, 2011 at 11:47 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote:
On 21/09/2011, at 2:18 PM, Casey McCann wrote:
I still don't see why it makes sense to add separate IEEE comparisons
instead of just adding a standard partial order class, though.
In any mathematical partial order,
On Tue, Sep 20, 2011 at 11:33 PM, rocon...@theorem.ca wrote:
For what it's worth, at some point in time I was sketching a proposal to
split the Enum class into two classes because I felt that two distinct ideas
were being conflated. Unfortunately this was years ago and I have forgotten
what
On Wed, Sep 21, 2011 at 12:09 AM, Daniel Fischer
daniel.is.fisc...@googlemail.com wrote:
Yes. Which can be inconvenient if you are interested in whether you got a
-0.0, so if that's the case, you can't simply use (== -0.0).
Okay, problematic is a too strong word, but it's another case that may
On Wed, Sep 21, 2011 at 14:31, Casey McCann c...@uptoisomorphism.net wrote:
My thoughts are that the first interpretation is most naturally suited
to list range syntax, that the second would be better served by a
slightly different syntax to make the predicate more explicit, and
that the
On Wed, Sep 21, 2011 at 2:41 PM, Brandon Allbery allber...@gmail.com wrote:
On Wed, Sep 21, 2011 at 14:31, Casey McCann c...@uptoisomorphism.net wrote:
My thoughts are that the first interpretation is most naturally suited
to list range syntax, that the second would be better served by a
On Wednesday 21 September 2011, 20:39:09, Casey McCann wrote:
On Wed, Sep 21, 2011 at 12:09 AM, Daniel Fischer
daniel.is.fisc...@googlemail.com wrote:
Yes. Which can be inconvenient if you are interested in whether you
got a -0.0, so if that's the case, you can't simply use (== -0.0).
On Mon, 2011-09-19 at 22:09 -0700, Evan Laforge wrote:
Then I tried switching to a fixed point format, and discovered my
mistake. Enum is supposed to enumerate every value between the two
points, and the result is memory exhaustion.
I'm not sure where you read that Enum is supposed to
On Tue, Sep 20, 2011 at 10:59 AM, Chris Smith cdsm...@gmail.com wrote:
I certainly hope not. Instead, perhaps the issue should be brought up
with the fixed-point number library you're using, and they could fix
their Enum instance to be more helpful.
I'm the author of the library in question.
On Tue, Sep 20, 2011 at 10:59 AM, Chris Smith cdsm...@gmail.com wrote:
The better way to look at this is that the notion of `succ` and `pred`
is dependent on the type, much like `mappend` has no particular meaning
until a Monoid instance is given for the type. It's fairly well
established,
Chris Smith cdsm...@gmail.com writes:
It would be a shame if we lost an occasionally useful and easy to read
You forgot confusing? Expecting Enum to enumerate all inhabitants of
a type seems very reasonable to me, and seems to hold for all
non-floating point types. A numeric range [a..a+n]
On Tuesday 20 September 2011, 17:39:49, Ketil Malde wrote:
Chris Smith cdsm...@gmail.com writes:
It would be a shame if we lost an occasionally useful and easy to read
You forgot confusing? Expecting Enum to enumerate all inhabitants of
a type seems very reasonable to me, and seems to hold
On Tue, 2011-09-20 at 17:39 +0200, Ketil Malde wrote:
You forgot confusing?
I didn't forget it; whether it's confusing or not depends on the
perspective you're coming from. The kids in my beginning programming
class are using Enum (via the list syntactic sugar) on Float and don't
get
Daniel Fischer writes:
A numeric range [a..a+n] might be expected
to have a+n+1 elements, but that doesn't hold either for Float and
Double. I think Enum for floating point values is broken
Yes, it is. Like Eq and Ord.
.. only more so. And the brokenness has infected Rational: try
On Tue, Sep 20, 2011 at 12:47 PM, Paterson, Ross r.pater...@city.ac.uk wrote:
Daniel Fischer writes:
A numeric range [a..a+n] might be expected
to have a+n+1 elements, but that doesn't hold either for Float and
Double. I think Enum for floating point values is broken
Yes, it is. Like Eq and
On Tue, 2011-09-20 at 15:28 -0400, Casey McCann wrote:
I actually think the brokenness of Ord for floating point values is
worse in many ways, as demonstrated by the ability to insert a value
into a Data.Set.Set and have other values disappear from the set as
a result.
Definitely Ord is
On Tue, Sep 20, 2011 at 3:48 PM, Chris Smith cdsm...@gmail.com wrote:
But it would be the *wrong* thing to use as a desugaring for list range
notation. List ranges are very unlikely to be useful or even meaningful
for most such enumerations (what is [ Red, Green .. LightPurple]?); and
On Tue, Sep 20, 2011 at 1:22 PM, Jake McArthur jake.mcart...@gmail.comwrote:
On Tue, Sep 20, 2011 at 3:48 PM, Chris Smith cdsm...@gmail.com wrote:
But it would be the *wrong* thing to use as a desugaring for list range
notation. List ranges are very unlikely to be useful or even meaningful
This makes me wonder if maybe the reason this discussion is happening
at all is that we don't have a well-defined meaning for what Enum
*is*. At this point, it seems like the only answer is that it's
I agree, that's why I suggested a separate 'range' function. I think
the all values in this
On Tue, Sep 20, 2011 at 3:48 PM, Chris Smith cdsm...@gmail.com wrote:
On Tue, 2011-09-20 at 15:28 -0400, Casey McCann wrote:
I actually think the brokenness of Ord for floating point values is
worse in many ways, as demonstrated by the ability to insert a value
into a Data.Set.Set and have
On Tue, 2011-09-20 at 16:22 -0400, Jake McArthur wrote:
This makes me wonder if maybe the reason this discussion is happening
at all is that we don't have a well-defined meaning for what Enum
*is*.
Certainly, we don't have a type-independent definition for Enum. I'm
not sure whether it's
I actually think the brokenness of Ord for floating point values is
worse in many ways, as demonstrated by the ability to insert a value
into a Data.Set.Set and have other values disappear from the set as
a result. Getting an unexpected element in a list doesn't really seem
as bad as silently
complete enumeration. I'm taking it for granted that the current
behavior on Float is useful; I honestly don't see how you could argue
with that. People use it all the time; I used it just this morning. Of
course it's useful.
It was useful but not as useful as a 'range' function. I
On Tue, 2011-09-20 at 17:28 -0400, Casey McCann wrote:
Since removing the instances entirely is
probably not a popular idea, the least broken solution would be to
define NaN as equal to itself and less than everything else, thus
accepting the reality of Ord as the meaningless arbitrary total
On Wed, 2011-09-21 at 00:04 +0200, Ketil Malde wrote:
If Haskell defined list syntax in terms of something that's not called
Enum, that would be fine. Renaming is never all that big a deal. But
the list sugar is a big deal, and I don't think there's any point at all
in leaving the list
On Tue, Sep 20, 2011 at 5:56 PM, Evan Laforge qdun...@gmail.com wrote:
I actually think the brokenness of Ord for floating point values is
worse in many ways, as demonstrated by the ability to insert a value
into a Data.Set.Set and have other values disappear from the set as
a result. Getting
On Tuesday 20 September 2011, 23:56:53, Evan Laforge wrote:
I actually think the brokenness of Ord for floating point values is
worse in many ways, as demonstrated by the ability to insert a value
into a Data.Set.Set and have other values disappear from the set as
a result. Getting an
On Tue, 2011-09-20 at 16:05 -0600, Chris Smith wrote:
On Tue, 2011-09-20 at 17:28 -0400, Casey McCann wrote:
Since removing the instances entirely is
probably not a popular idea, the least broken solution would be to
define NaN as equal to itself and less than everything else, thus
On Wednesday 21 September 2011, 00:20:09, Casey McCann wrote:
This plays havoc with the search tree used internally by Set and Map,
the result being that if you have any NaN values in the data
structure, you may not be able to find other values anymore. Because
NaN values never compare equal
On Wednesday 21 September 2011, 00:38:12, Maciej Marcin Piechotka wrote:
+1 for:
class Eq a = Iq a where
(.) :: a - a - Bool
(.) :: a - a - Bool
Regards
-1 for the class name, too easy to miscount the Es.
And perhaps it would be better to add the IEEE compliant(?)
On Tue, Sep 20, 2011 at 6:58 PM, Daniel Fischer
daniel.is.fisc...@googlemail.com wrote:
On Wednesday 21 September 2011, 00:20:09, Casey McCann wrote:
Because
NaN values never compare equal to themselves, I'm not sure if it's
even possible to remove them from the structure,
filter (not .
On Tue, Sep 20, 2011 at 4:23 PM, Daniel Fischer
daniel.is.fisc...@googlemail.com wrote:
On Wednesday 21 September 2011, 00:38:12, Maciej Marcin Piechotka wrote:
+1 for:
class Eq a = Iq a where
(.) :: a - a - Bool
(.) :: a - a - Bool
Regards
-1 for the class name, too easy to
On Wednesday 21 September 2011, 01:23:48, Casey McCann wrote:
On Tue, Sep 20, 2011 at 6:58 PM, Daniel Fischer
daniel.is.fisc...@googlemail.com wrote:
On Wednesday 21 September 2011, 00:20:09, Casey McCann wrote:
Because
NaN values never compare equal to themselves, I'm not sure if it's
On Wed, 2011-09-21 at 01:23 +0200, Daniel Fischer wrote:
On Wednesday 21 September 2011, 00:38:12, Maciej Marcin Piechotka wrote:
+1 for:
class Eq a = Iq a where
(.) :: a - a - Bool
(.) :: a - a - Bool
Regards
-1 for the class name, too easy to miscount the Es.
On Tue, Sep 20, 2011 at 17:56, Evan Laforge qdun...@gmail.com wrote:
I actually think the brokenness of Ord for floating point values is
worse in many ways, as demonstrated by the ability to insert a value
into a Data.Set.Set and have other values disappear from the set as
Whoah, that's
On Tue, Sep 20, 2011 at 6:05 PM, Chris Smith cdsm...@gmail.com wrote:
There's nothing *wrong* with pragmatism, but in any case, we seem to
agree on this. As I said earlier, we ought to impose a (rather
arbitrary) total order on Float and Double, and then offer comparison
with IEEE semantics
On Tue, Sep 20, 2011 at 7:38 PM, Maciej Marcin Piechotka
uzytkown...@gmail.com wrote:
+1 for:
class Eq a = Iq a where
(.) :: a - a - Bool
(.) :: a - a - Bool
We already have this but it is hidden inside a library. It's called
PartialOrd [1] and it's on the logfloat package.
On Tue, Sep 20, 2011 at 8:20 PM, Daniel Fischer
daniel.is.fisc...@googlemail.com wrote:
Yes, where NaNs matter, you always have to check (well, unless you *know*
that your calculations don't produce any NaNs).
Btw, -0.0 can be problematic too.
How so? As far as I can tell Ord and Eq treat it
On 21/09/2011, at 2:59 AM, Chris Smith wrote:
On Mon, 2011-09-19 at 22:09 -0700, Evan Laforge wrote:
Then I tried switching to a fixed point format, and discovered my
mistake. Enum is supposed to enumerate every value between the two
points, and the result is memory exhaustion.
% ghci
On Tue, 20 Sep 2011, Alexander Solla wrote:
On Tue, Sep 20, 2011 at 1:22 PM, Jake McArthur jake.mcart...@gmail.com wrote:
On Tue, Sep 20, 2011 at 3:48 PM, Chris Smith cdsm...@gmail.com wrote:
But it would be the *wrong* thing to use as a desugaring for list range
notation.
On 21/09/2011, at 2:18 PM, Casey McCann wrote:
I still don't see why it makes sense to add separate IEEE comparisons
instead of just adding a standard partial order class, though.
In any mathematical partial order, we expect
x `le` x
to be a law. But in IEEE arithmetic, if x is a
On Wed, Sep 21, 2011 at 12:47 AM, Richard O'Keefe o...@cs.otago.ac.nz wrote:
In any mathematical partial order, we expect
x `le` x
to be a law. But in IEEE arithmetic, if x is a NaN, x `le` x is
false. I don't see how to reconcile these.
I agree that a standard partial order class
On Wednesday 21 September 2011, 04:18:38, Casey McCann wrote:
On Tue, Sep 20, 2011 at 8:20 PM, Daniel Fischer
daniel.is.fisc...@googlemail.com wrote:
Yes, where NaNs matter, you always have to check (well, unless you
*know* that your calculations don't produce any NaNs).
Btw, -0.0 can be
So I've been excising occurrences of the [n..m] syntax from my code.
The reason is that I had been using [0..5] as a shorthand for [0, 1,
2, 3, 4, 5], mostly in tests. This works for integral types and it
appears to work for floating point types.
Then I tried switching to a fixed point format,
66 matches
Mail list logo
