Remove Enum from Float and Double
There have been several discussions over the years regarding Enum instances for Float and Double. The conclusion each time appears to have been that there are no instances which are both sane and practical. I would like to propose that these instances be removed from Haskell 2014. This may be covered by the various alternative prelude and number class proposals, but they are much more ambitious and less likely to make it into the standard in the short term. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Remove Enum from Float and Double
Hi Harry, On Tue, Jun 11, 2013 at 3:51 AM, harry volderm...@hotmail.com wrote: There have been several discussions over the years regarding Enum instances for Float and Double. The conclusion each time appears to have been that there are no instances which are both sane and practical. Do you have a link to some of those discussions? I have a vague memory of them but can no longer remember the specifics. I would like to propose that these instances be removed from Haskell 2014. This may be covered by the various alternative prelude and number class proposals, but they are much more ambitious and less likely to make it into the standard in the short term. I don't see much gain. It will break previously working code and the workaround to the breakage will likely be manually reimplementing enumFromTo in each instance. Cheers, Johan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Remove Enum from Float and Double
I don't see much gain. It will break previously working code and the workaround to the breakage will likely be manually reimplementing enumFromTo in each instance. As an aside, many years ago I did exactly that after being bit by Enum infelicities, and while you could say it's a reimplementation, in my opinion it's a better implementation: -- | Enumerate an inclusive range. Uses multiplication instead of successive -- addition to avoid loss of precision. -- -- Also it doesn't require an Enum instance. range :: (Num a, Ord a) = a - a - a - [a] range start end step = go 0 where go i | step = 0 val end = [] | step 0 val end = [] | otherwise = val : go (i+1) where val = start + (i*step) -- | Enumerate a half-open range. range' :: (Num a, Ord a) = a - a - a - [a] range' start end step = go 0 where go i | step = 0 val = end = [] | step 0 val = end = [] | otherwise = val : go (i+1) where val = start + (i*step) -- | Infinite range. range_ :: (Num a) = a - a - [a] range_ start step = go 0 where go i = start + (i*step) : go (i+1) ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Remove Enum from Float and Double
Johan Tibell johan.tibell@... writes: I don't see much gain. It will break previously working code and the workaround to the breakage will likely be manually reimplementing enumFromTo in each instance. I forgot the main point of my post :-) The primary motivation for removing these instances is that they cause endless confusion for beginners, e.g. http://stackoverflow.com/questions/13203471/the-math-behind-1-0999-in-haskell, http://stackoverflow.com/questions/9810002/floating-point-list-generator, http://stackoverflow.com/questions/7290438/haskell-ranges-and-floats, http://stackoverflow.com/questions/10328435/how-to-solve-floating-point-number-getting-wrong-in-list-haskell, and many more. On the other hand, how much working code is there correctly using there instances? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Remove Enum from Float and Double
More to supply evidence in answer to your question than to present a point of view, the following is an example of code I wrote fairly recently: phi :: Double - Double - Complex Double phi x y = sum [ exp((-pi * (x + n)^2) :+ (2 * pi * n * y)) | n - [-100..100] ] I wouldn't claim for a second that this is good style, but the point is that I don't actually care in this instance whether I gain or lose one or two terms in the sum (they're all vanishingly small by that point) so I think this is in some sense legitimate. I could of course take n as an integer, but in this rather cheap-and-dirty program I made a conscious trade-off in favour of readability and against lots of fromIntegral's. I don't have strong views either way as to whether the language should coerce me into being a better person in this sense, but my point is just that this proposal would break not-unreasonable code -- how much depending on how many people ever use Haskell for numerical work. Freddie On 11 June 2013 19:18, harry volderm...@hotmail.com wrote: Johan Tibell johan.tibell@... writes: I don't see much gain. It will break previously working code and the workaround to the breakage will likely be manually reimplementing enumFromTo in each instance. I forgot the main point of my post :-) The primary motivation for removing these instances is that they cause endless confusion for beginners, e.g. http://stackoverflow.com/questions/13203471/the-math-behind-1-0999-in-haskell , http://stackoverflow.com/questions/9810002/floating-point-list-generator, http://stackoverflow.com/questions/7290438/haskell-ranges-and-floats, http://stackoverflow.com/questions/10328435/how-to-solve-floating-point-number-getting-wrong-in-list-haskell , and many more. On the other hand, how much working code is there correctly using there instances? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Remove Enum from Float and Double
If we truly believe that the instance is dangerous for users (and not merely for people who don't understand floating point arithmetic on computers), then we should add a deprecation pragma to the instance and discourage its use. But what would the deprecation message encourage instead, for users to write an explicit loop that tests against some lower/upper bound? It would have the same problem as enumFromTo. I think the issue here is really that floating point math on computers is hard to think about. On Tue, Jun 11, 2013 at 11:18 AM, harry volderm...@hotmail.com wrote: Johan Tibell johan.tibell@... writes: I don't see much gain. It will break previously working code and the workaround to the breakage will likely be manually reimplementing enumFromTo in each instance. I forgot the main point of my post :-) The primary motivation for removing these instances is that they cause endless confusion for beginners, e.g. http://stackoverflow.com/questions/13203471/the-math-behind-1-0999-in-haskell , http://stackoverflow.com/questions/9810002/floating-point-list-generator, http://stackoverflow.com/questions/7290438/haskell-ranges-and-floats, http://stackoverflow.com/questions/10328435/how-to-solve-floating-point-number-getting-wrong-in-list-haskell , and many more. On the other hand, how much working code is there correctly using there instances? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Remove Enum from Float and Double
On Tue, Jun 11, 2013 at 2:18 PM, Johan Tibell johan.tib...@gmail.com wrote: If we truly believe that the instance is dangerous for users (and not merely for people who don't understand floating point arithmetic on computers), then we should add a deprecation pragma to the instance and discourage its use. But what would the deprecation message encourage instead, for users to write an explicit loop that tests against some lower/upper bound? It would have the same problem as enumFromTo. If the problem is increasing inaccuracy, then it likely wouldn't. E.g.: last [0, 0.1 .. 20] 20.195 last (range 0 20 0.1) 20.0 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Remove Enum from Float and Double
Hi, The primary motivation for removing these instances is that they cause endless confusion for beginners [...] Not sure what that means for this discussion, but enumFromTo is already confusing without considering floating point numbers: Prelude [fromInteger 1, fromInteger 3 .. fromInteger 4] :: [Rational] [1 % 1,3 % 1,5 % 1] Prelude map fromInteger [1, 3 .. 4] :: [Rational] [1 % 1,3 % 1] In general, I would be against removing features just because they are confusing for beginners. I don't think that's a good design principle for a language that is primarily targeted at professional programmers and computer scientists. Tillmann ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Remove Enum from Float and Double
Does such thing as a deprecation pragma for an instance exist? What triggers it? Roman * Johan Tibell johan.tib...@gmail.com [2013-06-11 14:18:41-0700] If we truly believe that the instance is dangerous for users (and not merely for people who don't understand floating point arithmetic on computers), then we should add a deprecation pragma to the instance and discourage its use. But what would the deprecation message encourage instead, for users to write an explicit loop that tests against some lower/upper bound? It would have the same problem as enumFromTo. I think the issue here is really that floating point math on computers is hard to think about. On Tue, Jun 11, 2013 at 11:18 AM, harry volderm...@hotmail.com wrote: Johan Tibell johan.tibell@... writes: I don't see much gain. It will break previously working code and the workaround to the breakage will likely be manually reimplementing enumFromTo in each instance. I forgot the main point of my post :-) The primary motivation for removing these instances is that they cause endless confusion for beginners, e.g. http://stackoverflow.com/questions/13203471/the-math-behind-1-0999-in-haskell , http://stackoverflow.com/questions/9810002/floating-point-list-generator, http://stackoverflow.com/questions/7290438/haskell-ranges-and-floats, http://stackoverflow.com/questions/10328435/how-to-solve-floating-point-number-getting-wrong-in-list-haskell , and many more. On the other hand, how much working code is there correctly using there instances? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Remove Enum from Float and Double
On Tue, Jun 11, 2013 at 3:00 PM, Roman Cheplyaka r...@ro-che.info wrote: Does such thing as a deprecation pragma for an instance exist? What triggers it? I don't know. We'll need one if we're going to deprecating core instances. Just deleting them is not an option (as it gives users with large code bases no time to migrate). ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Remove Enum from Float and Double
* Johan Tibell johan.tib...@gmail.com [2013-06-11 15:03:10-0700] On Tue, Jun 11, 2013 at 3:00 PM, Roman Cheplyaka r...@ro-che.info wrote: Does such thing as a deprecation pragma for an instance exist? What triggers it? I don't know. We'll need one if we're going to deprecating core instances. Just deleting them is not an option (as it gives users with large code bases no time to migrate). On a second thought, it does seem feasible. The warning would be triggered at the point where the (implicit) class dictionary is used to invoke a polymorphic function. This, however, requires input from the type checker. All previous deprecations have been only name-based, IINM. Roman ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
