Stijn De Saeger stijndesaeger at gmail.com
Wed Oct 27 06:37:46 EDT 2004

```hello

Thanks for the explanation, at first it seemed like enumFromThenTo
would indeed give me the functionality I am looking for. But then all
of GHCi started acting weird while playing around... this is a
copy-paste transcript from the terminal.

*S3> 0.5 `elem` [0.0,0.1..1.0]
True
*S3> 0.8 `elem` [0.6,0.7..1.0]
False
*S3> 0.8 `elem` [0.6,0.7..1.0]
False
*S3> [0.6,0.7..0.9]
[0.6,0.7,0.7999999999999999,0.8999999999999999]
*S3>

????????

> However, you can't specify infinitesimally small steps, nor increment
> according to the resolution of the floating point type (at least, not
> using the enumeration syntax; you *could* do it manually using integer
> enumerations and encodeFloat, but that wouldn't be particularly
> practical).

Is this what you were referring to? i wouldn't say 0.1 is an
infinitesimal small step.
why would the floating point step size work the first time but not the
second? confusing...

thanks for the help though, much appreciated.
stijn.

On Wed, 27 Oct 2004 10:31:28 +0100, Glynn Clements
<glynn at gclements.plus.com> wrote:
>
> Stijn De Saeger wrote:
>
> > I'm new to this list, as well as to haskell, so this question probably
> > has "newbie" written all over it.
> > I'm thinking of a way to represent a set of reals, say the reals
> > between 0.0 and 1.0.  Right now I am just using a pair of Float to
> > represent the lower and upper bounds of the set, but i have this dark
> > throbbing feeling that there should be a more haskellish way to do
> > this, using laziness.
> > List comprehensions are out it seems, because they increment with
> > integer steps... (obviously). In other words,  0.5 `inSet` (Set
> > [0.0..1.0])   returns False.
>
> That form ([0.0..1.0]) is syntactic sugar for enumFromTo. There's also
> enumFromThenTo, for which you can use the syntax:
>
>         [0.0,0.1..1.0]
>
> However, you can't specify infinitesimally small steps, nor increment
> according to the resolution of the floating point type (at least, not
> using the enumeration syntax; you *could* do it manually using integer
> enumerations and encodeFloat, but that wouldn't be particularly
> practical).
>
> The only practical way to deal with large sets of reals is to use your
> own representation and write your own operators on it (or hope that
> someone else has written such a library). Generating massive lists (or
> other structures) then testing for membership won't result in the
> lists being optimised away.
>
> --
> Glynn Clements <glynn at gclements.plus.com>
>
```