I'm far from expert on those questions, but would the "invoke" function work?
I think it's considered to be a tool of the last resort, but seems to
be the situation you are in!
invoke(f, (types...), args...)
Invoke a method for the given generic function matching the
specified types (as a tuple
> My recollection is that part of the indexing interface in Julia (just by
> convention) is that indexing should be of O(1) (or close to that)
> complexity.
As the OP suggested, this could still be the case, the zip object
would simply forward the indexing to the zipped collections, which
would fa
In the pre-jb/functions era, where higher-order functions where
suboptimal (because function calls would not specialize on them),
there was a trick using the feature you noticed to overcome this
limitation, i.e. make it fast. Cf the discussion at
https://groups.google.com/d/topic/julia-users/qscRyN
I think the OP's question is not about the difference between a macro
and a function, but rather about the syntactic way of defining a
macro: if a macro can be seen as a function taking an expression and
returning another one, why can't we just define a macro with the
standard function syntax (i.e.
And indeed, as Scott points, a function can switch from using the
short form to the long form only because the number of characters
grows a bit, which is uncorelated to the functionalness. Having the
short form and long form disagree on the "default" returned value
would increase the risk to introd
I would be sorry to see this so elegant functional aspect of Julia
return to the void. It fits well with the
expression-rather-than-statement feel of Julia.
Regarding the annoyance of having to explicitly "return nothing" for
"procedures" (functions which are called only for side-effects): I
would
John, I tried your branch which works as expected, thank you. I found
that there has been a PR at
https://github.com/JuliaLang/julia/pull/13545 related to REPL hooks,
not sure how much this overlaps with your solution. In any case, I
hope to see this functionality merged.
> Again, I don't know if there is any demand for adding a general
> facility for this.
If you have in mind to make a PR, I would be a client for such a
facility. IIUC, this would e.g. allow me to change automatically the
prompt by calling a function from .juliarc.jl ? (which I do manually
now with
This in-preparation blogpost may be relevant?
https://github.com/JuliaLang/julialang.github.com/pull/324/files
The problem I think came essentially from the repeated creation of
RangeGenerator objects, cf.
https://github.com/JuliaLang/julia/pull/14772.
> Let's capture this as a Julia performance issue on github,
> if we can't figure out an easy way to speed this up right away.
I think I remember having identified a potentially sub-optimal
implementation of this function few weeks back (perhaps no more than
what Tim suggested) and had planned to
Regarding Mauro's example: it is my understanding that your first
example is that much faster mainly for cache reasons; indeed, the
speed difference is less visible with the following two functions:
f1(n) = (b = Array(Float64, n); fill!(b, 0.0))
f2(n) = (b = zeros(Float64, n); fill!(b, 0.0))
Then
I think the idiomatic way remains to be designed:
https://github.com/JuliaLang/julia/issues/5333.
>
> Docile.jl looks great, but I think that the API should be made into
> comments. One of Julia's goals is to have a simple syntax that even people
> who are not acquainted with programming can easily understand.
>
Python, despite using docstrings, is a great example of a language having
"a simpl
BigFloats are indeed immutable "in spirit" but not really:
julia> BigFloat.mutable == isimmutable(big(0.1))
true
So copy is a no-op (returns its argument as for every number), and deepopy
returns a new instance ("deepcopy(a) === a" is false), but then there is no
public API to mutate a or its cop
> To me the only difference is that I
`> really don't want to write
>
> @doc """
> commentary
> """
> function ...
>
>
> whereas I already write things along the lines of
>
> # commentary
> function ...
doc "function doc"
function ...
is already better, and then let's get rid of even the doc keyw
> Then one could use the existing Julia syntax for substituting values into
> the documentation, like:
>
> # This is a comment. 1 + 2 = $(1 + 2)
>
I don't have a strong opinion on this topic, but I really don't understand
why this is better than using directly:
@doc "This is a doc string: 1 + 2 =
>
> There's a complicated limit to when you want to fuse loops – at some point
> multiple iterations becomes better than fused loops and it all depends on
> how much and what kind of work you're doing. In general doing things lazily
> does not cut down on allocation since you have to allocate the
>
> Could you please explain why the iterator version is so much faster? Is
> it simply from avoiding temporary array allocation?
>
That's what I understand, and maybe marginally because there is only one
pass over the data.
> If that was the way things worked, would sum(abs(A)) do the computation
> right away or just wait until you ask for the result? In other words,
> should sum also be lazy if we're doing all vectorized computations that
> way?
>
sum(abs(A)) returns a scalar, so lazy would buy nothing here (in mos
>
> Obviously it would be even nicer not to have to do that :-)
>
My naive answer is then why not make vectorized functions lazy (like iabs
above, plus dimensions information) by default? Do you have links to
relevant discussions?
>
> We'd like to eventually be able to do stream fusion to make the vectorized
> version as efficient as the manually fused version, but for now there's a
> performance gap.
>
It is also not too difficult to implement a fused version via iterators, eg
:
immutable iabs{X}
x::X
end
Base.start(
>
> 'Traditional' Julia: you can pass a function f as an argument to another
> function g.
>
> Rafael's functors: instead you create new type F whose constructor is f,
> and then you make g a parametric function with a parameter F instead of an
> argument f.
>
A typo here, the constructor of type
>
> This is a really cool family of tricks. Time for me to start replacing some
> ::Function specifiers in my argument lists...
I saw in julia base that `Base.Callable`, an alias for Union(Function,
DataType), is used in argument lists.
I'm starting to consider replacing most normal functions by
I'm glad to report that the general and beautifully functional solution sum(
imap(sinc_plus_x, x)) is in fact as efficient as the "devectorized"
hand-written one!
It turns out I made the mistake to forget to forward an expression like
"{Type{F}}" to the imap iterator constructor (cf. code below),
> Love it! I get your point much better now. I'll be using it in the future
> :).
:) Yes I was probably a bit succint.
> Re Iterators, yes, your guess is spot on---it's those pesky tuples (which
> are
> way better than they used to be, see
> https://github.com/JuliaLang/julia/pull/4042). In hig
Ok thanks. I guess the heart of the question is overcoming Julia's builtin
pass-by-reference behavior. I would be fine using an explicit copy
function, but is there any way I can avoid defining a copy function for all
my types, which would be annoying?
OK, it seems that deepcopy corresponds bette
If the function "copy" is implemented for z:
z = ...
newfun = let zz = copy(z); (x, y) -> f(zz, x, y) end
I think I understood that lambdas are less efficient than functions so this
may be faster:
let zz = copy(z)
global newfun
newfun(x, y) = f(zz, x, y)
end
> I've not used NumericFuctors so I can't comment on your main question. If
> it's of any use, there's an entirely different approach (more of a dirty
> trick, really) to inlining functions passed in as arguments. Here's a gist
> that shows the trick:
> https://gist.github.com/timholy/bdcee95f9b772
> Hi Rafael, I recently posted an example of using function types, see:
Thanks Adrian, but I couldn't see how it helps to make a
function specialize on its (higher-order) function parameter (and
possibly inline it).
Oh, and by the way functions specialized on values can be emulated, e.g.
type plusN{N}
plusN(x) = x+N
end
plus{10}(1)
And writing a constrained function can be slightly simpler than in my
previous post:
# constrained function:
f{F<:BinaryFunctor}(::Type{F}, x) = F(x, x)
f(plus, 1)
Or, as a
Hi Julia users,
As this is my first post, I must say I'm extremely impressed by julia, met
2 weeks ago. For many months I've meant to clean-up a C++/python lib of
mine, for public consumption. I couldn't help but procrastinate, as the
maintenance cost is so high a tax (eg. too clever hacks, big
32 matches
Mail list logo
