# Did Julia community do something to improve its correctness?

**URL:** <https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515>\
**Category:** General Usage\
**Created:** [August 5, 2023, 7:16am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515 "2023-08-05T07:16:42Z")\
**Posts on this page:** 20\
**Page:** 5

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [August 14, 2023, 12:18pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/126 "2023-08-14T12:18:21Z")

</div>

(Edited) It was fixed after beta1. Still tagged for backporting. It’s been merged into [Backports for julia v1.10.0-beta2 by KristofferC · Pull Request #50708 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/50708) so it should be in beta2.

---

<div class="post-metadata">

**Author:** ![stucash](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stucash/32/202683_2.png) [@stucash](https://discourse.julialang.org/u/stucash)\
**Post date:** [October 23, 2023, 2:44pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/127 "2023-10-23T14:44:41Z")

</div>

Recently I’ve got a project that’s big enough for a deployment and also fairly technical, I was torn between Rust (Rust isn’t built for technical computing but the ecosystem is catching up fast and other advantages provided by Rust are almost too good) and Julia (I always wanted to try Julia for some real work in science computing, whereas I’ve been using R mainly and MATLAB several years back); but my attempt to do some work in Julia has come to a halt mainly because of Yuri’s blogpost. I’ve followed the [Reddit’s discussion](https://www.reddit.com/r/Julia/comments/uqwd2h/why_i_no_longer_recommend_julia/) on Yuris’ post, and [an earlier Julia community discussion](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151) on the same post.

There are, by now, a good number of opinions exchanged between both sides, with regards to the correctness issue raisd by Yuri in all 3 discussions. But I would really appreciate a formal address from Julia Dev Team on the correctness issue in Julia, regardless that the team agree or disagree (Or probably there is one already, please kindly point me to it).

Some argued that we should let Julia mature and these types of bugs were so common that many languages suffered before and time would cure all. Opponent disagreed with examples of R and Matlab Core. The Core R and Matlab really has been robust for very long (abundant evidence from all 3 discussions and other places). CRAN (R official package management), is too pedantic (almost notoriously) such that the majority of graduate students would not even consider publishing packages.

Some said that it is the third party packages from researchers and graduate students who were being a bit careless when it comes to programming (rather than solving math problems using computer language). Yuri however brought attention to Base Julia near the very top of the post and they were raised in Julia 1.7 ish back in 2021 or 2020 (e.g., `prod` function from `Base`, raised in Jan 2021, Yuri’s post was written at least before May 2022). It’s the number of correctness issues Yuri found and the likelihood of similar issues still pertaining in Core Julia that worried Yuri, in the first place at least. I believe OP was worried much, henceforth asking about new measures for correctness being employed or not. This is the very thing I’d hope the team would address as well, as a potential Julia user.

Others mentioned testing suites available to users such as `Aqua.jl` or `JET.jl`; I am not sure I, as an user, ought to write unit test on Base Julia functions as singular as `prod`, or to set up tests only to **almost frequently** find out that it was the Base Julia I’d have to fix.

While most critical posts of Julia from Google were merely complaints about user experience and how hard they’d have to depart from old habits built in other languages, Yuri’s post, on the other hand, constructed valid points on one of the main objectives of a technical computing language IMHO; that is to be correct in computation result.

I like Julia since it came out (I’ve been playing around in bitesize since 0.8 but I’ve not really used Julia for anything); I appreciate and support Julia’s ambitions, be it to solve “two-language problem” or to offer syntax similar to MATLAB with performance almost on par with C/C++; and yeah, multiple dispatch as well. Hand on heart I’d reall hope Julia to thrive and be the future of technical computing.

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [October 23, 2023, 3:04pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/128 "2023-10-23T15:04:05Z")

</div>

while it’s hard to quantify for sure, but I figure someone could write a Yuri style blog by picking oldest things out of: [https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AI-unsound](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AI-unsound)

the fact there are bug reports is a good thing because it means people are using it. But if you look at Rust or Julia’s list of “correctness” bugs, some are very-edge case, some are arguably correct just surprising. I think Julia itself is not more buggy than any major programming language kind project.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [October 23, 2023, 3:05pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/129 "2023-10-23T15:05:15Z")

</div>

> [@stucash](#):
>
> But I would really appreciate a formal address from Julia Dev Team on the correctness issue in Julia, regardless that the team agree or disagree (Or probably there is one already, please kindly point me to it).

Could you define what you are looking for exactly?

1. Who is the “Julia Dev Team”?
2. What constitutes a “formal address”?

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [October 23, 2023, 3:28pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/130 "2023-10-23T15:28:27Z")

</div>

There’s not been a formal address from the project (it’s not really clear what such an address would look like), but many prominent contributors have indeed weighed in on the many discussions around these — in addition to the Reddit and prior discourse threads, see also the [Hacker News discussion](https://news.ycombinator.com/item?id=31396861) from when the post was first published.

I see the hardest issues in Yuri’s post being symptomatic of — as Stefan writes in the HN thread — “the flip side of Julia’s composability is that composing generic code with types that implement abstractions can easily expose bugs when the caller and the callee don’t agree on exactly what the abstraction is.” And that’s where things get interesting. There’s some really cool work to formalize what those abstractions are (e.g., [[ANN] RequiredInterfaces.jl](https://discourse.julialang.org/t/ann-requiredinterfaces-jl/101296)). But as I myself previously said,

> [@Discussion on "Why I no longer recommend Julia" by Yuri Vishnevsky](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/81):
>
> I can easily imagine attempting to differentiate a distributed SVD of a BlockedArray filled with Unitful Quaternions. Sure, that’s an absurd example and it’s unlikely to work, but I can imagine how it _might_ work and may even be able to construct the problem statement in a few lines of code. And heck, if I’m intrepid, I think I _could_ make it work.

Yuri really pushed on the ecosystem — and indeed most of the issues he listed are about the composability of packages. As someone who sporadically interfaced with him on-and-off in issues like these, I earnestly thought he _enjoyed_ living on the cutting edge and slaying these dragons. That’s really the biggest loss in my view: that he burned out doing so and we lost his voice and work from the community.

So: Are there still dragons out there? Most definitely — especially if you find yourself bushwhacking through the weeds of packages nobody has tried together before. But it’s continuing to be easier and easier to stay on golden brick roads as Julia and its package ecosystem continue to develop and thrive.

---

<div class="post-metadata">

**Author:** ![stucash](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stucash/32/202683_2.png) [@stucash](https://discourse.julialang.org/u/stucash)\
**Post date:** [October 23, 2023, 3:32pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/131 "2023-10-23T15:32:03Z")

</div>

1. I am not sure who’d be the Julia Dev Team in this case; off the top of my head it probably could be someone, or some group who has had a focus on the development in relevant areas, who can taken ownship? Or probably from the authors/founders of Julia? I understand contributors to Julia Core have participated into the discussions of Yuri’s post.

2. But isn’t this “community” discussion? community discussion for me surely isn’t formal. By “formal” I guess I’m inclined to imply that I can be certain there is/isn’t future effort or internal discussion from some contributors/subgroups who own the relevant areas (I may well have missed them and I’d appreciate if you could point me to them). As mentioned by @mschauer, this thread has come to an awkward end. What do we know for sure that can answer OP’s question, out of this thread? Probably the contributors who’ve participated and cared before, could come up with some agreed response to the community?

---

<div class="post-metadata">

**Author:** ![stucash](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stucash/32/202683_2.png) [@stucash](https://discourse.julialang.org/u/stucash)\
**Post date:** [October 23, 2023, 3:52pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/132 "2023-10-23T15:52:17Z")

</div>

yep may well be; Yuri brought our attention to correctness and I agree that a good number of them were edge cases; there were not so edgy cases as well that’s what worries him I guess. I admit that I probably fret too much having reading Yuri’s post given how much I’d want to use Julia in the new project; it is the very intention that I wanted to try Julia that stopped me here when correctness has very high stake in a project. Yuri’s experience together with other public accounts, have really done a good job in validating their point.

---

<div class="post-metadata">

**Author:** ![adienes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adienes/32/37459_2.png) [@adienes](https://discourse.julialang.org/u/adienes)\
**Post date:** [October 23, 2023, 3:55pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/133 "2023-10-23T15:55:08Z")

</div>

I recommend you give Julia an earnest try for yourself 🙂

---

<div class="post-metadata">

**Author:** ![stucash](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stucash/32/202683_2.png) [@stucash](https://discourse.julialang.org/u/stucash)\
**Post date:** [October 23, 2023, 4:25pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/134 "2023-10-23T16:25:51Z")

</div>

good points were made in this reply; not being a release blocker doesn’t mean we couldn’t add some documentation to avoid the issue, let alone the issue has been flying since 1.5.3; what’s it not to add some minimal documentation for an issue existed for 2.5 years? It’s swamped in the Jiras I guess and never had a high enough priority.

[this](https://github.com/JuliaLang/julia/issues/39385#issuecomment-1668400231) is actually one issue raised by Yuri and it is one that’s not edgy. It was planned for 1.10 but removed because team has higher priorities (which is fair); but I probably wouldn’t call this issue “random stuff”.

Or it could be random given what’s ahead for Julia is really some game changer stuff and the team is really committed to get it out on time. I know how much pressure there is. It’s just that please give correctness issue some priority (25 labeled correctness issues, and 2 of them were in 1.10, which were removed thereafter).

> [@algunion](#):
>
> It seems that the issue has been open since January '21 - and the behavior was observed even in 1.5.3.
> 
> I wouldn’t expect the issue suddenly becoming a release-blocking issue.
> 
> However, some low-hanging fruits are more worrying: I understand the bug fix not being a release-blocking priority, but why not add the minimal documentation to help people avoid the issue in the meantime?
> 
> On the same note - it has been known for a while that `@async` is to be avoided in favor of `@spawn` to the extent that we have a clear warning against using `@async`: however, the new users reading the manual are clearly presented with [learning material that goes against the documentation](https://docs.julialang.org/en/v1/base/parallel/#Channels).
> 
> These easy-to-achieve goals that seem to reflect caring about new users are things that get me worried: the experienced users can get along and just avoid these traps (having access to a kind of special lore or simply being familiar to a larger extent with the up-to-date documentation), while new Julia users (who are primarily reading the manual before going into more depth) are actually taught to use the language in the _wrong_ way.

---

<div class="post-metadata">

**Author:** ![gdalle](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gdalle/32/224680_2.png) [@gdalle](https://discourse.julialang.org/u/gdalle)\
**Post date:** [October 23, 2023, 4:42pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/135 "2023-10-23T16:42:21Z")

</div>

> [@stucash](#):
>
> I am not sure who’d be the Julia Dev Team in this case

This blog post is a good recap:

> **[The Julia Project and Its Entities](https://julialang.org/blog/2019/02/julia-entities/)**
>
> The Julia Project and Its Entities | There are a number of entities surrounding the Julia programming language. Understandably, many people are not entirely clear on what these groups are and what their relationship to each other is. It’s pretty hard...

> The most clear cut line that can be drawn is that there is a set of people who have commit access to the [JuliaLang](https://github.com/JuliaLang) GitHub organization: there are currently 67 committers (36 active and 31 dormant). This set of people doesn’t really define the project, however, since there are many people who are prolific contributors to the Julia ecosystem but who do not have “commit bit.” The communal nature of open source makes it difficult to precisely define where the Julia project ends and the greater community begins, which is exactly how we like it.

---

<div class="post-metadata">

**Author:** ![algunion](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/algunion/32/51630_2.png) [@algunion](https://discourse.julialang.org/u/algunion)\
**Post date:** [October 23, 2023, 4:47pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/136 "2023-10-23T16:47:00Z")

</div>

@stucash, I made my peace with these kinds of issues. One can argue that many more issues are still more urgent than this - so the limited (human) resources are invested as seen fit by those who put in the time.

My experience is this:

- as somebody who comes from F#, I find myself in need of writing 80-90% more tests. The thumb rule is to test everything. However, I never encountered - in real life - any correctness issues.
- Julia is transparent enough so you can inspect almost everything you use (if that code is too weird, it is almost guaranteed that somebody here will happily answer any questions).
- Julia community is a superpower: you have actual experts who will give you their time for free (and sometimes more than one of them will compete to ensure you are getting either the most accurate answer or the most accessible answer).

Yes - we can be (still) justified to complain about all kinds of stuff. But I feel that all those _cons_ are redeemed by the excellent mix of _power_ and helpful community.

Enjoy!

---

<div class="post-metadata">

**Author:** ![mihalybaci](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mihalybaci/32/13528_2.png) [@mihalybaci](https://discourse.julialang.org/u/mihalybaci)\
**Post date:** [October 23, 2023, 5:01pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/137 "2023-10-23T17:01:15Z")

</div>

Is that really a correctness bug though? From my point of view, a correctness bug would be: Use a Julia function correctly, but get the wrong answer. Issue #39385 uses `sum!` _incorrectly_ and gets an incorrect answer.

```julia
help?> sum!
search: sum! cumsum! sum summary cumsum isnumeric VersionNumber issubnormal get_zero_subnormals set_zero_subnormals

  sum!(r, A)

  Sum elements of A over the singleton dimensions of r, and write results to r.

```

To me, its clear that I’m supposed to pass two different objects, not the same one twice. So claiming that Julia “produces incorrect results” for `sum!` seems odd.

But the larger point is, if you care about getting **mathematically correct** answers, then Julia is perfectly fine, and not really and different than any other language.

---

<div class="post-metadata">

**Author:** ![adienes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adienes/32/37459_2.png) [@adienes](https://discourse.julialang.org/u/adienes)\
**Post date:** [October 23, 2023, 5:03pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/138 "2023-10-23T17:03:45Z")

</div>

> Issue #39385 uses `sum!` _incorrectly_

I don’t think this is a fair statement given that there is no warning in the docstring to the contrary

> To me, its clear that I’m supposed to pass two different objects

that is not clear to me. after all, I think the “naive” implementation of `sum!` would probably work correctly here

---

<div class="post-metadata">

**Author:** ![mihalybaci](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mihalybaci/32/13528_2.png) [@mihalybaci](https://discourse.julialang.org/u/mihalybaci)\
**Post date:** [October 23, 2023, 5:14pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/139 "2023-10-23T17:14:08Z")

</div>

When I look at the docstring `sum elements of A` and `write to r`, to me implies that `A` and `r` are different things. Otherwise, for writing to the same location, I would expect `sum elements of A` and `write to A`. But the fact that this is ambiguous should mean that updating the docs is a good idea.

I am more questioning the idea of what “correctness bug” and “correctness issue” truly mean because that itself is ambiguous to me.

---

<div class="post-metadata">

**Author:** ![gdalle](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gdalle/32/224680_2.png) [@gdalle](https://discourse.julialang.org/u/gdalle)\
**Post date:** [October 23, 2023, 5:22pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/140 "2023-10-23T17:22:14Z")

</div>

> [@adienes](#):
>
> I don’t think this is a fair statement given that there is no warning in the docstring to the contrary

I have been trying hard to add warnings to the docs, but the PR has stalled. Help appreciated

> <https://github.com/JuliaLang/julia/pull/50824>
>
> Functions like \`sum!(B, A)\` have undefined behavior when \`A\` and \`B\` share memor…y. We might fix that in the long run, but in the short run, doc warnings are better than nothing.
> 
> Related issues:
> 
> \- #39385
> \- #50814
> 
> See also: https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/
> 
> \- \[x\] \`accumulate!\`
> \- \[x\] \`all!\`
> \- \[x\] \`any!\`
> \- \[\] \`append!\` (unsure)
> \- \[x\] \`asyncmap!\`
> \- \[\] \`broadcast!\`
> \- \[x\] \`circcopy!\`
> \- \[x\] \`circshift!\`
> \- \[\] \`clamp!\`
> \- \[\] \`conj!\`
> \- \[\] \`copy!\`
> \- \[x\] \`copyto!\`
> \- \[x\] \`count!\`
> \- \[x\] \`cumprod!\`
> \- \[x\] \`cumsum!\`
> \- \[\] \`delete!\`
> \- \[\] \`deleteat!\`
> \- \[\] \`digits!\`
> \- \[\] \`empty!\`
> \- \[x\] \`extrema!\`
> \- \[\] \`fill!\`
> \- \[\] \`filter!\`
> \- \[x\] \`findmax!\`
> \- \[x\] \`findmin!\`
> \- \[\] \`get!\`
> \- \[\] \`hex2bytes!\`
> \- \[\] \`insert!\`
> \- \[x\] \`intersect!\`
> \- \[x\] \`invpermute!\`
> \- \[x\] \`keepat!\`
> \- \[x\] \`kron!\`
> \- \[x\] \`map!\`
> \- \[x\] \`maximum!\`
> \- \[\] \`merge!\` (unsure)
> \- \[\] \`mergewith!\` (unsure)
> \- \[x\] \`minimum!\`
> \- \[\] \`modifyproperty!\`
> \- \[\] \`partialsort!\`
> \- \[x\] \`partialsortperm!\`
> \- \[x\] \`permute!\`
> \- \[\] \`permutedims!\`
> \- \[\] \`pop!\`
> \- \[\] \`popat!\`
> \- \[\] \`popfirst!\`
> \- \[\] \`prepend!\` (unsure)
> \- \[x\] \`prod!\`
> \- \[\] \`push!\`
> \- \[\] \`pushfirst!\`
> \- \[\] \`put!\`
> \- \[\] \`read!\`
> \- \[\] \`readbytes!\`
> \- \[\] \`replace!\`
> \- \[\] \`replaceproperty!\`
> \- \[\] \`resize!\`
> \- \[\] \`reverse!\`
> \- \[x\] \`setdiff!\`
> \- \[x\] \`setindex!\`
> \- \[\] \`setproperty!\`
> \- \[\] \`sizehint!\`
> \- \[\] \`sort!\`
> \- \[x\] \`sortperm!\`
> \- \[x\] \`splice!\`
> \- \[x\] \`sum!\`
> \- \[\] \`swapproperty!\`
> \- \[x\] \`symdiff!\`
> \- \[\] \`take!\`
> \- \[x\] \`union!\`
> \- \[\] \`unique!\`
> \- \[x\] \`unsafe\_copyto!\`
> \- \[\] \`unsafe\_store!\`

---

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [October 23, 2023, 5:23pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/141 "2023-10-23T17:23:44Z")

</div>

> [@adienes](#):
>
> that is not clear to me. after all, I think the “naive” implementation of `sum!` would probably work correctly here

Yes, of course:

```julia-repl
julia> function sum!(a,b)
           for i in eachindex(a,b)
               a[i] = a[i] + b[i]
           end
           return a
       end
sum! (generic function with 1 method)

julia> x = [1,2,3];

julia> sum!(x,x)
3-element Vector{Int64}:
 2
 4
 6

```

At the same time, I also think that the importance of such an issue is overrated. Anyone really uses a mutating function like that without checking the result?

Important libraries like numpy and other are full of gotchas, and while I think that bug should be fixed in a good way (not only by documentation), I find hardly believable that someone writing some complex math and working out performance tuning (to arrive at trying to use this) would have a program with a hidden bug like that.

By the way, can someone explain this?

```python
In [1]: import numpy as np

In [2]: a = np.array([1,2,3])

In [3]: sum(a,a)
Out[3]: array([7, 8, 9])

```

Seems that `sum` is not intended to sum two arrays (one thing is the array being summed, the other I didn’t understand from the documentation. Fair enough, but I think it makes my point: I do not trust my intuition about what a function should do… not here, not with any other language.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [October 23, 2023, 7:11pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/142 "2023-10-23T19:11:35Z")

</div>

Split this topic on October 23, 2023, 7:11pm UTC

2 posts were split to a new topic: [Strange behaviors in python and numpy](https://discourse.julialang.org/t/strange-behaviors-in-python-and-numpy/105325)

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [October 23, 2023, 6:26pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/143 "2023-10-23T18:26:22Z")

</div>

In the case of `sum!` the problem is that Julia initializes the result array before doing anything.

```julia
julia> x = [1,2,3];

julia> sum!(x,x; init=false)
3-element Vector{Int64}:
 2
 4
 6

```

The aliasing warning is noted in the documentation in development: [`sum!`](https://docs.julialang.org/en/v1.11-dev/base/collections/#Base.sum).

```julia
help?> sum!
search: sum! cumsum! sum summary cumsum isnumeric VersionNumber issubnormal

  sum!(r, A)

  Sum elements of A over the singleton dimensions of r, and write results to
  r. Note that since the sum! function is intended to operate without making
  any allocations, the target should not alias with the source.

```

---

<div class="post-metadata">

**Author:** ![ToucheSir](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/touchesir/32/14411_2.png) [@ToucheSir](https://discourse.julialang.org/u/ToucheSir)\
**Post date:** [October 23, 2023, 7:14pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/144 "2023-10-23T19:14:53Z")

</div>

FWIW, Numpy handles the aliasing without any apparent issue:

```python
>>> import numpy as np
>>> a = np.array([1, 2, 3])
>>> np.sum(a.reshape((-1, 1)), axis=1, out=a)
array([1, 2, 3])
>>> a
array([1, 2, 3])
>>> np.prod(a.reshape((-1, 1)), axis=1, out=a)
array([1, 2, 3])
>>> a
array([1, 2, 3])

```

> [@mkitti](#):
>
> The aliasing warning is noted in the documentation in development: [`sum!`](https://docs.julialang.org/en/v1.11-dev/base/collections/#Base.sum).

But notably, neither the `init` keyword or what it does in `sum!` are to be found anywhere in that same docstring. I don’t think I’m alone in only learning of its existence in mutating `sum!`/`prod!` today.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [October 23, 2023, 7:20pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/145 "2023-10-23T19:20:28Z")

</div>

Last I looked into it, using numpy’s `out` argument doesn’t actually avoid allocations in the manner we’re trying to support here. Indeed, the goal of avoiding allocations doesn’t really make much sense when you’re using a predominantly “vectorized” API.

In any case, this isn’t a competition nor is it a zero-sum game. Some comparisons can indeed be helpful, but let’s not overdo it and pile-on here.

[Previous page](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515.md?page=4)

[Next page](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515.md?page=6)