Not knowing the entire code, could it be that you are passing values > 255 to UInt8? And 'round' of e.g. 255.1 thus makes the error disappear?
julia> UInt8(255.0) 0xff julia> UInt8(255.1) ERROR: InexactError() in call at base.jl:36 julia> UInt8(-0.1) ERROR: InexactError() in call at base.jl:36 Regarding maintaining compatibility in your code for both 0.3 and 0.4, take a look at https://github.com/JuliaLang/Compat.jl - it allows to write your code for 0.4, and still have 0.3 be able to deal with it. Am 31.03.2015 um 14:30 schrieb J Luis <[email protected]>: > Hi, > > This piece of code (Win64, v0.4) > > add_off = 1; > range = 254. / (G.hdr[6] - G.hdr[5]) > img = zeros(UInt8, G.n_rows, G.n_columns) > for (k = 1:G.n_columns * G.n_rows) > img[k] = UInt8(((G.z[k] - G.hdr[5]) * range) + add_off) > end > > > errors with (just that) > > ERROR: InexactError() > > I cannot reproduce this in the REPL (actually I can but only in my local > build with MinGW). > However, during my several attempts to understand the problem I saw a > deprecation warning saying something like > using "convert(x::FloatingPoint, ...) is deprecated, use round(UInt8, x)" > and indeed if I replace the command in the loop by > > img[k] = round(UInt8, (((G.z[k] - G.hdr[5]) * range) + add_off)) > > than things work. So this is not exactly a deprecation but a compatibility > break. > > BTW, I really don't understand these deprecations (plus all other ints vs > Ints). They look contra-natura to me, are a pain if one tries to maintain 0.3 > compatibility and surely won't help the transition from other languages.
