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