I am not going to comment on the implementation issues because it's outside 
of my expertise and I will have nothing of substance to contribute.

But as a user, I do find it troubling that the only reliable high-precision 
number type is clearly not aiming for performance. It seems that what would 
trouble most users about this is that it looks like a higher-performing 
implementation (which looks functional? Is there a small and reasonable 
code snippet to show how to break it?) was pushed a side by a (somehow in a 
way I don't really understand) safer version. 

The larger looming issue is that bigs probably shouldn't be the go-to for 
arbitrary precision arithmetic anyways. Since Julia's type system lets 
someone use any number type which is well enough defined, the answer is 
probably to make a high-performing number type in a package. But if that's 
the case, the aim probably wouldn't be Bigs in the first place, rather 
something like Float128. It is sad that Julia makes it so easy to use 
whatever number type you wish, and so I know my differential equation 
package already works within the user chosen type, and likely a bunch of 
optimization, calculus, etc. packages can, but there really isn't anything 
to drop in except for Floats and Bigs (and Decimals?). This is probably 
best fixed over time by developing the package ecosystem, even if it is 
adding a "FastBig.jl". 

Reply via email to