I've been working on an arbitrary-precision floating-point module for a while and have uploaded the source to DSource. (www.dsource.org/projects/decimal)

It's an implementation of the General Decimal Arithmetic Specification, Version 1.70, March 2009. (www.speleotrove.com/decimal). It contains most of the specified arithmetic operations (except exponential and logarithmic operations) and miscellaneous operations (except for logical and rotate/shift operations).

I would appreciate feedback, especially with regard to the implementation of the context for the operations.

The current implementation compiles with D version 2.30, so does not incorporate the new operator overloading.

Paul

Paul D. Anderson wrote:
> I've been working on an arbitrary-precision floating-point module for a while and have uploaded the source to DSource. (www.dsource.org/projects/decimal)
> 
> It's an implementation of the General Decimal Arithmetic Specification, Version 1.70, March 2009. (www.speleotrove.com/decimal). It contains most of the specified arithmetic operations (except exponential and logarithmic operations) and miscellaneous operations (except for logical and rotate/shift operations).
> 
> I would appreciate feedback, especially with regard to the implementation of the context for the operations.
> 
> The current implementation compiles with D version 2.30, so does not incorporate the new operator overloading.
> 
> Paul
Awesome! Hmm, I really need to get my BigInt modules into D2 so that you can use them.

Hello Don,

> Paul D. Anderson wrote:
> 
>> I've been working on an arbitrary-precision floating-point module for
>> a while and have uploaded the source to DSource.
>> (www.dsource.org/projects/decimal)
>> 
>> It's an implementation of the General Decimal Arithmetic
>> Specification, Version 1.70, March 2009.
>> (www.speleotrove.com/decimal). It contains most of the specified
>> arithmetic operations (except exponential and logarithmic operations)
>> and miscellaneous operations (except for logical and rotate/shift
>> operations).
>> 
>> I would appreciate feedback, especially with regard to the
>> implementation of the context for the operations.
>> 
>> The current implementation compiles with D version 2.30, so does not
>> incorporate the new operator overloading.
>> 
>> Paul
>> 
> Awesome! Hmm, I really need to get my BigInt modules into D2 so that
> you can use them.
> 

Ditto my united type: http://www.dsource.org/projects/scrapple/browser/trunk/units/si2.d
(I'll tweak it and/or the license as needed to get it in).

Maybe we need a std.arithmetic.* for all the "a little more than just a number" types.

-- 
... <IXOYE><

BCS wrote:
> ...
> 
> Maybe we need a std.arithmetic.* for all the "a little more than just a number" types.

Phobos with subpackages?!  Blasphemy!  That's what those filthy Tango heathens do and everyone knows that's just morally WRONG.

(Yes, I know about std.c.*.)

On Tue, 16 Mar 2010 12:41:25 +1100, Daniel Keep wrote:

> BCS wrote:
>> ...
>> 
>> Maybe we need a std.arithmetic.* for all the "a little more than just a number" types.
> 
> Phobos with subpackages?!  Blasphemy!  That's what those filthy Tango heathens do and everyone knows that's just morally WRONG.
> 
> (Yes, I know about std.c.*.)

Then all of Java must be wrong too?

The list of std modules is getting a bit too long. Maybe a tree structure would work.  After all it is for a programming language.  Another idea would be to make another root,  like  dlang. or lang. Having std. in front of nearly makes it a piece of superflous, redundent information. There are many roots more to choice from, and maybe it be nice to have the root module path be more informative?

-- Michael Rynn

Michael Rynn wrote:
> On Tue, 16 Mar 2010 12:41:25 +1100, Daniel Keep wrote:
> 
>> BCS wrote:
>>> ...
>>>
>>> Maybe we need a std.arithmetic.* for all the "a little more than just a
>>> number" types.
>> Phobos with subpackages?!  Blasphemy!  That's what those filthy Tango
>> heathens do and everyone knows that's just morally WRONG.
>>
>> (Yes, I know about std.c.*.)
> 
> Then all of Java must be wrong too?

Yes. ;)


> The list of std modules is getting a bit too long. Maybe a tree structure would work.  After all it is for a programming language.

I have the impression that a lot of the Phobos modules in D2 are relics from D1 that will be removed in due time.


> Another idea would be to make another root,  like  dlang. or lang. Having std. in front of nearly makes it a piece of superflous, redundent information. There are many roots more to choice from, and maybe it be nice to have the root module path be more informative?

Why is 'std.' more redundant than Java's 'java.'?

-Lars

On 17.03.2010 04:45, Michael Rynn wrote:
> The list of std modules is getting a bit too long. Maybe a tree structure would work.  After all it is for a programming language.  Another idea would be to make another root,  like  dlang. or lang. Having std. in front of nearly makes it a piece of superflous, redundent information. There are many roots more to choice from, and maybe it be nice to have the root module path be more informative?
> 
> -- Michael Rynn
> 
> 

Let me use this opportunity to pitch tools.smart_import!

http://dsource.org/projects/scrapple/browser/trunk/tools/tools/smart_import.d

Example:

    mixin(expandImport("tango.[core.[Traits, Thread, Memory, BitManip]
      , stdc.[stringz, tgmath, stdio]
      , text.[Util, Unicode, convert.Utf, Regex], math.[Math, IEEE]
      , io.[Path: exists, Console: Cin, Path: createFolder, device.File]
      , net.InternetAddress
    ]"));

No more import path redundancy! :-)