Paul Johnson-2 wrote:
SevenThunders wrote:
Unfortunately if I wrap my matrix references in the IO monad, then at
best
computations like
S = A + B are themselves IO computations and thus whenever they are
'invoked' the computation ends up getting performed repeatedly contrary
to
my
Dominic Steinitz wrote:
If you arrange the types to try to do all the operations inside the IO
monad you can't chain together more than 1 binary operation. eg.
do
S - A + B
Z - Q * S
vs
do
S - Q * (A + B)
Are there any suggestions for this dilemma? Am I using
SevenThunders wrote:
OK so check out what really happens with liftM2. Suppose I have an IO
containing an involved matrix computation called s. For simplicity
we might
assume that
s :: IO (Int)
and the Int is an index into an array containing a bunch of matrices in C
land. Assume
SevenThunders wrote:
Unfortunately if I wrap my matrix references in the IO monad, then at best
computations like
S = A + B are themselves IO computations and thus whenever they are
'invoked' the computation ends up getting performed repeatedly contrary to
my intentions.
This sounds like a
As long as the FFI calls don't make destructive updates to existing
matrices, you can do what you want.
For example, assuming you have:
-- adds the second matrix to the first overwrites the first
matrixAddIO :: MatrixIO - MatrixIO - IO ()
-- creates a new copy of a matrix
matrixCopyIO ::
Ryan Ingram wrote:
As long as the FFI calls don't make destructive updates to existing
matrices, you can do what you want.
For example, assuming you have:
-- adds the second matrix to the first overwrites the first
matrixAddIO :: MatrixIO - MatrixIO - IO ()
-- creates a new copy
SevenThunders wrote:
I have a matrix library written in C and interfaced into Haskell
with a lot of additional Haskell support.
[snip]
Unfortunately if I wrap my matrix references in the IO monad, then
at best computations like S = A + B are themselves IO computations
and thus whenever they