3 ms·
Looking at the examples, I still struggle with code that imports multiple libraries at the top and then uses naked function names without telling me where those
by s1t5 6y ago
Looking at the examples, I still struggle with code that imports multiple libraries at the top and then uses naked function names without telling me where those functions come from.
- Buttons840 6y agoIn Julia you can `@which naked_function`. That might help. With Julia's function overloading a function might come from multiple packages.
- photon-torpedo 6y agoOr rather, a function from one package can be extended with methods by other packages.
- FabHK 6y agoAnd to add: Which of the many method of that function is called depends on the type of all the arguments (not only the first argument, as in single dispatch languages like C++). In other words, the implementation actually executed (and thus the source package) might vary depending on the argument type. If I understand Julia correctly.
- s1t5 6y agoI still don't get why multiple dispatch was chosen over having seperate functions with typed arguments. It just seems to add complexity with limited benefit.
- StefanKarpinski 6y agoThis video is my best attempt to explain it (not a rickroll, I swear): https://youtu.be/kc9HwsxE1OY https://youtu.be/kc9HwsxE1OY
- s1t5 6y agoNice talk, you're a really good speaker. Thanks.
- ddragon 6y agoIt's hard to say limited benefit when the entire Julia ecosystem evolved to so heavily rely on it, to allow for each package to work on it's own level of abstraction: For example, the Julia's standard library implements all of the basic math operators on the CPU, and libraries like Flux then define it's own methods to implement the higher level operators used in ML (such as convolutional layers and activation functions). And then someone writes those same basic math operators but instead of running on CPU they run on GPU, and for that they use a new type (CUArray). The original library knows nothing about CUArrays, it will call the same basic operators as always, but since they have a different type (received from the user) they'll dispatch to the GPU version. This kind of interaction can grow indefinitely, for example if you use a complex number type/library it will change the basic operators to deal with both real and imaginary parts, and if you use the GPU types within it, then it will do complex math in the GPU (and ML on complex math on GPU..., without any of the libraries being aware of the other). You can see a more detailed explanation on: https://www.youtube.com/watch?v=kc9HwsxE1OY https://www.youtube.com/watch?v=kc9HwsxE1OY
- mkborregaard 6y agoEven though you can do `@which naked_function` it's a fair position to have that you prefer to import modules and be explicit about where they come from. I tend to prefer explicitness like that in package code, but for data analytical scripts (like the examples here) it would be superfluous in my opinion. It is nice that Julia leaves this style decision to the user. I personally find the constant prepending of modules to be one of the clumsiest aspects of Python for data analysis.
- deleted 6y ago[deleted]