> Cagdas Ozgenc <[EMAIL PROTECTED]> wrote:
>
> > Greetings,
>
> > Is identity function the only meaningful function one can write
> > without constraining the type variable using a typeclass? If not,
> > could you please give a counter-example?
>
> Certainly you can write lots of ``meaningful f
> > Greetings,
> >
> > 1) How does one model "out of memory" condition in Haskell, perhaps
using a Maybe type?
>
> Unfortuntely not since it would not be referentially transparent. It's
> part of a more general issue of exceptions in pure code.
>
> You can't have
>
> calculateSomething :: X -> May
> I did not mean to include functions that take type constructors as
> parameters (so lists are out of my discussion scope). I am only considering
> functions that uses type variables that are not restricted by typeclasses.
There is const:
const :: a -> b -> a
const x _ = x
And of course
> Does this make the use of Monads doubtful? I mean it doesn't seem easy to
> have a completely pure language, and the time one starts introducing few
> impurities one also starts thinking why not include many others?
I suggest that you read this paper:
A semantics for imprecise exceptions, Pe
> > I did not mean to include functions that take type constructors as
> > parameters (so lists are out of my discussion scope). I am only
considering
> > functions that uses type variables that are not restricted by
typeclasses.
>
> There is const:
>
>const :: a -> b -> a
>const x _ =
Cagdas Ozgenc quotes himself (and somebody else):
>>>Is identity function the only meaningful function one can write
>>>without constraining the type variable using a typeclass? If not,
>>>could you please give a counter-example?
>>Certainly you can write lots of ``meaningful function''s without
On Monday, 2003-03-03, 10:00, CET, Cagdas Ozgenc wrote:
> [...]
> I did not mean to include functions that take type constructors as
> parameters (so lists are out of my discussion scope). I am only considering
> functions that uses type variables that are not restricted by typeclasses.
> In this
> My three eurocents.
> I believe that the Author of the original query won't care more about
> undefined stuff than most of us. He wants truly polymorphic functions,
> of the type, say, a->b->a etc., without constraints.
>
> The answer exists, although it is not always trivial to find interesting
Hello. I'm running into a problem with the Network module, which I suspect
is pretty easy to fix, but am not sure how to best do so.
The problem is that "accept" fails when the reverse DNS fails, with the
following error:
Fail: does not exist
Action: getHostByAddr
Reason: no such host entry
I'm
G'day.
On Mon, Mar 03, 2003 at 11:49:29AM +0200, Cagdas Ozgenc wrote:
> Yes, I thought about these too. Do you find these functions practically
> useful? Can you give an example where I can utilize these functions?
Functions like this are useful for plugging into higher-order functions
to tailor
So, I'm having to calculate 'n choose k' an awful lot. At the moment I've got
this:
comb :: Integer -> Integer -> Integer
comb m 0 = 1
comb m n = (numerator(toRational (fact m) / toRational (fact n * fact (m-n
where fact is a memoized factorial function. It's not perfectly memoized
I think you would get a big speed-up if you got rid of all the rational
stuff and just used:
comb m n = fact m `div` (fact n * fact (m-n))
If that doesn't speed it up enouch, you can of course cache fact m in your
computation and do something like:
sumbn n = sum [ bournoulli i * fm `div` (fn * f
On Tuesday, March 4, 2003, at 10:26 AM, Damien R. Sullivan wrote:
So, I'm having to calculate 'n choose k' an awful lot. At the moment
I've got
this:
comb :: Integer -> Integer -> Integer
comb m 0 = 1
comb m n = (numerator(toRational (fact m) / toRational (fact n * fact
(m-n
where fact is
G'day all.
On Mon, Mar 03, 2003 at 04:59:21PM -0800, Hal Daume III wrote:
> I think you would get a big speed-up if you got rid of all the rational
> stuff and just used:
>
> comb m n = fact m `div` (fact n * fact (m-n))
Or, even better, if you didn't multiply stuff that you're just going
to di
I have no idea if the following is faster or not (I suspect not), but
it is certainly easier to read:
n `choose` k = (n `permute` k) `div` (fact k)
n `permute` k = product [(n-k+1) .. n]
fact n = product [1 .. n]
mike
--
mike castleman / [EMAIL PROTECTED] / http://mlcastle.net
aolim: mlcastle /
On Tue, Mar 04, 2003 at 12:25:01PM +1100, Andrew J Bromage wrote:
> Or, even better, if you didn't multiply stuff that you're just going
> to divide out in the first place.
I had thought of that before, and used a simple
comb m n = product [m, m-1 .. m-n+1] / fact (m-n)
but the unmemoized produc
On Mon, Mar 03, 2003 at 04:59:21PM -0800, Hal Daume III wrote:
> comb m n = fact m `div` (fact n * fact (m-n))
This was the biggest help, 33 seconds instead of my original 43. fact is the
big consumer now, and I think cries out for being arrayed, especially as it
gets used a lot elsewhere too.
I would like to say that programming this project (calculate the
Euler-Mascheroni constant to as many digits as possible in a minute) in
Haskell has been fairly pleasant overall. The startup time was a bit oogy
-- ocaml was faster to get a working program -- and ghc's compilation time
continues to
main =
do
args <- System.getArgs
let (m, b) = (read (args!!0), read (args!!1))
let lim :: Int
lim = read (args!!2)
printstate = args!!3
time1 <- getClockTime
let n = 2^b
let afact = array (0,n) ((0,1):[(i,i*afact!(i-1)) |
G'day all.
On Mon, Mar 03, 2003 at 09:53:24PM -0500, Damien R. Sullivan wrote:
> Time to look at arrays, finally.
This might help:
http://haskell.org/wiki/wiki?MemoisingCafs
Cheers,
Andrew Bromage
___
Haskell-Cafe mailing list
[EMAIL PROTECTE
in 'do' notation, 'let' doesn't take an in. so you want to get rid of the
'in' on the third to last line.
> main =
> do
> args <- System.getArgs
> let (m, b) = (read (args!!0), read (args!!1))
> let lim :: Int
> lim = read (args!!2)
> printstat
On Mon, Mar 03, 2003 at 08:03:44PM -0800, Hal Daume III wrote:
> in 'do' notation, 'let' doesn't take an in. so you want to get rid of the
> 'in' on the third to last line.
But then I get "undefined variable afact" when my functions try to refer to
it.
-xx- Damien X-)
__
Damien writes:
> main =
> do
> args <- System.getArgs
> let (m, b) = (read (args!!0), read (args!!1))
> let lim :: Int
> lim = read (args!!2)
> printstate = args!!3
> time1 <- getClockTime
> let n = 2^b
> let afact = array
On Tue, Mar 04, 2003 at 03:06:13PM +1100, Bernard James POPE wrote:
> Damien writes:
> > main =
> > do
> > args <- System.getArgs
> > let (m, b) = (read (args!!0), read (args!!1))
> > let lim :: Int
> > lim = read (args!!2)
> > printstate = args!
Hi,
> For the reason that I'm lazy and don't want to have to modify all my functions
> which use afact, or call functions which use afact, and don't see why I should
> have to -- they were able to call the 'fact' function as a global, and can
> refer to a global 'afact' if I define it outside of m
"Damien R. Sullivan" <[EMAIL PROTECTED]> wrote:
> For the reason that I'm lazy and don't want to have to modify all my
> functions which use afact, or call functions which use afact, and
> don't see why I should have to -- they were able to call the 'fact'
> function as a global, and can refer to
Hi Damien,
| So, I'm having to calculate 'n choose k' an awful lot. At
| the moment I've got this:
|
| comb :: Integer -> Integer -> Integer
| comb m 0 = 1
| comb m n = (numerator(toRational (fact m) / toRational (fact
| n * fact (m-n
|
| where fact is a memoized factorial functi
Andrew J Bromage <[EMAIL PROTECTED]> wrote:
> G'day.
> On Mon, Mar 03, 2003 at 11:49:29AM +0200, Cagdas Ozgenc wrote:
> > Yes, I thought about these too. Do you find these functions
> > practically useful? Can you give an example where I can utilize
> > these functions?
> Functions like this are
On Mon, Mar 03, 2003 at 10:45:38PM -0600, Jon Cast wrote:
> Never programmed in C++ much, eh?
Only for a few years, professionally.
> In general, getting the ordering of initialization right in the general
> case is a harder problem than you might think.
It's not something I'd be having trouble
On Tue, Mar 04, 2003 at 03:29:48PM +1100, Bernard James POPE wrote:
> So if you want a global variable - read the paper by Hughes that I mentioned
> previously. It is short, easy to understand, and covers the typical
> ways Haskell programmers might try to do it (dirty and clean). It might even
I
30 matches
Mail list logo
