This is a classic greedy algorithm, much like the text-wrapping
problem.
My main suggestion would be that you're not making use of some standard
list functions that would simplify things. For example, your
runningSum is just scanl1 (+) . Similarly, splitAll should use
unfoldr. Another thing is
On 2004.04.22 15:02, I wrote:
splitAll :: (Real a) = a - [a] - [[a]]
splitAll = unfoldr . split
where split _ [] = Nothing
split n xs = let (ys,zs) = break (( n) . snd)
(zip xs (scanl1 (+) xs))
On 2004.01.21 15:03, Iavor S. Diatchki wrote:
hi,
not that it matters, but i think commonly when specifications say
that something is undefined, that means that the behaviour can be whatever,
i.e. the implementors can do what they like. this is not to be confused
with the entity undefined
On 2004.01.21 15:03, Iavor S. Diatchki wrote:
hi,
not that it matters, but i think commonly when specifications say
that something is undefined, that means that the behaviour can be whatever,
i.e. the implementors can do what they like. this is not to be confused
with the entity undefined
Phil Wadler writes:
| I'm with Jon Fairbairn on this. Negative arguments are an error
| because the domain of take and drop is the naturals. The problem
| is that we use Int to represent naturals. -- P
|
| For the people that share this sentiment, can you please
| explain why ints that are
Chris Okasaki writes:
| But if the type *says* Int, then it should have reasonable behavior
| for ints. I look at the negative case as being equivalent to
| standard mathematical treatment of ranges such as i..j, where the
| range is considered to be empty if j i. Allowing take/drop to
|
S.D.Mechveliani [EMAIL PROTECTED] writes
| Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] writes
| partition _ [] = ([], [])
| partition p (x:xs) = if p x then (x:ys, zs) else (ys, x:zs)
| where (ys, zs) = partition p xs
|
| runs your example in constant space.
|
|
| Probably,
Folks,
I claimed that these are different functions:
partition1 p xs = (filter p xs, filter (not . p) xs)
partition2 p = foldr (\x (ys, zs) - if p x then (x:ys,zs) else (ys,x:zs))
([],[])
I was correct, but not for the reason I thought. Nota bene:
partition1 p
Olivier LeFevre wrote,
| "R.S. Nikhil" [EMAIL PROTECTED] wrote,
|
| Sisal researchers [...] deliberatly chose to avoid higher-order functions,
| polymorphism, laziness, etc.
|
| In a first release, yes, but I believe higher-order functions were included in
| Sisal 2.0, which was almost
Frank Christoph wrote,
| Ah, right. Someone mentioned just recently (I forget who---sorry) that
| nothing in the Report forces a Haskell implementation to use call-by-need. I
| guess this is a manifestation of the change of direction, from laziness to
| non-strictness...?
My point was meant to
Tommy Thorn writes
| Jens' question gave my a perfect opportunity to open my a pet peeve of
| mine: the ditatorship of `Main'.
|
| In Haskell, the `main' function must reside in the `Main' module.
| Add to this that the `Main' module must reside in a `Main' file and
| you have an unfortunate
| I think using monads, and specially a powerful one like IO, everywhere is
| a mistake. I can't see the need for most uses of random numbers.
|
| -- Lennart
Besides that, isn't the name "randomIO" a bit unfortunate? It sounds
like it contrasts with "sequentialIO".
--Joe
Joseph H.
It looks like a mistake to me, too.
--Joe
| The definition of Maybe (at least in the Hugs prelude) is:
|
| data Maybe a = Just a | Nothing
|deriving (Eq, Ord, Read, Show)
|
| The (to me) unfortunate consequence of this is that "Nothing" is the upper
| bound of the type (as
I think Fergus's efficiency argument may be a red herring.
Here is an excerpt from a compiler I wrote recently:
data JvlArgs = JvlArgs {optNoLink :: Bool,
optVerbose :: Bool,
jvlClassNames :: [String]}
deriving Show
Fergus,
Quite right. I used "error" because I was lazy.
In fact, the lazy evaluation of the arguments is also a red herring,
because the compiler is in fact strict in argv. (How else does it
know what to compile?) All the flag arguments must be scanned
in order to retrieve "jvlClassNames
Paul writes
| It has occurred to me that unlifted tuples achieved via a special
| "newtype" decl are not the same as those achieved with strictness
| annotations. This is because with "newtype" it seems that people want
| a situation where (_|_,_|_) = _|_. But with strictness annotations on
|
Just a small addendum to Mark's response to Warren:
Overloading (even just polymorphism, as Mark says) does compromise
equational reasoning, in much the same way that lexical scoping does.
That is x = y |- f x = f y , provided it's the same x and the same y.
Cheers,
--Joe
Simon writes
| I have never, never been tripped up by the liftedness of tuples, but the
| argument that ``we are prepared to pay for laziness so why not this too''
| has a certain masochistic charm. I'll try the effect on performance of
| making all tuple-matching lazy in the nofib suite.
Good
Paul writes:
| Like Ian, I would like to suggest that we lift functions in Haskell.
| Originally there was a good reason not to: there was no need (and
| indeed no way) to distinguish _|_ from \x-_|_. But now there are
| some compelling reasons to make the distinction:
I would say that there
I wrote:
|Thus, it would indeed be reasonable for the type of seq to determine
|that f x `seq` y is all right, whereas f `seq` y is not permissible.
|Similarly, I think it would be consistent to have unlifted products,
|but not give them data instances, so that (x,y) `seq` z is not allowed,
Nikhil says,
| Thomas Johnsson says:
|
| If I recall correctly, the := to be used in array comprehensions was a
| consession to the FORTRAN/Id/Sisal community, so that array comprehensions
| would look more like they were used to.
|
| Both Arvind and I think this is notation is
John Launchbury says,
| Here are three comments directed particularly at Haskell 1.3 people, but
| obviously open to general feedback.
|
| 1. We should get rid of Assoc.
|
| When explaining my programs to other people I find this is a point of
| confusion. Imagine exaplaining array construction,
Phil Writes:
|However, for the extended type system that allows polymorphism in
|recursion, this is no longer the case -- my thanks to Lennart
|Augustsson for pointing this out. The counter-example (similar
|to one of Mark's) is:
|
|g :: a - Bool
|g x = g [x]
|
|This function
| From: [EMAIL PROTECTED]
|
| I'm puzzled by a detail in the Report, which seems to contradict itself.
|
| On page 13 it says:
|
| The special form -e denotes prefix negation, [...] and is simply
| syntax for negate (e), where negate is as defined in the standard
|
John Peterson
Lennart Augustsson
Joe Fasel
| This whole issue regarding redefinition of + and - is getting confused
| unnecessarily. Both of these are in PreludeCore and cannot be renamed
| or hidden. Because of this their fixities cannot be changed. It is
| possible to locally
e the feature of n+k-patterns to simulate
| n*k+k' patterns? [I am talking about weird user-defined
| instances of Num.]
quite possibly.
| Stefan Kahrs
--Joe Fasel
|Another question along the same lines: What if (+) has been rebound?
|Are n+k patterns still allowed?
|
|-- Lennart
The answer should be that n+k patterns are still allowed, but (+), (-),
and (=) from PreludeCore are used in the translation.
--Joe
27 matches
Mail list logo
