[ANN] A decimals lib like Java BigDecimal

1 Like

isaactsang, Are you and gfZeng, one and the same person?

(I am assuming this is a package announcement, and changed the category accordingly)

Yeah, it’s me, both


Could you explain the benefit of this package over using BigFloat or BigInt?

1 Like

The real infinite precision support

big"1.0" / big"3.0" 
=> 0.3333333333333333333333333333333333333333333333333333333333333333333333333333348

using Decimals
d"1.0" / d"3.0"
=> Decimal(3333333333333333333333333333333333333333333333333333333333333333333333333333333, -79)

You will need to add an open-source license, such as MIT, for people to be able to use the package.


Thanks for your remind, I have added just now


What are the Pros and Cons vs https://github.com/JuliaMath/Decimals.jl


compares with https://github.com/JuliaMath/Decimals.jl
at here

Well, I don’t know much about https://github.com/JuliaMath/FixedPointNumbers.jl

Well, the only comparison with Decimals.jl that you give at the referenced link is that your implementation is simpler and the use is more friendly. Now that you made such statement, could you be a bit more specific? In which aspect is your implementation simpler? And in which situations is the use more friendly? Perhaps examples might help.

You may also want to take an inspiration from a comparision displayed on the Decimals.jl page: https://github.com/JuliaMath/Decimals.jl#comparison-with-other-packages


The code is simple enough, best docs is code. :slight_smile:

yeah,it is, the idea of a string macro is very good. with that said, as i saw a lot of times with number packages, a speed comparison would be very good. the main difference i saw is that the JuliaMath Decimals.jl uses the following struct:

struct Decimal <: AbstractFloat
        s::Integer  # sign can be 0 (+) or 1 (-)
        c::BigInt   # coefficient (significand), must be non-negative
        q::Integer  # exponent

your decimal uses:

struct Decimal <: AbstractFloat
    c::BigInt  # coefficient
    q::Integer # exponent

a glaring fault is the absence of compatibility with other number types. (for example, 1+d"3.0")

1+d"3.0" should be working, you can try again


I take great offense that your implementation is simpler and the use is more friendly.

Let me give you an example of my PDFPs.jl which is more simpler and more friendly


julia> using PDFPs

julia> s = PDFP_toCommonString
PDFP_toCommonString (generic function with 1 method)

"Now using 4 digit precision via format of PDFP(number,4)";

julia> A=PDFP("7.0",4); B=PDFP(pi,4); C=A+B; s(C)

"Now using the simpler and more friendlier 0 digit precision";

julia> A=PDFP("7.0",0); B=PDFP(pi,0); C=A+B; s(C)

julia> show(C)
PDFP(0, 0, [])

Any number can be represented by my 0 digit precision PDFP and the result is also a 0 digit precision PDFP. NOTHING could be simpler or more friendly to use. In fact my 0 digit precision PDFP is the fastest decimal floating point number system in the world because it can give you the result before you even started the calculation!!! It is also 100% foolproof because it is absolutely impossible to get the wrong result.


Well, we should be considering what features we use most.

You can write a simple function to achieve your case, or just use setexponent(d, 0, RoundDown)