POV-Ray : Newsgroups : povray.off-topic : Haskell raving : Re: Haskell raving Server Time
11 Oct 2024 07:14:39 EDT (-0400)
  Re: Haskell raving  
From: Tim Attwood
Date: 30 Oct 2007 19:09:10
Message: <4727c7a6$1@news.povray.org>
> His message seems fairly complex. Maybe it's incorrect?

It's simpler to ignore rants, but not always the correct solution.

Computers were created to automate complex and repetitive
tasks.  Therefore it follows that the more complex and
repetitive a task is to accomplish the more suitable it is to
being implemented on a computer.

In everyday life we typically reduce a task into smaller steps.

So if Darren is walking to China to deliver a letter, he'll
put one foot in front of the other, camp in various parks,
eat at countless burger stands, and probably buy
several pairs of shoes on the way. He would do all the work.

He might reduce the problem, and replace walking on
foot with driving his car, this shortens the time and means
less stops. He now lets the car do most of the work.

He might then replace the long drive with an airplane flight,
again, less time. Now the airlines do most of the work.

He might mail a letter instead. Now the postal service
uses some delivery trucks and a plane to deliver the letter,
they do most of the work.

He might use E-mail instead. Now the work is done by
computers and a few technicians.

Now let's say that Darren's friend in China is a really
attractive woman... a peviously unstated factor in his
deciding to take a trip to China. Now it can be seen
the best solution is not always the simple one, if you
allow for outside factors.

In terms of programming, an outside factor might be things
like available memory, disk space, or computation speed.
When memory comes into play you might need destructive
updates to arrays, etc.  The simplest solution isn't always
the best.

For example...
fac n = product [1..n]

This is simple code, but not always the quickest...

Here's a memoized version, it uses more memory
in order to gain speed...
fac :: Integer -> Integer
fac n = facList!!(fromInteger n)

facList = [fac' m | m <- [0..]]

fac' n | n == 0    = 1
       | otherwise = n * fac (n-1)

You can check the performance by mapping
a factorial over a list and taking the sum.  On
my machine the first one takes about 104 sec
to factorial numbers in a list [1..4000], the second
one does that in about 0.5 sec. Essentially the first
runs in O(n^2) time, and the second in O(n), but
has higher memory usage, it's a trade-off based on
outside factors, which one to use in which situation.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.