Re: [julia-users] Question: Forcing readtable to create string type on import

[Michael Krabbe Borregaard]

DataFrames is currently undergoing a very major change. Looks like CSV
creates the new type of DataFrames. I hope someone can help you with using
that. As a workaround, on the normal DataFrames version, I have generally
just replaced with a string representation:
```
df[:account_numbers] = ["$account_number" for account_number in
df[:account_numbers]]

On Thu, Nov 3, 2016 at 3:05 PM, LeAnthony Mathews 
wrote:

> Sure, so I need col #1 in my CSV to be a string in my data frame.
>
> So as a test  I tried to load the file 3 different ways:
>
> *df1_CSV = CSV.read("$df1_path"; types=Dict(1=>String))  #forcing the
> column to stay a string*
> *df1_readtable = readtable("$df1_path")  #Do not know how to force the
> column to stay a string*
> *df1_convertDF = convert(DataFrame, df1_CSV)*
>
> Here is the output:  If they are all dataframes then showcols should work
> an all three df1:
>
> *julia> names(df1_CSV)*
> 3-element Array{Symbol,1}:
>  :account_number
>  Symbol("Discharge Date")
>  :site
>
> *julia> names(df1_readtable)*
> 3-element Array{Symbol,1}:
>  :account_number
>  :Discharge_Date
>  :site
>
> *julia> names(df1_convertDF)*
> 3-element Array{Symbol,1}:
>  :account_number
>  Symbol("Discharge Date")
>  :site
>
>
> *julia> eltypes(df1_CSV)*
> 3-element Array{Type,1}:
>  Nullable{String}
>  Nullable{WeakRefString{UInt8}}
>  Nullable{WeakRefString{UInt8}}
>
> *julia> eltypes(df1_readtable)*
> 3-element Array{Type,1}:
>  Int32   *#Do not know how to force the column to stay a string*
>  String
>  String
>
> *julia> eltypes(df1_convertDF)*
> 3-element Array{Type,1}:
>  Nullable{String}
>  Nullable{WeakRefString{UInt8}}
>  Nullable{WeakRefString{UInt8}}
>
> *julia> showcols(df1_convertDF)*
> 1565x3 DataFrames.DataFrame
> ERROR: MethodError: no method matching countna(::NullableArrays.
> NullableArray{St
> ring,1})
> Closest candidates are:
>   countna(::Array{T,N}) at C:\Users\lmathews\.julia\v0.5\
> DataFrames\src\other\ut
> ils.jl:115
>   countna(::DataArrays.DataArray{T,N}) at C:\Users\lmathews\.julia\v0.5\
> DataFram
> es\src\other\utils.jl:128
>   countna(::DataArrays.PooledDataArray{T,R<:Integer,N}) at
> C:\Users\lmathews\.ju
> lia\v0.5\DataFrames\src\other\utils.jl:143
>  in colmissing(::DataFrames.DataFrame) at C:\Users\lmathews\.julia\v0.5\
> DataFram
> es\src\abstractdataframe\abstractdataframe.jl:657
>  in showcols(::Base.TTY, ::DataFrames.DataFrame) at
> C:\Users\lmathews\.julia\v0.
> 5\DataFrames\src\abstractdataframe\show.jl:574
>  in showcols(::DataFrames.DataFrame) at C:\Users\lmathews\.julia\v0.5\
> DataFrames
> \src\abstractdataframe\show.jl:581
>
> *julia> showcols(df1_readtable)*
> 1565x3 DataFrames.DataFrame
> │ Col # │ Name   │ Eltype │ Missing │
> ├───┼┼┼─┤
> │ 1 │ account_number │ Int32  │ 0   │
> │ 2 │ Discharge_Date │ String │ 0   │
> │ 3 │ site   │ String │ 0   │
>
> *julia> showcols(df1_CSV)*
> 1565x3 DataFrames.DataFrame
> ERROR: MethodError: no method matching countna(::NullableArrays.
> NullableArray{St
> ring,1})
> Closest candidates are:
>   countna(::Array{T,N}) at C:\Users\lmathews\.julia\v0.5\
> DataFrames\src\other\ut
> ils.jl:115
>   countna(::DataArrays.DataArray{T,N}) at C:\Users\lmathews\.julia\v0.5\
> DataFram
> es\src\other\utils.jl:128
>   countna(::DataArrays.PooledDataArray{T,R<:Integer,N}) at
> C:\Users\lmathews\.ju
> lia\v0.5\DataFrames\src\other\utils.jl:143
>  in colmissing(::DataFrames.DataFrame) at C:\Users\lmathews\.julia\v0.5\
> DataFram
> es\src\abstractdataframe\abstractdataframe.jl:657
>  in showcols(::Base.TTY, ::DataFrames.DataFrame) at
> C:\Users\lmathews\.julia\v0.
> 5\DataFrames\src\abstractdataframe\show.jl:574
>  in showcols(::DataFrames.DataFrame) at C:\Users\lmathews\.julia\v0.5\
> DataFrames
> \src\abstractdataframe\show.jl:581
>
>
>
> On Thursday, November 3, 2016 at 8:54:19 AM UTC-4, Michael Borregaard
> wrote:
>>
>> The result of CSV should be a DataFrame by default.  What return type do
>> you get?
>>
>

Re: [julia-users] Re: julia installation broken

[Michael Krabbe Borregaard]

Thanks a lot, Jeffrey! Incredibly, this worked.

Best,
Michael

On Fri, Sep 16, 2016 at 6:48 PM, Jeffrey Sarnoff 
wrote:

> I have had this happen, too.  My suggestion is  grounded in persistence
> rather than deep mastery of Julia's structural and file relationships.
> So someone else may have a more studied approach with some explaining.
> Until then,
>
> quit() Julia.
> To have an new install be really clean, first cd  to /.julia/
> and delete the directory `v0.5` -- if that is overkill because you do not
> want to redo many Pkg.add()s then cd v0.5 and delete the METADATA directory
> the REQUIRE file and the META_BRANCH file and the entry for whatever
> packages you had added just before this difficulty (including those that
> have hiccuped on precompile).
> now delete and then reget the most current binary for your system
> julia-0.5.0-rc4-osx10.7+.dmg
> 
> install
> Then start julia and quit().  Then start Julia and do Pkg.update() then
> quit().
> Then start julia and do Pkg.add() for 1 package you want then quit(). then
> start julia and do using  (so it precompiles) and quit().
> now try using that package.
>
>
>
>
>
>
> On Friday, September 16, 2016 at 4:43:06 AM UTC-4, Michael Borregaard
> wrote:
>>
>> Hi, Is this the right forum for troubleshooting / issues with my julia
>> install?
>>
>> I have kept having problems with packages giving error on precompile,
>> rendering julia unusable. I then reinstalled julia-0.5-rc4, and removed my
>> .julia folder from my home dir to do a fresh install. Now, Julia fails with
>> an error message when I do Pkg.update():
>>
>> julia> Pkg.update()
>> INFO: Initializing package repository /Users/michael/.julia/v0.5
>> INFO: Cloning METADATA from https://github.com/JuliaLang/METADATA.jl
>> ERROR: SystemError (with /Users/michael/.julia/v0.5/METADATA): rmdir:
>> Directory not empty
>>  in #systemerror#51 at ./error.jl:34 [inlined]
>>  in (::Base.#kw##systemerror)(::Array{Any,1}, ::Base.#systemerror,
>> ::Symbol, ::Bool) at ./:0
>>  in #rm#7(::Bool, ::Bool, ::Function, ::String) at ./file.jl:125
>>  in #rm#7(::Bool, ::Bool, ::Function, ::String) at
>> /Applications/Julia-0.5.app/Contents/Resources/julia/lib/jul
>> ia/sys.dylib:?
>>  in (::Base.Filesystem.#kw##rm)(::Array{Any,1}, ::Base.Filesystem.#rm,
>> ::String) at ./:0
>>  in init(::String, ::String) at ./pkg/dir.jl:62
>>  in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String,
>> ::Vararg{Any,N}) at ./pkg/dir.jl:28
>>  in update() at ./pkg/pkg.jl:210
>>
>> I assums that a completely clean install should work. Are there keys to
>> delete etc that will give me a properly clean install? I am on Mac OS X
>> (newest version).
>> Thanks!
>>
>

Re: [julia-users] code design question – best ideomatic way to define nested types?

[Michael Krabbe Borregaard]

"An hour", pfhh, I only wish I was that efficient. I really like it, also
looking very much forward to reading the comments people will make on this.

On Tue, Sep 13, 2016 at 4:16 PM, Tom Breloff <t...@breloff.com> wrote:

> I stole an hour this morning and implemented this: https://github.com/
> tbreloff/ConcreteAbstractions.jl
>
> It's pretty faithful to my earlier description, except that the macros
> names are `@base` and `@extend`.  Comments/criticisms welcome!
>
> On Tue, Sep 13, 2016 at 9:57 AM, Michael Krabbe Borregaard <
> mkborrega...@gmail.com> wrote:
>
>> First, apologies, I didn't mean that you wanted to 'subvert' (
>> http://www.merriam-webster.com/dictionary/subvert) julia. As a
>> non-native speaker the finer nuances of English sometimes slip. The word I
>> was looking for was perhaps 'sidestep'.
>> Also I see your point that as long as the Abstract type cannot be
>> instantiated, the problem with putting supertypes in an array should not be
>> relevant. So perhaps this is actually a nice general solution to the issue.
>>
>
>

Re: [julia-users] code design question – best ideomatic way to define nested types?

[Michael Krabbe Borregaard]

First, apologies, I didn't mean that you wanted to 'subvert' (
http://www.merriam-webster.com/dictionary/subvert) julia. As a non-native
speaker the finer nuances of English sometimes slip. The word I was looking
for was perhaps 'sidestep'.
Also I see your point that as long as the Abstract type cannot be
instantiated, the problem with putting supertypes in an array should not be
relevant. So perhaps this is actually a nice general solution to the issue.

Re: [julia-users] Re: lower triangular matrix in julia

[Michael Krabbe Borregaard]

A symmetric matrix and a lower triangular matrix are different things. Look
for what you want here:
http://julia.readthedocs.io/en/latest/manual/linear-algebra/ and here:
http://julia.readthedocs.io/en/latest/stdlib/linalg/

On Fri, Aug 19, 2016 at 4:07 PM, Ahmed Mazari 
wrote:

> 4×4 Array{Int64,2}:
>  0  1  2  3
>  1  0  4  5
>  2  4  0  6
>  3  5  6  0
>
> a symetric matrix m[i,j] =m[j,i]  and m[i,i]= 0
>
> On Fri, Aug 19, 2016 at 3:59 PM, Jeffrey Sarnoff <
> jeffrey.sarn...@gmail.com> wrote:
>
>> Is this what you want, or are you looking for a more general way to
>> construct nxn matrices like this 4x4 matrix, or something else?
>>
>> julia> m = [ [0,1,2,3] [1,0,4,5] [2,3,0,6] [4,5,6,0] ]
>> 4×4 Array{Int64,2}:
>>  0  1  2  4
>>  1  0  3  5
>>  2  4  0  6
>>  3  5  6  0
>>
>>
>> On Friday, August 19, 2016 at 9:01:06 AM UTC-4, Ahmed Mazari wrote:
>>>
>>> Yes but it doesn't allow me to set the diagonal to 0 ??
>>>
>>> On Fri, Aug 19, 2016 at 2:55 PM, Michael Borregaard >> > wrote:
>>>
 You can build the matrix as normal, then specify that the upper
 triangle is undefined by
 mat = LowerTriangular(mat) # where mat is a Matrix of any eltype.

>>>
>>>
>

Re: [julia-users] Re: When can the broadcast dot (in 0.5) be used?

[Michael Krabbe Borregaard]

That's wonderful news, thanks a lot for this. I know .() is just syntactic
sugar, but to me it really feels intuitive and powerful. Thanks again,
Michael

On Thu, Aug 18, 2016 at 8:27 PM, Steven G. Johnson 
wrote:

> (If you want dot calls to work with your own container type, then you just
> need to make broadcast(...) work.  e.g. here is some discussion for
> ApproxFun: https://github.com/ApproxFun/ApproxFun.jl/issues/356)
>

Re: [julia-users] Re: When can the broadcast dot (in 0.5) be used?

[Michael Krabbe Borregaard]

It'd be nice with a list of the methods a user-defined type would need to
define to be amenable to .() in an Array.

On Thu, Aug 18, 2016 at 8:16 PM, Michael Krabbe Borregaard <
mkborrega...@gmail.com> wrote:

> Thanks! Right now it makes a difference for my understanding just to know
> that this is an issue with String, and that .() will otherwise behave like
> map.
>

Re: [julia-users] Re: When can the broadcast dot (in 0.5) be used?

[Michael Krabbe Borregaard]

Thanks! Right now it makes a difference for my understanding just to know
that this is an issue with String, and that .() will otherwise behave like
map.

Re: [julia-users] Re: When can the broadcast dot (in 0.5) be used?

[Michael Krabbe Borregaard]

That sounds right. I wonder if this is not a bug?

Re: [julia-users] precompiling all packages

[Michael Krabbe Borregaard]

Nice, thanks!
#MakePkg.update()GreatAgain!

On Tue, Aug 9, 2016 at 12:46 PM, Kristoffer Carlsson 
wrote:

> Can look at this:
>
> https://github.com/staticfloat/MakePkgUpdatePrecompileInTheBackground.jl
>
> https://github.com/JuliaLang/julia/issues/16409#issuecomment-228873060

Re: [julia-users] R code to Julia Performance issues with pmap

[Michael Krabbe Borregaard]

Ah, forgot that the system.time is a bit tricky when running parallel cores

Re: [julia-users] Re: polynomial terms in formula specification

[Michael Krabbe Borregaard]

And... Sorry if I sounded unnecessarily critical, I just hoped to argue the
case for a change. I know all decisions in Julia are based on careful
consideration of all the options.

Re: [julia-users] How do I find out which package is causing problems running Pkg.update()

[Michael Krabbe Borregaard]

Thanks! After a bit if experimenting I could Pkg.checkout("Atom",
"julia-0.4"), which solved the issue.

Re: [julia-users] How do I find out which package is causing problems running Pkg.update()

[Michael Krabbe Borregaard]

Sorry for being slow but I am not sure I understand what you suggest?

On Tue, Jun 7, 2016 at 2:38 PM, Yichao Yu  wrote:

> On Tue, Jun 7, 2016 at 8:06 AM, Michael Borregaard
>  wrote:
> > Hi,
> > I cannot Pkg.update(), I get the error message:
> >
> > ERROR: ASTInterpreter can't be installed because it has no versions that
> > support 0.4.5 of julia. You may need to update METADATA by running
> > `Pkg.update()`
> >  in error at error.jl:22
> >  in resolve at
> >
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
> >  in update at
> >
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
> >  in anonymous at pkg/dir.jl:31
> >  in cd at file.jl:22
> >  in cd at pkg/dir.jl:31
> >  in update at
> >
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
> >
> > I do not have ASTInterpreter installed, neither do I have Gallium, which
> > apparently references it. I would like to know which package is causing
> the
> > issue, so I can create an issue on their github or uninstall it. I
> > downloaded the newest stable version of julia and installed it, but it
> did
> > not help.
> >
> > The problem means that e.g. my Atom package is in an unstable state, so I
> > cannot use my normal julia workflow. Please refer me to if this should
> be an
> > issue somewhere else, but I guess the issue of finding out the criminal
> > package (that tries to install ASTInterpreter) is general enough for this
> > mailing list.
>
> IIRC the Atom master doesn't support 0.4 and you need the 0.4 branch
> or the latest tag.
>
> >
> >
> > Thanks a lot,
> > Michael
>

Re: [julia-users] Re: convert array elements

[Michael Krabbe Borregaard]

Well, what do you know, it behaves differently in a function. Food for
thought. Thanks a lot!

On Thu, May 12, 2016 at 3:38 PM, Kristoffer Carlsson 
wrote:

> Try it in a function. Array comprehensions are a bit annoying that the
> results depend on the ability of type inference to figure out the result
> type. There is an issue tracking this:
> https://github.com/JuliaLang/julia/issues/7258
>
> On Thursday, May 12, 2016 at 3:36:06 PM UTC+2, Michael Borregaard wrote:
>>
>> Awesome, thank you! I love the Julia 0.5 implementation.
>> PS. On my system ["$x" for x in ID] gives an Array{Any}, this seems to be
>> a general issue with array comprehensions.
>>
>> On Thu, May 12, 2016 at 12:38 PM, Steven G. Johnson 
>> wrote:
>>
>>>
>>>
>>> On Thursday, May 12, 2016 at 6:34:30 AM UTC-4, Michael Borregaard
>>> wrote:y - the 'easiest' way of doing this is

 ID = [UTF8String("$x") for x in ID]


>>> map(string, ID) converts all elements of ID to strings.   You could also
>>> use ["$x" for x in ID].   In Julia 0.5 you can do string.(ID)
>>>
>>
>>

Re: [julia-users] Re: convert array elements

[Michael Krabbe Borregaard]

Awesome, thank you! I love the Julia 0.5 implementation.
PS. On my system ["$x" for x in ID] gives an Array{Any}, this seems to be a
general issue with array comprehensions.

On Thu, May 12, 2016 at 12:38 PM, Steven G. Johnson 
wrote:

>
>
> On Thursday, May 12, 2016 at 6:34:30 AM UTC-4, Michael Borregaard wrote:y
> - the 'easiest' way of doing this is
>>
>> ID = [UTF8String("$x") for x in ID]
>>
>>
> map(string, ID) converts all elements of ID to strings.   You could also
> use ["$x" for x in ID].   In Julia 0.5 you can do string.(ID)
>

Re: [julia-users] if .. else on a whole array

[Michael Krabbe Borregaard]

Thanks for clarifying that!
So do you suggest
[code]
function foo(x::bar)
  #the function body
end

function foo(x::AbstractVector{bar})
  map(foo, x)
end
[/code]

On Thu, Feb 11, 2016 at 10:33 AM, Tim Holy  wrote:

> If the input is a scalar and the output is a scalar, that's also
> type-stable.
> Type-stability is about "predictability of the output type, given the input
> types," not "always returns the same type."
>
> Also, wrapping scalars in an array will have a significant performance
> cost.
>
> Best,
> --Tim
>
> On Thursday, February 11, 2016 12:44:19 AM Michael Borregaard wrote:
> > Note that both of these versions will return an array, allowing for type
> > stability
> >
> > Den torsdag den 11. februar 2016 kl. 09.40.27 UTC+1 skrev Michael
> >
> > Borregaard:
> > > If you are worried about maintaining two versions, that can be solved
> > > simply:
> > > function foo(x::Vector{bar})
> > >
> > >   #the main code of your function
> > >
> > > end
> > >
> > > function foo(x::bar)
> > >
> > >   foo([x])
> > >
> > > end
>
>

Re: [julia-users] Re: multiple methods with keyword arguments?

[Michael Krabbe Borregaard]

Thanks, that looks interesting, I will check out the Parameters.jl package!

On Wed, Jan 6, 2016 at 9:03 AM, Mauro  wrote:

> > OK, so that is the long way to do it.
> > I just thought that, since multiple dispatch does not work on keyword
> > arguments, they should by definition be the same for all methods, no?
> > Otherwise you end up with keyword arguments throwing an error because the
> > type of a different argument changing, an error that is hard to debug
> > because the kwargs do not show up under a methods(foo) call. Seems to me
> > such a potentially ripe source of bugs that julia would have an inbuilt
> (or
> > at least recommended ideomatic) way of dealing with it.
>
> No, I don't think that would help either as keywords are not necessarily
> the same for different methods.  What you can do is:
>
> f(x,y; kws...) = (deal_with_kws(kws); ...)
>
> Or use metaprogramming to make sure all you keywords are the same.
>
> You should consider using an option structure.  I think Parameters.jl
> can help with that:
>
> @with_kw immutable Opts
>t=5
>u=9
> end
>
> f(x,y, opts=Opts()) = ...
> f(x, opts=Opts()) = ...
> ...
>
> # call with default opts
> f(x,y)
> # call with non-default opts
> f(x,y, Opts(t=7))
>
> > Den onsdag den 6. januar 2016 kl. 00.09.10 UTC+1 skrev Jeffrey Sarnoff:
> >>
> >> If you want all methods to use the same keyword arguments, define each
> >> method with the same keyword arguments.  You can declare keyword
> arguments'
> >> types.
> >>
> >> function foo(a::Int; test::Bool = true)
> >>if test
> >>a
> >>else
> >>0
> >>end
> >> end
> >>
> >> function foo(a::AbstractFloat; test::Bool = true)
> >>if test
> >>a
> >>else
> >>100.0
> >>end
> >> end
> >>
> >> foo(1)
> >> 1
> >> foo(1,false)
> >> 0
> >> foo(1,"grue")
> >> ERROR
> >>
> >> foo(1.0)
> >> 1.0
> >> foo(1.0,false)
> >> 100.0
> >> foo(1.0,"grue")
> >> ERROR
> >>
> >>
> >>
> >> On Tuesday, January 5, 2016 at 4:30:14 PM UTC-5, Michael Borregaard
> wrote:
> >>>
> >>> Hi, sorry I have a simple question, I have tried to RTFM.
> >>>
> >>> If I have a function with multiple methods and keyword arguments, all
> >>> methods should share the same keyword args, right? How do I write this?
> >>>
> >>> function foo(a::Int; test = true)
> >>> 2+a
> >>> end
> >>>
> >>> function foo(a::AbstractFloat #how do I continue this line?
> >>>
> >>> In my real-world example I have multiple methods and a long list of
> >>> keyword arguments.
> >>>
> >>> Thanks!
> >>>
> >>
>

Re: [julia-users] Re: multiple methods with keyword arguments?

[Michael Krabbe Borregaard]

Maybe writing generic code is the way to solve it. I thought it was
preferred style to always specify the type of function arguments, to make
sure that the user supplies arguments that actually support the operations
defined in the function meaningfully?


On Wed, Jan 6, 2016 at 12:33 PM, James Gilbert  wrote:

> Do you need to specify the type of the argument "a"? Without specifying
> the type of "a", you can write generic code, and let Julia take care of
> generating methods for the different types.
>
> If you find that you're passing the same sets of keyword arguments to a
> set of functions, maybe you should define your own composite type to hold
> the arguments.
>

Re: [julia-users] Re: multiple methods with keyword arguments?

[Michael Krabbe Borregaard]

Interesting. I come from R, and one of the main advantages I feel Julia has
is that I do not have to do any in-function testing of what types of
arguments the user has passed into the function, generating error messages
etc. In Julia, all of this is handled automatically if I specify a function
argument.

I would think the ideal way of doing it would be to specify a function
argument with a broad type (e.g. Number) that is meaningful for all the
operations in the function, and prevents the user from e.g. passing in a
string and getting a weird error message, or a bool and getting something
spurious. Unfortunately, most of my functions do not take simple types,
they take Vectors, and a Vector{Int} does not inherit from a
Vector{Number}! - meaning that the whole idea of inheritance is a bit lost
for me. I guess I can do foo{T <: Number}(a::Vector{T}) but that goes very
far from the easy non-specifying format that you support.

In short, I am really confused about how to use types well in Julia
functions - and I did read the style guide. Can you guide me a bit more
towards a good approach?

Thanks

On Wed, Jan 6, 2016 at 1:27 PM, James Gilbert  wrote:

> You'd think, reading this forum, that the preferred style is to specify
> the type of function arguments. I think that's what feels right for people
> with experience in other languages. Specifying argument types doesn't
> necessarily improve speed, and harms the reusability of code.
>

Re: [julia-users] Re: multiple methods with keyword arguments?

[Michael Krabbe Borregaard]

Thanks a lot!

On Wed, Jan 6, 2016 at 2:00 PM, Milan Bouchet-Valat <nalimi...@club.fr>
wrote:

> Le mercredi 06 janvier 2016 à 13:48 +0100, Michael Krabbe Borregaard a
> écrit :
> > Interesting. I come from R, and one of the main advantages I feel
> > Julia has is that I do not have to do any in-function testing of what
> > types of arguments the user has passed into the function, generating
> > error messages etc. In Julia, all of this is handled automatically if
> > I specify a function argument.
> Yes, that's a feature that I really appreciate too! When it is obvious
> that one is expecting e.g. a Number or an AbstractString, there's no
> reason not to restrict the type (both for correctness and
> documentation).
>
> > I would think the ideal way of doing it would be to specify a
> > function argument with a broad type (e.g. Number) that is meaningful
> > for all the operations in the function, and prevents the user from
> > e.g. passing in a string and getting a weird error message, or a bool
> > and getting something spurious. Unfortunately, most of my functions
> > do not take simple types, they take Vectors, and a Vector{Int} does
> > not inherit from a Vector{Number}! - meaning that the whole idea of
> > inheritance is a bit lost for me. I guess I can do foo{T <:
> > Number}(a::Vector{T}) but that goes very far from the easy non
> > -specifying format that you support.
> >
> > In short, I am really confused about how to use types well in Julia
> > functions - and I did read the style guide. Can you guide me a bit
> > more towards a good approach?
> You're hitting a property called type invariance. See
> http://docs.julialang.org/en/release-0.4/manual/types/#parametric-compo
> site-types
>
> There's nothing wrong with writing foo{T<:Number}(a::Vector{T}).
> That's the recommended way, though that it's a bit verbose (maybe a
> shorter syntax will be added at some point).
>
>
> Regards
>
>
> > Thanks
> >
> > On Wed, Jan 6, 2016 at 1:27 PM, James Gilbert <jgrgilb...@gmail.com>
> > wrote:
> > > You'd think, reading this forum, that the preferred style is to
> > > specify the type of function arguments. I think that's what feels
> > > right for people with experience in other languages. Specifying
> > > argument types doesn't necessarily improve speed, and harms the
> > > reusability of code.
> > >
>

Re: [julia-users] Re: Strange behaviour on type dependency of function

[Michael Krabbe Borregaard]

Thanks, I will edit it to Int64.

On Tue, Jan 5, 2016 at 12:50 PM, Lutfullah Tomak 
wrote:

> Good you sorted out that. One thing to keep in mind, if anyone tries to
> use it on 32bit machine zeros(Int,1,1) will give an error.

Re: [julia-users] Re: Strange behaviour on type dependency of function

[Michael Krabbe Borregaard]

OK, thanks

On Tue, Jan 5, 2016 at 1:21 PM, Kristoffer Carlsson 
wrote:

> A other question is if those arrays really need to be Int64. Are you
> planning on using properties of Int64 that fail on Int32? Else just go with
> Int.

Re: [julia-users] force recompilation of package at update

[Michael Krabbe Borregaard]

Cool, I will try that.

On Sat, Nov 7, 2015 at 4:59 AM, Tony Kelman  wrote:

> I don't think there's a setting, but see the Base.compilecache function.
> You could define in your .juliarc.jl a wrapper around Pkg.update that calls
> update then recompiles any updated packages.

Re: [julia-users] track progress to 0.5

[Michael Krabbe Borregaard]

Wonderful, thanks for the help and pointers - that was exactly what I was
looking for.

On Wed, Nov 4, 2015 at 7:15 PM, Yichao Yu  wrote:

> On Wed, Nov 4, 2015 at 1:48 PM, Michael Borregaard
>  wrote:
> > I am using Julia 0.4, compiling from the release-0.4 branch on github.
> > Considering using 'master' instead, but - is there somewhere that lists
> the
> > planned and implemented changes to the dev version at once?
>
> Using `master` branch is generally not recommanded unless you are
> willing to fix all breackage (in packages for example) you see.
>
> If you want to know what we'd like to happen in 0.5, checkout the 0.5
> milestone on the issue tracker. If you want to know what major
> features have been implemented, checkout NEWS.md
>

Re: [julia-users] fixing aspect ratio in Compose.jl

[Michael Krabbe Borregaard]

bump? :-)

On Mon, Sep 28, 2015 at 9:13 PM, Michael Borregaard 
wrote:

> Hi,
> does anyone know how to fix the aspect ratio in a compose canvas? Gadfly
> can do it with ```coords.Cartesian(fixed = true)```, which uses Compose,
> but how to do it for that?
>
> thanks,
> M
>

Re: [julia-users] fixing aspect ratio in Compose.jl

[Michael Krabbe Borregaard]

Thanks, that link was very useful. I did not understand ctxpromise(), but
it seems I can achieve a quadratic canvas regardless of the shape of the
plotting area by:
```compose(context(0, 0, h > w ? w : h, h > w ? w : h), foo(), bar() ) ```

Best,
Michael

On Thu, Oct 1, 2015 at 5:09 PM, Isaiah Norton <isaiah.nor...@gmail.com>
wrote:

> I think you need to use "ctxpromise". See
> https://github.com/dcjones/Compose.jl/issues/112
>
> On Thu, Oct 1, 2015 at 8:02 AM, Michael Krabbe Borregaard <
> mkborrega...@gmail.com> wrote:
>
>> bump? :-)
>>
>> On Mon, Sep 28, 2015 at 9:13 PM, Michael Borregaard <
>> mkborrega...@gmail.com> wrote:
>>
>>> Hi,
>>> does anyone know how to fix the aspect ratio in a compose canvas? Gadfly
>>> can do it with ```coords.Cartesian(fixed = true)```, which uses Compose,
>>> but how to do it for that?
>>>
>>> thanks,
>>> M
>>>
>>
>>
>

Re: [julia-users] return 2D (or nD) array from function

[Michael Krabbe Borregaard]

Thanks a lot, both of you. I did look into array comprehensions, but as far
as I can see, these are designed to create the outer product (or other
function that returns a scalar) of the combinations of elements from two
Arrays - not combining the results of a function that returns 1d arrays? If
there is a way to use comprehensions I would prefer that, because I like
that syntax.
Otherwise, I had used the zeros(T, r, c) method before, so if that is the
recommended Julia style I will stick to that.

On Tue, Sep 15, 2015 at 8:53 PM, Tom Breloff  wrote:

> It's also perfectly normal/valid to do the loop explicitly.  Just use
> Array(T, r, c) to allocate, or zeros(T, r, c) or fill(val,r,c) to allocate
> and initialize.
>
> On Tue, Sep 15, 2015 at 2:38 PM, Stefan Karpinski 
> wrote:
>
>> You can use array comprehensions, e.g.:
>>
>> julia> f(x,y) = 2x + 3y - 1
>> f (generic function with 1 method)
>>
>> julia> [f(x,y) for x=1:7, y=1:5]
>> 7x5 Array{Int64,2}:
>>   4   7  10  13  16
>>   6   9  12  15  18
>>   8  11  14  17  20
>>  10  13  16  19  22
>>  12  15  18  21  24
>>  14  17  20  23  26
>>  16  19  22  25  28
>>
>>
>> On Tue, Sep 15, 2015 at 3:53 AM, Michael Borregaard <
>> mkborrega...@gmail.com> wrote:
>>
>>> Hi,
>>> I am trying to migrate from R to julia. I am trying to wrap my head
>>> around:
>>> In R, there are the apply functions - when used with, e.g. a function
>>> that returns a 1d array of constant length, they will return a 2d array
>>> with the results. In julia, using map() will return a Array{Array{T, 1}, 1}
>>> . What is the best, ideomatic way of building an Array{T, 2} from repeated
>>> runs of a function? A hcat() call at the end of a forloop? Initializing an
>>> array with the right dimensions with zeros(T, r, c) an indexing inside a
>>> for loop? Or is there something smarter/nicer/better?
>>>
>>> Thanks,
>>> Michael
>>>
>>
>>
>

Re: [julia-users] constrain arguments in function

[Michael Krabbe Borregaard]

Thanks, I will look into that then. So essentially if I build a module I
export the enums used for all functions into the global workspace?

On Tue, Sep 15, 2015 at 2:22 PM, Milan Bouchet-Valat 
wrote:

> Le mardi 15 septembre 2015 à 03:04 -0700, Michael Borregaard a écrit :
> > Ahh, I remember enum from the good old C++ days. That looks useful,
> > but in reality I guess still not more user friendly than just taking
> > a string defining the method, and then writing in the documentation
> > that it can only have these values.
> > I like Julia in most other ways, though in this I do think the R
> > match.arg way is really very convenient (also because 'args(f)' will
> > give the possible versions right at the command line).
> I would say an enum is better than an arbitrary string. It offers
> automatic checks that the input arguments are correct. Also, the user
> can just call instances() on the enum type to get the list of possible
> values. This could be shown automatically in the documentation (an IDE
> could show a tooltip, or the values could be added to the text).
>
>
> Regards
>
> > Thanks for the input!
> >
> > Den tirsdag den 15. september 2015 kl. 11.19.31 UTC+2 skrev Mauro:
> > > Related, in Julia0.4 there is also enum:
> > >
> > > help?> @enum
> > >   ..  @enum EnumName EnumValue1[=x] EnumValue2[=y]
> > >
> > >   Create an :obj:`Enum` type with name ``EnumName`` and enum member
> > > values of ``EnumValue1`` and ``EnumValue2`` with optional assigned
> > > values of ``x`` and ``y``, respectively. ``EnumName`` can be used
> > > just like other types and enum member values as regular values,
> > > such as
> > >
> > >   .. doctest::
> > >
> > >  julia> @enum FRUIT apple=1 orange=2 kiwi=3
> > >
> > >  julia> f(x::FRUIT) = "I'm a FRUIT with value: $(Int(x))"
> > >  f (generic function with 1 method)
> > >
> > >  julia> f(apple)
> > >  "I'm a FRUIT with value: 1"
> > >
> > >
> > > On Tue, 2015-09-15 at 10:51, Michael Borregaard <
> > > mkborr...@gmail.com> wrote:
> > > > Thanks, both, the pattern dispatch package looks useful. I guess
> > > the nice
> > > > thing about having the possibilities directly in the arguments
> > > line is that
> > > > it is extremely easy for the user to see the legal possible
> > > values of the
> > > > argument.
> > > > Best,
> > > > Michael
> > > >
> > > > Den tirsdag den 15. september 2015 kl. 10.44.38 UTC+2 skrev Tomas
> > > Lycken:
> > > >>
> > > >> You could also use a fairly common (although it is discouraged
> > > in the style
> > > >> guide
> > > >>  > > ghlight=style#avoid-confusion-about-whether-something-is-an
> > > -instance-or-a-type>)
> > > >> construct with an “enum type tree”:
> > > >>
> > > >> abstract SolverMethod
> > > >> immutable Spearman end
> > > >> immutable Pearson end
> > > >> immutable Kendall end
> > > >>
> > > >> Now, you can define and use your function definition like this:
> > > >>
> > > >> function foo{Method<:SolverMethod}(x, method::Type{Method})
> > > >> ...
> > > >> end
> > > >>
> > > >> foo(x, Kendall) # solve using Kendall solver
> > > >>
> > > >> Furthermore, you can leverage multiple dispatch for parts of the
> > > function
> > > >> that differ based on the solver method. Inside foo, this
> > > >>
> > > >> if method == "spearman"
> > > >> # do spearman specific stuff
> > > >> elseif method == "pearson"
> > > >> # do pearson specific stuff
> > > >> elseif method == "kendall"
> > > >> # do kendall specific stuff
> > > >> else
> > > >> # handle incorrect input
> > > >> end
> > > >>
> > > >> turns into
> > > >>
> > > >> dostuff(..., method)
> > > >>
> > > >> # and outside of foo
> > > >> function dostuff(..., ::Type{Spearman})
> > > >> # do spearman specific stuff
> > > >> end
> > > >> function dostuff(..., ::Type{Pearson})
> > > >> # do pearson specific stuff
> > > >> end
> > > >> function dostuff(..., ::Type{Kendall})
> > > >># do kendall specific stuff
> > > >> end
> > > >>
> > > >> //T
> > > >>
> > > >> On Tuesday, September 15, 2015 at 10:32:39 AM UTC+2, Mauro
> > > wrote:
> > > >>
> > > >> No, Julia only dispatches on types not on values.  The latter
> > > sometimes
> > > >>> goes under the name of pattern matching.  There is a package
> > > for that:
> > > >>> https://github.com/toivoh/PatternDispatch.jl
> > > >>>
> > > >>> On Tue, 2015-09-15 at 10:15, Michael Borregaard <
> > > mkborr...@gmail.com>
> > > >>> wrote:
> > > >>> > Is there a way in julia to restrict the values of arguments
> > > to a
> > > >>> function,
> > > >>> > eg to the contents of a certain vector?
> > > >>> >
> > > >>> > So, e.g. method in the function
> > > >>> >
> > > >>> > function foo(x, method::String) ...
> > > >>> >
> > > >>> > would be constrained to either "spearman", "pearson" or
> > > "kendall"?
> > > >>> >
> > > >>> > Thanks
> > > >>>
> > > >>>
> > > >>
> > >
>

Re: [julia-users] Re: rownames in data matrices

[Michael Krabbe Borregaard]

Thanks, it looks like that package will do the trick!

On Tue, Sep 8, 2015 at 1:33 PM, Tamas Papp  wrote:

> AFAIK https://github.com/davidavdav/NamedArrays.jl already does this and
> is maintained actively.
>
> Best,
>
> Tamas
>
> On Tue, Sep 08 2015, Andreas Lobinger  wrote:
>
> > Hello colleague,
> >
> > in the first order i think this could be emulated by a dictionary mapping
> > the row name to an index into a matrix or DataFrame.
> > Afaics calling this a  'misfeature' comes from trying to make a matrix
> > datatype that has row names by default and many people with
> > numerics/engineering background reserve the name matrix for the simplest
> > possible form: rectangular array with single number entries and integer
> row
> > and column indexing.
> >
> > So what you look for: a rectangular collection accessible with both row
> and
> > column index as names is something new and should have different name.
> You
> > could browse the dataFrames development and see if there are enough hooks
> > to extend this.
> >
> > Bringing this into julia as package (written in julia) should not be that
> > complicated if defined clearly (but still, someone is needed to
> implement).
>
>

Re: [julia-users] Re: rownames in data matrices

[Michael Krabbe Borregaard]

Interesting to follow that discussion, thanks. I can see the philosophical
arguments not to, though I think rownames are intuitive and nice.

On Tue, Sep 8, 2015 at 2:37 PM, Cedric St-Jean 
wrote:

> DataFrame behavior has been discussed many times, eg.
> https://groups.google.com/d/msg/julia-users/8UFnEIfIW0k/QNEustV9BQAJ.
> Short answer: having row names is considered, but a bit of a philosophical
> difference, so it's not guaranteed to happen at some point.
>
> On Tuesday, September 8, 2015 at 7:59:24 AM UTC-4, Michael Borregaard
> wrote:
>>
>> Thanks, it looks like that package will do the trick!
>>
>> On Tue, Sep 8, 2015 at 1:33 PM, Tamas Papp  wrote:
>>
>>> AFAIK https://github.com/davidavdav/NamedArrays.jl already does this and
>>> is maintained actively.
>>>
>>> Best,
>>>
>>> Tamas
>>>
>>> On Tue, Sep 08 2015, Andreas Lobinger  wrote:
>>>
>>> > Hello colleague,
>>> >
>>> > in the first order i think this could be emulated by a dictionary
>>> mapping
>>> > the row name to an index into a matrix or DataFrame.
>>> > Afaics calling this a  'misfeature' comes from trying to make a matrix
>>> > datatype that has row names by default and many people with
>>> > numerics/engineering background reserve the name matrix for the
>>> simplest
>>> > possible form: rectangular array with single number entries and
>>> integer row
>>> > and column indexing.
>>> >
>>> > So what you look for: a rectangular collection accessible with both
>>> row and
>>> > column index as names is something new and should have different name.
>>> You
>>> > could browse the dataFrames development and see if there are enough
>>> hooks
>>> > to extend this.
>>> >
>>> > Bringing this into julia as package (written in julia) should not be
>>> that
>>> > complicated if defined clearly (but still, someone is needed to
>>> implement).
>>>
>>>
>>