rning.)
To this end, we are seeking two postdoctoral researchers and one
research programmer with interest and experience in a cohert subset
of: programming language theory, numerics, automatic differentiation,
and machine learning.
Inquiries to: Barak A. Pearlmutter
Informal announcment with
> ... in most of the cases I do want this warnings. It's possible to get
> something default to Integer when it should be Int. There are only few
> cases when it's not appropriate. Only ^ and ^^ with literals I think
There are a few other cases, albeit less annoying. Like this:
c = fromIntegral
cause this, but common innocuous
cases could---and I would argue, should---be addressed in ad-hoc ways.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
transcript
$ cat tw
/real computation issues.
Project headquarters: Hamilton Institute, NUI Maynooth, Ireland,
http://www.hamilton.ie/.
Applications and queries to:
"Barak A. Pearlmutter"
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.o
> The problem are not so much the additional instructions. Rather,
> it's the fact that compare for Float and Double can fail at all
> which inhibits some optimisations. For instance, GHC is free to
> eliminate the comparison in (x `compare` y) `seq` a but wouldn't be
> with your change. It doesn't
> It's a question of what the right default is - safety or
> performance. In the case of floating point numbers, I'm leaning
> towards performance.
I quite agree.
Currently the standard prelude has default definition:
...
compare x y
| x == y= EQ
| x <= y= LT
> And yet a lot of generic code is written in terms of compare.
That's can be an advantage, because often that code *should* blow up
when it gets a NaN. E.g., sorting a list of Floats which includes a
NaN.
> Even deriving(Ord) only produces compare and relies on standard
> definitions for other
> Please think of the poor guys trying to write high-performance code in
> Haskell!
Like me? (Well, not in Haskell per-se, but in a pure functional context.)
In all seriousness, I think it is reasonable when "isNaN x" for
x < C
x == C
x > C
C < x
C == x
C > x
to all be False, for all flo
> ... An invalid comparison evaluating to _|_ is arguably more
> correct, but I personally find the idea of introducing more bottoms
> rather distasteful.
Too late! NaN is pretty much the _|_ of IEEE Floating Point.
That was certainly the intent of the IEEE standard, and is why NaN is
so contagi
.
The project headquarters will be in the Hamilton Institute, NUI
Maynooth, Ireland, http://www.hamilton.ie/.
Applications to:
"Barak A. Pearlmutter"
--
Prof Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hami
min (0/0) 1
nan
Hugs> min 1 (0/0)
1.0
Hugs> max (0/0) 1
1.0
Discuss?
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
11 matches
Mail list logo
