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