On Saturday, October 06, 2012 19:03:39 Arlen wrote:
> I wasn't aware that we already had std.typelist module in Phobos until I was ready to submit my work.  I suppose the work was abandoned or it was never finalized?  There are differences in typelist2.d and typelist.d, though.

It needs to be removed. It's not even compiled in. std.typetuple is what we use. I would suggest looking at adding further functionality to it rather than trying to create anything based on type lists. TypeTuples can do the same things and are actually more flexible.

- Jonathan M Davis

Just a quick update:

I have made Rational nothrow, fixed toString, and some other minor changes.  For the past several months I've used Rational extensively in units (see my other thread), and it works great.

source: https://github.com/Arlen/phobos/blob/std_rational/std/rational.d docs: http://arlen.github.com/phobos/std_rational.html

What would be the next step, a formal review?

Arlen

Arlen:

> https://github.com/Arlen/phobos/blob/std_rational/std/rational.d
> docs: http://arlen.github.com/phobos/std_rational.html

I'd like a good Rational in Phobos.

From your code:

private template isSignedIntegral(T)
{
    enum isSignedIntegral = isIntegral!T && isSigned!T;
}
...
struct Rational(T) if (isSignedIntegral!T)
{
    static if (is(T == immutable) || is(T == const))
    {
        private enum bool mutableT = false;
    }
    else
    {
        private enum bool mutableT = true;
    }

    static if (mutableT)
    {
        private T numerator;
        private T denominator = 1;
        private bool dirty;
    }
    else
    {
        private T numerator, denominator;
        @disable this();
    }
...


A Rational should accept T as BigInt too.

And isn't it better for the Rational constructor to simplify the arguments (calling an optimized GCD)? See this implementation (that doesn't use an optimized GCD):

http://rosettacode.org/wiki/Arithmetic/Rational#D

Bye,
bearophile

On Mon, Feb 11, 2013 at 1:05 PM, bearophile <bearophileHUGS@lycos.com>wrote:

>
> A Rational should accept T as BigInt too.
>
> Bye,
> bearophile
>

Rational doesn't support BigInt because the necessary math functions do not support BigInt.  And if you are going to have Rational support BigInt, you are most likely going to need BigFloat, which is something we don't have.

I personally do not like BigInt because it is incomplete, and because it is reinventing the wheel.  I much rather see Phobos provide an interface to GMP, MPFR, or some other arbitrary precision arithmetic library, similar to what you see with Haskell and Python.

Arlen

Arlen:

> Rational doesn't support BigInt because the necessary math functions do not
> support BigInt.  And if you are going to have Rational support BigInt, you
> are most likely going to need BigFloat, which is something we don't have.

I have used Rationals with BigInts several times, and so far I didn't need bigfloats...


> I personally do not like BigInt because it is incomplete, and because it is
> reinventing the wheel.  I much rather see Phobos provide an interface to
> GMP, MPFR, or some other arbitrary precision arithmetic library, similar to
> what you see with Haskell and Python.

CPython defines its own multi-precision numbers.

But I have not yet understood why D isn't using GMP as Haskell does. Maybe Don knows this answer.

In theory Open Source is meant to give a huge help to code reuse, in practice you see wheel reinvention all the time. D should use bigints from GMP, a garbage collector developed in conjunction with Rust and Mono developers, the back-end (that supports 32 bit Windows exceptions) on LLVM, etc.

Thankfully Phobos uses Curl :o)

Bye,
bearophile

On 2013-02-12 04:03, bearophile wrote:
> But I have not yet understood why D isn't using GMP as Haskell does.

Especially that when you get dynamic libraries working it would create good common ground for interoperability.

> In theory Open Source is meant to give a huge help to code reuse, in practice
> you see wheel reinvention all the time. D should use bigints from GMP, a garbage
> collector developed in conjunction with Rust and Mono developers, the back-end
> (that supports 32 bit Windows exceptions) on LLVM, etc.

There's this terrible and often terminal Not-invented-here disease. ;)
Not sure though whether what's possible in Mono's GC can be ported to D.

> Thankfully Phobos uses Curl :o)

Yay!

FG:

> Not sure though whether what's possible in Mono's GC can be ported to D.

With "developed in conjunction" I meant written with then, not just ported (that means copied and then adapted). Go, C#, Rust and D need GCs with different characteristics, but not totally different characteristics.

Compared to D, I think in C# pinned objects and low level coding is less common.

Bye,
bearophile

On 2/12/13, bearophile <bearophileHUGS@lycos.com> wrote:
> D should use bigints from GMP

Good luck compiling that with DMC on win32. And fixing bugs upstream. :)

Andrej Mitrovic:

> Good luck compiling that with DMC on win32. And fixing bugs upstream. :)

For the first problem maybe using LLVM is a solution. For the second problem, do you know how do Haskell devs solve it?

Bye,
bearophile

On 2/12/13, bearophile <bearophileHUGS@lycos.com> wrote:
>> Good luck compiling that with DMC on win32. And fixing bugs upstream. :)
>
> For the first problem maybe using LLVM is a solution.

That doesn't help if we want to use DMD. As for the second part I meant it's likely easier to fix bugs in BigInt than it is in GMP, GMP is over 200 KLOC big.