Will do. I just need to take the time to find out exactly what it fails 
with. I'll open some issues soon. Have a good time at JuliaCon!

On Monday, June 20, 2016 at 11:15:28 PM UTC+1, Stefan Karpinski wrote:
>
> If you hit issues with DoubleDouble and/or generic math algorithms in 
> Julia's stdlib, please do file issues. We want to get to the point where 
> *everything* just works.
>
> On Mon, Jun 20, 2016 at 4:31 PM, Chris Rackauckas <rack...@gmail.com 
> <javascript:>> wrote:
>
>> I see. I surely can't wait for native bigs, but there are definitely more 
>> pressing issues to work on first. Tim's proof of principle results look 
>> really nice.
>>
>> I tried DoubleDouble and ran into some errors. I don't think it worked 
>> with all standard library math. I'll probably take another look at it in a 
>> month. That is definitely the right direction to go for now.
>>
>> On Monday, June 20, 2016 at 7:09:57 PM UTC+1, Stefan Karpinski wrote:
>>>
>>> I think it might actually be easier for BigFloat since BigFloats are 
>>> fixed-size, whereas BigInts are variable-size.
>>>
>>> Chris, there is a DoubleDouble package 
>>> <https://github.com/simonbyrne/DoubleDouble.jl>, which implements 
>>> efficient higher-precision floating-point arithmetic, albeit not IEEE 
>>> 128-bit floats. As soon as hardware and LLVM support 128-bit IEEE floats, 
>>> Julia can easily support them as well – as I'm sure you realize, much more 
>>> easily than any other system.
>>>
>>> Nobody wants BigFloats to be inefficient; the current state of the 
>>> compiler's ability to reuse them and eliminate allocations simply isn't as 
>>> good as it could potentially be. That doesn't mean that this won't be 
>>> improved in the future – it will be, although it's hard to say when since 
>>> there are a lot of competing priorities and a limited number of people who 
>>> can do the kind of compiler work necessary to improve this situation. 
>>> Fortunately, the problem is closely related to a number of other 
>>> performance issues that we also need to address (strings, array views).
>>>
>>
>

Reply via email to