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
>
