Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#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: Changed 6 years ago by claus

The x<200 is a *filter*, not a limit. Perhaps you mean

Prelude> [x|x<-[1..200],x`mod`6==1,x`mod`6==5]
[]

Otherwise, GHC will happily try and dismiss all those numbers in [200..], which will keep it busy for a while!-)

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

Note: See TracTickets for help on using tickets.