[Haskell-cafe] Set of reals...?

[Stijn De Saeger]

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> 

????????

in your reply you wrote :
> 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>
>