To see what function definitions are useful for implementing a basic
numeric type, you might want to peruse the FixedPointNumbers.jl source code
(https://github.com/JeffBezanson/FixedPointNumbers.jl) and work from that.
On Mon Dec 29 2014 at 8:57:46 AM Páll Haraldsson <pall.haralds...@gmail.com>
wrote:
>
> On Thursday, December 25, 2014 12:20:48 PM UTC, Páll Haraldsson wrote:
>>
>>
>> Hi,
>>
>> This is my first useful Julia code so far. I should have probably started
>> with wrapping C-code for Decimal floating point. I'm a little conflicted, I
>> see that SymPi.jl doesn't wrap all of the Python code and I thought you
>> could call the rest of the functions that are missing also with my code.
>> Then if I change the implementation that wouldn't work.. Right? Would
>> macros help?
>>
>
> I mean, I can do:
>
> julia> a=D"1.1"
> "1.1"
>
> julia> a.n[:radix]()
> PyObject Decimal('10')
>
> There is no such thing as private or protected as in C++. I can even do:
>
> a.n=b.n
>
> When I wrap C code n will be a 64-bit bittype. And with different
> functions.. Should I do "abstract Decimal"? And implement C and Python
> types from that one? I want the C type to be a drop-in replacement (and not
> get runtime errors). I guess I can't have my cake and eat it too.
>
>
>> Is there something missing to fully be Julian? Do not care about sin,
>> cos.. etc.
>>
>>
> Such as:
>
> julia> zeros(Dec, 2, 2)
> ERROR: `convert` has no method matching convert(::Type{Dec}, ::Int64)
> in zeros at array.jl:169
>
> Seems to be the same issue as with:
>
> julia> mean([D"1.1" D"2.2"])
> ERROR: no promotion exists for Dec and Int64
> in mean at statistics.jl:17
>
> I tried:
> convert(::Type{Dec}, x::Int64) = Dec(x)
>
> In general what functions would I have to implement to get Decimal merged
> into Julia? Ideally it should be a drop-on replacement for other types. But
> is there at least a minimal "must-haves"? This is just an exercise for me
> for learning more about Julia (and Python..) and decimal floating (and
> fixed) point.
>
> I think this is the C library I should wrap:
> http://www.netlib.org/misc/intel/README.txt
>
> Then I found this one..:
>
> https://gcc.gnu.org/onlinedocs/gccint/Decimal-float-library-routines.html#Decimal-float-library-routines
> "The software decimal floating point library supports either DPD (Densely
> Packed Decimal) or BID (Binary Integer Decimal) encoding as selected at
> configure time."
>
> Maybe there isn't too much interest, I do not even have use for decimal
> floating point. As I said, this is just an exercise for me, I just think
> Julia is incomplete without Decimal support.. I'm ok with just the basic
> operators I provided (+ average). I'm not sure how much Decimal would be
> used beyond basic financial stuff.
>
> As Julia is generic, maybe a lot will fall into place with just some few
> functions/conversions. I see that linear algebra even works now (except
> for):
>
> julia> [D"1.1" D"2.2"; D"1.1" D"2.2"]/[D"1.1" D"2.2"; D"1.1" D"2.2"]
> ERROR: no promotion exists for Dec and Int64
> in istril at linalg/generic.jl:288
> in \ at linalg/dense.jl:411
> in Ac_ldiv_Bc at operators.jl:156
> in / at linalg/generic.jl:236
>
> julia> [1.1 2.2; 1.1 2.2]/[1.1 2.2; 1.1 2.2]
> ERROR: SingularException(2)
> in \ at linalg/factorization.jl:815
> in \ at linalg/dense.jl:412
> in Ac_ldiv_Bc at operators.jl:156
> in / at linalg/generic.jl:236
>
> Let's say I wanted sin to work, I probably should it return float not
> Decimal? I think all the libraries convert to binary floating point and it
> seems just wasteful to change back. Would I have to implement sin, cos etc.
> or just have some promotion?
>
> julia> typeof(sin(BigInt(1)))
> BigFloat (constructor with 14 methods)
>
>
> https://github.com/quinnj/ODBC.jl/blob/master/src/ODBC_Types.jl
>> typealias SQLDECIMAL Cdouble
>> typealias SQLNUMERIC Cdouble
>>
>
> This one is kind of a lie.. :) Along with:
>
> # Data Type Status: Pretty good, I think we're at 95% support, really only
> missing native date, time, interval, and GUID types (currently just read in
> as strings)
>
> # SQL_DECIMAL SQL_C_DOUBLE Float64
> # SQL_NUMERIC SQL_C_DOUBLE Float64
>
> If most aggregates are handled in the SQL, Float64 might not be to bad for
> querying, otherwise this could be a problem. If I would change this to
> Decimal (that doesn't implement all functions) I would brake code.. I
> wander how much this has been used already..
>
> Best regards,
>
> --
> Palli
>
