Thanks, I should have know about this, am looking into it, not sure if it
is enough as it is not a subtype of FloatingPoint.
Another issue:
[I vaguely remember this having been asked before for types, but mine is a
Number (actually a FloatingPoint), not sure if it matters.]
A.
Why is Dec right justified (and should it? How would I change it?):
julia> a=[D"1.100", D"1.1", D"2.1"]
3-element Array{Dec,1}:
Dec("1.100")
Dec("1.1")
Dec("2.1")
[also it seems a little redundant to repeat the type when not a Union.]
unlike:
julia> a=[1.101, 1, 2]
3-element Array{Float64,1}:
1.101
1.0
2.0
and even strings:
julia> a=["1.101", "1", "2"]
3-element Array{ASCIIString,1}:
"1.101"
"1"
"2"
B.
Note:
julia> D"Inf" #Both work in Python's Decimal:
Dec("Infinity")
And is this a problem (for Julia?):
julia> D"Infinity"===D"Infinity"
false
julia> D"Inf"===D"Infinity"
false
julia> D"Infinity"==D"Infinity"
false
Unlike:
julia> Inf===Inf
true
julia> Inf==Inf
true
C. Is print and the rest the right way:
Code:
module Dec_m ...
print(io::IO, x::Dec) = (write(io,x.n[:__str__]()); nothing)
function showcompact(io::IO, x::Dec)
print(io, typeof(x))
print(io, "(")
showcompact(io, x)
print(io, ")")
end
function showcompact(io::IO, x::Dec)
show(io, x.n[:__str__]())
end
# can use D"literal number" as short for Dec("number"). Better to use lower
case d?
macro D_str(s)
Dec(s)
end
end
--
Palli.
On Monday, December 29, 2014 at 3:40:54 PM UTC, Jameson wrote:
>
> 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.ha...@gmail.com
> <javascript:>> 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
>>
>
