91–100 of 120 posts
I get confused by this every time this comes up. Is multiple dispatch the same as function-overloading (e.g. in C++)?
It's a breeze doing such analyses with Stata, and with a bunch of weird syntax, some libraries and more lines you can get it done in R as well.
But I tried assisting my SO with setting up their statistical methods in Python and it was so much more work than Stata (or R).
Earlier quoted context omitted.
They're different. IIRC, multiple dispatch is dynamic (i.e., happens at runtime) while C++'s function overloading is static (happens at compile time).
>happens at runtime is not technically true, because that implies a massive slow-down. instead it's more accurate to say behavior-wise it's always equivalent to a dynamic dispatch, but because Julia's Just-Ahead-of-Time compilation, often you eliminate the dynamic dispatch during run time.
First sentence from the Wikipedia article on multiple dispatch:
"Multiple dispatch or multimethods is a feature of some programming languages in which a function or method can be dynamically dispatched based on the run-time (dynamic) type or, in the more general case, some other attribute of more than one of its arguments."
And later:
"Multiple dispatch should be distinguished from function overloading, in which static typing information, such as a term's declared or inferred type (or base type in a language with subtyping) is used to determine which of several possibilities will be used at a given call site, and that determination is made at compile or link time (or some other time before program execution starts) and is thereafter invariant for a given deployment or run of the program."
The article is supposed to tell us why Jilia is better than R, but it mainly focuses on one feature - multiple dispatch. Can someone please explain - does multiple dispatch provide any advantage over other function call strategies, and even if it does how much effort would it save, how much shorter or less ambiguous our code would become.
There a few recordings of the "Unreasonable effectiveness of multiple dispatch" talk that explains this: https://youtu.be/QTCKsqIK6nE
> For example, in R, we try to avoid loops because they are very inefficient This was true before, but the performance of for loops has been improved a lot later years, and while vectorization is still faster, for loops are no longer a no-no See https://www.r-bloggers.com/2022/02/avoid-loops-in-r-really/
The obsession with cpu speed almost always confuses me in these topics. Time it takes to program is way more important, and that’s where a terse language like R shines. The base/most common functions are almost always executing C anyway. It’s kind of like lisp in that it’s easy to write slow code, but who cares if it’s “fast enough”? Also, it’s almost always easy to speed up if necessary at the R level and R’s C API…
You might like writing slow programs, but that doesn't mean people like using them.
Earlier quoted context omitted.
One interesting thing is that if julia can prove what types a function will be called with at compile time, it doesn't have to do dynamic dispatch, so it has no overhead. It's what the julia folks call type-stable code
If ifs and buts were candy and nuts...
``` julia> @code_warntype identity(5) MethodInstance for identity(::Int64) from identity(x) @ Base operators.jl:513 Arguments #self#::Core.Const(identity) x::Int64 Body::Int64 1 ─ nothing └── return x ```
This is type unstable and results in dynamic dispatch because we are not sure if the argument to identity will be an Int64 or a Float64.
``` julia> f(x) = identity(x ≥ 0 ? x : x + 0.0) f (generic function with 1 method)
julia> @code_warntype f(5) MethodInstance for f(::Int64) from f(x) @ Main REPL[4]:1 Arguments #self#::Core.Const(f) x::Int64 Locals @_3::Union{Float64, Int64} Body::Union{Float64, Int64} 1 ─ %1 = (x ≥ 0)::Bool └── goto #3 if not %1 2 ─ (@_3 = x) └── goto #4 3 ─ (@_3 = x + 0.0) 4 ┄ %6 = @_3::Union{Float64, Int64} │ %7 = Main.identity(%6)::Union{Float64, Int64} └── return %7 ```
Earlier quoted context omitted.
Of course, this is piques one's curiosity. It might be, if the function is simple enough, that there is little advantage to Julia here. But if you are combining multiple operations on a vector, there could be opportunities for Julia, in-place operations, fusing, simd. Maybe even StaticArrays. Any chance of sharing that little piece of code?
sure, for parameters par (what is optimized for), data vector x (typical length from 10 to 20), constants n and n2, a typical function is if((1 - par[3]^2)
Generally, it looks like a function where Julia could have a significant performance advantage.
Earlier quoted context omitted.
>happens at runtime is not technically true, because that implies a massive slow-down. instead it's more accurate to say behavior-wise it's always equivalent to a dynamic dispatch, but because Julia's Just-Ahead-of-Time compilation, often you eliminate the dynamic dispatch during run time.
It is technically true, Julia and other programming language's implementation of multiple dispatch notwithstanding. First sentence from the Wikipedia article on multiple dispatch: "Multiple dispatch or multimethods is a feature of some programming languages in which a function or method can be dynamically dispatched based on the run-time (dynamic) type or, in the more general case, some other attribute of more than o…