Re: [julia-users] atleast_2d and atleast_3d

[Júlio Hoffimann]

Good point Tim, will check my code to see if I can drop this distinction
between 2 and 3 dimensions.

Thanks.

-Júlio

Re: [julia-users] atleast_2d and atleast_3d

[Tim Holy]

atleast_2d{T}(A::Union(Array{T,0},Array{T,1})) = reshape(A, size(A,1), 1)
atleast_2d{T}(A) = A

but in general I'm not sure why you'd need such a function. size(A,2) returns 
1 even if A is one-dimensional, and A[3,1] works as well.

Best,
--Tim


On Friday, March 06, 2015 01:41:28 PM Júlio Hoffimann wrote:
> Hi,
> 
> What is the equivalent in Julia for numpy.atleast_2d and numpy.atleast_3d?
> Or how would you add a ghost dimension to an array in Julia without calling
> reshape(X, m, n, 1) explicitly?
> 
> -Júlio

Re: [julia-users] Re: Equivalent of MATLAB's nargout in Julia

[Kevin Squire]

Thanks, Jameson--it's nice to have a response from someone who actually
works on the compiler.

Cheers,

   Kevin

On Fri, Mar 6, 2015 at 8:09 PM, Jameson Nash  wrote:

> I'd put together one version of a gist of how this could work in the past,
> and Jeff's mentioned a similar draft idea he had in an early design
> document. In the end, however, I think this just ends up falling in the
> category of "features that just aren't actually desirable to have". It adds
> complexity to the compiler, true. More importantly though, it adds
> additional complexity to the user's concept of a function, and without
> sufficient benefit to justify itself. This feature is often useful in
> matlab for avoiding the expense of some extra computations (which are often
> very expensive in matlab in the first place), but it's also often abused to
> have a function do something different. Additionally, it makes
> composability much more difficult (since the function call starts to depend
> upon the syntax of the call), such that it can be harder to write fully
> generic code.
>
> Julia code is already much more expressive than C, and requires explicit
> ccall / cfunction conversions to translate between the languages, so direct
> compatibility isn't actually much of a concern.
>
> On Fri, Mar 6, 2015 at 9:13 PM Kevin Squire 
> wrote:
>
>> On Fri, Mar 6, 2015 at 11:43 AM, J Luis  wrote:
>>
>>> Is there any fundamental reason why the nargout mechanism cannot (or is
>>> very hard) to implement?
>>> Because if not I really think it would be very very handy to have it.
>>> While we can workaround the nargin concept with the multiple dispatch, the
>>> same does help for the nargout.
>>>
>>
>> I'm not an expert on the innards of the Julia compiler, but I believe the
>> most important reason is that it interferes with type stability of a
>> function, which in turn interferes with the ability of the compiler to
>> generate optimized code.
>>
>> Additionally, functions can currently be used as callbacks from C and
>> Fortran code (and there's generally a desire to keep/enhance C
>> interactivity as much as possible).  If we wanted functions to know the
>> number of output parameters, there would need to be a mechanism to provide
>> this information to the function at call time (e.g., the number of args
>> would perhaps need to be passed in as a hidden parameter).  As there is no
>> mechanism to do this in C, we would either lose compatibility with C, or
>> need to provide a new kind of function, solely for this purpose.
>>
>> So while adding such functionality might add convenience (mostly for
>> people coming from Matlab), it 1) would produce slower, less optimized
>> code, and 2) would require adding a new kind of function to the language
>> and compiler (which is already pretty complicated).
>>
>> I think that would be a pretty hard sell to the primary developers.
>>
>> Cheers!
>>
>>Kevin
>>
>

Re: [julia-users] Re: Equivalent of MATLAB's nargout in Julia

[Jameson Nash]

I'd put together one version of a gist of how this could work in the past,
and Jeff's mentioned a similar draft idea he had in an early design
document. In the end, however, I think this just ends up falling in the
category of "features that just aren't actually desirable to have". It adds
complexity to the compiler, true. More importantly though, it adds
additional complexity to the user's concept of a function, and without
sufficient benefit to justify itself. This feature is often useful in
matlab for avoiding the expense of some extra computations (which are often
very expensive in matlab in the first place), but it's also often abused to
have a function do something different. Additionally, it makes
composability much more difficult (since the function call starts to depend
upon the syntax of the call), such that it can be harder to write fully
generic code.

Julia code is already much more expressive than C, and requires explicit
ccall / cfunction conversions to translate between the languages, so direct
compatibility isn't actually much of a concern.

On Fri, Mar 6, 2015 at 9:13 PM Kevin Squire  wrote:

> On Fri, Mar 6, 2015 at 11:43 AM, J Luis  wrote:
>
>> Is there any fundamental reason why the nargout mechanism cannot (or is
>> very hard) to implement?
>> Because if not I really think it would be very very handy to have it.
>> While we can workaround the nargin concept with the multiple dispatch, the
>> same does help for the nargout.
>>
>
> I'm not an expert on the innards of the Julia compiler, but I believe the
> most important reason is that it interferes with type stability of a
> function, which in turn interferes with the ability of the compiler to
> generate optimized code.
>
> Additionally, functions can currently be used as callbacks from C and
> Fortran code (and there's generally a desire to keep/enhance C
> interactivity as much as possible).  If we wanted functions to know the
> number of output parameters, there would need to be a mechanism to provide
> this information to the function at call time (e.g., the number of args
> would perhaps need to be passed in as a hidden parameter).  As there is no
> mechanism to do this in C, we would either lose compatibility with C, or
> need to provide a new kind of function, solely for this purpose.
>
> So while adding such functionality might add convenience (mostly for
> people coming from Matlab), it 1) would produce slower, less optimized
> code, and 2) would require adding a new kind of function to the language
> and compiler (which is already pretty complicated).
>
> I think that would be a pretty hard sell to the primary developers.
>
> Cheers!
>
>Kevin
>

Re: [julia-users] creation of parametric variables in a macro

[Jameson Nash]

oh, that’s reasonably easy then:

macro testfn(expr)
children = esc(:children)
syms = [:($(symbol(string("_", i))) = $children[$i]) for i = 1:10]
return Expr(:let, Expr(:block, esc(expr)), :(children=children), syms..)
end

which will expand to:

let children=children, _1 = children[1], _2 = children[2], ...
   $expr
end

(I added the first children=children line, so that the user could
theoretically assign to a variable named children, without leaking it to
the enclosing environment. it's not strictly necessary).

-

alternatively, you could recurse through their expr code and replace all
variables of the form `_(\d+)` with :(children[\1])

-


On Fri, Mar 6, 2015 at 9:30 PM Abe Schneider abe.schnei...@gmail.com
 wrote:

Hmmm, good to know. Thank you.
>
>  The rationale for doing so is to provide a shortcut for the elements of a
> variable `children`. Specifically, for a grammar, I might have a rule like:
>
> ```
> @grammar foo begin
>number = r"[0-9]+" { parseint(children[1]) }
> end
> ```
>
> What I would like to have instead, to make it more succint is:
>
> ```
> @grammar foo begin
>number = r"[0-9]+" { parseint(_1) }
> end
> ```
>
> Originally, just to get things working, I used an `eval`, which while
> worked, also made the assignment global, which was less than ideal.
>
>
> I'd be curious if anyone has a suggestion on other methods to accomplish
> this, or if this is outside the scope of what's possible to do with Julia.
>
>
>
> On Friday, March 6, 2015 at 5:10:07 PM UTC-5, Jameson wrote:
>
>> you can't do what you are proposing, by design. a macro cannot do
>> anything that you cannot express directly, it simply allows you to express
>> it more succinctly by templating the redundant parts.
>>
>> if you want a "set" or "numbered list", use a set or number list.
>> variables are bad at that sort of task. whereas an Array is very good at it.
>>
>> On Fri, Mar 6, 2015 at 8:05 AM Abe Schneider  wrote:
>>
>>> I'm trying to create a set of variables (_1, _2, ...) from items within
>>> a list in a macro. I have a (much) condensed version of the code:
>>>
>>> macro testfn()
>>> quote
>>> i = 1
>>> value = [1, 2, 3]
>>> $(Expr(:(=), Expr(:symbol, Expr(:string, "_", :i)), :value))
>>> println(_1)
>>> end
>>> end
>>>
>>>
>>> which gives me:
>>>
>>> ERROR: syntax: invalid assignment location
>>>
>>>
>>> Any ideas on what might be wrong or the proper way to do this? I would
>>> like to keep this in the quotes, as in the actual version there's a lot
>>> more code surrounding the assignment.
>>>
>>> I can get things to work with an eval, but I rather avoid the eval, and
>>> it appears to create a non-local variable.
>>>
>>>
>>> Thanks!
>>>
>>  ​

Re: [julia-users] difficulty disabling multicore BLAS?

[Pontus Stenetorp]

On 7 March 2015 at 01:57, Steven G. Johnson  wrote:
>
> Is there any reason why blas_set_num_threads(1) would not be sufficient to
> disable additional cores?

Given the code [1], I would say no.  I do however always have `export
OPENBLAS_NUM_THREADS=1` in my `.bashrc`, since I tend to work with
small matrices.

Pontus

[1]: 
https://github.com/JuliaLang/julia/blob/cb09d285e0f8dcfc1d34e963bf8ddb35c2b5679c/base/util.jl#L138-L153

Re: [julia-users] Pkg.generate reads git user.name with commas

[Jake Bolewski]

Should be fixed now, thanks

On Friday, March 6, 2015 at 8:52:39 PM UTC-5, Kevin Squire wrote:
>
> Hi Robert,
>
> You're using Julia v0.4, right?  This is actually a bug introduced 
> recently, by https://github.com/JuliaLang/julia/commit/42b3d905 (which 
> itself was trying to fix a deprecation warning).  It should be an easy 
> fix--are you up for it?  If not, could you submit a bug report?
>
> Cheers,
>Kevin
>
> On Fri, Mar 6, 2015 at 3:32 PM, Robert DJ  > wrote:
>
>> Hi,
>>
>> I've run into a weird problem: When making a new package with
>>
>> Pkg.generate("name", "license")
>>
>> the first non-empty Git commit writes my name with commas between every 
>> character:
>>
>> authors:  R, o, b, e, r, t
>>
>> My Git user name has been specified as
>>
>> git config --global user.name Robert
>>
>> I've tried writing replacing this with "Robert" (adding surrounding 
>> quotes) in my ~/.gitconfig, but that doesn't fix the problem.
>>
>> Is there a way to fix this (that doesn't involve rebasing Git history)?
>>
>> Thanks,
>>
>> Robert
>>
>>
>

Re: [julia-users] creation of parametric variables in a macro

[Abe Schneider]

Hmmm, good to know. Thank you.

 The rationale for doing so is to provide a shortcut for the elements of a 
variable `children`. Specifically, for a grammar, I might have a rule like:

```
@grammar foo begin
   number = r"[0-9]+" { parseint(children[1]) }
end
```

What I would like to have instead, to make it more succint is:

```
@grammar foo begin
   number = r"[0-9]+" { parseint(_1) }
end
```

Originally, just to get things working, I used an `eval`, which while 
worked, also made the assignment global, which was less than ideal.


I'd be curious if anyone has a suggestion on other methods to accomplish 
this, or if this is outside the scope of what's possible to do with Julia.


On Friday, March 6, 2015 at 5:10:07 PM UTC-5, Jameson wrote:
>
> you can't do what you are proposing, by design. a macro cannot do anything 
> that you cannot express directly, it simply allows you to express it more 
> succinctly by templating the redundant parts.
>
> if you want a "set" or "numbered list", use a set or number list. 
> variables are bad at that sort of task. whereas an Array is very good at it.
>
> On Fri, Mar 6, 2015 at 8:05 AM Abe Schneider  > wrote:
>
>> I'm trying to create a set of variables (_1, _2, ...) from items within a 
>> list in a macro. I have a (much) condensed version of the code:
>>
>> macro testfn()
>> quote
>> i = 1
>> value = [1, 2, 3]
>> $(Expr(:(=), Expr(:symbol, Expr(:string, "_", :i)), :value))
>> println(_1)
>> end
>> end
>>
>>
>> which gives me:
>>
>> ERROR: syntax: invalid assignment location
>>
>>
>> Any ideas on what might be wrong or the proper way to do this? I would 
>> like to keep this in the quotes, as in the actual version there's a lot 
>> more code surrounding the assignment.
>>
>> I can get things to work with an eval, but I rather avoid the eval, and 
>> it appears to create a non-local variable.
>>
>>
>> Thanks!
>>
>

Re: [julia-users] Re: Equivalent of MATLAB's nargout in Julia

[Kevin Squire]

On Fri, Mar 6, 2015 at 11:43 AM, J Luis  wrote:

> Is there any fundamental reason why the nargout mechanism cannot (or is
> very hard) to implement?
> Because if not I really think it would be very very handy to have it.
> While we can workaround the nargin concept with the multiple dispatch, the
> same does help for the nargout.
>

I'm not an expert on the innards of the Julia compiler, but I believe the
most important reason is that it interferes with type stability of a
function, which in turn interferes with the ability of the compiler to
generate optimized code.

Additionally, functions can currently be used as callbacks from C and
Fortran code (and there's generally a desire to keep/enhance C
interactivity as much as possible).  If we wanted functions to know the
number of output parameters, there would need to be a mechanism to provide
this information to the function at call time (e.g., the number of args
would perhaps need to be passed in as a hidden parameter).  As there is no
mechanism to do this in C, we would either lose compatibility with C, or
need to provide a new kind of function, solely for this purpose.

So while adding such functionality might add convenience (mostly for people
coming from Matlab), it 1) would produce slower, less optimized code, and
2) would require adding a new kind of function to the language and compiler
(which is already pretty complicated).

I think that would be a pretty hard sell to the primary developers.

Cheers!

   Kevin

Re: [julia-users] How to generate composite types with a macro?

[Isaiah Norton]

You are right, I had defined it earlier and apparently the redefinition
restriction does not apply to empty immutables. Anyway, this should work:

macro deftype(name)
  esc(:(immutable $name end))
end



On Fri, Mar 6, 2015 at 8:19 PM, Kaj Wiik  wrote:

> Thanks for the reply!
>
> Hmm, well my intention was to build the definition piecewise inserting the
> fields after this line without end, now I see that it will not work.
> Perhaps I should make a template and push! fields to ex.args[3].args?
>
> In fact your suggestion does not work in my Julia:
> julia> macro deftype(name)
> ex1 = :(immutable $name end)
>end
>
> julia> @deftype foo
>
> julia> foo()
> ERROR: foo not defined
>
>
>
> The reason is:
> julia> macroexpand(:(@deftype foo))
> :(immutable #133#foo
> end)
>
>
> I.e. the type name is modified... How to escape it?
>
> Thanks,
> Kaj
>
> julia> versioninfo()
> Julia Version 0.3.6
> Commit a05f87b* (2015-01-08 22:33 UTC)
> Platform Info:
>   System: Linux (x86_64-linux-gnu)
>   CPU: AMD A6-4455M APU with Radeon(tm) HD Graphics
>   WORD_SIZE: 64
>   BLAS: libopenblas (NO_LAPACK NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY)
>   LAPACK: liblapack.so.3
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>
>
> On Friday, March 6, 2015 at 5:35:23 PM UTC+2, Isaiah wrote:
>>
>> Missing an `end` in both expressions.
>>
>>>
>> julia> macro deftype(name)
>>
>>>ex1 = :(immutable $name end)
>>  end
>> julia> @deftype foo
>> julia> foo()
>>
>> On Thu, Mar 5, 2015 at 5:02 AM, Kaj Wiik  wrote:
>>
>>> I have been trying to write a macro that would generate fields in a
>>> for-loop.
>>>
>>> However, when I try to generate the first line I get an error:
>>>
>>> julia> macro deftype(name,artype,num)
>>>ex1 = :(esc( immutable $name))
>>> ERROR: syntax: unexpected ")"
>>>
>>> julia> macro deftype(name,artype,num)
>>>ex1 = :(esc(quote immutable $name end))
>>> ERROR: syntax: extra token ")" after end of expression
>>>
>>>
>>> There must be a way to do this, I cannot find how...
>>>
>>> Thanks,
>>> Kaj
>>>
>>>
>>

Re: [julia-users] Pkg.generate reads git user.name with commas

[Kevin Squire]

Hi Robert,

You're using Julia v0.4, right?  This is actually a bug introduced
recently, by https://github.com/JuliaLang/julia/commit/42b3d905 (which
itself was trying to fix a deprecation warning).  It should be an easy
fix--are you up for it?  If not, could you submit a bug report?

Cheers,
   Kevin

On Fri, Mar 6, 2015 at 3:32 PM, Robert DJ  wrote:

> Hi,
>
> I've run into a weird problem: When making a new package with
>
> Pkg.generate("name", "license")
>
> the first non-empty Git commit writes my name with commas between every
> character:
>
> authors:  R, o, b, e, r, t
>
> My Git user name has been specified as
>
> git config --global user.name Robert
>
> I've tried writing replacing this with "Robert" (adding surrounding
> quotes) in my ~/.gitconfig, but that doesn't fix the problem.
>
> Is there a way to fix this (that doesn't involve rebasing Git history)?
>
> Thanks,
>
> Robert
>
>

[julia-users] Re: Using ModX: Can scope avoid collisions & improve readability?

[MA Laforge]

ele...: I did not know about this sys.modules thing.  Good to know.

Josh & ele...:
Agreed.  I don't think pollution happens until the "using modX" call 
happens.  So, I don't really understand why we can't have scope-level 
"using" commands.

And yes, maybe Julia *should* use a different keyword than "using" when 
applied to arbitrary scopes (as opposed to when we use it at the 
module-level).

...So linking back to Patrick's comment:
The "export" list sort of tells the module user what functions are meant to 
be used.  It just happens that Julia's implementation of "using" pulls in 
all "export"-ed elements into the current module namespace.  This works 
extremely well with the multi-dispatch engine.

However, I can also see a place for a slightly weaker directive: Let's call 
it "provide" for now.  The "provide" directive could be used to tell the 
user what other elements (like constructors) are "supported" by the 
module.  The "provide"-ed elements would not be pulled in by the "using" 
statement.  Only "export"-ed values do that.  Instead, "provide"-ed 
elements would *only* be pulled-in when a user calls "using >>namespace<< 
modX" (or some other keyword).

This would allow developers to use shorter names.  Names that would 
otherwise collide if they were to be "export"-ed:
module Electroncis
type Circuit
name::String
elemlist::Array{CktElem}
...
end

abstract IndepCktElem
abstract drivePattern
type Vsrc <: IndepCktElem ...; end
type SineWave <: drivePattern ...; end

connect(c::Circuit, x::CktElem, n::NodeList) = ...
drive(c::Circuit, x::IndepCktElem, n::NodeList, p::drivePattern) = ...
...

export connect, drive  #No problem: Can be handled by multi-dispatch
provide Circuit#Dangerous: Cannot always be resolved by 
multi-dispatch
provide Vsrc, SineWave #Also a little dangerous
end

Now, in the user's module, you can do the following:
using Electronics #Brings in connect & drive, as usual

#Eventually gets a little verbose when dealing with elements that cannot 
easily
#be resolved by multi-dispatch ("provide"-ed elements):
function make_circuit()
c = Electronics.Circuit("Myckt") 
drive(c, Electronics.Vsrc(), [:SUPPLY, :GND], Electronics.SineWave(1e9))
return c
end

#But this function *could* be made more succinct:
function make_circuit2()
using namespace Electronics #Also brings in all other "legitimate" 
elements
c = Circuit("Myckt") #More succinct constructor call

#Things gets even nicer with more complex expressions:
drive(c, Vsrc(), [:SUPPLY, :GND], SineWave(1e9))
return c
end


On Friday, March 6, 2015 at 6:36:44 PM UTC-5, ele...@gmail.com wrote:
>
> This is essentially the method used by Python (as I believe I understand 
> it, import is the worst documented thing in Python).  Python puts a 
> reference to all modules into sys.modules, no matter where they are 
> imported.  And sys.modules is always the first thing searched before path. 
>  So all modules are imported and initialized once (excepting users 
> explicitly deleteing or reloading).  An no matter where the imports happen 
> the first will actually load and initialize the module and all the others 
> will just use that copy.  But since modules are referenced by sys.modules, 
> not the top level namespace, there is no pollution until a user explicitly 
> imports into that namespace.
>
> On Saturday, March 7, 2015 at 5:48:11 AM UTC+10, Josh Langsfeld wrote:
>>
>> So then your results would indicate that putting 'using MyModule' inside 
>> a function *could* actually bring the exported names into only the local 
>> scope *if* the module had already been constructed in the global scope. 
>> I know I've seen some people discuss name pollution by 'using' too many 
>> modules. It might be part of a wider solution to enable local scope 
>> 'using', either with a new keyword or just having 'using' check if the 
>> module already exists.
>>
>>

Re: [julia-users] How to generate composite types with a macro?

[Kaj Wiik]

Thanks for the reply!

Hmm, well my intention was to build the definition piecewise inserting the 
fields after this line without end, now I see that it will not work. 
Perhaps I should make a template and push! fields to ex.args[3].args?

In fact your suggestion does not work in my Julia:
julia> macro deftype(name)
ex1 = :(immutable $name end)
   end

julia> @deftype foo

julia> foo()
ERROR: foo not defined



The reason is:
julia> macroexpand(:(@deftype foo))
:(immutable #133#foo
end)


I.e. the type name is modified... How to escape it?

Thanks,
Kaj

julia> versioninfo()
Julia Version 0.3.6
Commit a05f87b* (2015-01-08 22:33 UTC)
Platform Info:
  System: Linux (x86_64-linux-gnu)
  CPU: AMD A6-4455M APU with Radeon(tm) HD Graphics
  WORD_SIZE: 64
  BLAS: libopenblas (NO_LAPACK NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY)
  LAPACK: liblapack.so.3
  LIBM: libopenlibm
  LLVM: libLLVM-3.3


On Friday, March 6, 2015 at 5:35:23 PM UTC+2, Isaiah wrote:
>
> Missing an `end` in both expressions.
>
>>
> julia> macro deftype(name)
>
>>ex1 = :(immutable $name end)
>  end
> julia> @deftype foo
> julia> foo()
>
> On Thu, Mar 5, 2015 at 5:02 AM, Kaj Wiik > 
> wrote:
>
>> I have been trying to write a macro that would generate fields in a 
>> for-loop.
>>
>> However, when I try to generate the first line I get an error:
>>
>> julia> macro deftype(name,artype,num)
>>ex1 = :(esc( immutable $name))
>> ERROR: syntax: unexpected ")"
>>
>> julia> macro deftype(name,artype,num)
>>ex1 = :(esc(quote immutable $name end))
>> ERROR: syntax: extra token ")" after end of expression
>>
>>
>> There must be a way to do this, I cannot find how...
>>
>> Thanks,
>> Kaj
>>
>>
>

[julia-users] @parallel (+) for and zip()

[Júlio Hoffimann]

Consider this code:

A = eye(3)
B = {A,A,A}

for (a1,a2) in zip(B,B)
  a1+a2
end

It works fine. If I add @parallel (+) it fails with:

exception on 1: ERROR: MethodError: `getindex` has no method matching 
getindex(::Base.Zip2{Array{Any,1},Array{Any,1}}, ::Int64)
 in anonymous at no file:1471
 in anonymous at multi.jl:1320
 in run_work_thunk at multi.jl:617
 in run_work_thunk at multi.jl:626
 in anonymous at task.jl:6

Could you please confirm this is a bug?

-Júlio

Re: [julia-users] Re: Equivalent of MATLAB's nargout in Julia

[Pierre-Yves Gérardy]

nargout can be emulated by (ab)using the iteration protocol on a
custom return type that will be accessed through tuple
assignment/destructuring.

Take this example:

tpl = (1,2)
a,b = tpl

the second line will call start(), done() and next() on tpl to extract
the two numbers.

So, for your use case:

type Result; output1; otherstate; end

function myfunc(x, y)
return Result(x+y, (x, y))
end

my_expensive_func(r::Result)
#compute output2
end

start(r::Result) = 1
done(::Result, i) = i > 2
function next(r::Result, i)
if i == 1
(r.output1, 2)
elseif i == 2
(my_expensive_func(r), 3)
end
end

to get the first result, use this (note the coma):

a, = myfunc(4,5)

Hopefully this helps :-)
—Pierre-Yves


On Fri, Mar 6, 2015 at 8:47 PM, Tim Holy  wrote:
> I'll take it in the opposite direction of uniformity, and point out that
> another useful approach is to pass the optional output in as an argument:
>
> function myfunction!(output2, input1, input2, ...)
> # do some calculations
> if !isa(output2, Nothing)
> for i = 1:n
> output2[i] = ...
> end
> end
> output1
> end
>
> output1 = myfunction!(nothing, x, params)
> g = Array(T, sz)
> output1 = myfunction!(g, x, params)
>
> This is used extensively in optimization, where output2 might be storage for
> the gradient.
>
> Best,
> --Tim
>
>
> On Friday, March 06, 2015 08:24:08 PM Milan Bouchet-Valat wrote:
>> Le jeudi 05 mars 2015 à 11:59 -0800, Pooya a écrit :
>> > Thanks for this clear explanation. If I do the following, is my
>> > function type still unstable? How do you compare the following
>> > solution to yours in terms of efficiency, style, etc?
>> >
>> > function compute_outputs(..., output2Flag)
>> >
>> >   # do some stuff, get x, y, and z
>> >   # compute output 1
>> >   output1 = ...
>> >   if output2Flag
>> >
>> > # compute output 2
>> > output2 = ...
>> >
>> >   else
>> >
>> > output2 = SparseMatrixCSC[]  # the same type as output2 when it is
>> >
>> > computed
>> >
>> >   end
>> >   return output1, output2
>> >
>> > end
>>
>> This version indeed appears to be type-stable, so it should be quite
>> efficient. Users will also be able to write
>> a, b = compute_outputs(..., false)
>> or
>> a, = compute_outputs(..., false)
>> when they don't care about the second output. So it's not a bad design,
>> but returning a second output even when not needed isn't super
>> satisfying.
>>
>> Thus, maybe Steven's suggestion to create two separate functions is
>> better. Do you have any reason to think it's not practical for your
>> case?
>>
>> We should probably decide what's the most idiomatic solution, and
>> document it to ensure consistency. What do other people think?
>>
>>
>> Regards
>>
>> > On Thursday, March 5, 2015 at 10:58:02 AM UTC-5, Steven G. Johnson
>> >
>> > wrote:
>> > On Wednesday, March 4, 2015 at 6:38:28 PM UTC-5, Pooya wrote:
>> > Thanks for your response. I am not sure what you mean
>> > by a lower-level subroutine. Is that a function inside
>> > another one? If yes, How does the scope of variables
>> > work for that?
>> >
>> > From your description, right now you have:
>> >
>> >
>> > function compute_two_outputs(...)
>> >
>> >...do some stuff, get x, y, and z
>> >use x, y, and z to compute output1
>> >use output1, x, y, and z to compute output2
>> >
>> >   return output1, output2
>> >
>> > end
>> >
>> >
>> > Instead, if you don't always want to compute both outputs, but
>> > still want to write the shared computations only once, you can
>> > refactor the code to pull out the shared computations into
>> > another function (that is "lower level" in the sense that
>> > users won't normally call it directly):
>> >
>> >
>> > function some_stuff(...)
>> >
>> >...do some stuff, get x, y, and z
>> >use x, y, and z to compute output1
>> >return output1,x,y,z
>> >
>> > end
>> >
>> >
>> > function compute_output1(...)
>> >
>> >   return some_stuff(...)[1]
>> >
>> > end
>> >
>> >
>> > function compute_two_outputs(...)
>> >
>> >output1,x,y,z = some_stuff(...)
>> >use output1, x, y, and z to compute output2
>> >
>> >   return output1, output2
>> >
>> > end
>

[julia-users] Re: Declaring a function taking a type not yet declared as argument.

[Sam L]

Afaik there are only a couple of ways to deal with this issue:

1) Define all types beforehand, as you mention
2) Define an abstract type ahead of time that your future type is a subtype 
of.

For example:
abstract AbstractBar

type foo end

f(arg1::foo, arg2::AbstractBar)
yadda yadda
end


type bar <: AbstractBar end

g(arg1::foo, arg2::AbstractBar)
   yadda yadda
end

You could do something analogous with foo if you wanted as well, but don't 
need to in this example. There won't be a performance penalty here because 
f and g will be compiled for specific concrete types once they are called. 
It is a little weird though if you're only ever going to have one subtype 
of AbstractBar for it to exist in the first place though.


On Friday, March 6, 2015 at 2:30:13 PM UTC-8, Kristoffer Carlsson wrote:
>
> If I have a function that uses two types as argument do I have to declare 
> both types before defining the function?
>
> I think an example will make my question clearer.
>
> Say I want the following structure of a package:
>
> #Package.jl
> module Package
> export f, g
> include("foo.jl")
> include("bar.jl")
> end
>
> #foo.jl
> type foo end
>
> f(arg1::foo, arg2::bar)
> yadda yadda
> end
>
> #bar.jl
> type bar end
>
> g(arg1::foo, arg2::bar)
>yadda yadda
> end
>
>
>
> This will not work because when f is declared, bar is not defined.
>
> Is there anyway I can solve this without moving both type declarations to 
> a separate file and including that first?
>

[julia-users] Re: Using ModX: Can scope avoid collisions & improve readability?

[elextr]

This is essentially the method used by Python (as I believe I understand 
it, import is the worst documented thing in Python).  Python puts a 
reference to all modules into sys.modules, no matter where they are 
imported.  And sys.modules is always the first thing searched before path. 
 So all modules are imported and initialized once (excepting users 
explicitly deleteing or reloading).  An no matter where the imports happen 
the first will actually load and initialize the module and all the others 
will just use that copy.  But since modules are referenced by sys.modules, 
not the top level namespace, there is no pollution until a user explicitly 
imports into that namespace.

On Saturday, March 7, 2015 at 5:48:11 AM UTC+10, Josh Langsfeld wrote:
>
> So then your results would indicate that putting 'using MyModule' inside a 
> function *could* actually bring the exported names into only the local 
> scope *if* the module had already been constructed in the global scope. I 
> know I've seen some people discuss name pollution by 'using' too many 
> modules. It might be part of a wider solution to enable local scope 
> 'using', either with a new keyword or just having 'using' check if the 
> module already exists.
>
> On Wednesday, March 4, 2015 at 7:33:37 PM UTC-5, MA Laforge wrote:
>>
>> Josh:
>> I do not fully appreciate the details of how modules get imported 
>> either.  Here is what I can gather:
>>
>> module moda
>> export modvar, setmodvar
>> modvar = 1
>> setmodvar(x) = (global modvar=x)
>> end
>>
>> module modb
>> export modvar, setmodvar
>> modvar = 2
>> setmodvar(x) = (global modvar=x)
>> end
>>
>> module modc
>> using moda
>> import modb
>> println("using moda")
>> @show modvar, moda.modvar, modb.modvar
>> @show setmodvar(5)
>> @show modvar, moda.modvar, modb.modvar
>> @show modb.setmodvar(3)
>> @show modvar, moda.modvar, modb.modvar
>> end
>>
>> module modd
>> import moda
>> using modb
>> println("using modb")
>> @show modvar, moda.modvar, modb.modvar
>> @show setmodvar(8)
>> @show modvar, moda.modvar, modb.modvar
>> end
>>
>> This gives the following results:
>> using moda
>> (modvar,moda.modvar,modb.modvar) => (1,1,2)
>> setmodvar(5) => 5
>> (modvar,moda.modvar,modb.modvar) => (5,5,2)
>> modb.setmodvar(3) => 3
>> (modvar,moda.modvar,modb.modvar) => (5,5,3)
>> using modb
>> (modvar,moda.modvar,modb.modvar) => (3,5,3)
>> setmodvar(8) => 8
>> (modvar,moda.modvar,modb.modvar) => (8,5,8)
>>
>> So it looks like it is the same code in the background (at least the 
>> variables appear to be in a common address space).
>>
>> So... it looks like import merely "makes visible"  the code at a module 
>> level...
>> And "using" first "imports", then "provides a shortcut" to the exported 
>> variables/functions...
>>
>> But as far as I can tell, compilation is done "on demand".  I believe 
>> that the "real" compile step is done when we call a particular version of 
>> the code.  Compilation is actually a separate step from "using" and "import"
>>
>>
>> On Tuesday, March 3, 2015 at 11:48:53 AM UTC-5, Josh Langsfeld wrote:
>>>
>>> I'm curious about that workaround suggested in the FAQ, where you wrap 
>>> the function inside its own module. What is happening under the hood there? 
>>> Does it reinitialize the desired module entirely inside of the wrapper 
>>> module or does it just make a reference to some other compiled and 
>>> initialized top-level area? This is assuming the module has already been 
>>> built elsewhere and you just want easy local access to the exported symbols.
>>>
>>> On Monday, March 2, 2015 at 5:59:30 PM UTC-5, ele...@gmail.com wrote:

 The C++ "using namespace" and Julia "using module" are not quite the 
 same thing.  The C++ namespace is a top level entity that is created and 
 initialized as part of the C++ startup code and the "using" just makes the 
 names of these global entities available within the scope.   The Julia 
 "using" imports, and thus creates, the module for the first time, and 
 Julia 
 modules can contain statements that run at initialization, whereas C++ 
 namespaces can only contain declarations.  

 But if the Julia "using" is within the function, when should the actual 
 import and initialize and execute the statements be done?  Every time the 
 function is called is very expensive.  Hoist the import out of the 
 function 
 to the top level, but doing this naively (ie putting the hoisted import 
 just before the function) will then affect all code following the function 
  Have a "pseudo" top- level visible only to the function adds a complete 
 new complication to the name management code.  But then what happens if 
 the 
 module is imported into two functions, how is its initialization managed? 
 Or the top level and the function?

 So for now the "simpler is better" approach is to have t

[julia-users] Pkg.generate reads git user.name with commas

[Robert DJ]

Hi,

I've run into a weird problem: When making a new package with

Pkg.generate("name", "license")

the first non-empty Git commit writes my name with commas between every 
character:

authors:  R, o, b, e, r, t

My Git user name has been specified as

git config --global user.name Robert

I've tried writing replacing this with "Robert" (adding surrounding quotes) 
in my ~/.gitconfig, but that doesn't fix the problem.

Is there a way to fix this (that doesn't involve rebasing Git history)?

Thanks,

Robert

[julia-users] Declaring a function taking a type not yet declared as argument.

[Kristoffer Carlsson]

If I have a function that uses two types as argument do I have to declare 
both types before defining the function?

I think an example will make my question clearer.

Say I want the following structure of a package:

#Package.jl
module Package
export f, g
include("foo.jl")
include("bar.jl")
end

#foo.jl
type foo end

f(arg1::foo, arg2::bar)
yadda yadda
end

#bar.jl
type bar end

g(arg1::foo, arg2::bar)
   yadda yadda
end



This will not work because when f is declared, bar is not defined.

Is there anyway I can solve this without moving both type declarations to a 
separate file and including that first?

Re: [julia-users] creation of parametric variables in a macro

[Jameson Nash]

you can't do what you are proposing, by design. a macro cannot do anything
that you cannot express directly, it simply allows you to express it more
succinctly by templating the redundant parts.

if you want a "set" or "numbered list", use a set or number list. variables
are bad at that sort of task. whereas an Array is very good at it.

On Fri, Mar 6, 2015 at 8:05 AM Abe Schneider 
wrote:

> I'm trying to create a set of variables (_1, _2, ...) from items within a
> list in a macro. I have a (much) condensed version of the code:
>
> macro testfn()
> quote
> i = 1
> value = [1, 2, 3]
> $(Expr(:(=), Expr(:symbol, Expr(:string, "_", :i)), :value))
> println(_1)
> end
> end
>
>
> which gives me:
>
> ERROR: syntax: invalid assignment location
>
>
> Any ideas on what might be wrong or the proper way to do this? I would
> like to keep this in the quotes, as in the actual version there's a lot
> more code surrounding the assignment.
>
> I can get things to work with an eval, but I rather avoid the eval, and it
> appears to create a non-local variable.
>
>
> Thanks!
>

Re: [julia-users] [ANN] MatrixDepot 0.2.0: include a Julia interface to the UF Sparse Matrix collection

[Andreas Noack]

Oh. That is right. Sounds good.

2015-03-06 16:43 GMT-05:00 Weijian Zhang :

> Hi Andreas,
>
> Yes, you are right. I am using MAT.jl to read matrices.
>
> That's a nice idea. Thanks a lot. But I think Base.SparseMatrix.CHOLMOD.Sparse
> is
> only available for Julia v0.4. I will change to this reader when Julia
> v0.4 is released.
>
> Best,
>
> Weijian
>
>
> On Friday, 6 March 2015 20:35:43 UTC, Andreas Noack wrote:
>>
>> Hi Weijian
>>
>> This is a great functionality. It seems that you are using MAT.jl to read
>> in the sparse matrices. You could consider using the the MatrixMarket
>> reader in Base e.g.
>>
>> A = sparse(Base.SparseMatrix.CHOLMOD.Sparse("matrix.mtx"))
>>
>> It will also have the benefit of using the Symmetric matrix type when the
>> matrix is symmetric and thereby saving half of the storage.
>>
>> 2015-03-06 14:39 GMT-05:00 Weijian Zhang :
>>
>>> Hello,
>>>
>>> I just included a Julia interface to the University of Florida Sparse
>>> Matrix Collection in Matrix Depot (https://github.com/
>>> weijianzhang/MatrixDepot.jl).
>>>
>>> Here is the documentation: http://matrixdepotjl.readthedocs.org/
>>> en/latest/ufsparse.html#ufsparse
>>>
>>> Please let me know if you have any comments.
>>>
>>> Thanks,
>>>
>>> Weijian
>>>
>>>
>>>
>>

Re: [julia-users] [ANN] MatrixDepot 0.2.0: include a Julia interface to the UF Sparse Matrix collection

[Weijian Zhang]

Hi Andreas,

Yes, you are right. I am using MAT.jl to read matrices. 

That's a nice idea. Thanks a lot. But I think 
Base.SparseMatrix.CHOLMOD.Sparse is 
only available for Julia v0.4. I will change to this reader when Julia v0.4 
is released.

Best,

Weijian


On Friday, 6 March 2015 20:35:43 UTC, Andreas Noack wrote:
>
> Hi Weijian
>
> This is a great functionality. It seems that you are using MAT.jl to read 
> in the sparse matrices. You could consider using the the MatrixMarket 
> reader in Base e.g.
>
> A = sparse(Base.SparseMatrix.CHOLMOD.Sparse("matrix.mtx"))
>
> It will also have the benefit of using the Symmetric matrix type when the 
> matrix is symmetric and thereby saving half of the storage.
>
> 2015-03-06 14:39 GMT-05:00 Weijian Zhang >
> :
>
>> Hello,
>>
>> I just included a Julia interface to the University of Florida Sparse 
>> Matrix Collection in Matrix Depot (
>> https://github.com/weijianzhang/MatrixDepot.jl).
>>
>> Here is the documentation: 
>> http://matrixdepotjl.readthedocs.org/en/latest/ufsparse.html#ufsparse
>>
>> Please let me know if you have any comments.
>>
>> Thanks,
>>
>> Weijian
>>
>>
>>
>

[julia-users] atleast_2d and atleast_3d

[Júlio Hoffimann]

Hi,

What is the equivalent in Julia for numpy.atleast_2d and numpy.atleast_3d? 
Or how would you add a ghost dimension to an array in Julia without calling 
reshape(X, m, n, 1) explicitly?

-Júlio

Re: [julia-users] [ANN] MatrixDepot 0.2.0: include a Julia interface to the UF Sparse Matrix collection

[Andreas Noack]

Hi Weijian

This is a great functionality. It seems that you are using MAT.jl to read
in the sparse matrices. You could consider using the the MatrixMarket
reader in Base e.g.

A = sparse(Base.SparseMatrix.CHOLMOD.Sparse("matrix.mtx"))

It will also have the benefit of using the Symmetric matrix type when the
matrix is symmetric and thereby saving half of the storage.

2015-03-06 14:39 GMT-05:00 Weijian Zhang :

> Hello,
>
> I just included a Julia interface to the University of Florida Sparse
> Matrix Collection in Matrix Depot (
> https://github.com/weijianzhang/MatrixDepot.jl).
>
> Here is the documentation:
> http://matrixdepotjl.readthedocs.org/en/latest/ufsparse.html#ufsparse
>
> Please let me know if you have any comments.
>
> Thanks,
>
> Weijian
>
>
>

[julia-users] Re: Using ModX: Can scope avoid collisions & improve readability?

[Josh Langsfeld]

So then your results would indicate that putting 'using MyModule' inside a 
function *could* actually bring the exported names into only the local 
scope *if* the module had already been constructed in the global scope. I 
know I've seen some people discuss name pollution by 'using' too many 
modules. It might be part of a wider solution to enable local scope 
'using', either with a new keyword or just having 'using' check if the 
module already exists.

On Wednesday, March 4, 2015 at 7:33:37 PM UTC-5, MA Laforge wrote:
>
> Josh:
> I do not fully appreciate the details of how modules get imported either.  
> Here is what I can gather:
>
> module moda
> export modvar, setmodvar
> modvar = 1
> setmodvar(x) = (global modvar=x)
> end
>
> module modb
> export modvar, setmodvar
> modvar = 2
> setmodvar(x) = (global modvar=x)
> end
>
> module modc
> using moda
> import modb
> println("using moda")
> @show modvar, moda.modvar, modb.modvar
> @show setmodvar(5)
> @show modvar, moda.modvar, modb.modvar
> @show modb.setmodvar(3)
> @show modvar, moda.modvar, modb.modvar
> end
>
> module modd
> import moda
> using modb
> println("using modb")
> @show modvar, moda.modvar, modb.modvar
> @show setmodvar(8)
> @show modvar, moda.modvar, modb.modvar
> end
>
> This gives the following results:
> using moda
> (modvar,moda.modvar,modb.modvar) => (1,1,2)
> setmodvar(5) => 5
> (modvar,moda.modvar,modb.modvar) => (5,5,2)
> modb.setmodvar(3) => 3
> (modvar,moda.modvar,modb.modvar) => (5,5,3)
> using modb
> (modvar,moda.modvar,modb.modvar) => (3,5,3)
> setmodvar(8) => 8
> (modvar,moda.modvar,modb.modvar) => (8,5,8)
>
> So it looks like it is the same code in the background (at least the 
> variables appear to be in a common address space).
>
> So... it looks like import merely "makes visible"  the code at a module 
> level...
> And "using" first "imports", then "provides a shortcut" to the exported 
> variables/functions...
>
> But as far as I can tell, compilation is done "on demand".  I believe that 
> the "real" compile step is done when we call a particular version of the 
> code.  Compilation is actually a separate step from "using" and "import"
>
>
> On Tuesday, March 3, 2015 at 11:48:53 AM UTC-5, Josh Langsfeld wrote:
>>
>> I'm curious about that workaround suggested in the FAQ, where you wrap 
>> the function inside its own module. What is happening under the hood there? 
>> Does it reinitialize the desired module entirely inside of the wrapper 
>> module or does it just make a reference to some other compiled and 
>> initialized top-level area? This is assuming the module has already been 
>> built elsewhere and you just want easy local access to the exported symbols.
>>
>> On Monday, March 2, 2015 at 5:59:30 PM UTC-5, ele...@gmail.com wrote:
>>>
>>> The C++ "using namespace" and Julia "using module" are not quite the 
>>> same thing.  The C++ namespace is a top level entity that is created and 
>>> initialized as part of the C++ startup code and the "using" just makes the 
>>> names of these global entities available within the scope.   The Julia 
>>> "using" imports, and thus creates, the module for the first time, and Julia 
>>> modules can contain statements that run at initialization, whereas C++ 
>>> namespaces can only contain declarations.  
>>>
>>> But if the Julia "using" is within the function, when should the actual 
>>> import and initialize and execute the statements be done?  Every time the 
>>> function is called is very expensive.  Hoist the import out of the function 
>>> to the top level, but doing this naively (ie putting the hoisted import 
>>> just before the function) will then affect all code following the function 
>>>  Have a "pseudo" top- level visible only to the function adds a complete 
>>> new complication to the name management code.  But then what happens if the 
>>> module is imported into two functions, how is its initialization managed? 
>>> Or the top level and the function?
>>>
>>> So for now the "simpler is better" approach is to have the user manage 
>>> importing at the top level only.
>>>
>>> Cheers
>>> Lex
>>>
>>> On Tuesday, March 3, 2015 at 7:23:33 AM UTC+10, Josh Langsfeld wrote:

 It's discussed in the FAQ so there must be a good reason for it, though 
 no rationale is mentioned.


 http://docs.julialang.org/en/latest/manual/faq/#can-i-use-using-or-import-inside-a-function

 On Monday, March 2, 2015 at 3:00:21 PM UTC-5, Patrick O'Leary wrote:
>
> On Saturday, February 28, 2015 at 11:06:38 AM UTC-6, MA Laforge wrote:
>>
>> C++ provides "using namespace X" to "make available" the contents of 
>> X to the current scope.  This even works on un-named scopes within a 
>> function:
>>
>
> (etc.)
>
> I know this is something that's come up before, and I think 
> rejected--I think because it causes conflicts with multiple dispatch

Re: [julia-users] Re: Equivalent of MATLAB's nargout in Julia

[Tim Holy]

I'll take it in the opposite direction of uniformity, and point out that 
another useful approach is to pass the optional output in as an argument:

function myfunction!(output2, input1, input2, ...)
# do some calculations
if !isa(output2, Nothing)
for i = 1:n
output2[i] = ...
end
end
output1
end

output1 = myfunction!(nothing, x, params)
g = Array(T, sz)
output1 = myfunction!(g, x, params)

This is used extensively in optimization, where output2 might be storage for 
the gradient.

Best,
--Tim


On Friday, March 06, 2015 08:24:08 PM Milan Bouchet-Valat wrote:
> Le jeudi 05 mars 2015 à 11:59 -0800, Pooya a écrit :
> > Thanks for this clear explanation. If I do the following, is my
> > function type still unstable? How do you compare the following
> > solution to yours in terms of efficiency, style, etc?
> > 
> > function compute_outputs(..., output2Flag)
> > 
> >   # do some stuff, get x, y, and z
> >   # compute output 1
> >   output1 = ...
> >   if output2Flag
> >   
> > # compute output 2
> > output2 = ...
> >   
> >   else
> >   
> > output2 = SparseMatrixCSC[]  # the same type as output2 when it is
> > 
> > computed
> > 
> >   end
> >   return output1, output2
> > 
> > end
> 
> This version indeed appears to be type-stable, so it should be quite
> efficient. Users will also be able to write
> a, b = compute_outputs(..., false)
> or
> a, = compute_outputs(..., false)
> when they don't care about the second output. So it's not a bad design,
> but returning a second output even when not needed isn't super
> satisfying.
> 
> Thus, maybe Steven's suggestion to create two separate functions is
> better. Do you have any reason to think it's not practical for your
> case?
> 
> We should probably decide what's the most idiomatic solution, and
> document it to ensure consistency. What do other people think?
> 
> 
> Regards
> 
> > On Thursday, March 5, 2015 at 10:58:02 AM UTC-5, Steven G. Johnson
> > 
> > wrote:
> > On Wednesday, March 4, 2015 at 6:38:28 PM UTC-5, Pooya wrote:
> > Thanks for your response. I am not sure what you mean
> > by a lower-level subroutine. Is that a function inside
> > another one? If yes, How does the scope of variables
> > work for that?
> > 
> > From your description, right now you have:
> > 
> > 
> > function compute_two_outputs(...)
> > 
> >...do some stuff, get x, y, and z
> >use x, y, and z to compute output1
> >use output1, x, y, and z to compute output2
> >   
> >   return output1, output2
> > 
> > end
> > 
> > 
> > Instead, if you don't always want to compute both outputs, but
> > still want to write the shared computations only once, you can
> > refactor the code to pull out the shared computations into
> > another function (that is "lower level" in the sense that
> > users won't normally call it directly):
> > 
> > 
> > function some_stuff(...)
> > 
> >...do some stuff, get x, y, and z
> >use x, y, and z to compute output1
> >return output1,x,y,z
> > 
> > end
> > 
> > 
> > function compute_output1(...)
> > 
> >   return some_stuff(...)[1]
> > 
> > end
> > 
> > 
> > function compute_two_outputs(...)
> > 
> >output1,x,y,z = some_stuff(...)
> >use output1, x, y, and z to compute output2
> >   
> >   return output1, output2
> > 
> > end

[julia-users] Another (basic) parameterization question

[Seth]

I have

abstract AbstractGraph{T<:Integer}

type Graph{T}<:AbstractGraph{T}
vertices::UnitRange{T}
edges::Set{Edge{T}}
finclist::Vector{Vector{Edge{T}}} # [src]: ((src,dst), (src,dst), 
(src,dst))
binclist::Vector{Vector{Edge{T}}} # [dst]: ((src,dst), (src,dst), 
(src,dst))
end

function Graph{T<:Integer}(n::T)





and g = Graph(5) works and produces a graph of type Graph{Int64}, but g = 
Graph{Int64}(5) produces

ERROR: MethodError: `convert` has no method matching 
convert(::Type{LightGraphs.Graph{Int64}}, ::Int64)

This is a problem because I have 

function union{T<:AbstractGraph}(g::T, h::T)
gnv = nv(g)
r = T(gnv + nv(h))
for e in edges(g)
add_edge!(r,e)
end
for e in edges(h)
add_edge!(r, gnv+src(e), gnv+dst(e))
end
return r
end



Which is failing on line 3 (in the creation of the graph).

What's the proper way of creating the object from a parameterized type? 
Thanks.

Re: [julia-users] Re: Equivalent of MATLAB's nargout in Julia

[J Luis]

> We should probably decide what's the most idiomatic solution, and 
> document it to ensure consistency. What do other people think? 
>

Is there any fundamental reason why the nargout mechanism cannot (or is 
very hard) to implement?
Because if not I really think it would be very very handy to have it. While 
we can workaround the nargin concept with the multiple dispatch, the same 
does help for the nargout.

 

>
>
> Regards 
>
> > On Thursday, March 5, 2015 at 10:58:02 AM UTC-5, Steven G. Johnson 
> > wrote: 
> > 
> > 
> > On Wednesday, March 4, 2015 at 6:38:28 PM UTC-5, Pooya wrote: 
> > Thanks for your response. I am not sure what you mean 
> > by a lower-level subroutine. Is that a function inside 
> > another one? If yes, How does the scope of variables 
> > work for that? 
> > 
> > 
> > From your description, right now you have: 
> > 
> > 
> > function compute_two_outputs(...) 
> >...do some stuff, get x, y, and z 
> >use x, y, and z to compute output1 
> >use output1, x, y, and z to compute output2 
> >   return output1, output2 
> > end 
> > 
> > 
> > Instead, if you don't always want to compute both outputs, but 
> > still want to write the shared computations only once, you can 
> > refactor the code to pull out the shared computations into 
> > another function (that is "lower level" in the sense that 
> > users won't normally call it directly): 
> > 
> > 
> > function some_stuff(...) 
> >...do some stuff, get x, y, and z 
> >use x, y, and z to compute output1 
> >return output1,x,y,z 
> > end 
> > 
> > 
> > function compute_output1(...) 
> >   return some_stuff(...)[1] 
> > end 
> > 
> > 
> > function compute_two_outputs(...) 
> >output1,x,y,z = some_stuff(...) 
> >use output1, x, y, and z to compute output2 
> >   return output1, output2 
> > end 
> > 
> > 
> > 
> > 
>
>

[julia-users] [ANN] MatrixDepot 0.2.0: include a Julia interface to the UF Sparse Matrix collection

[Weijian Zhang]

Hello,

I just included a Julia interface to the University of Florida Sparse 
Matrix Collection in Matrix Depot 
(https://github.com/weijianzhang/MatrixDepot.jl).

Here is the 
documentation: 
http://matrixdepotjl.readthedocs.org/en/latest/ufsparse.html#ufsparse

Please let me know if you have any comments.

Thanks,

Weijian

Re: [julia-users] Re: Equivalent of MATLAB's nargout in Julia

[Milan Bouchet-Valat]

Le jeudi 05 mars 2015 à 11:59 -0800, Pooya a écrit :
> Thanks for this clear explanation. If I do the following, is my
> function type still unstable? How do you compare the following
> solution to yours in terms of efficiency, style, etc? 
> 
> function compute_outputs(..., output2Flag)
>   # do some stuff, get x, y, and z
>   # compute output 1
>   output1 = ...
>   if output2Flag
> 
> # compute output 2
> output2 = ...
>   else
> output2 = SparseMatrixCSC[]  # the same type as output2 when it is
> computed
>   end
>   return output1, output2
> end
This version indeed appears to be type-stable, so it should be quite
efficient. Users will also be able to write 
a, b = compute_outputs(..., false)
or
a, = compute_outputs(..., false)
when they don't care about the second output. So it's not a bad design,
but returning a second output even when not needed isn't super
satisfying.

Thus, maybe Steven's suggestion to create two separate functions is
better. Do you have any reason to think it's not practical for your
case?

We should probably decide what's the most idiomatic solution, and
document it to ensure consistency. What do other people think?


Regards

> On Thursday, March 5, 2015 at 10:58:02 AM UTC-5, Steven G. Johnson
> wrote:
> 
> 
> On Wednesday, March 4, 2015 at 6:38:28 PM UTC-5, Pooya wrote:
> Thanks for your response. I am not sure what you mean
> by a lower-level subroutine. Is that a function inside
> another one? If yes, How does the scope of variables
> work for that? 
> 
> 
> From your description, right now you have:
> 
> 
> function compute_two_outputs(...)
>...do some stuff, get x, y, and z
>use x, y, and z to compute output1
>use output1, x, y, and z to compute output2
>   return output1, output2
> end
> 
> 
> Instead, if you don't always want to compute both outputs, but
> still want to write the shared computations only once, you can
> refactor the code to pull out the shared computations into
> another function (that is "lower level" in the sense that
> users won't normally call it directly):
> 
> 
> function some_stuff(...)
>...do some stuff, get x, y, and z
>use x, y, and z to compute output1
>return output1,x,y,z
> end
> 
> 
> function compute_output1(...)
>   return some_stuff(...)[1]
> end
> 
> 
> function compute_two_outputs(...)
>output1,x,y,z = some_stuff(...)
>use output1, x, y, and z to compute output2
>   return output1, output2
> end
> 
> 
> 
> 

Re: [julia-users] Re: [julia-dev] Re: Job posting: high performance computing (image analysis and acquisition)

[Stefan Karpinski]

Seems like a sane policy to me. If it gets out of hand (we should be so
lucky), then we can make a julia-jobs list and people post there. I'm also
personally excited about this particular job posting :-)

On Fri, Mar 6, 2015 at 1:50 PM, Keno Fischer 
wrote:

> I think if they are julia job postings they're fine. General data science
> job postings not so much. I think the right policy to follow here is the
> LLVM mailing list. People are allowed to advertise their compiler jobs
> where they need people with strong LLVM skills, but general job offerings
> unrelated to LLVM (where people just happen to think that those interested
> in LLVM are also good programmers in general) are disallowed.
>
> On Fri, Mar 6, 2015 at 1:45 PM, Milktrader  wrote:
>
>> Are job posting part of a dev mailing list?
>>
>>
>> On Friday, March 6, 2015 at 1:35:26 PM UTC-5, Tim wrote:
>>
>>> (Apologies for cross-posting.)
>>>
>>> We seek candidates with expertise in Julia and/or high-performance
>>> computing
>>> to develop software for a broad community of users of an imaging
>>> facility at
>>> Washington University in St. Louis. Challenges include working with "big
>>> data"
>>> (multi-terabyte multidimensional images) and the extensive application
>>> of
>>> machine-learning and numerical algorithms. An ideal candidate would also
>>> be
>>> comfortable with topics such as developing software interfaces for
>>> acquisition
>>> hardware, GPU computing, and/or multithreading. Candidates should be
>>> prepared
>>> to train users of the software, and to interact with them about possible
>>> refinements.
>>>
>>> For more information, please contact Tim Holy (ho...@wustl.edu).
>>>
>>> Best,
>>> --Tim
>>>
>>>
>

[julia-users] Re: Print(char(0x08))

[Ivar Nesje]

I don't think the backspace character will be interpreted as you want it by 
a web browser. It doesn't really make sense in a stored format like HTML.

fredag 6. mars 2015 19.46.28 UTC+1 skrev DP følgende:
>
> I am using juliabox (v0.3.6)
>
> On Saturday, March 7, 2015 at 12:10:16 AM UTC+5:30, Ivar Nesje wrote:
>>
>> It works for me in the standard OSX terminal with a recent 0.4 version. 
>> What kind of system (and julia version) are you on? (versioninfo() tells us 
>> everything we need).
>>
>> fredag 6. mars 2015 19.27.48 UTC+1 skrev DP følgende:
>>>
>>> print("123",char(0x08),"567")
>>> println()
>>> print("123",char(0x09),"567")
>>>
>>> 123567
>>>
>>> 123 567
>>>
>>> As per ASCII Characters,
>>>
>>> ht horizontal tab 
>>> bs backspace
>>>
>>> Why backspace is not working?
>>> Am I doing something wrong?
>>> ​
>>>
>>>

[julia-users] Re: Print(char(0x08))

[DP]

May be some issue with IJulia-Juliabox !!

On Saturday, March 7, 2015 at 12:22:56 AM UTC+5:30, Pablo Zubieta wrote:
>
> It works for me in the julia 0.3.6 REPL (on linux), but it does not seem 
> to work on IJulia.
>

[julia-users] Re: [julia-dev] Re: Job posting: high performance computing (image analysis and acquisition)

[Keno Fischer]

I think if they are julia job postings they're fine. General data science
job postings not so much. I think the right policy to follow here is the
LLVM mailing list. People are allowed to advertise their compiler jobs
where they need people with strong LLVM skills, but general job offerings
unrelated to LLVM (where people just happen to think that those interested
in LLVM are also good programmers in general) are disallowed.

On Fri, Mar 6, 2015 at 1:45 PM, Milktrader  wrote:

> Are job posting part of a dev mailing list?
>
>
> On Friday, March 6, 2015 at 1:35:26 PM UTC-5, Tim wrote:
>
>> (Apologies for cross-posting.)
>>
>> We seek candidates with expertise in Julia and/or high-performance
>> computing
>> to develop software for a broad community of users of an imaging facility
>> at
>> Washington University in St. Louis. Challenges include working with "big
>> data"
>> (multi-terabyte multidimensional images) and the extensive application of
>> machine-learning and numerical algorithms. An ideal candidate would also
>> be
>> comfortable with topics such as developing software interfaces for
>> acquisition
>> hardware, GPU computing, and/or multithreading. Candidates should be
>> prepared
>> to train users of the software, and to interact with them about possible
>> refinements.
>>
>> For more information, please contact Tim Holy (ho...@wustl.edu).
>>
>> Best,
>> --Tim
>>
>>

[julia-users] Re: Print(char(0x08))

[Pablo Zubieta]

It works for me in the julia 0.3.6 REPL (on linux), but it does not seem to 
work on IJulia.

[julia-users] Re: Job posting: high performance computing (image analysis and acquisition)

[Milktrader]

Are job posting part of a dev mailing list?

On Friday, March 6, 2015 at 1:35:26 PM UTC-5, Tim wrote:
>
> (Apologies for cross-posting.) 
>
> We seek candidates with expertise in Julia and/or high-performance 
> computing 
> to develop software for a broad community of users of an imaging facility 
> at 
> Washington University in St. Louis. Challenges include working with "big 
> data" 
> (multi-terabyte multidimensional images) and the extensive application of 
> machine-learning and numerical algorithms. An ideal candidate would also 
> be 
> comfortable with topics such as developing software interfaces for 
> acquisition 
> hardware, GPU computing, and/or multithreading. Candidates should be 
> prepared 
> to train users of the software, and to interact with them about possible 
> refinements. 
>
> For more information, please contact Tim Holy (ho...@wustl.edu 
> ). 
>
> Best, 
> --Tim 
>
>

[julia-users] Re: Print(char(0x08))

[DP]

I am using juliabox (v0.3.6)

On Saturday, March 7, 2015 at 12:10:16 AM UTC+5:30, Ivar Nesje wrote:
>
> It works for me in the standard OSX terminal with a recent 0.4 version. 
> What kind of system (and julia version) are you on? (versioninfo() tells us 
> everything we need).
>
> fredag 6. mars 2015 19.27.48 UTC+1 skrev DP følgende:
>>
>> print("123",char(0x08),"567")
>> println()
>> print("123",char(0x09),"567")
>>
>> 123567
>>
>> 123 567
>>
>> As per ASCII Characters,
>>
>> ht horizontal tab 
>> bs backspace
>>
>> Why backspace is not working?
>> Am I doing something wrong?
>> ​
>>
>>

[julia-users] Re: Print(char(0x08))

[Ivar Nesje]

It works for me in the standard OSX terminal with a recent 0.4 version. 
What kind of system (and julia version) are you on? (versioninfo() tells us 
everything we need).

fredag 6. mars 2015 19.27.48 UTC+1 skrev DP følgende:
>
> print("123",char(0x08),"567")
> println()
> print("123",char(0x09),"567")
>
> 123567
>
> 123 567
>
> As per ASCII Characters,
>
> ht horizontal tab 
> bs backspace
>
> Why backspace is not working?
> Am I doing something wrong?
> ​
>
>

[julia-users] Job posting: high performance computing (image analysis and acquisition)

[Tim Holy]

(Apologies for cross-posting.)

We seek candidates with expertise in Julia and/or high-performance computing 
to develop software for a broad community of users of an imaging facility at 
Washington University in St. Louis. Challenges include working with "big data" 
(multi-terabyte multidimensional images) and the extensive application of 
machine-learning and numerical algorithms. An ideal candidate would also be 
comfortable with topics such as developing software interfaces for acquisition 
hardware, GPU computing, and/or multithreading. Candidates should be prepared 
to train users of the software, and to interact with them about possible 
refinements.

For more information, please contact Tim Holy (h...@wustl.edu).

Best,
--Tim

[julia-users] Print(char(0x08))

[DP]

print("123",char(0x08),"567")
println()
print("123",char(0x09),"567")

123567

123 567

As per ASCII Characters,

ht horizontal tab 
bs backspace

Why backspace is not working?
Am I doing something wrong?
​

Re: [julia-users] Unevenly distributed arrays

[Viral Shah]

Now that DistributedArrays.jl is a package - some of these things are much 
easier to experiment with.

-viral

On Friday, March 6, 2015 at 2:47:05 AM UTC+5:30, Andreas Noack wrote:
>
> I hope so. It is something we really want to do but I cannot promise when 
> we'll do it.
>
> 2015-03-04 17:01 GMT-05:00 Simone Ulzega :
>
>> Thank you Andreas. Is there any plan to implement something more flexible 
>> in the near future? 
>>  
>>
>> On Wednesday, March 4, 2015 at 10:09:41 PM UTC+1, Andreas Noack wrote:
>>>
>>> I don't think it is possible right now. We have been discussing more 
>>> flexible solutions, but so far nothing has been done.
>>>
>>> 2015-03-04 9:22 GMT-05:00 Simone Ulzega :
>>>
 Is it possible to construct a DArray with unevenly distributed chunks? 
 For example, I want to create a distributed array with size (5*n,), 
 where n is an integer, on 4 processes. 
 For some reasons I want uneven chunks of sizes n, 2*n, n and n.

 The syntax 

 DArray(size) do I  end  

 doesn't seem to work as I is automatically generated to have, 
 obviously, evenly distributed chunks on the available processes. 

>>>
>>>
>

[julia-users] Re: difficulty disabling multicore BLAS?

[Viral Shah]

It seems to work fine on 0.4. On my dual core i5:

julia> peakflops()
6.3990880531633675e10

julia> blas_set_num_threads(1)

julia> peakflops()
3.2582507660855206e10

-viral

On Friday, March 6, 2015 at 10:27:46 PM UTC+5:30, Steven G. Johnson wrote:
>
> For my numerics class at MIT , I 
> used the following notebook to talk about cache effects and matrix 
> multiplication:
>
> 
> http://nbviewer.ipython.org/url/math.mit.edu/~stevenj/18.335/Matrix-multiplication-experiments.ipynb
>
> It includes some code to benchmark the built-in BLAS-based multiplication 
> against some simpler algorithms, and for comparison purposes I used 
> blas_set_num_threads(1) to benchmark only serial performance... I thought.
>
> When I ran the benchmark on my desktop, the results made sense: OpenBLAS 
> got about 3 * 4 Gflops, which is peak performance for a 3GHz CPU that can 
> perform 4 flops per cycle (via 256-bit AVX instructions).   However, on my 
> laptop, it got about 40 gigaflops, which only makes sense if it was using 
> additional cores.  In both cases, this was with Julia 0.4 using OpenBLAS.
>
> Is there any reason why blas_set_num_threads(1) would not be sufficient to 
> disable additional cores?
>
> --SGJ
>

[julia-users] difficulty disabling multicore BLAS?

[Steven G. Johnson]

For my numerics class at MIT , I used 
the following notebook to talk about cache effects and matrix 
multiplication:

  
  
http://nbviewer.ipython.org/url/math.mit.edu/~stevenj/18.335/Matrix-multiplication-experiments.ipynb

It includes some code to benchmark the built-in BLAS-based multiplication 
against some simpler algorithms, and for comparison purposes I used 
blas_set_num_threads(1) to benchmark only serial performance... I thought.

When I ran the benchmark on my desktop, the results made sense: OpenBLAS 
got about 3 * 4 Gflops, which is peak performance for a 3GHz CPU that can 
perform 4 flops per cycle (via 256-bit AVX instructions).   However, on my 
laptop, it got about 40 gigaflops, which only makes sense if it was using 
additional cores.  In both cases, this was with Julia 0.4 using OpenBLAS.

Is there any reason why blas_set_num_threads(1) would not be sufficient to 
disable additional cores?

--SGJ

Re: [julia-users] Re: L1 Minimization?

[Steven G. Johnson]

On Thursday, March 5, 2015 at 4:58:10 PM UTC-5, Sheehan Olver wrote:
>
>
> Hmm, maybe I’m posing the wrong problem then…  I wanted a fast way to 
> calculate the null space of a sparse matrix, where the basis spanning the 
> null space is also sparse.  And the dimension of the vector space is in the 
> millions.
>

 In that case, why not use:

 min ||Lx||_1 subject to ||x||_1= 1  (or ||x||_\infty = 1)?

That can be transformed into an LP.   (As I understand it, the only reason 
for your norm constraint on x is to prevent the trivial x=0 solution, but 
won't any norm work for that?)

[julia-users] Re: L1 Minimization?

[Steven G. Johnson]

On Thursday, March 5, 2015 at 12:51:07 PM UTC-5, Iain Dunning wrote:
>
> I don't think anything in JuliaOpt other than NLOpt is going to play 
> nicely with that non-convex L2 norm constraint.
>

Actually, I would tend to transform the problem to eliminate the equality 
constraint:

min |Lx|_1 /  |x|_2

and then turn the |Lx|_1 into a dummy variable t and add 2N inequality 
constraints t >= (Lx)_i, t >= -(Lx)_i.

Nonlinear inequality constraints can be handled by NLopt, but in general I 
find it is better to have a nonlinear objective than a nonlinear inequality 
constraint when you have a choice, and in this particular problem that 
isn't difficult.Then any algorithm that supports nonlinear objectives 
and affine inequality constraints is applicable.

Re: [julia-users] Re: using Gadfly and PyPlot at the same time

[Steven G. Johnson]

On Friday, March 6, 2015 at 9:42:34 AM UTC-5, Andrei Berceanu wrote:
>
> ok so now im doing import PyPlot, but have some problems with the latex 
> axis labels
>>
>>
you could try

   using LaTeXStrings 

to pull in the L_str macro separately from PyPlot.   (I'm not sure if there 
is any nice syntax for using unimported string macros.)

[julia-users] Re: Confused about parametrization type

[Simon Danisch]

Mybe you're looking for this pattern:
type Foo{T <: String}
   a::T
   b::T
end
Foo(a::String, b::String) = Foo(promote(a,b)...)
If you don't know promote, here's an excerpt from help()
julia> help(promote)
Base.promote(xs...)

   Convert all arguments to their common promotion type (if any), and
   return them all (as a tuple).



Am Donnerstag, 5. März 2015 17:55:40 UTC+1 schrieb Benjamin Deonovic:
>
> Moving a post from julia issues to here since it is more appropriate: 
> https://github.com/JuliaLang/julia/issues/10408
>
> If I am making a function or composite type that involves floating point 
> numbers, should I enforce those numbers to be Float64 or FloatingPoint? I 
> thought 
> it should be FloatingPoint so that the function/type will work with any 
> kind of floating point number. However, several julia packages enforce 
> Float64 (e.g. Distributions package Multinomial distribution) and so I run 
> into problems and have to put in a lot of converts in my code to Float64. Am 
> I doing this wrong? I'm quite new to julia
>
>
> I don't have any intention to use non Float64 floatingpoints numbers, I'm 
> just trying to write good code. I saw a lot of examples where people 
> recommended to to use Integer rather than Int64 or String rather than 
> ASCIIString, etc. I'm just trying to be consistent. I'm fine just using 
> Float64 if that is the appropriate approach here.
>

Re: [julia-users] Re: Confused about parametrization type

[Tim Holy]

It depends a little bit on what you mean by "better":
- Using the first one will cause specialized functions to be compiled for each 
version
- Using the second one will use generic fallback code every time you access b

Consequently, the first should give faster performance at runtime, but have a 
larger compile-time overhead. In most cases, most users seem to want to 
maximize runtime performance.

--Tim

On Friday, March 06, 2015 07:14:26 AM Benjamin Deonovic wrote:
> That was the perfect resource, thank you Tim Holy!
> 
> Here's a question about a specific situation:
> 
> Suppose I have a type that has two String variables, but at construction,
> these might not be the same type of Strings (e.g. one might be ASCIIString,
> the other SubString{ASCIIString}). Which parametrization is better:
> 
> type Foo{T <: String, U <: String}
>a::T
>b::U
> end
> 
> or
> 
> type Foo{T <: String}
>a::T
>b::String
> end
> 
> On Thursday, March 5, 2015 at 2:59:40 PM UTC-6, Tim Holy wrote:
> > Extensive discussion here:
> > 
> > http://docs.julialang.org/en/release-0.3/manual/faq/#how-do-abstract-or-am
> > biguous-fields-in-types-interact-with-the-compiler
> > 
> > --Tim
> > 
> > On Thursday, March 05, 2015 12:50:59 PM Benjamin Deonovic wrote:
> > > This has been very helpful
> > > 
> > > @Ivar Nesje
> > > 
> > > Can you explain the difference between your two examples of type A? I
> > 
> > think
> > 
> > > that is where most of my confusion comes from.
> > > 
> > > On Thursday, March 5, 2015 at 12:24:12 PM UTC-6, Ivar Nesje wrote:
> > > >1. Make sure that your code is correct for the inputs you allow.
> > 
> > There
> > 
> > > >is no need to accept BigFloat (nor Float16) if you end up
> > 
> > converting to
> > 
> > > >Float64 for the calculation anyway (the user of your code can do
> > 
> > that
> > 
> > > >himself). If you don't care enough about different precisions to
> > 
> > even
> > 
> > > >think
> > > >about  how it will affect your program, I think it is better to add
> > 
> > a
> > 
> > > >TODO
> > > >comment in the code/documentation, so that others that care might
> > > >submit
> > > >the required changes in a PR.
> > > >2. Testing your algorithm with random Float16 and BigInt will
> > > >sometimes raise new issues that affects Float64, but is much harder
> > 
> > to
> > 
> > > >find
> > > >there. There is definitely value in thinking about how different
> > 
> > makes
> > 
> > > >a
> > > >difference (or why it doesn't).
> > > > 
> > > > Usually you shouldn't use abstract types in a type definition, but
> > 
> > rather
> > 
> > > > make a parametric type. This is for performance, because the current
> > 
> > Julia
> > 
> > > > runtime is very slow if it can't statically infer the types of the
> > 
> > members
> > 
> > > > of a type. See that
> > > > 
> > > > type A{T<:FloatingPoint}
> > > > 
> > > >   member::T
> > > > 
> > > > end
> > > > 
> > > > is usually much better than
> > > > 
> > > > type A
> > > > 
> > > > member::FloatingPoint
> > > > 
> > > > end
> > > > 
> > > > Regards
> > > > Ivar
> > > > 
> > > > torsdag 5. mars 2015 18.27.38 UTC+1 skrev Simon Danisch følgende:
> > > >> I think it's a good idea to have things parametric and type stable.
> > 
> > So
> > 
> > > >> I'd vote for T <: FloatingPoint.
> > > >> Like this, the type you call a function with can be propagated down
> > 
> > to
> > 
> > > >> all other functions and no conversions are needed.
> > > >> As you said, this gets difficult as some people have Float64 hard
> > 
> > coded
> > 
> > > >> all over the place. It's understandable as John pointed out.
> > > >> But for someone like me who works with GPU's which depending on the
> > > >> graphics card perform up to 30 times faster with Float32, this is
> > 
> > quite
> > 
> > > >> annoying as I always need to convert©.
> > > >> 
> > > >> Am Donnerstag, 5. März 2015 17:55:40 UTC+1 schrieb Benjamin Deonovic:
> > > >>> Moving a post from julia issues to here since it is more
> > 
> > appropriate:
> > > >>> https://github.com/JuliaLang/julia/issues/10408
> > > >>> 
> > > >>> If I am making a function or composite type that involves floating
> > 
> > point
> > 
> > > >>> numbers, should I enforce those numbers to be Float64 or
> > 
> > FloatingPoint?
> > 
> > > >>> I thought it should be FloatingPoint so that the function/type will
> > > >>> work with any kind of floating point number. However, several julia
> > > >>> packages enforce Float64 (e.g. Distributions package Multinomial
> > > >>> distribution) and so I run into problems and have to put in a lot of
> > > >>> converts in my code to Float64. Am I doing this wrong? I'm quite new
> > 
> > to
> > 
> > > >>> julia
> > > >>> 
> > > >>> 
> > > >>> I don't have any intention to use non Float64 floatingpoints
> > 
> > numbers,
> > 
> > > >>> I'm just trying to write good code. I saw a lot of examples where
> > > >>> people recommended to to

Re: [julia-users] How to generate composite types with a macro?

[Isaiah Norton]

Missing an `end` in both expressions.

>
julia> macro deftype(name)

   ex1 = :(immutable $name end)
 end
julia> @deftype foo
julia> foo()

On Thu, Mar 5, 2015 at 5:02 AM, Kaj Wiik  wrote:

> I have been trying to write a macro that would generate fields in a
> for-loop.
>
> However, when I try to generate the first line I get an error:
>
> julia> macro deftype(name,artype,num)
>ex1 = :(esc( immutable $name))
> ERROR: syntax: unexpected ")"
>
> julia> macro deftype(name,artype,num)
>ex1 = :(esc(quote immutable $name end))
> ERROR: syntax: extra token ")" after end of expression
>
>
> There must be a way to do this, I cannot find how...
>
> Thanks,
> Kaj
>
>

Re: [julia-users] Re: Confused about parametrization type

[Benjamin Deonovic]

That was the perfect resource, thank you Tim Holy!

Here's a question about a specific situation:

Suppose I have a type that has two String variables, but at construction, 
these might not be the same type of Strings (e.g. one might be ASCIIString, 
the other SubString{ASCIIString}). Which parametrization is better:

type Foo{T <: String, U <: String}
   a::T
   b::U
end

or 

type Foo{T <: String}
   a::T
   b::String
end

On Thursday, March 5, 2015 at 2:59:40 PM UTC-6, Tim Holy wrote:
>
> Extensive discussion here: 
>
> http://docs.julialang.org/en/release-0.3/manual/faq/#how-do-abstract-or-ambiguous-fields-in-types-interact-with-the-compiler
>  
>
> --Tim 
>
> On Thursday, March 05, 2015 12:50:59 PM Benjamin Deonovic wrote: 
> > This has been very helpful 
> > 
> > @Ivar Nesje 
> > 
> > Can you explain the difference between your two examples of type A? I 
> think 
> > that is where most of my confusion comes from. 
> > 
> > On Thursday, March 5, 2015 at 12:24:12 PM UTC-6, Ivar Nesje wrote: 
> > >1. Make sure that your code is correct for the inputs you allow. 
> There 
> > >is no need to accept BigFloat (nor Float16) if you end up 
> converting to 
> > >Float64 for the calculation anyway (the user of your code can do 
> that 
> > >himself). If you don't care enough about different precisions to 
> even 
> > >think 
> > >about  how it will affect your program, I think it is better to add 
> a 
> > >TODO 
> > >comment in the code/documentation, so that others that care might 
> > >submit 
> > >the required changes in a PR. 
> > >2. Testing your algorithm with random Float16 and BigInt will 
> > >sometimes raise new issues that affects Float64, but is much harder 
> to 
> > >find 
> > >there. There is definitely value in thinking about how different 
> makes 
> > >a 
> > >difference (or why it doesn't). 
> > > 
> > > Usually you shouldn't use abstract types in a type definition, but 
> rather 
> > > make a parametric type. This is for performance, because the current 
> Julia 
> > > runtime is very slow if it can't statically infer the types of the 
> members 
> > > of a type. See that 
> > > 
> > > type A{T<:FloatingPoint} 
> > > 
> > >   member::T 
> > > 
> > > end 
> > > 
> > > is usually much better than 
> > > 
> > > type A 
> > > 
> > > member::FloatingPoint 
> > > 
> > > end 
> > > 
> > > Regards 
> > > Ivar 
> > > 
> > > torsdag 5. mars 2015 18.27.38 UTC+1 skrev Simon Danisch følgende: 
> > >> I think it's a good idea to have things parametric and type stable. 
> So 
> > >> I'd vote for T <: FloatingPoint. 
> > >> Like this, the type you call a function with can be propagated down 
> to 
> > >> all other functions and no conversions are needed. 
> > >> As you said, this gets difficult as some people have Float64 hard 
> coded 
> > >> all over the place. It's understandable as John pointed out. 
> > >> But for someone like me who works with GPU's which depending on the 
> > >> graphics card perform up to 30 times faster with Float32, this is 
> quite 
> > >> annoying as I always need to convert©. 
> > >> 
> > >> Am Donnerstag, 5. März 2015 17:55:40 UTC+1 schrieb Benjamin Deonovic: 
> > >>> Moving a post from julia issues to here since it is more 
> appropriate: 
> > >>> https://github.com/JuliaLang/julia/issues/10408 
> > >>> 
> > >>> If I am making a function or composite type that involves floating 
> point 
> > >>> numbers, should I enforce those numbers to be Float64 or 
> FloatingPoint? 
> > >>> I thought it should be FloatingPoint so that the function/type will 
> > >>> work with any kind of floating point number. However, several julia 
> > >>> packages enforce Float64 (e.g. Distributions package Multinomial 
> > >>> distribution) and so I run into problems and have to put in a lot of 
> > >>> converts in my code to Float64. Am I doing this wrong? I'm quite new 
> to 
> > >>> julia 
> > >>> 
> > >>> 
> > >>> I don't have any intention to use non Float64 floatingpoints 
> numbers, 
> > >>> I'm just trying to write good code. I saw a lot of examples where 
> > >>> people recommended to to use Integer rather than Int64 or String 
> rather 
> > >>> than ASCIIString, etc. I'm just trying to be consistent. I'm fine 
> just 
> > >>> using Float64 if that is the appropriate approach here. 
>
>

Re: [julia-users] Re: using Gadfly and PyPlot at the same time

[Andrei Berceanu]

ok so now im doing import PyPlot, but have some problems with the latex 
axis labels

this used to work before
ax[:set_xlabel](L"$\kappa$")
while now it gives

@L_str not defined
so i tried
ax[:set_xlabel](PyPlot.L"$\kappa$")
which gives
syntax: invalid interpolation syntax: "\"



On Friday, March 6, 2015 at 2:16:58 PM UTC+1, René Donner wrote:
>
> To get rid of name clashed you could e.g. also say 
>
> import Gadfly 
> using PyPlot 
>
> Like this "plot" will refer to PyPlot.plot, and you can use "Gadfly.plot" 
> anytime you need Gadfly's plot. 
>
> You can find more info here: 
> http://docs.julialang.org/en/release-0.3/manual/modules/#summary-of-module-usage
>  
>
>
>
> Am 06.03.2015 um 14:12 schrieb Andreas Lobinger  >: 
>
> > Hello colleague, 
> > 
> > On Friday, March 6, 2015 at 2:05:19 PM UTC+1, Andrei Berceanu wrote: 
> > Hi guys, 
> > 
> > when I do 
> > 
> > using Gadfly, PyPlot 
> > 
> > i get 
> > Warning: using PyPlot.plot in module Main conflicts with an existing 
> identifier. 
> > 
> > And other warning of the same type. How can I solve this? 
> > 
> > 
> > I guess to solve this, you need to work on the packages (or even the 
> julia logic for exporting). Still you should be able to use (as this is a 
> warning only) both .plot by prefixing Gadly.plot and PyPlot.plot.   
> > 
>
>

[julia-users] Re: Chi square test in Julia?

[Benjamin Deonovic]

My pull has been merged: https://github.com/JuliaStats/HypothesisTests.jl

On Thursday, March 5, 2015 at 8:32:32 AM UTC-6, Benjamin Deonovic wrote:
>
> I implemented the chisquare test in julia. I made a pull request in the 
> HypothesisTests package. It hasn't been pulled yet, but probably will be 
> soon. 
>
> On Sunday, February 8, 2015 at 5:32:48 PM UTC-6, Arin Basu wrote:
>>
>> Hi All,
>>
>> Please pardon my ignorance, but how does one do chisquare test in Julia. 
>> Something like,
>>
>> ```
>>
>> chisq.test(x, y = NULL, correct = TRUE,
>>p = rep(1/length(x), length(x)), rescale.p = FALSE,
>>simulate.p.value = FALSE, B = 2000)
>>
>> ```
>>
>> in R
>>
>>
>> I could not find anything in the documentation. I must not have searched 
>> enough, what can it be?
>>
>>
>> Best,
>>
>> Arin
>>
>>

Re: [julia-users] Re: using Gadfly and PyPlot at the same time

[René Donner]

To get rid of name clashed you could e.g. also say

import Gadfly
using PyPlot

Like this "plot" will refer to PyPlot.plot, and you can use "Gadfly.plot" 
anytime you need Gadfly's plot.

You can find more info here: 
http://docs.julialang.org/en/release-0.3/manual/modules/#summary-of-module-usage



Am 06.03.2015 um 14:12 schrieb Andreas Lobinger :

> Hello colleague,
> 
> On Friday, March 6, 2015 at 2:05:19 PM UTC+1, Andrei Berceanu wrote:
> Hi guys,
> 
> when I do 
> 
> using Gadfly, PyPlot 
> 
> i get
> Warning: using PyPlot.plot in module Main conflicts with an existing 
> identifier.
> 
> And other warning of the same type. How can I solve this? 
> 
> 
> I guess to solve this, you need to work on the packages (or even the julia 
> logic for exporting). Still you should be able to use (as this is a warning 
> only) both .plot by prefixing Gadly.plot and PyPlot.plot.  
> 

[julia-users] Re: using Gadfly and PyPlot at the same time

[Andreas Lobinger]

Hello colleague,

On Friday, March 6, 2015 at 2:05:19 PM UTC+1, Andrei Berceanu wrote:
>
> Hi guys,
>
> when I do 
>
> using Gadfly, PyPlot 
>
> i get
>
> Warning: using PyPlot.plot in module Main conflicts with an existing 
> identifier.
>
> And other warning of the same type. How can I solve this? 
>
>
>
I guess to solve this, you need to work on the packages (or even the julia 
logic for exporting). Still you should be able to use (as this is a warning 
only) both .plot by prefixing Gadly.plot and PyPlot.plot.  

[julia-users] using Gadfly and PyPlot at the same time

[Andrei Berceanu]

Hi guys,

when I do 

using Gadfly, PyPlot 

i get

Warning: using PyPlot.plot in module Main conflicts with an existing identifier.

And other warning of the same type. How can I solve this? 

[julia-users] creation of parametric variables in a macro

[Abe Schneider]

I'm trying to create a set of variables (_1, _2, ...) from items within a 
list in a macro. I have a (much) condensed version of the code:

macro testfn()
quote
i = 1
value = [1, 2, 3]
$(Expr(:(=), Expr(:symbol, Expr(:string, "_", :i)), :value))
println(_1)
end
end


which gives me:

ERROR: syntax: invalid assignment location


Any ideas on what might be wrong or the proper way to do this? I would like 
to keep this in the quotes, as in the actual version there's a lot more 
code surrounding the assignment.

I can get things to work with an eval, but I rather avoid the eval, and it 
appears to create a non-local variable.


Thanks!

Re: [julia-users] Re: Getting people to switch to Julia - tales of no(?) success

[Joachim Dahl]

My story is similar.  I have no reservations recommending Julia to 
colleagues what-so-ever.  

I write optimization software for a living,  and I've used the basic parts 
of Matlab or Python + addons in past, but always got so annoyed that I 
switched back and forth between them for different projects.

With Julia I finally found something that I really like.  I can structure 
my Julia prototype in a way that's easily portable to C later on, and it's 
a bliss to write larger projects. 

I've written Julia prototypes for a complete conic interior-point 
optimizer, a graph partition algorithm for reordering large sparse 
matrices, and a toolbox for polynomial optimization using semidefinite 
programming, and the code is nice and clean and scales well.  I could not 
have done that with either Matlab or Python.

Things have broken for me in Julia when I upgrade,  but I've always been 
able to update my projects in a couple of hours (after line-number 
reporting in error messages has become sensible).



Den fredag den 6. marts 2015 kl. 09.42.29 UTC+1 skrev Daniel Carrera:
>
> On Thursday, 5 March 2015 18:49:24 UTC+1, Stefan Karpinski wrote:
>>
>> It's the people who are desperately unhappy with what they currently use 
>> that might really benefit – and those people do exist. 
>>
>
> *raises his hand*
>
> That is exactly me. For years I have wanted a language for scientific 
> computing with a nice syntax, nice API, and open source. I never managed to 
> like Python + NumPy. I was using Octave, and I was on the mailing list 
> asking if they'd consider making a few more improvements on the Matlab 
> syntax when someone said "have a look at Julia, it has the things you are 
> asking for". That was about a year after the official release of Julia (I 
> think).
>
>  
>
>> but you'll have to deal with sometimes implementing things that other 
>> language already have packages for and with packages sometimes breaking 
>> when you upgrade them (the secret is don't upgrade often).
>>
>
> Yeah. When my last paper was getting ready to be submitted I upgraded 
> *nothing*, even though a new and faster version of Julia had just come out. 
> I could not take the risk of some of my scripts breaking at the last minute.
>
>  
>
>> As long as that tradeoff is clear, I think it's ok to recommend Julia, 
>> but one does have to set expectations honestly and not oversell it.
>>
>
> Yeah. A couple of people have asked me about Julia and I tell them 
> something similar to what you just wrote.
>
> Cheers,
> Daniel.
>  
>

Re: [julia-users] Re: L1 Minimization?

[Christoph Ortner]

I can send you some thoughts over email, but this is not Julia related, so 
I won't post here.  Christoph

Re: [julia-users] Re: Getting people to switch to Julia - tales of no(?) success

[Daniel Carrera]

On Thursday, 5 March 2015 18:49:24 UTC+1, Stefan Karpinski wrote:
>
> It's the people who are desperately unhappy with what they currently use 
> that might really benefit – and those people do exist. 
>

*raises his hand*

That is exactly me. For years I have wanted a language for scientific 
computing with a nice syntax, nice API, and open source. I never managed to 
like Python + NumPy. I was using Octave, and I was on the mailing list 
asking if they'd consider making a few more improvements on the Matlab 
syntax when someone said "have a look at Julia, it has the things you are 
asking for". That was about a year after the official release of Julia (I 
think).

 

> but you'll have to deal with sometimes implementing things that other 
> language already have packages for and with packages sometimes breaking 
> when you upgrade them (the secret is don't upgrade often).
>

Yeah. When my last paper was getting ready to be submitted I upgraded 
*nothing*, even though a new and faster version of Julia had just come out. 
I could not take the risk of some of my scripts breaking at the last minute.

 

> As long as that tradeoff is clear, I think it's ok to recommend Julia, but 
> one does have to set expectations honestly and not oversell it.
>

Yeah. A couple of people have asked me about Julia and I tell them 
something similar to what you just wrote.

Cheers,
Daniel.
 

Re: [julia-users] Re: Julia users Berlin

[Felix Jung]

Hi all,

why not use meetup? I sure got the feeling it'a the go-to platform for this 
sort of thing.

Good thinking on those julia best practices. I do have the feeling I'm not 
doing things the best way (i.e. I specify function parameter types almost all 
the time, despite knowing I don't have to).

Hope this works out somehow.

Felix




> On 05 Mar 2015, at 14:14, David Higgins  wrote:
> 
> Hi all,
> 
> Alex: I'm not around on those dates, but you should definitely go ahead and 
> meet up there!
> 
> I was thinking of probably using Meet-up to try to organise a Users Group 
> meeting. Does anyone know of any other site which offers similar 
> functionality? (for free??)
> 
> I'm particularly interested in meeting existing users to hear how they use 
> the language. With every new programming language you learn there are a bunch 
> of bad habits you initially develop in your programming. I'm hoping to use 
> this interaction to remove them from my Julia coding. Also, I'd like exposure 
> to the wider Julia Libraries which I don't encounter in my daily work.
> 
> David.
> 
>> On Tuesday, 3 March 2015 12:31:06 UTC+1, Alex wrote:
>> Hi together,
>> 
>> As you might know the Spring Meeting of the German Physical Society is held 
>> in Berlin from 15/03 to 20/03. Maybe this would be an opportunity to have a 
>> (small) Julia meeting/get-together of some sort? There certainly must be 
>> some Julians among the ~6k participants ...
>> 
>> Best,
>> 
>> Alex.