Al Falloon wrote:
>
> SevenThunders wrote:
>> Well it certainly requires some thought here. As I see it, I now have
>> two
>> reasonable choices. Either I pull all my matrix operations back inside
>> the
>> IO monad and avoid the matrix action as a matrix variable paradigm (due
>> to
>> the
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 contrar
Ronald Guida wrote:
>
>
>
>
> I could translate your example to the following:
>
>> let S = A += B in
>> do
>> s <- S
>> (r,c) <- size (return s)
>> k <- matindex (return s)
>
> This should only perform action S one time.
>
That's a good point actually. If I am caref
apfelmus wrote:
>
> SevenThunders wrote:
>> 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
>>> matrix
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 c
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. A
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
> 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 the wrong monad
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 a
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
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 :: Mat
I have a matrix library written in C and interfaced into Haskell with a lot
of additional Haskell
support. The C library of course has a lot of side effects and actually
ties into the BLAS libraries, thus at the present time, most of the
interesting calls are done in the IO monad. I have no inte
12 matches
Mail list logo
