Henning Thielemann ha scritto:
On Thu, 5 Feb 2009, Manlio Perillo wrote:
Yitzchak Gale ha scritto:
Ah, OK. Thanks. Now we have a well-defined problem. :)
Good :).
I have used this example to describe how to avoid big integers at all:
http://haskell.org/haskellwiki/Integers_too_big_for_
--- Begin Message ---
Simon Peyton-Jones wrote:
| By the way: it is possible to use a private constructor (via some
| special GHC flag?).
| I would like to do a quick performance check using the existing
| fromRational specialization by constructing a Rational directly.
|
| I know that Haskell a
On Thu, 5 Feb 2009, Manlio Perillo wrote:
Yitzchak Gale ha scritto:
Ah, OK. Thanks. Now we have a well-defined problem. :)
Good :).
I have used this example to describe how to avoid big integers at all:
http://haskell.org/haskellwiki/Integers_too_big_for_floats
_
| By the way: it is possible to use a private constructor (via some
| special GHC flag?).
| I would like to do a quick performance check using the existing
| fromRational specialization by constructing a Rational directly.
|
| I know that Haskell allows declaration hiding for program safety, but
|
Yitzchak Gale schrieb:
> Manlio Perillo wrote:
>> However there is still a *big* problem: it is inefficient.
>>
>> Here is a Python version of the Chudnovsky algorithm [1] for computing Pi:
>> http://paste.pocoo.org/show/102800/
>> On my system it takes 10 seconds.
>> Here is an Haskell version:
>>
Yitzchak Gale ha scritto:
[...]
Suppose we have a function
decodeIntegerAsFloat :: RealFloat a => Integer -> (Integer,a)
such that if (s,m) = decodeIntegerAsFloat x
then either x = 0 and s = 0 and m = 0
or x = m * 2**s (mathematically) and abs m \in [0.5,1.0).
Yes, that is what Man
| Manlio Perillo wrote:
| > By the way, in GHC.Float there is a (private):
| > integerLogBase :: Integer -> Integer -> Int
|
| Yes, I have needed this function many times.
| Too bad it is not exposed.
So use the libraries process to propose exposing it!
Simon
_
Manlio Perillo wrote:
> By the way, in GHC.Float there is a (private):
> integerLogBase :: Integer -> Integer -> Int
Yes, I have needed this function many times.
Too bad it is not exposed.
In this case, though, we only need base 2.
For that, it would be nice if we could just read
it directly from
Manlio Perillo wrote:
>> I'm looking for an exact integer division that avoids overflows, if
>> possible.
Richard O'Keefe wrote:
> What this sounds like to me is a request that the Prelude
> function 'fromRational' should work well...
> If you cannot divide two Integers n, d accurately using
> (
Richard O'Keefe ha scritto:
On 5 Feb 2009, at 10:38 am, Manlio Perillo wrote:
I'm looking for an exact integer division that avoids overflows, if
possible.
What this sounds like to me is a request that the Prelude
function 'fromRational' should work well.
Just found that it actually works
Jonathan Cast ha scritto:
On Thu, 2009-02-05 at 01:10 +0100, Manlio Perillo wrote:
Yitzchak Gale ha scritto:
In our case, the Python division first does a quick estimate
of the sizes of the two integers, and just returns zero if it
sees that there will be underflow on conversion to double.
So I
On 5 Feb 2009, at 10:38 am, Manlio Perillo wrote:
I'm looking for an exact integer division that avoids overflows, if
possible.
What this sounds like to me is a request that the Prelude
function 'fromRational' should work well. Since
"The floating point literal f is equivalent to
fromRation
On Thu, 2009-02-05 at 01:10 +0100, Manlio Perillo wrote:
> Yitzchak Gale ha scritto:
> > In our case, the Python division first does a quick estimate
> > of the sizes of the two integers, and just returns zero if it
> > sees that there will be underflow on conversion to double.
> > So I made the fo
Yitzchak Gale ha scritto:
Manlio Perillo wrote:
However there is still a *big* problem: it is inefficient.
Here is a Python version of the Chudnovsky algorithm [1] for computing Pi:
http://paste.pocoo.org/show/102800/
On my system it takes 10 seconds.
Here is an Haskell version:
http://paste.po
Manlio Perillo wrote:
> However there is still a *big* problem: it is inefficient.
>
> Here is a Python version of the Chudnovsky algorithm [1] for computing Pi:
> http://paste.pocoo.org/show/102800/
> On my system it takes 10 seconds.
> Here is an Haskell version:
> http://paste.pocoo.org/show/102
Thomas DuBuisson ha scritto:
What other optimizations should I enable?
-fexcess-precision or some such
There is pratically no performance gain (maybe about 1 second).
Thanks Manlio Perillo
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Max Rabkin ha scritto:
[...]
Here is an Haskell version:
http://paste.pocoo.org/show/102801/
On my system it takes 30 seconds.
You're only dividing integers by integers to get Doubles.
x /. y = fromIntegral x / fromIntegral y
works just fine in this case.
No, this *does not works*.
I g
> What other optimizations should I enable?
-fexcess-precision or some such
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Manlio Perillo ha scritto:
[...]
Here is an Haskell version:
http://paste.pocoo.org/show/102801/
On my system it takes 30 seconds.
Sorry, I compiled without optimizations enabled.
With -O2 it now runs in 20 seconds.
What other optimizations should I enable?
Thanks Manlio Perillo
_
Yitzchak Gale ha scritto:
[...]
exactDiv :: (Real a, Real b, Fractional c) => a -> b -> c
x `exactDiv` y = realToFrac x / realToFrac y
Python does that same type coercion automatically at runtime.
No, this is not correct.
CPython converts to float only for a "simple" integer (since conversio
Yitzchak Gale ha scritto:
Manlio Perillo wrote:
No.
I'm looking for...
Manlio - can you describe exactly what you want?
Do you know exactly what you want?
You have said that you want division like in Python -
but that even that is not well defined:
Python 2.6.1
3/5
0
You have to:
from _
On Wed, Feb 4, 2009 at 2:03 PM, Manlio Perillo wrote:
> Max Rabkin ha scritto:
>>
>> [...]
>>
>> Then we can define
>>(/.) :: (Real a1, Real a2, Fractional a) => a1 -> a2 -> a
>>x /. y = fromRational $ toRational x / toRational y
>
>> [...]
>>
>> (//) :: (Integral b, Real a, Real a1) => a
Max Rabkin ha scritto:
[...]
Then we can define
(/.) :: (Real a1, Real a2, Fractional a) => a1 -> a2 -> a
x /. y = fromRational $ toRational x / toRational y
> [...]
(//) :: (Integral b, Real a, Real a1) => a -> a1 -> b
x // y = floor $ toRational x / toRational y
Hope that helps,
Ma
Manlio Perillo wrote:
> No.
> I'm looking for...
Manlio - can you describe exactly what you want?
Do you know exactly what you want?
You have said that you want division like in Python -
but that even that is not well defined:
Python 2.6.1
>>> 3/5
0
Python 3.1
>>> 3/5
0.59998
Pleas
Manlio Perillo wrote:
>> fac(777) / fac(777)
>>> 1.0
>>> Here CPython does not convert the two integers to float before to divide
>>> them, but make use of a special algorithm.
>>> GHC, instead, returns NaN
I wrote:
>> No, actually here Haskell shines. Perhaps this GHCi session
>> will illumin
> No.
> I'm looking for an exact integer division that avoids overflows, if
> possible.
Use Data.Ratio:
*Main Data.Ratio> (fac 777) / (4 * fac 776) :: Ratio Integer
777%4
Convert to a float , if you want, before displaying it.
___
Haskell-Cafe mailing
Ross Mellgren ha scritto:
Prelude> let i2fDiv a b = fromIntegral a / fromIntegral b
Prelude> :t i2fDiv
i2fDiv :: (Integral a, Fractional b, Integral a1) =>
a -> a1 -> b
Prelude> 10 `i2fDiv` 3
3.3335
Prelude> fac 777 `i2fDiv` fac 777
NaN
That what you're looking f
Prelude> let i2fDiv a b = fromIntegral a / fromIntegral b
Prelude> :t i2fDiv
i2fDiv :: (Integral a, Fractional b, Integral a1) =>
a -> a1 -> b
Prelude> 10 `i2fDiv` 3
3.3335
That what you're looking for?
-Ross
On Feb 4, 2009, at 4:22 PM, Manlio Perillo wrote:
Manli
On Wed, Feb 4, 2009 at 1:09 PM, Manlio Perillo wrote:
> In Haskell, something like
>
> (/) :: (Num a, Real b) => a -> a -> b
You probably want (Real a, Fractional b) => a -> a -> b. Int is an
instance of Real... Real is the class of types that can be converted
to Rational.
Then we can define
Manlio Perillo ha scritto:
[...]
I personally prefer the Python solution, where we have two operators
with the same behaviour over all the numbers.
In Haskell, something like
(/) :: (Num a, Real b) => a -> a -> b
This should be
(/) :: (Num a, Fractional b) => a -> a -> b
but I'm not sure
Yitzchak Gale ha scritto:
Manlio Perillo wrote:
[...]
The second difference is about the division of two integers.
fac(777) / fac(777)
1.0
Here CPython does not convert the two integers to float before to divide
them, but make use of a special algorithm.
GHC, instead, returns NaN
No, actuall
Manlio Perillo wrote:
>> The first difference is about a `mod` b, when a and b are Float types.
>> Python use the fmod function, and it also implement divmod; Haskell seems to
>> lack support for this operation.
I wrote:
> Yes, Haskell does not implement the full IEEE.
I spoke too soon. Data.Fixe
Manlio Perillo wrote:
> The first difference is about a `mod` b, when a and b are Float types.
> Python use the fmod function, and it also implement divmod; Haskell seems to
> lack support for this operation.
Yes, Haskell does not implement the full IEEE. There are
differing opinions about that: s
Hi.
During some experiments with Python and Haskell I found some important
differences about how some integer and float operations are implemented.
The first difference is about a `mod` b, when a and b are Float types.
Python use the fmod function, and it also implement divmod; Haskell
seem
34 matches
Mail list logo
