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