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
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