www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Decimal Arithmetic module available

reply Paul D. Anderson <paul.d.removethis. anderson comcast.andthis.net> writes:
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
Mar 13 2010
parent reply Don <nospam nospam.com> writes:
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



can use them.
Mar 15 2010
next sibling parent reply BCS <none anon.com> writes:
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
 



 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><
Mar 15 2010
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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.*.)
Mar 15 2010
next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
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.



 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
Mar 17 2010
prev sibling parent FeepingCreature <default_357-line yahoo.de> writes:
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! :-)
Mar 18 2010
prev sibling parent Michael Rynn <michaelrynn optusnet.com.au> writes:
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
Mar 16 2010