https://yuri.is/not-julia/ I saw this on Bluesky today. " In my experience, Julia and its packages have the highest rate of serious correctness bugs of any programming system I’ve used, and I started programming with Visual Basic 6 in the mid-2000s. It might be useful to give some concrete examples. Here are some correctness issues I filed: Sampling a probability density produces an incorrect result Sampling an array can produce biased results The product function can produce incorrect results for 8-bit, 16-bit, and 32-bit integers Fitting a histogram to a Float64 array can produce incorrect results Base functions sum!, prod!, any!, and all! may silently return incorrect results"

It seems all of them are closed (presumably fixed) except the last one. Good job Julia community!

[image] Discussion on "Why I no longer recommend Julia" by Yuri Vishnevsky Community Hey folks! There was a pretty good critical article written about Julia recently called “Why I no longer recommend Julia” by Yuri Vishnevsky There is an ongoing discussion about the article that has largely been constructive on Slack. Hoping to capture some of these thoughts here to provide actionable points for the community. Feel free to comment or continue streams of thought here about the article and what actions could be done next. Thanks and remember: this is meant to be a cordial and… Please, not again :crying_cat_face:

It’s fascinating how people circulate the same posts and arguments for years. Find any Linux-related discussion on the Internet and observe how many people are complaining about bugs or configuration problems that were fixed over 10 years ago. It only shows that they haven’t actually used the thing to see the progress.

It has been discussed many times, though re-reading the blog reminds me that Elon Musk used to post more sensible stuff on Twitter.

I went ahead and looked at the blog post for opened issue links and vast majority of them finished/closed. A couple stays open pending some finish up work and a couple is pending for design decision(I think). A couple is real issue. Great work Julia community!

Let’s not be too hard on someone for missing an old discussion. Also put quotes in quote blocks (leading > for formatting) like this and this so people don’t mistake the blog’s text for your own. The " starting and ending a quote are easily missed, and the custom for quoting multiple paragraphs is to write a leading " for each paragraph.

[image] kristoffer.carlsson: It seems all of them are closed (presumably fixed) except the last one. Good job Julia community! Right (though that last one a bit of a tough one), also he reported more, e.g.: Incorrect results from floating-point division (`fld`, `cld`, `div`) opened 12:38AM - 21 Apr 23 UTC (UTC) [yurivish] yurivish bug maths float16 correctness bug ⚠ Julia has a [`div`](https://docs.julialang.org/en/v1/base/math/#Base.div) functi…on that is used to implement [floor division](https://docs.julialang.org/en/v1/base/math/#Base.fld) (`fld`) and [ceil division](https://docs.julialang.org/en/v1/base/math/#Base.cld) (`cld`). I think I’ve found a bug that causes all of these division functions to return incorrect results. Floor division is documented to return the largest integer less than or equal to `x / y`. It should never return a number that is *greater* than `x / y`. But it does: ```julia julia> 514 / Float16(0.75) Float16(685.5) julia> div(514, Float16(0.75)) # should round down, but rounds up instead Float16(686.0) julia> fld(514, Float16(0.75)) # likewise Float16(686.0) julia> fld(514, Float16(0.75)) ≤ 514 / Float16(0.75) false ``` Similarly, ceil division should never return a number that is *smaller* than regular division, but it does: ```julia julia> 515 / Float16(0.75) Float16(686.5) julia> cld(515, Float16(0.75)) # should round up, but rounds down instead Float16(686.0) julia> cld(515, Float16(0.75)) ≥ 515 / Float16(0.75) false ``` This behavior is not limited to 16-bit floats. Here’s a case where `fld` produces an incorrect result for `Float32` inputs: ```julia julia> 4_194_307 / Float32(0.75) # = 5592409.5 5.5924095f6 julia> fld(4_194_307, Float32(0.75)) # = 5592410, incorrectly rounded up 5.59241f6 julia> fld(4_194_307, Float32(0.75)) ≤ 4_194_307 / Float32(0.75) false ``` And here’s the same for `cld`: ```julia julia> 4_194_308 / Float32(0.75) # = 5592410.5 julia> cld(4_194_308, Float32(0.75)) # = 5592410, incorrectly rounded down 5.59241f6 julia> cld(4_194_308, Float32(0.75)) ≥ 4_194_308 / Float32(0.75) false ``` The equivalent operations in Python produce the correct results: ```python # For 16-bit floats: >>> np.float16(514) / np.float16(0.75) # regular division 685.5 >>> np.float16(514) // np.float16(0.75) # floor division 685.0 # For 32-bit floats: >>> np.float32(4_194_307) / np.float32(0.75) # regular division 5592409.5 >>> np.float32(4_194_307) // np.float32(0.75) # floor division 5592409.0 ``` Examples of this incorrect behavior are not hard to find – for most floats, you can find a divisor that will make either `fld` or `cld` return the wrong answer. Here are some examples for `Float16` where either `fld` or `cld` is incorrect: - `cld(1, Float16(0.000999)) 5 / Float16(0.004925)` And here are some for `Float32`: - `fld(5, Float32(6.556511e-7)) > 5 / Float32(6.556511e-7)` - `fld(10, Float32(1.3113022e-6)) > 10 / Float32(1.3113022e-6)` - `fld(11, Float32(1.4305115e-6)) > 11 / Float32(1.4305115e-6)` - `cld(16, Float32(2.8014183e-6)) < 16 / Float32(2.8014183e-6)` - `cld(17, Float32(2.2053719e-6)) < 17 / Float32(2.2053719e-6)` For simplicity I’ve presented examples where the first argument is an integer; this bug also occurs for non-integral inputs. A divisor producing the wrong result can be found for over 51% of all possible 16-bit floats. I have not evaluated how widespread this is for `Float32`, but the results above suggest that it is similarly easy to find failures there too. I’ve tracked the invocations down to [this definition](https://github.com/JuliaLang/julia/blob/72aec423c2ab9f80c249d63fdd68b35833cfd7ed/base/div.jl#L370) of `div`, which has existed at least as far back as [Julia 1.6](https://github.com/JuliaLang/julia/blob/f9720dc2ebd6cd9e3086365f281e62506444ef37/base/div.jl#L279): ```julia div(x::T, y::T, r::RoundingMode) where {T<:AbstractFloat} = convert(T, round((x - rem(x, y, r)) / y)) ``` Most recent update in August. [image] Checked vs unchecked, e.g. (floored) divison Performance The advantage of mapping ÷ to fld is that then % needs to be mod, which is not so uncommon to use with a negative first argument. Both rem and mod give you a useful cyclic behavior for positive numbers. If you go past zero mod keeps being cyclic, whereas rem makes a sign shift and goes over to a cycle with negative numbers. I’m sure there’s some context where rem is useful with negative first argument, but I’m yet to find it. In my experience mod is always the operator you want and if you carel… I’m not generally enthusiastic about Python but this is something they got right, and Julia (and many other languages) sadly didn’t. Julia does (or well tries) to do same as C and C++. It’s not clear to me Python’s way is better, either definition works, assuming people know which is used. Also a (minor? i.e. not correctness, only stackoverflow) bug was fixed in OrderedCollections.jl, and the PR fix, approved in Feb 2021, got forgotten for 4 years, and I reported it some months before that with Bug in OrderedDict (unlike in LittleDict, and Dict) · Issue #65 · JuliaCollections/OrderedCollections.jl · GitHub

Most of them were already fixed when the post was published.

Correctness bugs

Offtopic

barucden November 20, 2024, 3:30pm 3

Please, not again

Topic		Replies	Views
Division by zero runs without warning -> complicates finding bugs Internals & Design question	31	3879	May 17, 2024
Did Julia community do something to improve its correctness? General Usage	216	16686	November 4, 2023
Correctness and Multiple Dispatch (Help explain to a julia noob) Community question	13	1360	April 30, 2025
Is Julia reliable for solving ordinary and stochastic differential equations? General Usage	12	2843	May 10, 2023
Julia stability vs Rust for Scientific Computing Optimization (Mathematical) question	43	4364	August 10, 2026

Correctness bugs

Related topics