#3053 closed bug (invalid)
Modular arithmetic bug?
Reported by: | vlaad | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GHCi | Version: | 6.10.1 |
Keywords: | Cc: | ||
Operating System: | Windows | Architecture: | x86 |
Type of failure: | Test Case: | ||
Blocked By: | Blocking: | ||
Related Tickets: | Differential Revisions: |
Description
GHC dies here (please note the x < 200 limit):
take 15 [x | x <- [1..], x < 200, x mod 6 == 1, x mod 6 == 5]
And here (nothing with infix notation):
take 15 [x | x <- [1..], x < 200, mod x 6 == 1, mod x 6 == 5]
But *not* here:
take 15 [x | x <- [1..], mod x 6 == 1, x < 200, x > 100]
Change History (9)
comment:1 follow-up: ↓ 4 Changed 6 years ago by claus
comment:2 Changed 6 years ago by vlaad
- Component changed from Compiler to GHCi
comment:3 Changed 6 years ago by augustss
- Resolution set to invalid
- Status changed from new to closed
comment:4 in reply to: ↑ 1 Changed 6 years ago by vlaad
- Resolution invalid deleted
- Status changed from closed to reopened
Otherwise, GHC will happily try and dismiss all those numbers in [200..], which will keep it busy for a while!-)
Why then we forget about infinite series support, if we have to wait the GHCi to approach the infinity?
Here is another one NOT WORKING:
take 2 [x | x <- [1,2..], x < 195, x > 188, mod x 6 == 2]
Please don't tell me that GHCi will enumerate from 1 to infinity, what about this WORKING example:
take 2 [x | x <- [255255..], mod x 15 == 2]
comment:5 Changed 6 years ago by augustss
- Resolution set to invalid
- Status changed from reopened to closed
Both ghc and ghci are working exactly as they should.
If you say
[ x | x <- [1..], x < 10]
then it will let x go through all the numbers from 1 and up, and only keep those that are < 10. The compiler "does not know" that the seqeunce is monotonically increasing, so it has to loop after delivering 9, because it "thinks" that somewhere in the infinite list (beyond 9) there could again be a number < 10.
This is not a bug.
(And indeed, for some non-standard kind of numbers it could very well be that enumFrom would deliver some smaller numbers later.)
comment:6 follow-up: ↓ 7 Changed 6 years ago by vlaad
Well, if this is *not* a bug, then please explain how in your first response we are getting an empty list? (or better, stop thinking, and pass it to the guys, please).
("Perhaps you mean [x|x<-[1..200],xmod6==1,xmod6==5]")
Prelude> [x|x<-[1..20],x`mod`6==5] [5,11,17] Prelude> [x|x<-[1..20],x`mod`6==1] [1,7,13,19] Prelude> [x|x<-[1..20],x`mod`6==1,x`mod`6==5] []
comment:7 in reply to: ↑ 6 ; follow-up: ↓ 8 Changed 6 years ago by vlaad
I'm sorry. Wrong example. This is stupid.
comment:8 in reply to: ↑ 7 Changed 6 years ago by vlaad
However, I'm totally dicouraged in using GHC, thanks to the fact that it is the only Haskell compiler around, and thanks to your fanatic dedication to it's advocacy (I've just happily uninstalled it).
comment:9 Changed 6 years ago by augustss
Why are you discouraged by ghc? What you reported is not a bug and all Haskell implementations will give you the same answer.
To put it another way, of you have a list comprehension [ e | x <- gen, ... ] and you look at the resulting list then the result list will only ever end when the generator (gen) gets to the end of its list. This is according to the definition of Haskell and has nothing to do with ghc.
If you want a language where list comprehensions behave in some other way, then you'll have to look elsewhere.
The x<200 is a *filter*, not a limit. Perhaps you mean
Otherwise, GHC will happily try and dismiss all those numbers in [200..], which will keep it busy for a while!-)