I was not aware of that, but it is good to know - thanks! By now we are actually mixing different precision on purpose here and there, using standard conversions, so our current test is to solve a number of problems to well below double precision accuracy.
On Wednesday, April 20, 2016 at 11:48:31 AM UTC+2, Paweł Biernat wrote: > > Thanks! I will try that. I might be wrong, but looking at the code of > mpfr.jl I can find some functions that mix BigFloat and Float64 that don't > rely on a convert, instead they just pass the arguments directly to the > mpfr library (this > <https://github.com/JuliaLang/julia/blob/master/base/mpfr.jl#L229> line > for example). I ended up writing a minimal implementation of an > AbstractNumber type, and so far it worked out pretty well. > > W dniu wtorek, 19 kwietnia 2016 15:17:31 UTC+2 użytkownik Daan Huybrechs > napisał: >> >> I second that - overwriting the conversion worked very well for me while >> debugging some time ago. If you throw an error, you get the exact line >> number where it happened: >> >> Base.convert(::Type{BigFloat}, x::Float64) = throw(InexactError()) >> >> One case to watch out for, which I only found in my code with the above >> trick, is the automatic conversion of builtin constants to Float64. For >> example, 2*pi is a Float64. To be safe in a mixed precision environment, if >> T is the numeric type you are working with, you could write 2*T(pi). >> >> On Tuesday, April 19, 2016 at 12:07:48 AM UTC+2, Greg Plowman wrote: >>> >>> Perhaps you could overwrite the convert function to include a warning. >>> (Maybe just temporarily until you discover all the conversions) >>> >>> As an example, this is a quick hack, modified from definition in mpfr.jl >>> >>> @eval begin >>> function Base.convert(::Type{BigFloat}, x::Float64) >>> println("*** Warning: converting Float64 to BigFloat") >>> z = BigFloat() >>> ccall(($(string(:mpfr_set_,:d)), :libmpfr), Int32, (Ptr{BigFloat >>> }, Float64, Int32), &z, x, Base.MPFR.ROUNDING_MODE[end]) >>> return z >>> end >>> end >>> >>> >>> julia> BigFloat(3.0) + 2.5 >>> *** Warning: converting Float64 to BigFloat >>> >>> 5.500000000000000000000000000000000000000000000000000000000000000000000000000000 >>> >>> >>> >>> >>> On Tuesday, April 19, 2016 at 1:50:52 AM UTC+10, Paweł Biernat wrote: >>> >>>> I know about the promotion, but this is precisely what I want to >>>> avoid. It might happen that there are hard-coded Float64 constants >>>> somewhere in the code and I would like to locate them and replace with >>>> higher precision ones. I could probably just do a direct search in the >>>> source code to locate these spots but I still might miss some of them. I >>>> guess it would be safer to just print a warning when an operations mixing >>>> both types occurs and then eliminate these spots case by case. >>>> >>>> Maybe defining my own AbstractFloat type with a minimal set of >>>> operations and passing it as an argument instead of BigFloat would be a >>>> better solution. Then if I don't implement the operations involving >>>> Float64 I will get an error every time the mixing occurs. >>>> >>>> W dniu poniedziałek, 18 kwietnia 2016 17:28:14 UTC+2 użytkownik Tomas >>>> Lycken napisał: >>>>> >>>>> Adding a BigFloat and a Float64 should automatically promote both to >>>>> BigFloats, avoiding precision loss for you. >>>>> >>>>> julia> BigFloat(2.9) + 0.3 >>>>> 3.199999999999999900079927783735911361873149871826171875000000000000000000000000 >>>>> >>>>> Do you have a case where this doesn’t happen? >>>>> >>>>> // T >>>>> >>>>> On Monday, April 18, 2016 at 4:32:52 PM UTC+2, Paweł Biernat wrote: >>>>> >>>>> Hi, >>>>>> >>>>>> I want to make sure I am not loosing any precision in my code by >>>>>> accidentally mixing BigFloat and Float64 (e.g. adding two numbers of >>>>>> different precision). I was thinking about replacing the definitions of >>>>>> `+`, `-`, etc. for BigFloat but if you do that for all two argument >>>>>> functions this would be a lot of redefining, so I started to wonder if >>>>>> there is a more clever approach. Is there any simple hack to get a >>>>>> warning >>>>>> if this happens? >>>>>> >>>>>> Best, >>>>>> Paweł >>>>>> >>>>>> >>>>> >>>>
