On Thursday, April 30, 2015 at 11:56:28 PM UTC, Páll Haraldsson wrote: > > "In general, you should be able to use the DecFP types in any context > where you would have used binary floating-point types: arrays, complex > arithmetic, and linear algebra should all work, for the most part." > > Way better than what I was going for - I thought only +, -, *, / was > needed and maybe only wanted.. plus convert but not automatic: > > s/better/more/
> "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?). > > Maybe I should have stopped about here. The above dangerous, will clarify below: 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? > > "Most basic arithmetic functions are supported, and many special functions > (sqrt, log, trigonometric functions, etc.)." > The functions aren't dangerous per se. But are they and the irrational constants not a sign you want binary floating point? Are you converting back and fourth for type stability reasons? If you are doing that is type instability is slow (and yes slower than either binary or decimal) wouldn't manual convert give you a hint and force you to convert to binary floating point and be faster and be what you want? I've also been think about the numeric tower. Is this for sure ok: abstract DecimalFloatingPoint <: FloatingPoint what are the implications? Are you saying Decimal is similar to Binary (on the same "inheritance" level). Maybe I'm confused, as all but leaf-types are abstract. should it be: abstract DecimalFloatingPoint <: Real What are then the implications? I'm also thinking about other decimal types, arbitrary precision. they need no NaN (is the NaN the same for binay and decimal..?). Do not think BigFloat has NaN and that can be under FloatingPoint so again, maybe I'm just confused. -- Palli. > 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? > 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.. > > I just scanned the code or one file: > > for c in (:π, :e, :γ, :catalan, :φ) > > Not sure if these are the only Julia constants.. 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. :) > > -- > Palli. > > On Wednesday, April 29, 2015 at 1:26:17 AM UTC, Steven G. Johnson wrote: >> >> The DecFP package >> >> https://github.com/stevengj/DecFP.jl >> >> provides 32-bit, 64-bit, and 128-bit binary-encoded decimal >> floating-point types following the IEEE 754-2008, implemented as a wrapper >> around the (BSD-licensed) Intel Decimal Floating-Point Math Library >> <https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library>. >> >> Decimal floating-point types are useful in situations where you need to >> exactly represent decimal values, typically human inputs. >> >> As software floating point, this is about 100x slower than hardware >> binary floating-point math. On the other hand, it is significantly >> (10-100x) faster than arbitrary-precision decimal arithmetic, and is a >> memory-efficient bitstype. >> >> The basic arithmetic functions, conversions from other numeric types, and >> numerous special functions are supported. >> >
