[Haskell] Power series in a nutshell

[Doug McIlroy]

For lovers of things small and beautiful,
http://www.cs.dartmouth.edu/~doug/powser.html
boils down basic operations on power series with numeric
coefficients to the bare minimum--each is a one-liner.
Included are overloaded arithmetic operators, integration,
differentiation, functional composition, functional inverse
and coercion from scalars. --A telling demonstration of the
power of lazy evaluation and of Haskell's attunement to math.

Doug McIlroy
_______________________________________________
Haskell mailing list
Has...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Taral]

On 7/12/07, Doug McIlroy <do...@cs.dartmouth.edu> wrote:
> http://www.cs.dartmouth.edu/~doug/powser.html

Very nice. I would only recommend that you include:

scale k f = map (k*) f

and have (*) use it. Thanks for your contribution!

--
Taral <tar...@gmail.com>
"Please let me know if there's any further trouble I can give you."
-- Unknown

[Derek Elkins]

On Thu, 2007-07-12 at 12:49 -0400, Doug McIlroy wrote:
> For lovers of things small and beautiful,
> http://www.cs.dartmouth.edu/~doug/powser.html
> boils down basic operations on power series with numeric
> coefficients to the bare minimum--each is a one-liner.
> Included are overloaded arithmetic operators, integration,
> differentiation, functional composition, functional inverse
> and coercion from scalars. --A telling demonstration of the
> power of lazy evaluation and of Haskell's attunement to math.

and a link to your earlier Functional Pearl,
http://citeseer.ist.psu.edu/mcilroy98power.html

[jerzy.kar...@info.unicaen.fr]

Derek Elkins writes:

> Doug McIlroy wrote:
>> For lovers of things small and beautiful,
>> http://www.cs.dartmouth.edu/~doug/powser.html

..

> and a link to your earlier Functional Pearl,
> http://citeseer.ist.psu.edu/mcilroy98power.html

If somebody is interested in similar manipulations, sometimes a bit
more involved, there is a paper (sorry for shameless auto-ad) published
more that 10 years ago, copy here:
http://users.info.unicaen.fr/~karczma/arpap/lazysem.pdf

Jerzy Karczmarczuk

[Ryan Ingram]

This is really interesting. I love how the typechecker can resolve
1:0:1 (representing (1+x^2))

1 : 0 : 1
=> 1 : 0 : (fromInteger 1 :: [Integer])
=> 1 : 0 : (series (fromInteger 1 :: Integer))
=> 1 : 0 : (series 1)
=> 1 : 0 : 1 : repeat 0

(I'm going to go on a bit of a soapbox here...)

I feel that Haskell could learn from one of C++'s goals here: provide
at least as good support for user-defined-types as for built-in types.
Automatic conversion to numeric types via fromInteger could be
extended to other types; fromList and fromString could be applied
automatically to convert other literals:

class LiteralString a where fromString :: String -> a
class LiteralList a b where fromList :: [a] -> b

[Bas van Dijk]

On 7/17/07, Ryan Ingram <ryani...@gmail.com> wrote:
> Automatic conversion to numeric types via fromInteger could be
> extended to other types; fromList and fromString could be applied
> automatically to convert other literals:
>
> class LiteralString a where fromString :: String -> a
> class LiteralList a b where fromList :: [a] -> b

GHC HEAD has support for overloaded String literals. See:

http://haskell.org/ghc/dist/current/docs/users_guide/other-type-extensions.html#overloaded-strings

regards,

Bas van Dijk

[Wolfgang Jeltsch]

Am Dienstag, 17. Juli 2007 11:47 schrieb Bas van Dijk:
> […]

> GHC HEAD has support for overloaded String literals. See:
>
> http://haskell.org/ghc/dist/current/docs/users_guide/other-type-extensions.
> html#overloaded-strings

These are really good news!

However, the identifier IsString is problematic. We don’t have classes IsEq,
IsOrd and IsNum, so why should there be IsString? Is there any chance that
this identifier gets changed at some time?

As an aside, the identifier State has a similar problem since the
corresponding type is about state transformers, not states. It’s problematic
if you want to talk about states and state transformers in your program and
you name them both “state”.

In my opinion, we should care that all libraries get cleaned up (not only
regarding identifiers) before they become part of a standard – even if this
reduces compatibility. What do others think?

> […]

Best wishes,
Wolfgang