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ł >>> >>> >> >