ScrollingText

takes about 15 seconds to execute

> isPrime <- function(x)
+ {
+ y = sqrt(x)
+ for(i in 2:y)
+ {
+ if(x%%i==0) return(F)
+ }
+ return(T)
+ }
> for(i in 1:y){if(600851475143%%i==0 && isPrime(i)) {x<-c(x, i); print(i)}; if(i%%1000000==0) print(“…”)}
[1] 71
[1] 839
[1] 1471
[1] 6857
[1] “…”
[1] “…”
[1] “…”
[1] “…”
[1] “…”

19 Oct 2008 map costa del veneto venetian riviera hotel coast venice and book hotels rooms B&Bs Compare prices and book an hotel online. Even though there are no certain facts it is estimated that the Maldives have been populated by 1500 BC the explorers from USA and Sri Lanka may had come to the archipelago. Monaco hotels & Monte Carlo hotel accommodation. Book online for special offers & great discounts on hotels.

Same problem solved in C#.

https://sites.google.com/site/eulerproblemsincsharp/home/problem-3

Before i start to rant on small style issues I must say that I like your choice of languages and i think solving project Euler problems (and especially with Haskell) is a great way to grow as a programmer.

Also note that my comments are not about your choice of algorithms or general approach to the problem, this is probably a more interesting area of improvement but my feedback focus only on the code itself.

  if top_number % divisor == 0:
    return True
  else:
    return False

this is written much better as:

  return top_number % divisor == 0

and that goes for Haskell as well:

  zero_mod divisor = 600851475143 `mod` divisor == 0

Does the expression round . fromIntegral in your factor-function in Haskell do anything? To my knowledge it can just be deleted.

  new_top = top_number `div` count

What you did right with that line however was that you used functional
composition (.) to construct a pipe-line of functions. It is
considered good practise in the Haskell community since it makes
refactoring easier. You should use that technique in your function main
as well. so instead of:

  putStrLn $ show $ snd $  maximum ( zip y x)

write:

  putStrLn . show . snd . maximum $ zip y x

This could be considered a matter of taste if it was done consistently,
it's the inconsistency that causes the code-smell (and that goes for
the whitespace inconsistency as well, notice the extra space before
maximum and the space before zip in your version).

Don't have commented out code within your code. It's fine for
experimentation, but before posting (or commiting to your VCS) either
uncomment it or delete it. When it comes to top-level types in Haskell
i suggest that you keep them, i find that the code becomes easier to
reason about if the right functions and values have their types in the
code (tip: if you want help finding the right type you can use the :t command in ghci).

  if divided == 1:
    return True
  else:
    ...

This could be rewritten to:

  if divided == 1:
    return True
  ...

This reduces nesting and makes the code easier to read.

I'm not to fond of your sqrt_divided in any of the languages. It's only used once and the expression you assign to it expresses its meaning better than the name, you should remove this variable and use its expression directly in Python and Perl. In Haskell it's a similar story but your expression is much larger because of the type conversion, i would suggest writing a version of sqrt that works with integers instead and removing the sqrt_divided symbol there as well.

Here is a quick and dirty attempt to clean up your prime function from the Haskell code:

divides x y = y `mod` x == 0
iSqrt = round . sqrt . fromIntegral
 
prime :: Integer -> Integer -> Bool
prime _ 1 = True
prime divisor divided
    | divisor >= iSqrt divided = True
    | divisor `divides` divided = False
    | otherwise = prime (divisor + 2) divided

You don't need a do in your main when you are really only performing a single IO action, i would rewrite that to use a where block which is the style you have used in other places. (Note that print = putStrLn . show)

main :: IO ()
main = print . snd . maximum $ zip y x
    where
      x = factors 3 600851475143
      y = map is_prime x

It became a fairly large comment, I hope you find it at least somewhat constructive and best of luck with the next Euler problem.

1. You can use a list comprehension without otherwise restructuring your program, this is the "pythonic" way to do it:

first_list  = divisor for divisor in range(...) if not zero_mod(divisor)
second_list = [divisor for divisor in first_list if is_prime(divisor)]

second_list = [divisor for divisor in range(...) if not top_number % divisor and is_prime(divisor)]

2. Your algorithm is not correct. What is the largest prime factors of 14? 15?

3. Your algorithm is not efficient. You're dividing by numbers that can't possibly yield any number's largest prime factor.

There are some other small things but those are the main points.

You should clean up the code before posting, for starters the zero_mod functions in both Haskell and Python are quite smelly.

you really want comments? provide timings for your scripts to show which language is faster... (plus it'd just be interesting)

.. the first of many of the Project Euler problems that suck purely because you have to generate prime numbers. It's not an interesting problem to solve (imho) and there are so many problems that rely on it.

For this problem I wrote my own. For every prime-related problem afterward, I just reused one that I found on the web that's really fast.