On Thursday, April 30, 2015 at 7:56:28 PM UTC-4, Páll Haraldsson wrote: > > "Mixed operations involving decimal and binary floating-point or integer > types are supported (the result is promoted to decimal floating-point)." > > Is that really advised? Is that what you do or the C library? In C you have > automatic promotion between native types, but I guess you can't otherwise. > The library you wrap provides converts (good), you make them automatic > (bad?). >
In C, you can't have automatic promotion between user-defined types, and C++ is very limited in this regard as well (try adding complex<float> or int and complex<double>). One of the strengths of Julia is that it allows user-defined types to be first-class. I wanted the DecFP types to be first-class. At first blush, as Julia is generic by default, this seems what you would > want, but is it? When I thought about this, it seemed just dangerous. If > you force people to use manual conversion you might get away with wrapping > fewer functions? > Defining the promotion rule does not require wrapping more functions. It just requires a couple of promote_rule methods to be defined; just a few lines of code in DecFP.jl. > "Most basic arithmetic functions are supported, and many special functions > (sqrt, log, trigonometric functions, etc.)." > > I'm not sure if the library you wrap provides this and if it does, doesn't > convert to binary floating point, runs the function, then converts back? > The library I wrap provides these—if it didn't, I wouldn't have advertised them. And no, it is not as simple as converting back and forth between the binary floating-point functions; browsing the code, it seems that it uses some additional tricks to increase the accuracy of the decimal representation. > Whether it does it or you do it, is it not better to let the user decide > on both converts? And faster if you eliminate some.. > If the user wants to do it in binary, they can also call Float64(x) themselves; see below. > for c in (:π, :e, :γ, :catalan, :φ) > > Not sure if these are the only Julia constants.. > They are the only built-in MathConst constants in Julia (see base/constants.jl) — they are special constants that automatically expand to match the precision of anything they are combined with, hence it is (a) natural to define their conversions to decimal-floating-point and (b) important to do so for type stability (see below). > Or only you care about. Anyway, wasn't expecting to see them in any > decimal context. I would not be rich with π dollars in my account. :) > The point is to make the DecFP types first-class floating-point types. To do this, you want to be able to do a drop-in substitution of the DecFP types into existing Julia code written for other floating-point types and have it a) Work. This means that methods have to be implemented (where there are no adequate generic fallbacks already). b) Preserve decimal exactness for as long as possible (since decimal exactness is the whole point of DecFP types). This means that e.g. x * 1.5, where x::Dec64 and 1.5 is a binary floating-point literal that is exactly represented in binary, should promote 1.5 to Dec64 (where it is also exactly represented) before doing the multiplication and giving a decimal result. Or that e.g. exp10(d"23") should give exactly 10^23 (which is not true for exp10(23.0)). c) Lead to type-stable code. This also means that you cannot unexpectedly convert to Float64 just because I happened to multiply by π at some point. Of course, if you have decimal inputs but you are doing lots of transcendental math, there is no point in using decimal floating-point — irrational results will get rounded anyway, so you might as well use binary floating point since it is a lot faster. But it is really up to the user to call the conversion to Float64 in that case.
