On Thu, Jan 22, 2015 at 05:12:17PM +0000, Russel Winder via Digitalmars-d-learn wrote:
> Using reduce for factorial, seems to require iota, not a bad things per se, with ulongs:
> 
> 	reduce!"a*b"(1, iota(1, n + 1))
> 
> works fine. Now switch to BigInt:
> 
> 	reduce!"a*b"(one, iota(one, n + one))
> 
> fails to compile, one and n + one are of different types. Problem is that one is immutable but n + one is not. I can't remember how to create an immutable value as an expression so:
> 
> 	immutable BigInt v = n + one;
> 	reduce!"a*b"(one, iota(one, v))
> 
> now I get an error telling me that I can't use iota because BigInt is not a float or an integer. Is this a known bug? Yes it is: https://issues.dlang.org/show_bug.cgi?id=6447
> 
> Does anyone know how to fix this 3.5 year old bug that is a blocker for doing anything with factorial and Fibonacci Series.?
[...]

https://github.com/D-Programming-Language/phobos/pull/2895

This is just the tip of the iceberg. The full enhancement is described in:

	https://issues.dlang.org/show_bug.cgi?id=10762


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.

On Thu, 2015-01-22 at 10:21 -0800, H. S. Teoh via Digitalmars-d-learn
wrote:
[…]
> 
> https://github.com/D-Programming-Language/phobos/pull/2895
> 
> This is just the tip of the iceberg. The full enhancement is described in:
> 
> 	https://issues.dlang.org/show_bug.cgi?id=10762
> 

Sadly, I suspect it will be a long time before this is usable by folk in the field :-(

It's a pity there is not better support for arbitrary size integers and floating point in D. Hardware integers are too limited and hardware floating point far too inaccurate for an awful lot of computing out there (*). Groovy is getting a lot of traction exactly because the default floating point is BigDecimal and not IEEE754.


(*) I know games requires speed above all else, as does a lot of the sort of calculations I have done in the past, but these calculations generally need very few significant digits of accuracy. We won't mention the calculation that are just wrong because insufficient attention to error management occurs.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder