Discussion on "Why I no longer recommend Julia" by Yuri Vishnevsky

Well, an AbstractArray axis is documented to be AbstractUnitRange{T} where T<:Integer, so that’ll need even more changes to AbstractArray code.

Right, this is not (currently) possible in Julia. I just wanted to show a contrived example of matrix multiplication. Yet, by the same logic you might give meaning to your example of multiplying a matrix with axes (0:3, 1:3) and (1:3, 2:3): The result should indeed by a matrix with axes (0:3, 2:3) as it would represent a linear map between spaces whos basis vectors are – for some reason – numbered from 0:3 and 2:3 respectively.

1 Like

An example:

A neural network in Julia can easily be written in a way that one can add layers with complex weights instead of real weights. This might even be a good idea, at least people are doing research on it.

But there is no “interface/protocol solution” possible which protects you from algorithmic failure: your training algorithm while valid for real weights might of course fail for complex weights (perhaps because complex activation function with bounded real part have necessarily singularities).

So: Either you disallow complex numbers, dual numbers, intervals or anything other than <:AbstractFloat for your inputs and weights – or you allow it, at the price of needing to answer the question of algorithmic correctness by understanding the algorithm and your inputs.

11 Likes

Yes, that would be the correct approach. Just needs someone to implement it. Until then we throw an error for matrix multiplication that is not 1-offset.

3 Likes

Not with *, but with packages all is possible:

using Random, Tullio, OffsetArrays
X = rand!(zeros(0:3, 1:3)); 
Y = rand!(zeros(1:3, 2:3));

@tullio Z[i,k] := X[i,j] * Y[j,k]  # 4×2 OffsetArray(::Matrix{Float64}, 0:3, 2:3)

all(Z[i,k] ≈ sum(X[i,j] * Y[j,k] for j in 1:3) for i in 0:3, k in 2:3)  # true

One approach is #270. This tries to avoid the ambiguities of adding yet more methods to *, by catching offsets further down the the pipe.

4 Likes

I tried reading the linked issue, but I’m not exactly sure what you meant by this. Is this referring to OffsetArrays being wrapped by any number of other types e.g. reinterpreting an OffsetArray? At least when I clicked through more links I ran across the text “I’m not too sure how to approach arbitrarily nested OffsetArrays wrt dispatch” and it seemed close.

It was also pointed out to me recently that a full OffsetArray isn’t even necessary for offset indices, a view (SubArray) indexed with a OffsetArrays.IdOffsetRange will have offset indices. I’m very curious how the type promotion and forwarding of indices would work, e.g. multiplying (0:3, 1:3) SubArray and (1:3, 2:3) ReinterpretArray{..., OffsetArray{...}, ...} to some (1:3, 2:3) matrix.

Right now, the intricacies of 1-based input types are seemingly ignored and an output Matrix is made; see the below example. It would make sense to make an OffsetMatrix if the inputs were found to have offset indices, but allocating 1 of 2 output types depending on a runtime check would make the methods type-unstable.

julia> x = ones(5, 5); view(x, 1:3, 1:2) * reinterpret(Int, view(x, 1:2, 1:4))
3×4 Matrix{Float64}:
 9.21436e18  9.21436e18  9.21436e18  9.21436e18
 9.21436e18  9.21436e18  9.21436e18  9.21436e18
 9.21436e18  9.21436e18  9.21436e18  9.21436e18

To make * work, it’s sufficient that mul! is called with C = similar(B, axes(A,1), axes(B,2)), and dispatch on that, which is what the PR (and its companion) does. But perhaps better discussed there.

1 Like

Perhaps we should close this never ending thread of discussion? The thread started in May and we are already in July. Many replies here are no longer related to the original post and I think people can discuss specific topics in new threads moving forward?

13 Likes

I fully agree with moving unrelated discussions to another thread, but I would suggest to keep this thread open. Closing threads about dissenting or challenging opinions about Julia could send a wrong message.

8 Likes

There will be users in the future who want to write about their experiences with this topic.
And if they can’t, Yuri will be right.
Yuri: “… but the net effect is that people’s legitimate experiences feel diminished or downplayed, and the deeper issues go unacknowledged and unaddressed.”

So please do not close.

7 Likes

Users are free to write whatever, it is not my proposal to stop that. It is just that many people have poor criteria when they decide to reply to a long thread like this. They are spamming tons of members of this forum with topics that are unrelated. We can always unfollow the thread, but that is not ideal. Anyways, that is what I will do now. If anyone wants to address any of my previous replies related to the original topic, please reach out directly over direct messages.

3 Likes

I have been using R for the past 20 years.

From time to time I am absolutely flabbergasted about the kind of bugs popping up in core R packages {stats}: [Rd] Bias in R’s random integers? in September 2018 for example:

[…]

I find this discussion fascinating. I normally test random numbers in different languages every now and again using various methods. One simple check that I do is to use Michal Zalewski’s method when he studied Strange Attractors and Initial TCP/IP Sequence Numbers:

Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later
Strange attractors and tcp/ip sequence number analysis | Semantic Scholar

The technique works by mapping the dynamics of the generated numbers into a three-dimensional phase space. This is then plotted in a graph so that you can visually see if something odd is going on.

I used runif(10000, min = 0, max = 65535) to get a set of numbers. This is the resulting plot that was generated from R’s numbers using this technique:

And for comparison this was generated by collecting the same number of samples from the bash shell:

The net result is that it shows some banding in the R generated random numbers where bash has uniform random numbers with no discernible pattern.

Best Regards,
-Steve

These fundamental bugs affect us all; in any programming language.

It took the R developers many years to reach a state that was considered mature.
:point_right: It won’t be any different for Julia.

11 Likes

What do you get when you run it in Julia?

5 Likes

What is the meaning of the coordinates in these plots?

1 Like

I started using R in about 1998 or so at a company that largely used cshell and SAS. Even back then R was plenty mature enough to do the basics of data processing cleaning and making plots it’s biggest problem at the time was memory management but of course it benefited hugely from the fact that it was based on s and splus which first began to be developed in the 1960s or early 70s if I remember correctly.

Julia has I think taken a lot of heritage from common lisp and so it does benefit quite a bit from having had certain things figured out before they even started writing it but of course a lot of Julia was developed de Novo.

I think Julia would probably benefit a lot from some kind of core correctness type test suite in the basic numerical data processing and statistics fields perhaps specifically including intentionally a number of tricky numerically unstable type problems it could benefit users a lot to know that known correctness issues that can arise in scientific computing are continuously monitored to ensure quality answers examples include your random number generator graph. For example if before every major release there were some large test suite of problems that utilized data frames and stats base and glm and differential equations and calculations of means and variances of various data sets with known floating point issues having something like that could really help drive confidence in correct ness of Julia packages

Sorry if there are run-on sentences there I was using Google dictation on my phone

4 Likes

After we can’t use Julia anymore, now Python can’t be used anymore. So I have to go back to R :frowning:

TL;DR; from the article:

After noticing an annoying warning, I went on an absurd yak shave, and discovered that because of a tiny handful of Python packages built with an appealing-sounding but dangerous compiler option, more than 2,500 Python packages—some with more than a million downloads per month—could end up causing any program that uses them to compute incorrect numerical results.

7 Likes

That has nothing to do with the Python language, though. We had to deal with a similar issue years ago, addressed by preventing packages built with BinaryBuilder from using -ffast-math and Co. Also, Simon Byrne posted write-up about the same topic last year:
https://simonbyrne.github.io/notes/fastmath/

6 Likes

I’m gonna go ahead and close this. Please feel free to start new topics for related discussions.

13 Likes