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

Reply via email to