RE: [Haskell] getArgs, maxBound, float division: pure functions?

[Ralf Lammel]

Just for the record,
Cobol has a long history of specifying local rounding options.
More recently, the options for rounding are elaborated in the context of
adding standard arithmetic.

http://www.cobolportal.com/j4/files/05-0152.doc

Ralf

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
> Behalf Of Bjorn Lisper
> [...]
> He was very careful to give
> the language a good design also regarding floating-point computations.
His
> design choice, as regards rounding, was to allow the compiler to
choose
> rounding mode by default (thus allowing more freedom for
optimization),
> while providing a set of special arithmetic operators, with specified
> rounding modes, to use when more explicit control is needed.
> 
> He also proposed a special construct "letctrl ... in e", where the
"..."
> are
> a list of directives telling how to interpret and evaluate the
expression
> e. One possible directive is "RoundingMode = ..." to set the rounding
mode
> locally in e. Other directives control, for instance, whether
> optimizations
> like x*0.0 -> 0.0 are allowed in e, whether to force strict evaluation
of
> all subexpressions (so optimizations cannot affect exceptions), to set
> allowed miminum accuracy, etc.
> 
> The language has exception handling (including a "handle" construct to
> catch
> exceptions), which also takes care of floating-point exceptions.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] getArgs, maxBound, float division: pure functions?

[Bjorn Lisper]

John Meacham:
>On Wed, Oct 12, 2005 at 12:05:39AM -0400, David Menendez wrote:
>> In principle, you could use seperate types to distinguish floats with
>> different rounding modes, but I imagine this would be difficult or
>> annoying to implement.
>
>I think it would make more sense to have different operations for each
>rounding mode. That matches the reality of the situation more and you
>don't want to have to do tons of type conversions when you need to
>operate on something with different rounding modes. of course, then you
>could declare several 'newtypes' whose default Num instances were of
>specific rounding modes too.

A student of mine designed a special-purpose, pure functional language for
block-oriented matrix computations for his PhD. He was very careful to give
the language a good design also regarding floating-point computations. His
design choice, as regards rounding, was to allow the compiler to choose
rounding mode by default (thus allowing more freedom for optimization),
while providing a set of special arithmetic operators, with specified
rounding modes, to use when more explicit control is needed.

He also proposed a special construct "letctrl ... in e", where the "..." are
a list of directives telling how to interpret and evaluate the expression
e. One possible directive is "RoundingMode = ..." to set the rounding mode
locally in e. Other directives control, for instance, whether optimizations
like x*0.0 -> 0.0 are allowed in e, whether to force strict evaluation of
all subexpressions (so optimizations cannot affect exceptions), to set
allowed miminum accuracy, etc.

The language has exception handling (including a "handle" construct to catch
exceptions), which also takes care of floating-point exceptions.

If Haskell ever gets redesigned to give better support for numerical
computations, then I think this work is worth a look. Alas, it is not
well-published, but the PhD thesis should be possible to order from the
Dept. of Information Technology and Microelectronics at KTH. I also have a
few copies to give away of someone is interested.

Here's the reference:

@PHDTHESIS{npd-phd,
AUTHOR = {N. Peter Drakenberg},
TITLE = {Computational Structure and Language Design},
SCHOOL = {Dept.\ of Information Technology and Microelectronics, KTH},
ADDRESS = {Stockholm},
YEAR = {2004},
MONTH = sep,
NOTE = {TRITA-IMIT-LECS AVH 04:02}
}

Björn Lisper
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] getArgs, maxBound, float division: pure functions?

[John Meacham]

On Wed, Oct 12, 2005 at 12:05:39AM -0400, David Menendez wrote:
> In principle, you could use seperate types to distinguish floats with
> different rounding modes, but I imagine this would be difficult or
> annoying to implement.

I think it would make more sense to have different operations for each
rounding mode. That matches the reality of the situation more and you
don't want to have to do tons of type conversions when you need to
operate on something with different rounding modes. of course, then you
could declare several 'newtypes' whose default Num instances were of
specific rounding modes too.
John

-- 
John Meacham - ⑆repetae.net⑆john⑈ 
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] getArgs, maxBound, float division: pure functions?

[David Menendez]

[EMAIL PROTECTED] writes:

> Regarding argument 1: the value of |maxBound :: Int| is also the
> function of the environment. Haskell98 Report says [p82, Section
> 6.4]
> 
>The finite-precision integer type Int covers at least the range 
>[ - 2^29 , 2^29 - 1 ]. As Int is an instance of the Bounded class, 
>maxBound and minBound can be used to determine the exact Int range
>defined by an implementation.
> 
> Thus, the value of |maxBound :: Int| may conceivably change from on
> program run (under runhugs32 on an AMD64 platform) to another (under
> runghc64 on the same platform).

I guess we could declare 32- and 64-bit Ints to be distinct types, and
then do a system call to get the native Int type.

data SomeIntegral = forall a. Integral a => SomeIntegral a

nativeInt :: IO SomeIntegral

main = case nativeInt of
SomeIntegral (_::int) -> print (maxBound :: int)

The disadvantage would be the need for polymorphism over the Integral
class whenever we wanted native-sized integers.

> Regarding argument 2: the existence of System.Environment.withArgs
> seems to doom getArgs to remain with the IO type. It cannot be a pure
> function. The simple extension of the argument points however to
> inconsistency with the floating-point facility. Haskell98 Report
> permits an implementation to use IEEE FP for Haskell Floats and
> Doubles. The Report specifically provides the class RealFrac to give a
> program access to some aspects of the IEEE FP system. IEEE FP
> computations are sensitive to the rounding mode, which is observable
> in pure code. The rounding mode can be changed. [...] Should all 
> floating-point computations be put in the IO monad?

In principle, you could use seperate types to distinguish floats with
different rounding modes, but I imagine this would be difficult or
annoying to implement.
-- 
David Menendez <[EMAIL PROTECTED]> 
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell