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
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
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
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
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
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 simple
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 keyword. It would
be
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 copy.
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
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?
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 most
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.
'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 F is F,
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 high
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 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).
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:
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
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
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,
27 matches
Mail list logo
