<div class="gmail_quote">On 1 April 2010 10:53, Ivan Lazar Miljenovic <span dir="ltr"><<a href="mailto:ivan.miljenovic@gmail.com">ivan.miljenovic@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Jens Blanck <<a href="mailto:jens.blanck@gmail.com">jens.blanck@gmail.com</a>> writes:<br>
> I was wondering if someone could give me some references to when and why the<br>
> choice was made to default integral numerical literals to Integer rather<br>
> than to Int in Haskell.<br>
<br>
</div>My guess is precision: some numeric calculations (even doing a round on<br>
some Double values) will be too large for Int values (at least on<br>
32bit). Note that unlike Python, etc. Haskell doesn't allow functions<br>
like round to choose between Int and Integer (which is equivalent to the<br>
long type in Python, etc.).</blockquote><div> </div><div>Ints have perfect precision as long as you remember that it implements modulo arithmetic for some power of 2. I was hoping that the reason would be that Integers give more users what they expect, namely integers, instead of something where you can add two positive numbers and wind up with a negative number. The type for round is (Fractional a, Integral b) => a -> b, so that can used to give Integer or Int as you like.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> I'd like to use this information to make an analogous case for defaulting<br>
> real numerical literals (well, the literals are likely to be in scientific<br>
> notation, i.e., floating point) to some data type of computable reals rather<br>
> than to floating point Double.<br>
<br>
</div>The difference here is performance: under the hood, Integer values which<br>
can be expressed as an Int _are_ stored as an Int (IIUC anyway); however<br>
computable reals are almost always inefficient.</blockquote><div> </div><div>Yes, the cost for computable reals will be an order of magnitude or possibly two for well-behaved computations. For not well-behaved problems it will be much worse, but it won't return nonsense either. Also consider that the difference between Integers and unboxed Ints is also quite big. I'll happily to take the hit.</div>
<div><br></div></div>