[julia-users] Re: Anyone working on Julia wrappers for TensorFlow?

[James Dang]

The Python API is far more useful than C++. I've really had no difficulty 
using it via PyCall for Julia. You just write

using PyCall
@pyimport tensorflow as TF

to import the whole library, and code such as

TF.placeholder("float32")
TF.train[:GradientDescentOptimizer](α)[:minimize](loss)

to invoke it. There's a bit of experimentation to determine whether you use 
a "." or a ":" syntax to access a function, as it may not be clear whether 
you are calling the function on a module or an object.

Additionally, you can make it more friendly towards Julia operators by 
overloading the basic ones, such as

+(a::PyObject, b) = a[:__add__](b)
-(a::PyObject, b) = a[:__sub__](b)
>(a::PyObject, b) = a[:__gt__](b)
etc

With a little cleverness, you can even get the python context managers to 
work:

export pycm
function pycm(f::Function, pyobj::PyObject)
  pyobj[:__enter__]()
  err = nothing
  try
f(pyobj)
  catch err2
err = err2
  finally
pyobj[:__exit__](nothing, nothing, nothing)
  end
  if err != nothing
rethrow(err)
  end
end


pycm(TF.device("/cpu:0")) do dev
  ...
end




There is also a new Julia package that wraps TensorFlow and basically does 
all this. 

https://github.com/benmoran/TensorFlow.jl

I'm not sure how well it would keep up as the TensorFlow API evolves, so I 
find it easier to just call TensorFlow directly.


Regards,
James







On Tuesday, December 15, 2015 at 3:17:50 AM UTC+8, Phil Tomson wrote:
>
> TensorFlow is written in C++ and they use SWIG to generate wrappers for 
> Python. There is no Julia target for SWIG, but looking at some discussions 
> here seems to indicate that SWIG for Julia is kind of pointless given that 
> things like Cxx.jl exist.
>
> However, Cxx.jl requires special dev versions of both Julia and LLVM so 
> it's not an "out of the box" experience just yet. 
>
> There was a thread on TensorFlow here a few weeks back, I'm wondering if 
> anyone was was working on Julia/TensorFlow interoperability?
>
> Are there alternatives to Cxx.jl for this kind of thing? Will Cxx.jl ever 
> be at the point where we can use it with a standard release of Julia?
>
> Phil
>

Re: [julia-users] Announcing JuDE: autocomplete and jump to definition support for Atom

[James Dang]

Hi David, I think Jude's functionality is pretty orthogonal to julia-client 
so they function pretty well as distinct, easier to manage packages. 
julia-client is focused on live code execution and results visualization 
while Jude is more about getting traditional IDE tools via static syntax 
analysis. Why do you think they should merge?

Re: [julia-users] Re: Announcing JuDE: autocomplete and jump to definition support for Atom

[James Dang]

I just updated Jude so you can configure your Julia path. Good to know we
can eventually get autocomplete in the console for autocomplete+.

On Tue, Mar 22, 2016 at 7:00 PM, Mike Innes <mike.j.in...@gmail.com> wrote:

> This is very cool! RE the path, perhaps it could make sense for Jude to
> check for the `julia-client.juliaPath` before defaulting to `julia`? I'm
> also hoping that julia-client can expose some kind of API eventually so
> that people can build whatever custom interactions they want.
>
> Autocomplete in the console is definitely an issue, but there's actually a
> set of PRs to Atom and autocomplete-plus that will help us fix this. In
> future, there's no reason not to expect both julia-client and Jude
> autocompletions to be available there.
>
> On Tue, 22 Mar 2016 at 05:17 James Dang <dan...@gmail.com> wrote:
>
>> Hi Evan, no, the console is controlled by Juno (or "julia-client" in
>> Atom), and Jude can't hook into that. Besides, Jude is complementary and
>> distinct from what Juno provides. Jude does auto-complete within scopes, so
>> you can get autocomplete in the middle of a function body you are editing,
>> which might be nested deep in a module which is imported into your main
>> script. Juno does auto-complete just on your main script, ie at global
>> scope, just like a Julia REPL. It's probably possible for Juno to
>> eventually hook its own auto-completes into the console. It's just not as
>> easy because then it can't use Atom's Autocomplete+ package.
>>
>> Instead, you could type your code directly into your source file,
>> leveraging Jude's autocomplete there. Then once you're done typing the
>> line, you could type Ctrl-Enter to execute it via Juno. When I use Juno, I
>> rarely have to type directly into the console. I usually just edit a script
>> file and run the lines individually.
>>
>>
>>

[julia-users] Re: Announcing JuDE: autocomplete and jump to definition support for Atom

[James Dang]

Hi Evan, no, the console is controlled by Juno (or "julia-client" in Atom), 
and Jude can't hook into that. Besides, Jude is complementary and distinct 
from what Juno provides. Jude does auto-complete within scopes, so you can 
get autocomplete in the middle of a function body you are editing, which 
might be nested deep in a module which is imported into your main script. 
Juno does auto-complete just on your main script, ie at global scope, just 
like a Julia REPL. It's probably possible for Juno to eventually hook its 
own auto-completes into the console. It's just not as easy because then it 
can't use Atom's Autocomplete+ package.

Instead, you could type your code directly into your source file, 
leveraging Jude's autocomplete there. Then once you're done typing the 
line, you could type Ctrl-Enter to execute it via Juno. When I use Juno, I 
rarely have to type directly into the console. I usually just edit a script 
file and run the lines individually.

[julia-users] Re: Announcing JuDE: autocomplete and jump to definition support for Atom

[James Dang]

Hi Nitin, yeah I haven't set up a way to configure which Julia binary to 
run, so it just expects `julia` on your path. That will be fixed up soon. 
Another user who used homebrew found a workaround: 
https://github.com/jamesdanged/Jude/issues/1

[julia-users] Re: Announcing JuDE: autocomplete and jump to definition support for Atom

[James Dang]

Thanks! I think it's the default Atom theme heh.

[julia-users] Announcing JuDE: autocomplete and jump to definition support for Atom

[James Dang]

Hi All, Julia has been great for me, and I wanted to give back a little. 
LightTable and Atom are great editors, but I was really starting to miss 
good intellisense-like autocomplete and basic navigation features like 
jump-to-definition, especially on larger codebases. It's really quite a 
slog to remember exactly where in which file a function was defined, or 
what its exact arguments are. And maybe with better tooling, more people 
will be drawn to the community. So I put a bit of work into a new package 
for Atom that gives you that!

https://atom.io/packages/jude




This is a bit different from what you get out of julia-client and 
autocomplete-julia because it does a full syntax parsing and scope 
resolution of your codebase without executing it in a Julia process. It 
reparses very quickly on the fly without needing to save. And the matching 
is precise, not fuzzy, giving you exactly what names are available in the 
scope you are in currently. It's quite new and unpolished, but please try 
it out and let me know what you think!

Cheers,
James

[julia-users] Re: pyplot doesn't display anything, how do I choose the right backend

[James Dang]

If you use it with IPython Notebook or with Lighttable, it should pretty 
much work out of the box I think.

[julia-users] Re: Text editor for coding Julia: Atom vs Light Table vs Bracket

[James Dang]

I've been working quite productively with LightTable, as I specifically 
need to interact with my data. It even allows interactive plotting using 
PyPlot with the ability to show the plots in a separate window or inline.

[julia-users] generating functions with varying number of args

[James Dang]

Hi All,

I've been writing my own functors similar to the NumericExtensions package, 
and I've been able to get very good performance while also encapsulating my 
SIMD loops.

My problem is that I had to copy paste code over and over to handle the 
different situations where my functor takes 1 arg, 2 args, 3 args, etc. Is 
there a way to programatically generate a function call using eval or 
macros using a variable number of arguments? It would have to avoid using 
tuples and ... as the inner loops need to be fast. It seems providing the 
arguments in the function definition explicitly seems to be the only way to 
achieve this.

My code looks roughly like this, where f is a functor which allows the 
whole function to inline the inner calls to f at compile time. I'm trying 
to use up to 8 args and an additional functor for indexing into transposed 
or sub arrays (not shown here).

function broadcast_devec(
num_args, m, n, f, arr_out, 
a, b, c )
  
  if num_args == 1
for j=1:n
  for i=1:m
@inbounds arr_out[i, j] = evaluate(f, a)
  end
end
  elseif num_args == 2
for j=1:n
  for i=1:m
@inbounds arr_out[i, j] = evaluate(f, a, b)
  end
end
  elseif num_args == 3
for j=1:n
  for i=1:m
@inbounds arr_out[i, j] = evaluate(f, a, b, c)
  end
end
  end


end



It seems with eval and macros, you can generate all sorts of expressions 
which can be used inside a function, and you can generate a function if you 
provide its signature explicitly, but you cannot create an expression that 
is used for the function arg list.



Thanks,
James