I'm stymied trying to figure out why the program below blows up with
<<>> when I use "f 0" for building the array, but if I substitute
g or h in place of f, they work fine. Is this a bug or am I overlooking
something? I am using GHC 7.4.2.
Thanks,
Alex
P.S. Forgive the seemingly pointless progra
On 12 November 2012 04:50, Alex Stangl wrote:
> I'm stymied trying to figure out why the program below blows up with
> <<>> when I use "f 0"
If you replace the a!0 in f by its value 0, f is equivalent to:
f k = if k > 0
then f 0
else 0 : f 1
D
On Mon, Nov 12, 2012 at 08:36:49AM +0100, Bas van Dijk wrote:
> On 12 November 2012 04:50, Alex Stangl wrote:
> > I'm stymied trying to figure out why the program below blows up with
> > <<>> when I use "f 0"
> If you replace the a!0 in f by its value 0, f is equivalent to:
>
> f k =
On Montag, 12. November 2012, 08:36:49, Bas van Dijk wrote:
> On 12 November 2012 04:50, Alex Stangl wrote:
> > I'm stymied trying to figure out why the program below blows up with
> > <<>> when I use "f 0"
>
> If you replace the a!0 in f by its value 0, f is equivalent to:
>
> f k =
On 12 November 2012 14:52, Daniel Fischer
wrote:
> I see no loop in that, and ghci doesn't either:
Oops you're right of course.
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Mon, Nov 12, 2012 at 02:52:28PM +0100, Daniel Fischer wrote:
> The problem, Alex, is that
>
> f k = if k > 0
> then f (a!0)
> else 0 : f 1
>
> is strict, it needs to know the value of (a!0) to decide which branch to
> take.
> But the construction of the array a needs to know
Alex Stangl posed a problem of trying to efficiently memoize a
function without causing divergence:
> solve = let a :: Array Int Int
> a = listArray (0, 3) (0 : f 0)
> f k = if k > 0
> then f (a!0)
> else 0 : f 1
> in (interca
On Tue, Nov 13, 2012 at 08:06:59AM -, o...@okmij.org wrote:
> Alex Stangl posed a problem of trying to efficiently memoize a
> function without causing divergence:
> ...
> But the problem can be fixed: after all, f k is a list of integers. A
> list is an indexable collection. Let us introduce t
Alex Stangl wrote:
> To make this concrete, here is the real solve function, which computes
> a border array (Knuth-Morris-Pratt failure function) for a specified
> string, before the broken memoization modification is made:
> solve :: String -> String
> solve w = let h = length w - 1
>
On Wed, Nov 14, 2012 at 07:39:33AM -, o...@okmij.org wrote:
> dimensional memo table. Luckily, our case is much less general. We do
> have a very nice dynamic programming problem. The key is the
> observation
> k' : solveR (i+1) k'
> After a new element, k', is produced, it is used as an
10 matches
Mail list logo