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