Phlex wrote:
This is very informative, and easier to grasp for such a newbie as me.
So the idea is to take the changing function down the chain, i knew
this couldn't be that hard !
Still this requires indeed to think different, I guess i'm up for
quite a few exercises in order to wrap my mind
i would just like to say thank you for all the extensive replies. after
fiddling with them for an afternoon i'm positive i grokked the concept.
it's just too bad the nice wrapper concept from [1] does not seem to be
directly applicable to fix in haskell, since they require untyped
Donald Bruce Stewart wrote:
P.S. Have some cute code:
Control.Monad.Fix.fix ((1:) . scanl (+) 1)
this is cute indeed! (do you keep an emergency reserve of those around
for situations like this? ;-))
ever the interested amateur, i admittedly remain stumped by fix (there's
evidence i'm
Tomasz Zielonka wrote:
On Tue, May 29, 2007 at 02:19:31PM +0200, Tomasz Zielonka wrote:
On Tue, May 29, 2007 at 12:15:23PM +0200, Vincent Kraeutler wrote:
ever the interested amateur, i admittedly remain stumped by fix (there's
evidence i'm not the only one [1])
The above
Vincent Kraeutler wrote:
Tomasz Zielonka wrote:
[snip]
anyhow. if someone has a pedestrian's guide to the fixed point
operator lying around, a link would be much appreciated.
i see that dons has very recently provided an answer for this on reddit:
http://programming.reddit.com/info
as was pointed out on the programming reddit [1], crawling of the
haskell wiki is forbidden, since http://www.haskell.org/robots.txt contains
User-agent: *
Disallow: /haskellwiki/
and indeed, a google search gives the old wiki
http://www.google.ch/search?q=haskell+wiki
i.e.
Andrew Coppin wrote:
[snip]
Fact #1: I don't *know* of any other numerical integration algorithm.
(I've heard of RK4, but it's too complicated for me to understand.)
higher-order runge-kutta algorithms typically have high integration
accuracy, but may require multiple energy/force evaluations
Kurt Hutchinson wrote:
On 4/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
To get the indices, use the Schwartzian transform:
sortWith :: (Ord b) = (a - b) - [a] - [a]
sortWith f = mergeRuns . runs
where
runs = map (:[])
mergeRuns [] = []
mergeRuns [xs] = xs
Henning Thielemann wrote:
On Fri, 23 Mar 2007, Neil Mitchell wrote:
my_sqrt t = last (take 20 (iterate (\n - n/2 + t/(2 * n)) t))
http://darcs.haskell.org/htam/src/Numerics/ZeroFinder/Newton.hs
with
inverse t (\x-(x^2,2*x)) t
I don't know how to add it into the one
Matthew Brecknell wrote:
Ivan Miljenovic:
As such, I'd like to know if there's any way of storing a an n-by-n
matrix such that the algorithm/function to get either the rows or the
columns is less than O(n^2) like transposition is. I did try using an
Array, but my (admittedly hurried and
Claus Reinke wrote:
When you tried using Arrays, I presume you used an array indexed by a
pair (i,j), and just reversed the order of the index pair to switch from
row-wise to column-wise access? It's hard to see how that would slow you
down. Perhaps the slowdown was caused by excessive array
11 matches
Mail list logo
