Where did `conv` move to?

New to Julia
1

Hello there!

I finally have a reason to try out Julia. In this case: Testing some things related to digital signal processing.

A lot of documentation still refers to Julia 0.7 and similar versions. I was able to find out that fft, ifft, fftshift and the likes have been moved to the FFTW package.

What I have not been able to find, is where conv has been moved to. Where can the basic convolution operation be found?

1 Like
2

Run this in version 0.7:

a = rand(5);
b = rand(5);
conv(a,b)
ERROR: conv has been moved to the package DSP.jl.
Run `Pkg.add("DSP")` to install it, restart Julia,
and then run `using DSP` to load it.
Stacktrace:
 [1] error(::String) at .\error.jl:33
 [2] #conv#1(::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Function, ::Array{Float64,1}, ::Vararg{Array{Float64,1},N} where N) at .\deprecated.jl:150
 [3] conv(::Array{Float64,1}, ::Vararg{Array{Float64,1},N} where N) at .\deprecated.jl:150
 [4] top-level scope at none:0
1 Like
3

Then, you should do this:

(v1.0) pkg> add DSP

julia> using DSP

julia> a = rand(5);

julia> b = rand(5);

julia> conv(a,b)
9-element Array{Float64,1}:
 0.07552600153597361
 0.4454504761457533
 0.6820694306648747
 0.7491095589719305
 0.9602973792793014
 0.8087609222730767
 0.5679246434318976
 0.35446312174823513
 0.1102057752110403
4

Thank you for your reply, @Seif_Shebl!

As a beginner moving from MatLab to Julia, it seems very odd that I have to, alongside the stable version, install the old version 0.7, just to be able to find out how to find common functionality.

What would be the best place to ask for an improvement to Julia’s docs and ‘could not find function’ REPL response?

5

The awkwardness of needing to keep 0.7 around is temporary: it’s a result of the large body of outdated documentation, forum posts, etc. that predate update to julia 1.0. That situation will naturally improve over time, as the probability of your favorite search engine finding the right julia 1.0 syntax increases.

Note that, even now, the answer to your original question is on the first page of Google results for “julia conv” (at least for me), so things are already improving.

4 Likes
6

Make a pull request! Seriously, contributions to documentation are always welcome and there are many people here who would be happy to help.

1 Like
7

That’s the whole point of 0.7, to provide an upgrade path from earlier versions.

I would very much argue that things like fft and conv are not common functionality in programming languages,

2 Likes
8

I do think it’s possible to make things more discoverable though. If some hero wanted to put together some kind of Julia search engine that periodically (nightly?) downloaded all the registered packages, indexed all their exported names and their docstrings (also from Base and stdlib), and made it searchable - that would be awesome. :slight_smile:

5 Likes
9

Although this probably wouldn’t have fully solved the issue of discovering conv, a more verbose name DigitalSignalProcessing.jl might have helped finding the package at least.

DSP.jl seems to break with the convention. (Why named DSP.jl rather than DigitalSignalProcessing.jl? ¡ Issue #249 ¡ JuliaDSP/DSP.jl ¡ GitHub)

1 Like
10

He’s not upgrading though.

3 Likes
11

Working with a code example that was written for an earlier version implicitly requires updating that code example to 1.0.

12

I briefly experimented with a SQLite-based doc search tool like that once (Search Julia documentation), and it looked reasonably practical.

1 Like
13

If only code examples and tutorials were annotated with the version of the language they were using. Unfortunately, this is frequently not the case. Take the RosettaCode page on the Fast Fourier Transformation(http://rosettacode.org/wiki/Fast_Fourier_transform#Julia), for example.

This would be great! Tools like this exist in other languages; most notably, Haskell’s Hoogle comes to mind.

But I already would be very happy if the ‘deprecation changes’ that are part in 0.7 were mentioned somewhere in the documentation. Results like Search · The Julia Language are not useful.

I am against the notion of having to rely on a general-purpose search engine to find something specific: Searching in a confined space is for obvious reasons preferable to searching the whole of the internet, and even better is not having to search at all.
I have seen this argument used in the past for instance to keep T_PAMAAYIM_NEUKODATYIM in PHP. Because ‘if a newcomer would not understand it, they should just searching for it’.

Currently, there do not seem to be any ways to search for Julia library functions, let alone packages. pkg.julialang. org is a long list, which cannot even be filtered by package name.Yes, you can currently use find-in-page in your browser, but that will cease working once there are twice as many packages and the list will have to be paginated.

Maybe Julia has had a shift in target audience, but I came here first and foremost looking for a replacement to MatLab/Octave. I would argue that things like fft and conv are common functionality in math/scientific-oriented programming languages.

Anyhow, I don’t want to derail this thread’s original topic.
Thank you for your responses! I will try to create at least an issue, and potentially a PR to add a ‘this is where things have moved’ page to the documentation (although I’ll need help, because it seems like an enormous undertaking to parse through all of 0.7’s deprecation warnings).

2 Likes
14

Yes, that would be great, but for small snippets it is unlikely to happen. But this problem is not specific to Julia: languages and libraries move on, and looking at the date of a comment or blog post can be helpful in deciding whether one should look for changes.

I am not sure compiling another list is needed — we have a NEWS.md for 0.7, and in any case as others have suggested the best way to get the warnings is just run 0.7.

15

In Engineering fields, e.g., acronyms is a widely accepted convention, a junior electrical engineering student knows what DSP stands for before studying it. Imagine a ComputeUnifiedDeviceArchitectureNative.jl package vs. CUDAnative.jl, do you think the former is still better? If I wrote ODEs.jl, will scientists be unable to recognize what this is? These rules should be wisely followed, or we will end up with a new Java. I just hate it when programmers think of users as blind robots who can make every mistake in the book, brevity still matters. The exception of course would be the weird names that scientists and engineers wouldn’t recognize. I mean, yes Julia is a general purpose language, but if one doesn’t know what DSP means, then DSP.jl is not for them and they shouldn’t care.

4 Likes
16

I see your point, thanks for presenting it.

DSP.jl contains conv which I assume isn’t just for engineers. I’m a theoretical physicist and looked for fftfreq at some point to conveniently get the frequencies of a FFT.

Regarding ODEs, there is (verbose) DifferentialEquations.jl as a metapackage, which everyone would find.

Anyways, as there don’t seem to be many complaints, I assume you are right and most people that use the package know what DSP stands for.

17

That’s an awesome start! I also like the minimalist aesthetic. Is there a Julia package that does the indexing?

18

This uses the JavaScript search_index.js files that a number of Documenter sets have. I was just curious as to whether loading an SQLite database on a server on the other side of the world would be as quick as JavaScript in the browser… :grinning:

It would make a good GSoC project, perhaps, but needs server access and knowledge.

19

Hi there !

Below is all very helpful advice and Julia is a great community to get help.

So I don’t know if the helpful search engine now at https://pkg.julialang.org/ was available when you were asking, but searching for keyword conv there returns this helpful info now >> https://pkg.julialang.org/docs/search?q=conv

HTH future Julia users.

2 Likes