Julia 1.0 released


#42

Try to call fft in Julia 0.7 and it will tell you instantly where it moved to. That’s exactly what Julia 0.7 is for :wink:

Spoiler: Yes, the answer is the FFTW package.


#43

I am confused.

I had to Pkg.add("FFTW") and after that using FFTW threw an error:

julia> using FFTW
[ Info: Precompiling FFTW [7a1cc6ca-52ef-59f5-83cd-3a7055c09341]
ERROR: On worker 2:
ArgumentError: Package FFTW [7a1cc6ca-52ef-59f5-83cd-3a7055c09341] is required but does not seem to be installed:
 - Run `Pkg.instantiate()` to install all recorded dependencies.

Seems that I need to instantiate too.

I still had no time yet to spend more time with Julia 1.0 but I thought the stuff which was there before is now still there, and just needs to be “imported”. However, when I typed Pkg.add("FFTW") it installed a whole load of packages, including Sockets and Conda, Unicode etc. which seemed like it’s a regular installation. Is this the way now it works?
I thought it’s more like #include <math.h> and nothing has to be installed :wink:


#44

No, 0.7 is for package developers who need to upgrade their packages, and go through it for the convenience of depreciation warnings. No new user, and few old, would use 0.7. They will start directly with 1.0, naturally. How will they find fft?

FFTW isn’t in stdlib either, is it?


#45

I know it may be frustrating a bit, but here is how it worked with me:


(v1.0) pkg> add FFTW
  Updating registry at `C:\Users\Seif\.julia\registries\General`
  Updating git-repo `git://github.com/JuliaRegistries/General.git`
 Resolving package versions...
 Installed FillArrays ─ v0.2.0
  Updating `C:\Users\Seif\.julia\environments\v1.0\Project.toml`
  [7a1cc6ca] + FFTW v0.2.4
  Updating `C:\Users\Seif\.julia\environments\v1.0\Manifest.toml`
  [621f4979] + AbstractFFTs v0.3.2
  [7a1cc6ca] + FFTW v0.2.4
  [1a297f60] ↑ FillArrays v0.1.0 ⇒ v0.2.0

julia> using FFTW
[ Info: Precompiling FFTW [7a1cc6ca-52ef-59f5-83cd-3a7055c09341]
ERROR: LoadError: FFTW is not properly installed. Please run Pkg.build("FFTW") and restart Julia.
Stacktrace:
 [1] error(::String, ::String) at .\error.jl:42
 [2] top-level scope at C:\Users\Seif\.julia\packages\FFTW\p7sL\src\FFTW.jl:21
 [3] include at .\boot.jl:317 [inlined]
 [4] include_relative(::Module, ::String) at .\loading.jl:1038
 [5] include(::Module, ::String) at .\sysimg.jl:29
 [6] top-level scope at none:2
 [7] eval at .\boot.jl:319 [inlined]
 [8] eval(::Expr) at .\client.jl:389
 [9] top-level scope at .\none:3
in expression starting at C:\Users\Seif\.julia\packages\FFTW\p7sL\src\FFTW.jl:18
ERROR: Failed to precompile FFTW [7a1cc6ca-52ef-59f5-83cd-3a7055c09341] to C:\Users\Seif\.julia\compiled\v1.0\FFTW\PvIn2.ji.
Stacktrace:
 [1] error(::String) at .\error.jl:33
 [2] macro expansion at .\logging.jl:313 [inlined]
 [3] compilecache(::Base.PkgId, ::String) at .\loading.jl:1184
 [4] _require(::Base.PkgId) at .\logging.jl:311
 [5] require(::Base.PkgId) at .\loading.jl:852
 [6] macro expansion at .\logging.jl:311 [inlined]
 [7] require(::Module, ::Symbol) at .\loading.jl:834

julia> using Pkg

julia> Pkg.build("FFTW")
  Building Conda → `C:\Users\Seif\.julia\packages\Conda\m7ve\deps\build.log`
  Building FFTW ─→ `C:\Users\Seif\.julia\packages\FFTW\p7sL\deps\build.log`

julia> # Restart

julia> using FFTW
[ Info: Precompiling FFTW [7a1cc6ca-52ef-59f5-83cd-3a7055c09341]

julia> # Success

#46

I agree with the “new user” argument. But you asked how to find functionalities that have been moved out of Base. And for that, Julia 0.7 is ideal.

For new users, I assume they simply search for “julia fft” on google and at least for me one of the first results is FFTW. (I haven’t used fft in julia yet so I assume it’s not due to a bias of my google.)


#47

I guess I’m just used to (from my Matlab and Julia experience) thinking of fft as core–core–functionality, and now it’s just another thing you need to google to find (no hits in the Julia docs).

But it’s the same in Python. There are no hits for fft on python.org.


#48

Slightly off topic but if you ever want clean un-customized Google results just search in an incognito tab.


#49

haha, I know, thanks. Actually, that’s my normal mode, but I found that as an explanation too long and the other one is coincidentally correct, too. And I didn’t want to induce a discussion on that (:

Again, that could be a lengthy discussion but in the end its a question of opinions. And while I understand your point, I find it logical to have it in a separate module as Julia (and in particular Python) can do a lot more.


#50

No, that’s not my point.

I’m not saying it should be in Base. I’m saying it is surprisingly hard to find, and that it’s surprising that it’s not in stdlib. FFTs are actually the first thing several people have asked me about when I tell them about Julia.


#51

I agree with DNF. Seems to me that the documentation hasn’t been adjusted with the same care and effort that went into moving things out of Base. But this is something we should be able to fix easily. These suggestions and discussions should directly go into issues and (even better) PRs. Will you open one @DNF?


#52

I was about to suggest that (:


#53

I can see about an issue, at least.

It should be broader than “What happened to the FFT?”, so it needs a bit of thought. The gist of it might be: how can the contents of stdlib be better exposed and more discoverable? Should more stuff be in stdlib (like the fft)? And if not, should the official docs point to certain external libraries as ‘canonical’, or at least list the best known alternatives?

Perhaps the right approach is to profile the Julia organizations more/differently. Currently they are listed under julialang.org/community/ , which took me some time to realize. It might help a lot if the official docs included links to and search inside the Julia Organizations.

Finding something as central as the FFT by googling for some random repository will probably be quite off-putting to many in my field people in my field who are used to Matlab. Finding it in the JuliaMath Organization through the official Julia docs on the homepage, on the other hand, feels quite reassuring.


#54

In 1.0 I get the following for ?fft:

help?> fft

search: Cptrdiff_t findfirst fieldoffset

Couldn't find fft
Perhaps you meant fd, fld, fma, for, if, Set, cat, cot, get, Int, let or diff
  No documentation found.

  Binding fft does not exist.

No hint for FFTW. Maybe ?help> could search more than just the loaded packages. Or make a ??help> mode like in R that searches all the installed packages.


#55

@DNF Yes, I agree it’s more genral than just fft. Also see, https://github.com/JuliaLang/julia/issues/28712


#56

IIRC someone proposed a feature similar to this some time ago. Maybe this could be revived.


#57

True, but python users who want to do scientific computing know they have to use numpy/scipy, and from there have many functionalities at their fingertips.

Several functionalities (FFT, eigs) are now pretty tricky to find. I’m not sure what the right approach is. Most likely, users will first type “fft” in the REPL, and then google “julia FFT” (at least that’s what I do). I think ensuring that the top google result for “julia FFT” (and “julia eigs” and possibly others) gives the correct result is a pretty good start. That involves getting google to point to the 1.0 doc (rather than the 0.6 one), and possibly adding a “list of commonly used functionalities” pointing to “standard” packages like FFTW and ARPACK, as well as instruction on how to add “using FFTW” to the rc file, somewhere on the website.


#58

I think that

  1. general search engines (Google, DuckDuckGo, etc) are a good starting point,

  2. Github queries like

    fft language:Julia
    

    are usually very helpful in locating packages.

This is in general tricky to achieve, especially for search engines in general (not everyone uses Google because of privacy concerns). Julia is a very common name, and trying SEO for generic terms is an uphill struggle. I think we have to reconcile ourselves to a low signal/noise ratio for search engines.


#59

It would be nice to have a search engine mode in the REPL to search the stdlib packages or metadata packages for a function or type, while specifying the exported API only or all names in these packages. It seems counter-productive to go through Google noise when it’s all right there on my machine at least for stdlib.


#60

If there’s a single authoritative page on julialang.org (say, an FAQ item), then this should sort itself out automatically if search engines do a good job (which they usually do)


#61

I could try to work on that. I already have a pull request on Pkg for a search engine, so it’s a matter of adding that feature. However, I dont believe it is possible to search all the names without loading the package currently, so all packages would need to be loaded to search.

Use duckduckgo instead, that’s “incognito” by default, if google search is needed append !g