Re: [julia-users] Parsing complex numbers

[Jeffrey Sarnoff]

+1 (imo) It would be a real contribution to Julia's way of just working 
well with this as with that   
  for one with the requisite skill to make quick work of 
implementing
  parse(Complex, complex) and parse(Rational, rational) into 
v0.6  


On Friday, October 28, 2016 at 6:25:47 PM UTC-4, Jérémy Béjanin wrote:
>
> How easy would it be to make one assuming the standard julia notation 
> 3+4im?
>
> On Friday, October 28, 2016 at 3:58:08 PM UTC-4, Yichao Yu wrote:
>>
>> On Fri, Oct 28, 2016 at 3:53 PM, Jérémy Béjanin 
>>  wrote: 
>> > I've noticed that parsing a string representing a real number yields a 
>> real 
>> > number, but parsing a string representing a complex number yields an 
>> > expression that must subsequently be evaluated. Is there a reason for 
>> that 
>> > behaviour? I'd like to avoid that behaviour considering I am reading 
>> > user-inputted data. 
>> > 
>> > ```julia 
>> > julia> typeof(parse("1.60254+3im")) 
>> > Expr 
>> > 
>> > julia> typeof(parse("1.60254")) 
>> > Float64 
>> > ``` 
>>
>> Do no use `parse(::String)` to parse numbers. It is for parsing 
>> generic julia code. Use `parse(Float64, str)` to parse a floating 
>> point number. 
>>
>> I don't think we have a parsing function for complex number likely 
>> because there isn't a universal standard. 
>>
>

Re: [julia-users] Re: Sys.CPU_CORES

[Júlio Hoffimann]

Thank you Isaiah, I'll follow your tip and use Hwloc.jl

-Júlio

Re: [julia-users] Re: Sys.CPU_CORES

[Isaiah Norton]

Ref: https://github.com/JuliaLang/julia/issues/13901

On Wed, Nov 2, 2016 at 10:33 PM, Isaiah Norton 
wrote:

> it returns the same concept in all OS?
>
>
> As far as I can tell, yes.
>
>
>> Is it physical number of cores?
>
>
> Number of logical processors.
>
> On Wed, Nov 2, 2016 at 9:42 PM, Júlio Hoffimann  > wrote:
>
>> My question is, it returns the same concept in all OS? Is it physical
>> number of cores?
>>
>> -Júlio
>>
>
>

Re: [julia-users] Re: Sys.CPU_CORES

[Isaiah Norton]

>
> it returns the same concept in all OS?


As far as I can tell, yes.


> Is it physical number of cores?


Number of logical processors.

On Wed, Nov 2, 2016 at 9:42 PM, Júlio Hoffimann 
wrote:

> My question is, it returns the same concept in all OS? Is it physical
> number of cores?
>
> -Júlio
>

[julia-users] Re: How do I use Guide.yticks() with a log scale?

[Jeffrey Sarnoff]

Try posting your question/concern here:  discussing Plots.jl 



On Monday, October 24, 2016 at 4:14:45 PM UTC-4, Dean Schulze wrote:
>
>
> When I plot the DataFrame below using Scale.y_log10 the y-axis has ticks 
> for half powers of 10 (e.g. 10^5.5).  The plot is correct, but it's weird 
> seeing half powers of 10 on a log plot.
>
> If I add Guide.yticks(ticks=ymarks) with the following values
>
> ymarks=[10^4,10^5,10^6,10^7]
>
>
> I get a plot with the y-axis running up to 10^1000.
>
> How can I get rid of the half powers of 10 on the y-axis ticks?
>
>
>
> 9×2 DataFrames.DataFrame
> │ Row │ x │ y   │
> ├─┼───┼─┤
> │ 1   │ 5000  │ 35950   │
> │ 2   │ 1 │ 71961   │
> │ 3   │ 15000 │ 108145  │
> │ 4   │ 2 │ 154528  │
> │ 5   │ 24000 │ 395218  │
> │ 6   │ 28000 │ 689465  │
> │ 7   │ 32000 │ 2646407 │
> │ 8   │ 36000 │ 3138533 │
> │ 9   │ 4 │ 8648694 │
>
>
> ymarks=[10^4,10^5,10^6,10^7]
> plot(df, x="x",y="y",Scale.y_log10, Guide.yticks(ticks=ymarks) )
>
>
>

[julia-users] Re: how to report errors with context

[Jeffrey Sarnoff]

Tamas,

running this



typealias AkoString Union{String, SubString{String}}

function parsefield{T <: Real, S <: AkoString}(::Type{T}, str::S)
result = T(0)
try
result = parse(T, str)
catch ArgumentError
errormsg = string("Failed to parse \"",str,"\" as type ", T)
throw(ErrorException(errormsg))
end
return result
end

function parserow(schema, strings)
# keep i for reporting column, currently not used
[parsefield(T, string) for (i, (T, string)) in enumerate(zip(schema, 
strings))]
end

function parsefile(io, schema)
line = 1
while !eof(io)
strings = split(chomp(readline(io)), ';')
parserow(schema, strings)
line += 1 # currently not used, use for error reporting
end
end

test_file = """
1;2;3
4;5;6
7;8;error
"""

parsefile(IOBuffer(test_file), fill(Int, 3))




by evaluating parsefile(...), results in



julia> parsefile(IOBuffer(test_file), fill(Int, 3))
ERROR: Failed to parse "error" as type Int64
 in parsefield(::Type{Int64}, ::SubString{String}) at ./REPL[2]:7
 in (::##1#2)(::Tuple{Int64,Tuple{DataType,SubString{String}}}) at 
./:0
 in collect_to!(::Array{Int64,1}, 
::Base.Generator{Enumerate{Base.Zip2{Array{DataType,1},Array{SubString{String},1}}},##1#2},
 
::Int64, ::Tuple{Int64,Tuple{Int64,Int64}}) at ./array.jl:340
 in 
collect(::Base.Generator{Enumerate{Base.Zip2{Array{DataType,1},Array{SubString{String},1}}},##1#2})
 
at ./array.jl:308
 in parsefile(::Base.AbstractIOBuffer{Array{UInt8,1}}, ::Array{DataType,1}) 
at ./REPL[4]:5





On Wednesday, November 2, 2016 at 1:01:30 PM UTC-4, Tamas Papp wrote:
>
> This is a conceptual question. Consider the following (extremely 
> stylized, but self-contained) code 
>
> parsefield{T <: Real}(::Type{T}, string) = parse(T, string) 
>
> function parserow(schema, strings) 
> # keep i for reporting column, currently not used 
> [parsefield(T, string) for (i, (T, string)) in enumerate(zip(schema, 
> strings))] 
> end 
>
> function parsefile(io, schema) 
> line = 1 
> while !eof(io) 
> strings = split(chomp(readline(io)), ';') 
> parserow(schema, strings) 
> line += 1 # currently not used, use for error reporting 
> end 
> end 
>
> test_file = """ 
> 1;2;3 
> 4;5;6 
> 7;8;error 
> """ 
>
> parsefile(IOBuffer(test_file), fill(Int, 3)) 
>
> This will fail with an error message 
>
> ERROR: ArgumentError: invalid base 10 digit 'e' in "error" 
>  in tryparse_internal(::Type{Int64}, ::SubString{String}, ::Int64, 
> ::Int64, ::Int64 
> , ::Bool) at ./parse.jl:88 
>  in parse(::Type{Int64}, ::SubString{String}) at ./parse.jl:152 
>  in parsefield(::Type{Int64}, ::SubString{String}) at ./REPL[152]:1 
>  in (::##5#6)(::Tuple{Int64,Tuple{DataType,SubString{String}}}) at 
> ./:0 
>  in collect_to!(::Array{Int64,1}, 
> ::Base.Generator{Enumerate{Base.Zip2{Array{DataTy 
> pe,1},Array{SubString{String},1}}},##5#6}, ::Int64, 
> ::Tuple{Int64,Tuple{Int64,Int64 
> }}) at ./array.jl:340 
>  in 
> collect(::Base.Generator{Enumerate{Base.Zip2{Array{DataType,1},Array{SubString{
>  
>
> String},1}}},##5#6}) at ./array.jl:308 
>  in parsefile(::Base.AbstractIOBuffer{Array{UInt8,1}}, 
> ::Array{DataType,1}) at ./RE 
> PL[154]:5 
>
> Instead, I would like to report something like this: 
>
> ERROR: Failed to parse "error" as Int on line 3, column 3. 
>
> What's the idiomatic way of doing this in Julia? My problem is that 
> parsefield fails without knowing line or column (i in parserow). I could 
> catch and rethrow, constructing an error object gradually. Or I could 
> pass line and column numbers to parserow and parsefield for error 
> reporting, but that seems somehow inelegant (I have seen it in code 
> though). 
>
> Best, 
>
> Tamas 
>

[julia-users] Re: Calling Julia code from Python

[Harish Kumar]

Use pyjulia package. Convert your data set to list of list and pass to Julia

On Wednesday, November 2, 2016 at 1:43:27 PM UTC-5, Alexei Serdiuk wrote:
>
> Hi,
>
> I'm new to Julia and, unfortunately, I'm almost zero to Python. 
> I need to call Julia code from Python. This code must do some operations 
> and then return it back to Python.
>
> I have an example for calling Java:
> def solve_it(input_data):
>
>
> # Writes the inputData to a temporay file
>
>
> tmp_file_name = 'tmp.data'
> tmp_file = open(tmp_file_name, 'w')
> tmp_file.write(input_data)
> tmp_file.close()
>
>
> # Runs the command: java Solver -file=tmp.data
>
>
> process = Popen(['java', 'Solver', '-file=' + tmp_file_name], stdout=
> PIPE)
> (stdout, stderr) = process.communicate()
>
>
> # removes the temporay file
> os.remove(tmp_file_name)
>
>
> return stdout.strip()
>
>
> Would you please help me to create this code for Julia?
> Thanks.
>

[julia-users] Call Julia from Pyspark

[Harish Kumar]

I have a RDD with 10K columns and 70 million rows,  70 MM rows will be 
grouped into 2000-3000 groups based on a key attribute. I followed below 
steps 

1. Julia and Pyspark linked using pyjulia package
2. 70 MM rd is groupByKey
def juliaCall(x):
  <>
   j = julia.Julia()
   jcode = """ """
   calc= j.eval(jcode )
  result = calc(inputdata)

  RDD.groupBy(key).map(lambda x: juliaCall(x))

It works fine foe Key (or group) with 50K records, but my each group got 
100K to 3M records. in such cases Shuffle will be more and it will fail. 
Can anyoone guide me to over code this issue
I have cluster of 10 nodes, each node is of 116GB and 16cores. Standalone 
mode and i allocated only 10 cores per node. 

Any help?

Re: [julia-users] Re: Sys.CPU_CORES

[Júlio Hoffimann]

My question is, it returns the same concept in all OS? Is it physical
number of cores?

-Júlio

[julia-users] Re: Sys.CPU_CORES

[Jeffrey Sarnoff]

It works for me on Linux and Windows.

On Wednesday, November 2, 2016 at 9:29:28 PM UTC-4, Júlio Hoffimann wrote:
>
> Hi,
>
> Sys.CPU_CORES returns the number of physical cores or processing units? Is 
> it portable across different OS?
>
> -Júlio
>

Re: [julia-users] building julia 0.5.0 on FreeBSD 11

[Jeffrey Sarnoff]

Kostas,

Please post the location of those patches for others' reference.

Thanks

On Wednesday, November 2, 2016 at 6:29:40 PM UTC-4, Kostas Oikonomou wrote:
>
> Thanks, I found an entire set of patches.
>
> On Sunday, October 30, 2016 at 10:28:40 PM UTC-4, Isaiah wrote:
>>
>> Just guessing here from some quick poking around: try adding `#include 
>> ` to that file (`OPENBLAS_SRC/driver/others/blas_server.c`).
>>
>> On Sat, Oct 29, 2016 at 4:50 PM, Kostas Oikonomou > > wrote:
>>
>>> Hi, I'm following the instructions in the README, trying to build 0.5.0 
>>> from source on an amd64 machine.   
>>>
>>> However, I'm stuck at errors  in the OpenBlas build:
>>>
>>>
>>> blas_server.c:569:16: error: variable has incomplete type 'struct rlimit'
>>> struct rlimit rlim;
>>>   ^
>>> blas_server.c:569:9: note: forward declaration of 'struct rlimit'
>>> struct rlimit rlim;
>>>^
>>> blas_server.c:578:17: warning: implicit declaration of function 'raise' 
>>> is invalid in C99
>>>   [-Wimplicit-function-declaration]
>>> if(0 != raise(SIGINT)) {
>>> ^
>>> blas_server.c:578:23: error: use of undeclared identifier 'SIGINT'
>>> if(0 != raise(SIGINT)) {
>>>   ^
>>> 1 warning and 2 errors generated.
>>> gmake[3]: *** [Makefile:101: blas_server.o] Error 1
>>>
>>>
>>> I also tried using FreeBSD's OpenBlas port, but that apparently creates 
>>> a conflict between gcc 4.8.4 and the recommended gcc6.
>>>
>>> Here is my Make.user file:
>>>
>>> # libunwind needs a small patch to its tests to compile.
>>> FC=gfortran6
>>> # gfortran can't link binaries:
>>> FFLAGS=-Wl,-rpath,/usr/local/lib/gcc6
>>> # System libraries installed by pkg are not on the compiler path by 
>>> default:
>>> LDFLAGS=/usr/local/lib
>>> CPPFLAGS=/usr/local/include
>>> # Problems with OpenBLAS 
>>> OPENBLAS_TARGET_ARCH=BARCELONA
>>> OPENBLAS_DYNAMIC_ARCH=0 
>>> # Installation
>>> prefix=/opt/julia
>>>
>>> Thanks for any help.
>>>
>>> Kostas
>>>
>>
>>

[julia-users] Re: Calling Julia code from Python

[Jeffrey Sarnoff]

Alexi,

While you may want it to be otherwise, Steven is right.  There have been a 
few programming languages that were designed to be useful with very little 
instruction.  Julia, Python, Java, and most other modern languages are not 
that way.  And while it would be great if there really were a forthcoming 
interlingua .. there is not, not today anyway.  The best advice any of us 
could give you is to revisit the reason that you find a need to do this 
that way, and find an alternative way to satisfy that expectation.  No 
reasonable teacher or manager would expect you to make that happen without 
much more experience.  And once you have the experience, you would probably 
still want to choose a different way to work this.

*with some simpatico*


On Wednesday, November 2, 2016 at 6:21:20 PM UTC-4, Steven G. Johnson wrote:
>
>
>
> On Wednesday, November 2, 2016 at 2:43:27 PM UTC-4, Alexei Serdiuk wrote:
>>
>> I'm new to Julia and, unfortunately, I'm almost zero to Python. 
>>
>
> An unfortunate combination — better to learn one programming language 
> before you deal with inter-language calling.
>  
>
>> I need to call Julia code from Python. This code must do some operations 
>> and then return it back to Python.
>>
>
> Google "pyjulia"
>  
>
>> I have an example for calling Java:
>>
>
> That code is calling Java by piping the input and output through files and 
> popen.  You can do the exact same thing with Julia too, of course, but 
> pyjulia is far more efficient: it calls Julia as a library, within the same 
> process, and can even pass large arrays without making copies. 
>

[julia-users] Sys.CPU_CORES

[Júlio Hoffimann]

Hi,

Sys.CPU_CORES returns the number of physical cores or processing units? Is 
it portable across different OS?

-Júlio

Re: [julia-users] Where can I put code that will be run every time "using Module" is executed, and not just the first time?

[Yichao Yu]

On Nov 2, 2016 8:12 PM, "Scott Lundberg"  wrote:
>
> In Jupyter it is convenient to dump JS library code to the notebook when
"using Module" is run. This is simple to do in the Module's __init__(), and
saves a ton of memory since later visualizations can share this common JS
library code.
>
> However, if a user re-executes the cell, the library code is gone,
because __init__() is not re-run and the output is overwritten. (this will
effect the page next time it is reloaded)
>
> Where can I put code that will be run every time "using Module" is
executed, and not just the first time?

Not supported

>
> Thanks!

[julia-users] Where can I put code that will be run every time "using Module" is executed, and not just the first time?

[Scott Lundberg]

In Jupyter it is convenient to dump JS library code to the notebook when 
"using Module" is run. This is simple to do in the Module's __init__(), and 
saves a ton of memory since later visualizations can share this common JS 
library code.

However, if a user re-executes the cell, the library code is gone, because 
__init__() is not re-run and the output is overwritten. (this will effect 
the page next time it is reloaded)

*Where can I put code that will be run every time "using Module" is 
executed, and not just the first time?*

Thanks!

Re: [julia-users] building julia 0.5.0 on FreeBSD 11

[Kostas Oikonomou]

Thanks, I found an entire set of patches.

On Sunday, October 30, 2016 at 10:28:40 PM UTC-4, Isaiah wrote:
>
> Just guessing here from some quick poking around: try adding `#include 
> ` to that file (`OPENBLAS_SRC/driver/others/blas_server.c`).
>
> On Sat, Oct 29, 2016 at 4:50 PM, Kostas Oikonomou  > wrote:
>
>> Hi, I'm following the instructions in the README, trying to build 0.5.0 
>> from source on an amd64 machine.   
>>
>> However, I'm stuck at errors  in the OpenBlas build:
>>
>>
>> blas_server.c:569:16: error: variable has incomplete type 'struct rlimit'
>> struct rlimit rlim;
>>   ^
>> blas_server.c:569:9: note: forward declaration of 'struct rlimit'
>> struct rlimit rlim;
>>^
>> blas_server.c:578:17: warning: implicit declaration of function 'raise' 
>> is invalid in C99
>>   [-Wimplicit-function-declaration]
>> if(0 != raise(SIGINT)) {
>> ^
>> blas_server.c:578:23: error: use of undeclared identifier 'SIGINT'
>> if(0 != raise(SIGINT)) {
>>   ^
>> 1 warning and 2 errors generated.
>> gmake[3]: *** [Makefile:101: blas_server.o] Error 1
>>
>>
>> I also tried using FreeBSD's OpenBlas port, but that apparently creates a 
>> conflict between gcc 4.8.4 and the recommended gcc6.
>>
>> Here is my Make.user file:
>>
>> # libunwind needs a small patch to its tests to compile.
>> FC=gfortran6
>> # gfortran can't link binaries:
>> FFLAGS=-Wl,-rpath,/usr/local/lib/gcc6
>> # System libraries installed by pkg are not on the compiler path by 
>> default:
>> LDFLAGS=/usr/local/lib
>> CPPFLAGS=/usr/local/include
>> # Problems with OpenBLAS 
>> OPENBLAS_TARGET_ARCH=BARCELONA
>> OPENBLAS_DYNAMIC_ARCH=0 
>> # Installation
>> prefix=/opt/julia
>>
>> Thanks for any help.
>>
>> Kostas
>>
>
>

[julia-users] Re: Calling Julia code from Python

[Steven G. Johnson]

On Wednesday, November 2, 2016 at 2:43:27 PM UTC-4, Alexei Serdiuk wrote:
>
> I'm new to Julia and, unfortunately, I'm almost zero to Python. 
>

An unfortunate combination — better to learn one programming language 
before you deal with inter-language calling.
 

> I need to call Julia code from Python. This code must do some operations 
> and then return it back to Python.
>

Google "pyjulia"
 

> I have an example for calling Java:
>

That code is calling Java by piping the input and output through files and 
popen.  You can do the exact same thing with Julia too, of course, but 
pyjulia is far more efficient: it calls Julia as a library, within the same 
process, and can even pass large arrays without making copies. 

Re: [julia-users] [ANN] julia-repl, an Emacs minor mode for running a Julia REPL

[Angel de Vicente]

Hi,

Tamas Papp  writes:
>> What I miss from the ansi-term is that I cannot keep the whole
>> interaction in the buffer, which I grew accustomed to rely on when
>> running a regular shell inside Emacs. To illustrate, when running
>> something that generates a lot of output inside ansi-term, this gets
>> truncated, as you can see below, where the output starts with
>> -0.1-, etc., but most of the output is gone and only the last
>> parts remain (so I end up having a regular shell for long outputs and an
>> ansi-term for nice REPL interaction, but obviously it is not ideal). If
>> julia-repl solves that I'll buy it. :-)
>
> julia-repl can either use screen or not. With screen, you cannot scroll
> back beyond point. Without screen, you can --- I clarified it in the
> README and made it the default -- thanks!

Our exchange piqued my interest so I looked for how to do it from within
GNU screen. It turns out screen has options that will allow you to do it:

Inside the ansi-term and screen, if I want to scroll back:

- To see the buffer settings: Ctrl-a i

- To increase the screen buffer size: Ctrl-a :   and then type scrollback 1

- To scroll the bufferCtrl-a [   then scroll   and then ESC to
stop copy-mode

- To search   Ctrl-a Ctrl-s (forward) Ctrl-r
(backwards). ESC to quit search mode and keep cursor in the place of search.

- To copy stuff while in copy mode:   SPC (mark begin)  SPC (mark end). Then to
copy it to another Emacs buffer ???

- Ctrl-a :  then hardcopy -h  will write the whole buffer content to
 which can then be used anywhere.


Cheers,
-- 
Ángel de Vicente
http://www.iac.es/galeria/angelv/  

Re: [julia-users] Re: Nemo AcbField error

[digxx]

Diger@Diger-PC MINGW64 /d/julia/v0.5/nemo (master)
$ git config --global user.name "Diger"

Diger@Diger-PC MINGW64 /d/julia/v0.5/nemo (master)
$ git stash

*** Please tell me who you are.

Run

  git config --global user.email "y...@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'Diger@Diger-PC.(none)')
Cannot save the current index state

Diger@Diger-PC MINGW64 /d/julia/v0.5/nemo (master)
$ git config --global user.email "diger..."

Diger@Diger-PC MINGW64 /d/julia/v0.5/nemo (master)
$ git stash
Saved working directory and index state WIP on master: cc4ae5d Merge pull 
request #94 from thofma/update_version
HEAD is now at cc4ae5d Merge pull request #94 from thofma/update_version

Diger@Diger-PC MINGW64 /d/julia/v0.5/nemo (master)
$ git stash apply
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

modified:   windows_build.txt

no changes added to commit (use "git add" and/or "git commit -a")

Diger@Diger-PC MINGW64 /d/julia/v0.5/nemo (master)
$



Maybe just to update you. This is what I did. For whatever reason (which 
I'm not aware of) it seemed to work now...
So I did git stash
then:
julia> Pkg.update()
INFO: Updating METADATA...
INFO: Updating Nemo master...
INFO: Computing changes...
INFO: No packages to install, update or remove

and then git stash apply. If you dont mind would you tell me what is 
happening in the background?

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

[LeAnthony Mathews]

Spoke too soon.  
Again I simple want the CSV column that is read in to not be an int32, but 
a string.

Still having issues casting the CSV file back into a Dataframe.
Its hard to understand why the Julia system is attempting to determine the 
type of the columns when I use readtable and I have no control over this.

Why can I not say:
df1 = readtable(file1; types=Dict(1=>String)) # assuming your account 
number is column # 1

*Reading the Julia spec-Advanced Options for Reading CSV Files*
*readtable accepts the following optional keyword arguments:*

*eltypes::Vector{DataType} – Specify the types of all columns. Defaults to 
[].*


*df1 = readtable(file1, Int32::Vector(String))*

I get 
*ERROR: TypeError: typeassert: expected Array{String,1}, got Type{Int32}*

Is this even an option?  Or how about convert the df1_CSV to df1_dataframe? 
 
*df1_dataframe = convert(dataframe, df1_CSV)*
Since the CSV .read seems to give more granular control.


On Tuesday, November 1, 2016 at 7:28:36 PM UTC-4, LeAnthony Mathews wrote:
>
> Great, that worked for forcing the column into a string type.
> Thanks
>
> On Monday, October 31, 2016 at 3:26:14 PM UTC-4, Jacob Quinn wrote:
>>
>> You could use CSV.jl: http://juliadata.github.io/CSV.jl/stable/
>>
>> In this case, you'd do:
>>
>> df1 = CSV.read(file1; types=Dict(1=>String)) # assuming your account 
>> number is column # 1
>> df2 = CSV.read(file2; types=Dict(1=>String))
>>
>> -Jacob
>>
>>
>> On Mon, Oct 31, 2016 at 12:50 PM, LeAnthony Mathews  
>> wrote:
>>
>>> Using v0.5.0
>>> I have two different 10,000 line CSV files that I am reading into two 
>>> different dataframe variables using the readtable function.
>>> Each table has in common a ten digit account_number that I would like to 
>>> use as an index and join into one master file.
>>>
>>> Here is the account number example in the original CSV from file1:
>>> 8018884596
>>> 8018893530
>>> 8018909633
>>>
>>> When I do a readtable of this CSV into file1 then do a* 
>>> typeof(file1[:account_number])* I get:
>>> *DataArrays.DataArray(Int32,1)*
>>>  -571049996
>>>  -571041062
>>>  -571024959
>>>
>>> when I do a 
>>> *typeof(file2[:account_number])*
>>> *DataArrays.DataArray(String,1)*
>>>
>>>
>>> *Question:  *
>>> My CSV files give no guidance that account_number should be Int32 or 
>>> string type.  How do I force it to make both account_number elements type 
>>> String?
>>>
>>> I would like this join command to work:
>>> *new_account_join = join(file1, file2, on =:account_number,kind = :left)*
>>>
>>> But I am getting this error:
>>> *ERROR: TypeError: typeassert: expected Union{Array{Symbol,1},Symbol}, 
>>> got Array{*
>>> *Array{Symbol,1},1}*
>>> * in (::Base.#kw##join)(::Array{Any,1}, ::Base.#join, 
>>> ::DataFrames.DataFrame, ::D*
>>> *ataFrames.DataFrame) at .\:0*
>>>
>>>
>>> Any help would be appreciated.  
>>>
>>>
>>>
>>

[julia-users] ANN: Highlights.jl

[Michael Hatherly]

I’m pleased to announce the initial 0.1 release of Highlights.jl 
 — a Julia package for 
highlighting source code similar to the well-known Python package called 
Pygments .

The documentation for the package can be found here 
. Currently there are 
only a handful of supported languages and colour schemes, so if your 
favourite language (aside from Julia) is missing then please feel free to add 
it to the requests list 
 or open a PR.

Any bugs or feature requests can be made over on the issue tracker 
.

— Mike

[julia-users] PSA: Documenter.jl deprecations

[Michael Hatherly]

Version 0.7 of Documenter  has 
been tagged. Please note that this release *deprecates* the current 
authentication methods used to deploy generated documentation from Travis 
CI to GitHub Pages, namely GitHub personal access tokens and SSH keys 
generated via the travis Ruby gem. The new approach used is described in 
the docs 
.
 
The deprecation warnings will remain in place until version 0.9 of 
Documenter is released.

Please direct any issues you happen to encounter with these changes while 
upgrading to the new authentication method to the issue tracker 
.

— Mike

Re: [julia-users] [ANN] julia-repl, an Emacs minor mode for running a Julia REPL

[Tamas Papp]

On Wed, Nov 02 2016, Angel de Vicente wrote:

> Hi,
>
> Tamas Papp  writes:
>> Hi Julia & Emacs users,
>
> I'm one of those :-)
>
>> I wrote a minor mode for starting and interacting with a Julia REPL from
>> Emacs. It basically uses term, and defers to the Julia REPL for almost
>> everything. The main reason for using this instead of ESS is that some
>> packages, in particular Gallium and ASTinterpreter, require a more
>> capable terminal. You get completion and other extras of the Julia REPL
>> for free.
>
> when I have time I will try it, but just curious to know what julia-repl
> will give me than I cannot do now. My setting involves running an
> ansi-term inside Emacs, then running a screen session in it, and then
> starting julia. I have a nice REPL environment there, with

Not much: julia-repl is only a few LOC. There is functionality to find
an already running REPL, and raise it, or failing that, create one (C-c
C-z), and pulling up docs on the current symbol, etc. But again, it is
just a thin layer on ansi-term, I wrote it up to fix issue #1 in
julia-emacs, because I did not see anything packaged, just basic code
snippets floating around. I think that something one can (eventually)
install from MELPA would be better in the long run.

> What I miss from the ansi-term is that I cannot keep the whole
> interaction in the buffer, which I grew accustomed to rely on when
> running a regular shell inside Emacs. To illustrate, when running
> something that generates a lot of output inside ansi-term, this gets
> truncated, as you can see below, where the output starts with
> -0.1-, etc., but most of the output is gone and only the last
> parts remain (so I end up having a regular shell for long outputs and an
> ansi-term for nice REPL interaction, but obviously it is not ideal). If
> julia-repl solves that I'll buy it. :-)

julia-repl can either use screen or not. With screen, you cannot scroll
back beyond point. Without screen, you can --- I clarified it in the
README and made it the default -- thanks!

In any case, please submit issues, I am not an expert on packaging for
emacs, just wrote this to solve a problem.

Best,

Tamas

[julia-users] Re: Error calculating eigs of pentadiagonal matrix.

[Alejandro Castellanos]

As of now, I'm leaning towards maybe my feeding the matrix some Inf values 
due to the grid spacing I'm using but I'm not sure.

Would it help if I uploaded the whole of my code, in here? Mind you, the 
comments are in Spanish...

Cheers.

El miércoles, 2 de noviembre de 2016, 3:43:48 (UTC-7), Alejandro 
Castellanos escribió:
>
> Hello.
>
> I am working with a pentadiagonal sparse matrix that represents a 2D 
> Schrodinger's time-independent equation. I first work the laplacian 
> expressed in Finite Differences form and then I apply the potential on the 
> same matrix.
>
> So far I've been able to validate my results for both an electron in a box 
> as well as a harmonic oscillator, but when I change to the following 
> potential of a dipole, Julia pretty much quits on me when I try to obtain 
> the eigenvalues and eigenvectors:
>
>   O = [round(L/2)-hx round(L/2)-hy]# --el ORIGEN (centro -- x,y) 
> del potencial.
>   Eps_o  = 8.854187817e10-12# --F*m^-1
>   C = 1/(4*pi*Eps_o)
>   D = 1e-21#C*m^2/s# --Debyes)
>   pe= 1.8*D 
>   *P(X,Y)  = -(C)*pe*(Y/X)*(1/( (X)^2 + (Y)^2)   )*# --How the 
> potential gets described.
>  
> #--I'm aware there's singularities in the potential.
> #--and here's how I apply the potential to my sparse matrix.
>
>   Vi  = Float64[]# --container for the potential.
>   for j=Y  for i=X  push!(Vi,P(i,j))   end  end@ --applying the potential.
>
>
> I use this command: *l, v = eigs(M,nev=15,which = :SM ,ritzvec=true)*
>
> My problem seems to be that there's an error that I can't get past:
>
> ERROR: LoadError: ArgumentError: matrix has one or more zero pivots
>>>
>>>  in #ldltfact!#10(::Float64, ::Function, 
 ::Base.SparseArrays.CHOLMOD.Factor{Float64}, 
 ::Base.SparseArrays.CHOLMOD.Sparse{Float64}) at ./sparse/cholmod.jl:1350
>>>
>>>  in (::Base.LinAlg.#kw##ldltfact!)(::Array{Any,1}, 
 ::Base.LinAlg.#ldltfact!, ::Base.SparseArrays.CHOLMOD.Factor{Float64}, 
 ::Base.SparseArrays.CHOLMOD.Sparse{Float64}) at ./:0
>>>
>>>  in #ldltfact#12(::Float64, ::Array{Int64,1}, ::Function, 
 ::Base.SparseArrays.CHOLMOD.Sparse{Float64}) at ./sparse/cholmod.jl:1386
>>>
>>>  in #ldltfact#13(::Array{Any,1}, ::Function, 
 ::Hermitian{Float64,SparseMatrixCSC{Float64,Int64}}) at 
 ./sparse/cholmod.jl:1426
>>>
>>>  in factorize(::SparseMatrixCSC{Float64,Int64}) at ./sparse/linalg.jl:897
>>>
>>>  in #_eigs#62(::Int64, ::Int64, ::Symbol, ::Float64, ::Int64, ::Void, 
 ::Array{Float64,1}, ::Bool, ::Base.LinAlg.#_eigs, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at 
 ./linalg/arnoldi.jl:251
>>>
>>>  in (::Base.LinAlg.#kw##_eigs)(::Array{Any,1}, ::Base.LinAlg.#_eigs, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at ./:0
>>>
>>>  in #eigs#55(::Array{Any,1}, ::Function, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at 
 ./linalg/arnoldi.jl:78
>>>
>>>  in (::Base.LinAlg.#kw##eigs)(::Array{Any,1}, ::Base.LinAlg.#eigs, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at ./:0
>>>
>>>  in #eigs#54(::Array{Any,1}, ::Function, 
 ::SparseMatrixCSC{Float64,Int64}) at ./linalg/arnoldi.jl:77
>>>
>>>  in (::Base.LinAlg.#kw##eigs)(::Array{Any,1}, ::Base.LinAlg.#eigs, 
 ::SparseMatrixCSC{Float64,Int64}) at ./:0
>>>
>>>  in include_from_node1(::String) at ./loading.jl:488
>>>
>>> while loading /home/alejandro/Desktop/ACAD/PROG/ACADEMIC_PROGRAMMING/FDM 
 (Finite_Difference_Method)/2D/SCHROD_DIP_2D/SCRATCH-2D-SI-DIPOLO2.jl, in 
 expression starting on line 106
>>>
>>>
>>> My question is, is there a way to work around it, or, am I completely 
> screwed?
>
> Thanks so much in advance.
>

Re: [julia-users] [ANN] julia-repl, an Emacs minor mode for running a Julia REPL

[Angel de Vicente]

Hi,

Tamas Papp  writes:
> Hi Julia & Emacs users,

I'm one of those :-) 

> I wrote a minor mode for starting and interacting with a Julia REPL from
> Emacs. It basically uses term, and defers to the Julia REPL for almost
> everything. The main reason for using this instead of ESS is that some
> packages, in particular Gallium and ASTinterpreter, require a more
> capable terminal. You get completion and other extras of the Julia REPL
> for free.

when I have time I will try it, but just curious to know what julia-repl
will give me than I cannot do now. My setting involves running an
ansi-term inside Emacs, then running a screen session in it, and then
starting julia. I have a nice REPL environment there, with
auto-completion, arrow keys, reverse search, etc. plus being able to
change from line mode to char mode when I want to copy-paste stuff
from/to other buffers. 

What I miss from the ansi-term is that I cannot keep the whole
interaction in the buffer, which I grew accustomed to rely on when
running a regular shell inside Emacs. To illustrate, when running
something that generates a lot of output inside ansi-term, this gets
truncated, as you can see below, where the output starts with
-0.1-, etc., but most of the output is gone and only the last
parts remain (so I end up having a regular shell for long outputs and an
ansi-term for nice REPL interaction, but obviously it is not ideal). If
julia-repl solves that I'll buy it. :-) 

,
| •Powerful. Do more with less. Complex visualizations become easy.
|   
| •Intuitive. Stop reading so much documentation. Commands should "just 
work".
|   
| [3.18637,-9.2635,4.9458]
| [13.3777,3.68877,-17.3378]
| -
| 9.6-
| [0.989822,2.2296,0.101944]
| [0.654825,-0.0280955,3.54596]
| [-3.3894,18.8551,-15.2289]
| [9.50161,16.0473,-15.8163]
| [-1.53928,3.43175,5.02399]
| [11.1929,-10.6255,0.369727]
| [18.9342,13.1419,-10.4816]
| [0.790022,1.74249,0.842619]
| [3.22621,-9.36619,5.00161]
| [13.5345,3.73192,-17.5406]
| -
`

Cheers,
-- 
Ángel de Vicente
http://www.iac.es/galeria/angelv/  

[julia-users] Calling Julia code from Python

[Alexei Serdiuk]

Hi,

I'm new to Julia and, unfortunately, I'm almost zero to Python. 
I need to call Julia code from Python. This code must do some operations 
and then return it back to Python.

I have an example for calling Java:
def solve_it(input_data):


# Writes the inputData to a temporay file


tmp_file_name = 'tmp.data'
tmp_file = open(tmp_file_name, 'w')
tmp_file.write(input_data)
tmp_file.close()


# Runs the command: java Solver -file=tmp.data


process = Popen(['java', 'Solver', '-file=' + tmp_file_name], stdout=
PIPE)
(stdout, stderr) = process.communicate()


# removes the temporay file
os.remove(tmp_file_name)


return stdout.strip()


Would you please help me to create this code for Julia?
Thanks.

Re: [julia-users] Cannot PyPlot / Matplotlib broken (warnings about font cache?)

[Steven G. Johnson]

On Wednesday, November 2, 2016 at 11:35:20 AM UTC-4, Daniel Carrera wrote:
>
> Here is an idea for the future: Is it possible to get PyCall to print the 
> rest of Python's error message so that dummies like me aren't led astray... 
> It's weird that most of the error was printed but the path to the file was 
> not.
>

Could you file an issue, maybe with test code via pyeval or something, that 
illustrates the problem?   Maybe there is a separate Python API function 
that I should be using to display exception output. 

Re: [julia-users] Cannot PyPlot / Matplotlib broken (warnings about font cache?)

[Steven G. Johnson]

On Wednesday, November 2, 2016 at 10:39:58 AM UTC-4, Daniel Carrera wrote:
>
> On Wednesday, 2 November 2016 15:20:07 UTC+1, Isaiah wrote:
> Thanks! I've realized that Conda.jl doesn't actually install Python. But I 
> could use Anaconda to install Python in /opt and point Julia to that 
> version.
>

No, Conda.jl does actually install its own Python. 

[julia-users] Re: Error calculating eigs of pentadiagonal matrix.

[Steven G. Johnson]

On Wednesday, November 2, 2016 at 1:40:17 PM UTC-4, Ralph Smith wrote:
>
> Eigs uses shift-and-invert for the :sm variant, so it tries to solve M x = 
> b. Try adding a small sigma parameter.
>

Yes, but it really should be able to handle matrices with a nontrivial 
nullspace ... the nullspace is (part of) exactly what you want, and in 
principle you can get it efficiently and then project it out.

[julia-users] Re: Error calculating eigs of pentadiagonal matrix.

[Ralph Smith]

Eigs uses shift-and-invert for the :sm variant, so it tries to solve M x = b. 
Try adding a small sigma parameter.

Re: [julia-users] Re: [ANN] julia-repl, an Emacs minor mode for running a Julia REPL

[Tamas Papp]

On Wed, Nov 02 2016, David van Leeuwen wrote:

> I'd be interested to know what the supposed workflow for
> $interpretor-in-$editor is.  (This may be more general than emacs
> julia-repl)
>
> I've tried Julia, R in Atom, Emacs, and I don't seem to be able to work
> with it.  In the Julia / R / bash / ipython / ... the up-arrow is my
> friend.  That is how I quickly find and repeat/edit/... a previous command.
>  It appears to me that the first thing that an interpretor-in-editor does
> is hijack the up-arrow, and make this move the cursor around in the buffer.
>  (I suppose I cannot really blame the editor, that is what it normally does
> with up-arrow and friends).
>
> So I figure there must be a different workflow than I am used to (edit
> file--switch to repl--include("file")--run function).  What is that
> workflow?

In general Emacs term has two modes, line and char mode. Char mode does
not capture the arrow keys. Line mode does, so you can move around the
buffer as usual. julia-repl starts in char mode by default, and you can
switch between the two modes -- see the README.

Basically, I wrote julia-repl because did not want Emacs to capture
parts of the input and output (like ESS does). Among other things, arrow
keys just work, even in the partial match mode (when you have typed
something and want to cycle through matches).

Happy to include new features, just ask here or open an issue.

Best,

Tamas

[julia-users] how to report errors with context

[Tamas Papp]

This is a conceptual question. Consider the following (extremely
stylized, but self-contained) code

parsefield{T <: Real}(::Type{T}, string) = parse(T, string)

function parserow(schema, strings)
# keep i for reporting column, currently not used
[parsefield(T, string) for (i, (T, string)) in enumerate(zip(schema, 
strings))]
end

function parsefile(io, schema)
line = 1
while !eof(io)
strings = split(chomp(readline(io)), ';')
parserow(schema, strings)
line += 1 # currently not used, use for error reporting
end
end

test_file = """
1;2;3
4;5;6
7;8;error
"""

parsefile(IOBuffer(test_file), fill(Int, 3))

This will fail with an error message

ERROR: ArgumentError: invalid base 10 digit 'e' in "error"
 in tryparse_internal(::Type{Int64}, ::SubString{String}, ::Int64, ::Int64, 
::Int64
, ::Bool) at ./parse.jl:88
 in parse(::Type{Int64}, ::SubString{String}) at ./parse.jl:152
 in parsefield(::Type{Int64}, ::SubString{String}) at ./REPL[152]:1
 in (::##5#6)(::Tuple{Int64,Tuple{DataType,SubString{String}}}) at ./:0
 in collect_to!(::Array{Int64,1}, 
::Base.Generator{Enumerate{Base.Zip2{Array{DataTy
pe,1},Array{SubString{String},1}}},##5#6}, ::Int64, 
::Tuple{Int64,Tuple{Int64,Int64
}}) at ./array.jl:340
 in 
collect(::Base.Generator{Enumerate{Base.Zip2{Array{DataType,1},Array{SubString{
String},1}}},##5#6}) at ./array.jl:308
 in parsefile(::Base.AbstractIOBuffer{Array{UInt8,1}}, ::Array{DataType,1}) at 
./RE
PL[154]:5

Instead, I would like to report something like this:

ERROR: Failed to parse "error" as Int on line 3, column 3.

What's the idiomatic way of doing this in Julia? My problem is that
parsefield fails without knowing line or column (i in parserow). I could
catch and rethrow, constructing an error object gradually. Or I could
pass line and column numbers to parserow and parsefield for error
reporting, but that seems somehow inelegant (I have seen it in code
though).

Best,

Tamas

[julia-users] Re: [ANN] julia-repl, an Emacs minor mode for running a Julia REPL

[David van Leeuwen]

Hi, 

On Wednesday, November 2, 2016 at 2:51:54 PM UTC+1, Tamas Papp wrote:
>
> Hi Julia & Emacs users, 
>
> I wrote a minor mode for starting and interacting with a Julia REPL from 
> Emacs. It basically uses term, and defers to the Julia REPL for almost 
> everything. The main reason for using this instead of ESS is that some 
> packages, in particular Gallium and ASTinterpreter, require a more 
> capable terminal. You get completion and other extras of the Julia REPL 
> for free. 
>
> Thanks, 
 
I'd be interested to know what the supposed workflow for 
$interpretor-in-$editor is.  (This may be more general than emacs 
julia-repl)

I've tried Julia, R in Atom, Emacs, and I don't seem to be able to work 
with it.  In the Julia / R / bash / ipython / ... the up-arrow is my 
friend.  That is how I quickly find and repeat/edit/... a previous command. 
 It appears to me that the first thing that an interpretor-in-editor does 
is hijack the up-arrow, and make this move the cursor around in the buffer. 
 (I suppose I cannot really blame the editor, that is what it normally does 
with up-arrow and friends).  

So I figure there must be a different workflow than I am used to (edit 
file--switch to repl--include("file")--run function).  What is that 
workflow?

Cheers, 

---david 
 

> You can find it at 
>
> https://github.com/tpapp/julia-repl 
>
> If there is interest, I would be happy to submit it to MELPA, just file 
> an issue. 
>
> Best, 
>
> Tamas Papp 
>

Re: [julia-users] JuliaDB?

[Seth]

On Wednesday, November 2, 2016 at 9:43:16 AM UTC-7, Jeff Bezanson wrote:
>
> This is an internal name we've been using; it hasn't been finalized 
> yet so I removed it from the site (the name collision with the 
> existing github org is one of the issues of course). If you're 
> interested in this kind of functionality please contact me directly. 
>
>
> On Wed, Nov 2, 2016 at 10:37 AM, Seth  > wrote: 
> > From http://juliacomputing.com/products/juliafin.html 
> > 
> >> JuliaDB is a high-performance, columnar data store for working with 
> >> large-scale time series data. What sets it apart from the existing 
> products 
> >> in this area is the tight-knit integration of data and algorithms with 
> the 
> >> full power of the Julia ecosystem. In addition, high-performance 
> analytics, 
> >> easy parallelism, graphics and leveraging integrations with 
> spreadsheets and 
> >> data sources is the key to simplifying algorithmic trading, 
> backtesting, and 
> >> risk analytics. 
> > 
> > 
> > However, the only references I can find to JuliaDB is the GitHub 
> > organization (https://github.com/JuliaDB). 
> > 
> > Is this code open source, and if so, where does it reside? 
> > 
> > 
>

Thanks, Jeff. Are you folks planning on open-sourcing the database? 

Re: [julia-users] JuliaDB?

[Jeff Bezanson]

This is an internal name we've been using; it hasn't been finalized
yet so I removed it from the site (the name collision with the
existing github org is one of the issues of course). If you're
interested in this kind of functionality please contact me directly.


On Wed, Nov 2, 2016 at 10:37 AM, Seth  wrote:
> From http://juliacomputing.com/products/juliafin.html
>
>> JuliaDB is a high-performance, columnar data store for working with
>> large-scale time series data. What sets it apart from the existing products
>> in this area is the tight-knit integration of data and algorithms with the
>> full power of the Julia ecosystem. In addition, high-performance analytics,
>> easy parallelism, graphics and leveraging integrations with spreadsheets and
>> data sources is the key to simplifying algorithmic trading, backtesting, and
>> risk analytics.
>
>
> However, the only references I can find to JuliaDB is the GitHub
> organization (https://github.com/JuliaDB).
>
> Is this code open source, and if so, where does it reside?
>
>

[julia-users] Re: Error calculating eigs of pentadiagonal matrix.

[Alejandro Castellanos]

Hi, Steven. This is how I'm building the matrix:

#==#
# OPERATING THE MATRIX  #
#==#
# --Creating HAMILTONIAN container.
M  = spzeros(n*n, n*n)#--Creating the SPARSE matrix (n is 
the number of points per row).

# --Working kinetic energy into matrix  M (using 2D Laplacian scheme)...
# --Central part:

trmC   = -4#--el termino central de la matriz.
M[1,1] = trmC
for  i = 2:n*n   M[i,i] = trmC; M[i-1,i] = 1 end#--diags. central and 1 
above.
for  i = 1:(n*n)-1   M[i+1,i] = 1 end#--diag. below.

#--Exterior diagonals (2 in 1 loop).

for  i = 1:n*(n-1)  M[i,i+n]   =   1;  M[i+n,i]  = 1   end
#--"poking" zeroes into the matrix to make "holes."
for  i = 1:n*(n-1)  if i%n==0 M[i+1,i]=0;M[i,i+1] = 0  endend

After that I multiply M by the appropriate constants to get the full 
kinetic energy. Then I use the routine I posted previously so as to add the 
potential, all in the same matrix.

I assume my matrix creation scheme may not be the most efficient, but it 
did get the job done (up til now). 

Cheers.







El miércoles, 2 de noviembre de 2016, 3:43:48 (UTC-7), Alejandro 
Castellanos escribió:
>
> Hello.
>
> I am working with a pentadiagonal sparse matrix that represents a 2D 
> Schrodinger's time-independent equation. I first work the laplacian 
> expressed in Finite Differences form and then I apply the potential on the 
> same matrix.
>
> So far I've been able to validate my results for both an electron in a box 
> as well as a harmonic oscillator, but when I change to the following 
> potential of a dipole, Julia pretty much quits on me when I try to obtain 
> the eigenvalues and eigenvectors:
>
>   O = [round(L/2)-hx round(L/2)-hy]# --el ORIGEN (centro -- x,y) 
> del potencial.
>   Eps_o  = 8.854187817e10-12# --F*m^-1
>   C = 1/(4*pi*Eps_o)
>   D = 1e-21#C*m^2/s# --Debyes)
>   pe= 1.8*D 
>   *P(X,Y)  = -(C)*pe*(Y/X)*(1/( (X)^2 + (Y)^2)   )*# --How the 
> potential gets described.
>  
> #--I'm aware there's singularities in the potential.
> #--and here's how I apply the potential to my sparse matrix.
>
>   Vi  = Float64[]# --container for the potential.
>   for j=Y  for i=X  push!(Vi,P(i,j))   end  end@ --applying the potential.
>
>
> I use this command: *l, v = eigs(M,nev=15,which = :SM ,ritzvec=true)*
>
> My problem seems to be that there's an error that I can't get past:
>
> ERROR: LoadError: ArgumentError: matrix has one or more zero pivots
>>>
>>>  in #ldltfact!#10(::Float64, ::Function, 
 ::Base.SparseArrays.CHOLMOD.Factor{Float64}, 
 ::Base.SparseArrays.CHOLMOD.Sparse{Float64}) at ./sparse/cholmod.jl:1350
>>>
>>>  in (::Base.LinAlg.#kw##ldltfact!)(::Array{Any,1}, 
 ::Base.LinAlg.#ldltfact!, ::Base.SparseArrays.CHOLMOD.Factor{Float64}, 
 ::Base.SparseArrays.CHOLMOD.Sparse{Float64}) at ./:0
>>>
>>>  in #ldltfact#12(::Float64, ::Array{Int64,1}, ::Function, 
 ::Base.SparseArrays.CHOLMOD.Sparse{Float64}) at ./sparse/cholmod.jl:1386
>>>
>>>  in #ldltfact#13(::Array{Any,1}, ::Function, 
 ::Hermitian{Float64,SparseMatrixCSC{Float64,Int64}}) at 
 ./sparse/cholmod.jl:1426
>>>
>>>  in factorize(::SparseMatrixCSC{Float64,Int64}) at ./sparse/linalg.jl:897
>>>
>>>  in #_eigs#62(::Int64, ::Int64, ::Symbol, ::Float64, ::Int64, ::Void, 
 ::Array{Float64,1}, ::Bool, ::Base.LinAlg.#_eigs, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at 
 ./linalg/arnoldi.jl:251
>>>
>>>  in (::Base.LinAlg.#kw##_eigs)(::Array{Any,1}, ::Base.LinAlg.#_eigs, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at ./:0
>>>
>>>  in #eigs#55(::Array{Any,1}, ::Function, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at 
 ./linalg/arnoldi.jl:78
>>>
>>>  in (::Base.LinAlg.#kw##eigs)(::Array{Any,1}, ::Base.LinAlg.#eigs, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at ./:0
>>>
>>>  in #eigs#54(::Array{Any,1}, ::Function, 
 ::SparseMatrixCSC{Float64,Int64}) at ./linalg/arnoldi.jl:77
>>>
>>>  in (::Base.LinAlg.#kw##eigs)(::Array{Any,1}, ::Base.LinAlg.#eigs, 
 ::SparseMatrixCSC{Float64,Int64}) at ./:0
>>>
>>>  in include_from_node1(::String) at ./loading.jl:488
>>>
>>> while loading /home/alejandro/Desktop/ACAD/PROG/ACADEMIC_PROGRAMMING/FDM 
 (Finite_Difference_Method)/2D/SCHROD_DIP_2D/SCRATCH-2D-SI-DIPOLO2.jl, in 
 expression starting on line 106
>>>
>>>
>>> My question is, is there a way to work around it, or, am I completely 
> screwed?
>
> Thanks so much in advance.
>

Re: [julia-users] Cannot PyPlot / Matplotlib broken (warnings about font cache?)

[Daniel Carrera]

Hi guys,

I am really sorry for the spam. I just want to say that I am cautiously 
optimistic that the problem has been solved. I started Python to see the 
error from within Python, and this is what I saw:

>>> import matplotlib.pyplot as p
... blah blah blah...
IOError: [Errno 13] Permission denied: 
u'/usr/share/fonts/opentype/FrutigerLTStd/FrutigerLTStd-Light.otf'


So the IO error was referring to a font file!!! I didn't see this in the 
error output in Julia and I foolishly thought that it was complaining about 
one of the .py files. So I checked the permissions of the Frutiger font 
files and they were indeed wrong. I fixed the permissions and now PyPlot 
seems to work as before. I don't know why the permissions were wrong, but I 
guess it no longer matters.


Here is an idea for the future: Is it possible to get PyCall to print the 
rest of Python's error message so that dummies like me aren't led astray... 
It's weird that most of the error was printed but the path to the file was 
not.

Cheers,
Daniel.

Re: [julia-users] Cannot PyPlot / Matplotlib broken (warnings about font cache?)

[Daniel Carrera]

This is depressing... Installing a new matplotlib did not fix the problem 
at all. After I exited and restarted Julia the old error came right back, 
even with the new Python install:

--
Orion ~ % julia
   _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.5.0 (2016-09-19 18:14 UTC)
 _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
|__/   |  x86_64-pc-linux-gnu

julia> using PyPlot
/home/daniel/.julia/v0.5/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/font_manager.py:273:
 
UserWarning: Matplotlib is building the font cache using fc-list. This may 
take a moment.
  warnings.warn('Matplotlib is building the font cache using fc-list. This 
may take a moment.')
WARNING: No working GUI backend found for matplotlib.
/home/daniel/.julia/v0.5/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/__init__.py:1357:
 
UserWarning:  This call to matplotlib.use() has no effect
because the backend has already been chosen;
matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
or matplotlib.backends is imported for the first time.

  warnings.warn(_use_error_msg)
/home/daniel/.julia/v0.5/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/font_manager.py:273:
 
UserWarning: Matplotlib is building the font cache using fc-list. This may 
take a moment.
  warnings.warn('Matplotlib is building the font cache using fc-list. This 
may take a moment.')
ERROR: InitError: PyError (:PyImport_ImportModule) 
IOError(13, 'Permission denied')
  File 
"/home/daniel/.julia/v0.5/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/pyplot.py",
 
line 29, in 
import matplotlib.colorbar
  File 
"/home/daniel/.julia/v0.5/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/colorbar.py",
 
line 34, in 
import matplotlib.collections as collections
  File 
"/home/daniel/.julia/v0.5/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/collections.py",
 
line 27, in 
import matplotlib.backend_bases as backend_bases
  File 
"/home/daniel/.julia/v0.5/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/backend_bases.py",
 
line 62, in 
import matplotlib.textpath as textpath
  File 
"/home/daniel/.julia/v0.5/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/textpath.py",
 
line 15, in 
import matplotlib.font_manager as font_manager
  File 
"/home/daniel/.julia/v0.5/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/font_manager.py",
 
line 1421, in 
_rebuild()
  File 
"/home/daniel/.julia/v0.5/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/font_manager.py",
 
line 1406, in _rebuild
fontManager = FontManager()
  File 
"/home/daniel/.julia/v0.5/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/font_manager.py",
 
line 1059, in __init__
self.ttflist = createFontList(self.ttffiles)
  File 
"/home/daniel/.julia/v0.5/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/font_manager.py",
 
line 581, in createFontList
font = ft2font.FT2Font(fpath)

 in pyerr_check at /home/daniel/.julia/v0.5/PyCall/src/exception.jl:56 
[inlined]
 in pyerr_check at /home/daniel/.julia/v0.5/PyCall/src/exception.jl:61 
[inlined]
 in macro expansion at /home/daniel/.julia/v0.5/PyCall/src/exception.jl:81 
[inlined]
 in pyimport(::String) at /home/daniel/.julia/v0.5/PyCall/src/PyCall.jl:387
 in __init__() at /home/daniel/.julia/v0.5/PyPlot/src/PyPlot.jl:235
 in _include_from_serialized(::String) at ./loading.jl:150
 in _require_from_serialized(::Int64, ::Symbol, ::String, ::Bool) at 
./loading.jl:187
 in _require_search_from_serialized(::Int64, ::Symbol, ::String, ::Bool) at 
./loading.jl:217
 in require(::Symbol) at ./loading.jl:371
during initialization of module PyPlot
--


Notice that it's now looking at my brand-new locally installed Python in 
~/.julia/v0.5/Conda/deps

What's perhaps more surprising is that I still see an IO error and a 
"Permission denied". How is that possible? I'm pretty sure I never typed 
"sudo" when I did any of this. Incidentally, I already tried removing the 
~/.cache directory and it didn't help.

Cheers,
Daniel.




On Wednesday, 2 November 2016 16:16:33 UTC+1, Daniel Carrera wrote:
>
> Thanks!  Ok... getting close, but not quite there:
>
> Deleting ~/.cache/matplotlib and even ~/.cache/fontconfig didn't work for 
> me, but I figured out how to use Conda.jl to install matplotlib separately. 
> So I did this:
>
> $ sudo apt-get remove python-matplotlib
> $ julia
>
> julia> Pkg.add("Conda")
> julia> using Conda
> julia> Conda.add("matplotlib")
> julia> ENV["PYTHON"] = "/home/daniel/.julia/v0.5/Conda/deps/usr/bin/python"
> julia> Pkg.add("PyPlot")
> julia> using PyPlot
>
> Up to this point there are no errors!  But this is what happens next:
>
> julia> plot( [1,2,3], [4,5,6] )
> ERROR: 

Re: [julia-users] Cannot PyPlot / Matplotlib broken (warnings about font cache?)

[Daniel Carrera]

Thanks!  Ok... getting close, but not quite there:

Deleting ~/.cache/matplotlib and even ~/.cache/fontconfig didn't work for 
me, but I figured out how to use Conda.jl to install matplotlib separately. 
So I did this:

$ sudo apt-get remove python-matplotlib
$ julia

julia> Pkg.add("Conda")
julia> using Conda
julia> Conda.add("matplotlib")
julia> ENV["PYTHON"] = "/home/daniel/.julia/v0.5/Conda/deps/usr/bin/python"
julia> Pkg.add("PyPlot")
julia> using PyPlot

Up to this point there are no errors!  But this is what happens next:

julia> plot( [1,2,3], [4,5,6] )
ERROR: ArgumentError: haskey of NULL PyObject
 in haskey(::PyCall.PyObject, ::String) at 
/home/daniel/.julia/v0.5/PyCall/src/PyCall.jl:282
 in #plot#85(::Array{Any,1}, ::Function, ::Array{Int64,1}, 
::Vararg{Array{Int64,1},N}) at 
/home/daniel/.julia/v0.5/PyPlot/src/PyPlot.jl:396
 in plot(::Array{Int64,1}, ::Vararg{Array{Int64,1},N}) at 
/home/daniel/.julia/v0.5/PyPlot/src/PyPlot.jl:396


I partially understand the error. I'll experiment a bit more to see if I 
can resolve it, but I thought you'd like to know about it.

Cheers,
Daniel.




 so I think I'll switch to Conda Python. I figured out how to use Conda.jl 
to get a separate matplotlib install


On Wednesday, 2 November 2016 15:29:31 UTC+1, Steven G. Johnson wrote:
>
> For the font-cache, see
> https://github.com/matplotlib/matplotlib/issues/5836
> ...there is some ~/.cache/matplotlib directory that you can delete to get 
> rid of this.
>
> To tell PyPlot to use the Conda Python, you need to set the PYTHON 
> environment variable and re-build PyCall:
>
> ENV["PYTHON"]=""
> Pkg.build("PyCall")
>

Re: [julia-users] Barnes-Hut N-body simulations (was recursive data structures with Julia)

[Angel de Vicente]

Hi,

Angel de Vicente  writes:
> OK, so this was just a test example to go for something bigger, and by
> using the cleaner version with Nullable fields I implemented a basic
> code to perform a Barnes-Hut N-body simulation
> (https://en.wikipedia.org/wiki/Barnes%E2%80%93Hut_simulation)
>
> The good think is that it works OK, and development while being able to
> use the REPL accelerates coding so much (in comparison to compiled
> languages), but the bad news is that it is ~25x slower than my own
> Fortran version :-( (I have tried to make all functions type stable and
> I have followed the same algorithm as in the Fortran version).

after playing a little bit with the profiler, following some of the
advice in
http://docs.julialang.org/en/release-0.5/manual/performance-tips/ and
doing some very minor changes to the code, these
are the times (the best of three runs in all cases) for a test run of
the code (100 time steps, 1000 bodies):

Fortran: compiled with gfortran -O0  2.72s
   gfortran -O3  1.29s

 compiled with ifort -O0 4.73s
   ifort -O3 1.17s

Julia:   v.0.5   3.85s
 (first run ignored to avoid first compilation time)


So my Julia version now takes ~3x the time of the Fortran one. Probably
I could improve it even further, but given that I'm still very new to
Julia this is not bad at all, I think. 

Good stuff!
-- 
Ángel de Vicente
http://www.iac.es/galeria/angelv/  

Re: [julia-users] Cannot PyPlot / Matplotlib broken (warnings about font cache?)

[Daniel Carrera]

On Wednesday, 2 November 2016 15:20:07 UTC+1, Isaiah wrote:
>
> Ok. So first of all, PyPlot is grabbing the system-wide installation of 
>> Python. I don't know how to tell PyPlot to look at the one that was 
>> installed with the Conda package.
>
>  
> https://github.com/JuliaPy/PyCall.jl#specifying-the-python-version
>
> To force Julia to use its own Python distribution, via Conda, rather than 
> whatever is installed on your system, simply set ENV["PYTHON"] to the 
> empty string "" as described above.
>
>

Thanks! I've realized that Conda.jl doesn't actually install Python. But I 
could use Anaconda to install Python in /opt and point Julia to that 
version.

 

> Second, the errors are saying something about fonts, but I can't figure 
>> out what they are saying. I am also confused by the "permission denied" 
>> error:
>
>
> Hard to say. Try checking the permissions of the files listed by 
> `fc-list`... Maybe something was installed with `sudo` that should not have 
> been. 
>
>
That wouldn't surprise me. The other day I was messing around with pip3 
when trying to setup Jupyter and the Octave kernel, and I did run some 
commands with sudo. Thanks.

[julia-users] JuliaDB?

[Seth]

>From http://juliacomputing.com/products/juliafin.html

*JuliaDB* is a high-performance, columnar data store for working with 
> large-scale time series data. What sets it apart from the existing products 
> in this area is the tight-knit integration of data and algorithms with the 
> full power of the Julia ecosystem. In addition, high-performance analytics, 
> easy parallelism, graphics and leveraging integrations with spreadsheets 
> and data sources is the key to simplifying algorithmic trading, 
> backtesting, and risk analytics.


However, the only references I can find to JuliaDB is the GitHub 
organization (https://github.com/JuliaDB). 

Is this code open source, and if so, where does it reside?

Re: [julia-users] Cannot PyPlot / Matplotlib broken (warnings about font cache?)

[Steven G. Johnson]

For the font-cache, see
https://github.com/matplotlib/matplotlib/issues/5836
...there is some ~/.cache/matplotlib directory that you can delete to get 
rid of this.

To tell PyPlot to use the Conda Python, you need to set the PYTHON 
environment variable and re-build PyCall:

ENV["PYTHON"]=""
Pkg.build("PyCall")

Re: [julia-users] Cannot PyPlot / Matplotlib broken (warnings about font cache?)

[Isaiah Norton]

>
> Ok. So first of all, PyPlot is grabbing the system-wide installation of
> Python. I don't know how to tell PyPlot to look at the one that was
> installed with the Conda package.


https://github.com/JuliaPy/PyCall.jl#specifying-the-python-version

To force Julia to use its own Python distribution, via Conda, rather than
whatever is installed on your system, simply set ENV["PYTHON"] to the empty
string "" as described above.


Second, the errors are saying something about fonts, but I can't figure out
> what they are saying. I am also confused by the "permission denied" error:


Hard to say. Try checking the permissions of the files listed by
`fc-list`... Maybe something was installed with `sudo` that should not have
been.


On Wed, Nov 2, 2016 at 10:12 AM, Daniel Carrera  wrote:

> Hi everyone,
>
>
> I am getting some cryptic errors when I try to load PyPlot. It seems to be
> a problem on the Python end, but I'm not sure. I tried to use the "Conda"
> package so that Julia would have its own (hopefully not-broken) copy of
> Python, but that didn't help as PyPlot is still looking at the system-wide
> install of Python. Here are the messages in full (and some comments after
> ward). I decided to start from a completely clean install of Julia 0.5 (no
> packages) to make sure that there was no problem there:
>
> ---
> $ mv ~/.julia/v0.5 ~/.julia/old-v0.5
> $ julia
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "?help" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.5.0 (2016-09-19 18:14 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
> |__/   |  x86_64-pc-linux-gnu
>
> julia> Pkg.add("Conda")
> INFO: Initializing package repository /home/daniel/.julia/v0.5
> INFO: Cloning METADATA from https://github.com/JuliaLang/METADATA.jl
> INFO: Installing BinDeps v0.4.5
> INFO: Installing Compat v0.9.3
> INFO: Installing Conda v0.3.2
> INFO: Installing JSON v0.8.0
> INFO: Installing SHA v0.2.1
> INFO: Installing URIParser v0.1.6
> INFO: Package database updated
>
> julia> Pkg.add("PyPlot")
> INFO: Installing ColorTypes v0.2.12
> INFO: Installing Colors v0.6.9
> INFO: Installing FixedPointNumbers v0.2.1
> INFO: Installing LaTeXStrings v0.2.0
> INFO: Installing MacroTools v0.3.2
> INFO: Installing PyCall v1.7.2
> INFO: Installing PyPlot v2.2.4
> INFO: Installing Reexport v0.0.3
> INFO: Building PyCall
> INFO: PyCall is using python (Python 2.7.12) at /usr/bin/python, libpython
> = libpython2.7
> INFO: Package database updated
>
> julia> using PyPlot
> INFO: Recompiling stale cache file /home/daniel/.julia/lib/v0.5/PyPlot.ji
> for module PyPlot.
> /usr/lib/python2.7/dist-packages/matplotlib/font_manager.py:273:
> UserWarning: Matplotlib is building the font cache using fc-list. This may
> take a moment.
>   warnings.warn('Matplotlib is building the font cache using fc-list. This
> may take a moment.')
> /usr/lib/python2.7/dist-packages/matplotlib/__init__.py:1352:
> UserWarning:  This call to matplotlib.use() has no effect
> because the backend has already been chosen;
> matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
> or matplotlib.backends is imported for the first time.
>
>   warnings.warn(_use_error_msg)
> /usr/lib/python2.7/dist-packages/matplotlib/font_manager.py:273:
> UserWarning: Matplotlib is building the font cache using fc-list. This may
> take a moment.
>   warnings.warn('Matplotlib is building the font cache using fc-list. This
> may take a moment.')
> /usr/lib/python2.7/dist-packages/matplotlib/font_manager.py:273:
> UserWarning: Matplotlib is building the font cache using fc-list. This may
> take a moment.
>   warnings.warn('Matplotlib is building the font cache using fc-list. This
> may take a moment.')
> /usr/lib/python2.7/dist-packages/matplotlib/font_manager.py:273:
> UserWarning: Matplotlib is building the font cache using fc-list. This may
> take a moment.
>   warnings.warn('Matplotlib is building the font cache using fc-list. This
> may take a moment.')
> /usr/lib/python2.7/dist-packages/matplotlib/font_manager.py:273:
> UserWarning: Matplotlib is building the font cache using fc-list. This may
> take a moment.
>   warnings.warn('Matplotlib is building the font cache using fc-list. This
> may take a moment.')
> WARNING: No working GUI backend found for matplotlib.
> /usr/lib/python2.7/dist-packages/matplotlib/font_manager.py:273:
> UserWarning: Matplotlib is building the font cache using fc-list. This may
> take a moment.
>   warnings.warn('Matplotlib is building the font cache using fc-list. This
> may take a moment.')
> ERROR: InitError: PyError (:PyImport_ImportModule)  'exceptions.IOError'>
> IOError(13, 'Permission denied')
>   File "/usr/lib/python2.7/dist-packages/matplotlib/pyplot.py", line 29,
> in 
> import 

[julia-users] Cannot PyPlot / Matplotlib broken (warnings about font cache?)

[Daniel Carrera]

Hi everyone,


I am getting some cryptic errors when I try to load PyPlot. It seems to be 
a problem on the Python end, but I'm not sure. I tried to use the "Conda" 
package so that Julia would have its own (hopefully not-broken) copy of 
Python, but that didn't help as PyPlot is still looking at the system-wide 
install of Python. Here are the messages in full (and some comments after 
ward). I decided to start from a completely clean install of Julia 0.5 (no 
packages) to make sure that there was no problem there:

---
$ mv ~/.julia/v0.5 ~/.julia/old-v0.5
$ julia
   _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.5.0 (2016-09-19 18:14 UTC)
 _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
|__/   |  x86_64-pc-linux-gnu

julia> Pkg.add("Conda")
INFO: Initializing package repository /home/daniel/.julia/v0.5
INFO: Cloning METADATA from https://github.com/JuliaLang/METADATA.jl
INFO: Installing BinDeps v0.4.5
INFO: Installing Compat v0.9.3
INFO: Installing Conda v0.3.2
INFO: Installing JSON v0.8.0
INFO: Installing SHA v0.2.1
INFO: Installing URIParser v0.1.6
INFO: Package database updated

julia> Pkg.add("PyPlot")
INFO: Installing ColorTypes v0.2.12
INFO: Installing Colors v0.6.9
INFO: Installing FixedPointNumbers v0.2.1
INFO: Installing LaTeXStrings v0.2.0
INFO: Installing MacroTools v0.3.2
INFO: Installing PyCall v1.7.2
INFO: Installing PyPlot v2.2.4
INFO: Installing Reexport v0.0.3
INFO: Building PyCall
INFO: PyCall is using python (Python 2.7.12) at /usr/bin/python, libpython 
= libpython2.7
INFO: Package database updated

julia> using PyPlot
INFO: Recompiling stale cache file /home/daniel/.julia/lib/v0.5/PyPlot.ji 
for module PyPlot.
/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py:273: 
UserWarning: Matplotlib is building the font cache using fc-list. This may 
take a moment.
  warnings.warn('Matplotlib is building the font cache using fc-list. This 
may take a moment.')
/usr/lib/python2.7/dist-packages/matplotlib/__init__.py:1352: UserWarning: 
 This call to matplotlib.use() has no effect
because the backend has already been chosen;
matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
or matplotlib.backends is imported for the first time.

  warnings.warn(_use_error_msg)
/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py:273: 
UserWarning: Matplotlib is building the font cache using fc-list. This may 
take a moment.
  warnings.warn('Matplotlib is building the font cache using fc-list. This 
may take a moment.')
/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py:273: 
UserWarning: Matplotlib is building the font cache using fc-list. This may 
take a moment.
  warnings.warn('Matplotlib is building the font cache using fc-list. This 
may take a moment.')
/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py:273: 
UserWarning: Matplotlib is building the font cache using fc-list. This may 
take a moment.
  warnings.warn('Matplotlib is building the font cache using fc-list. This 
may take a moment.')
/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py:273: 
UserWarning: Matplotlib is building the font cache using fc-list. This may 
take a moment.
  warnings.warn('Matplotlib is building the font cache using fc-list. This 
may take a moment.')
WARNING: No working GUI backend found for matplotlib.
/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py:273: 
UserWarning: Matplotlib is building the font cache using fc-list. This may 
take a moment.
  warnings.warn('Matplotlib is building the font cache using fc-list. This 
may take a moment.')
ERROR: InitError: PyError (:PyImport_ImportModule) 
IOError(13, 'Permission denied')
  File "/usr/lib/python2.7/dist-packages/matplotlib/pyplot.py", line 29, in 

import matplotlib.colorbar
  File "/usr/lib/python2.7/dist-packages/matplotlib/colorbar.py", line 34, 
in 
import matplotlib.collections as collections
  File "/usr/lib/python2.7/dist-packages/matplotlib/collections.py", line 
27, in 
import matplotlib.backend_bases as backend_bases
  File "/usr/lib/python2.7/dist-packages/matplotlib/backend_bases.py", line 
62, in 
import matplotlib.textpath as textpath
  File "/usr/lib/python2.7/dist-packages/matplotlib/textpath.py", line 15, 
in 
import matplotlib.font_manager as font_manager
  File "/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py", line 
1421, in 
_rebuild()
  File "/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py", line 
1406, in _rebuild
fontManager = FontManager()
  File "/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py", line 
1059, in __init__
self.ttflist = createFontList(self.ttffiles)
  File "/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py", line 

[julia-users] [ANN] julia-repl, an Emacs minor mode for running a Julia REPL

[Tamas Papp]

Hi Julia & Emacs users,

I wrote a minor mode for starting and interacting with a Julia REPL from
Emacs. It basically uses term, and defers to the Julia REPL for almost
everything. The main reason for using this instead of ESS is that some
packages, in particular Gallium and ASTinterpreter, require a more
capable terminal. You get completion and other extras of the Julia REPL
for free.

You can find it at

https://github.com/tpapp/julia-repl

If there is interest, I would be happy to submit it to MELPA, just file
an issue.

Best,

Tamas Papp

[julia-users] Re: Error calculating eigs of pentadiagonal matrix.

[Steven G. Johnson]

On Wednesday, November 2, 2016 at 9:48:38 AM UTC-4, Steven G. Johnson wrote:
>
>
>
> On Wednesday, November 2, 2016 at 6:43:48 AM UTC-4, Alejandro Castellanos 
> wrote:
>>
>> I use this command: *l, v = eigs(M,nev=15,which = :SM ,ritzvec=true)*
>>
>
> How are you constructing the matrix M? 
>
> Apparently eigs thinks that your matrix is symmetric positive-definite 
> (SPD), because it is trying to use a Cholesky factorization.Schrodinger 
> operators are indefinite unless the potential V is >= 0, so this won't 
> work.  (If you're calling cholfact, don't.)
>

Oh, nevermind, it is using an LDTL factorization, which is appropriate for 
symmetric-indefinite operators.

Seems like it might be a bug in the eigs function — it shouldn't have a 
problem with singular matrices.

[julia-users] Re: Error calculating eigs of pentadiagonal matrix.

[Steven G. Johnson]

On Wednesday, November 2, 2016 at 6:43:48 AM UTC-4, Alejandro Castellanos 
wrote:
>
> I use this command: *l, v = eigs(M,nev=15,which = :SM ,ritzvec=true)*
>

How are you constructing the matrix M? 

Apparently eigs thinks that your matrix is symmetric positive-definite 
(SPD), because it is trying to use a Cholesky factorization.Schrodinger 
operators are indefinite unless the potential V is >= 0, so this won't 
work.  (If you're calling cholfact, don't.)

Re: [julia-users] Re: avoid dollar $ interpolation in shell commands

[Stefan Karpinski]

You can make a command with quoted `$` like this: `echo \$x` or `echo '$x'`.

On Wed, Nov 2, 2016 at 8:00 AM, Christian Theil Have <
christiantheilh...@gmail.com> wrote:

> Thank you for the responses and my apologies for not being entirely clear:
> Actually, the $PATH variable was just to provide an example. I really did
> want to construct a Cmd with an unquoted dollar in it.
> The reason why I want do such a silly thing is that I have a toying with a
> package (https://github.com/cth/QsubCmds.jl) which generates shell
> scripts from Cmd's that are run through sun grid engine, so
> since the commands are not executed by Julia anymore, but a shell, it
> makes sense to allow interaction with shell variables. I do not know
> whether there could be any other use case for this (probably not).
>
> I get if this is not possible for the reason that there is no shell to
> expand variables when running Cmds from Julia, but I just wondered if there
> are some escaping mechanism that makes it possible to construct such
> commands.
>
> Best,
> Christian
>
>
>
> Den onsdag den 2. november 2016 kl. 12.23.00 UTC+1 skrev Stefan Karpinski:
>>
>> I think that needs some additional parens: `echo $(ENV["PATH"])`. This is
>> in fact, exactly what you need – Julia commands in backticks are not run by
>> a shell so there is no shell to expand any environment variables, only
>> Julia can expand them.
>>
>> On Wed, Nov 2, 2016 at 7:02 AM, Simon Byrne  wrote:
>>
>>> Perhaps not quite what you had in mind, but
>>>
>>> `echo $ENV["PATH"]`
>>>
>>> should work
>>>
>>> On Wednesday, 2 November 2016 10:43:47 UTC, Christian Theil Have wrote:

 Hi,

 I've been trying to create a shell command that refers to an
 environment variable, e.g.,

 echo $PATH

 Julia will interpolate $ in shell commands in backticks to Julia
 variables, i.e., `echo $PATH`, will look for a Julia variable PATH.
 What can I do if I really want to insist having a shell command that
 includes a (non-quoted) dollar-sign? Currently,
 my workaround is `sh -c "echo \$PATH"`, but this is not really
 satisfactory.

 Best,
 Christian

>>>
>>

[julia-users] Re: async read from device?

[Simon Byrne]

I found that this seemed to work:

const STICK_INPUT_DEV="/dev/input/event0"

@async begin
stream, pipe = open(`cat $STICK_INPUT_DEV`)
while true
s = read(stream, Stick)
if s.ev_type == EV_KEY
println(s)
end
end
end

but it would be nice if there was a way to do this without cat


On Tuesday, 1 November 2016 11:17:31 UTC, Simon Byrne wrote:
>
> I'm trying to read from an input device asynchronously. I tried the obvious
>
> @async begin
> dev = open(STICK_INPUT_DEV)
> while true
> s = read(dev, Stick)
> if s.ev_type == EV_KEY
> println(s)
> end
> end
> end
>
> But this doesn't seem to yield correctly. The full code is available here:
> https://gist.github.com/simonbyrne/70f8c944ed7a76c95b1c90a964e9d7d1
>
> I did come across this related discussion for file IO which didn't really 
> resolve the issue:
> https://groups.google.com/d/topic/julia-users/kfu_hgM3bnI/discussion
>
> What's the best way to do this?
>
> Simon
>

Re: [julia-users] Re: avoid dollar $ interpolation in shell commands

[Christian Theil Have]

Thank you for the responses and my apologies for not being entirely clear: 
Actually, the $PATH variable was just to provide an example. I really did 
want to construct a Cmd with an unquoted dollar in it.
The reason why I want do such a silly thing is that I have a toying with a 
package (https://github.com/cth/QsubCmds.jl) which generates shell scripts 
from Cmd's that are run through sun grid engine, so
since the commands are not executed by Julia anymore, but a shell, it makes 
sense to allow interaction with shell variables. I do not know whether 
there could be any other use case for this (probably not).

I get if this is not possible for the reason that there is no shell to 
expand variables when running Cmds from Julia, but I just wondered if there 
are some escaping mechanism that makes it possible to construct such 
commands.

Best,
Christian



Den onsdag den 2. november 2016 kl. 12.23.00 UTC+1 skrev Stefan Karpinski:
>
> I think that needs some additional parens: `echo $(ENV["PATH"])`. This is 
> in fact, exactly what you need – Julia commands in backticks are not run by 
> a shell so there is no shell to expand any environment variables, only 
> Julia can expand them.
>
> On Wed, Nov 2, 2016 at 7:02 AM, Simon Byrne  > wrote:
>
>> Perhaps not quite what you had in mind, but
>>
>> `echo $ENV["PATH"]`
>>
>> should work
>>
>> On Wednesday, 2 November 2016 10:43:47 UTC, Christian Theil Have wrote:
>>>
>>> Hi,
>>>
>>> I've been trying to create a shell command that refers to an environment 
>>> variable, e.g., 
>>>
>>> echo $PATH
>>>
>>> Julia will interpolate $ in shell commands in backticks to Julia 
>>> variables, i.e., `echo $PATH`, will look for a Julia variable PATH. 
>>> What can I do if I really want to insist having a shell command that 
>>> includes a (non-quoted) dollar-sign? Currently,
>>> my workaround is `sh -c "echo \$PATH"`, but this is not really 
>>> satisfactory.
>>>
>>> Best,
>>> Christian
>>>
>>
>

Re: [julia-users] Recursive data structures with Julia

[Jeffrey Sarnoff]

John,

Currently (v0.5) :
Which uses of non-concrete types are performance friendly?
What ways of using abstract types are a drag on performance?

Regards, Jeffrey


On Sunday, October 30, 2016 at 9:38:15 PM UTC-4, John Myles White wrote:
>
> Working with non-concrete types is often a problem for performance, so 
> this approach may not be very efficient compared with alternatives that are 
> more careful about the use of concrete types.
>
>  --John
>
> On Sunday, October 30, 2016 at 6:27:47 PM UTC-7, Ralph Smith wrote:
>>
>> Conversion is done by methods listed in base/nullable.jl
>>
>> I would like to know if there is any drawback to an alternative like
>>
>> abstract Bst
>>
>> immutable NullNode <: Bst end
>>
>> type BstNode <: Bst
>> val::Int
>> left::Bst
>> right::Bst
>> end
>>
>> isnull(t::Bst) = isa(t,NullNode)
>>
>> BstNode(key::Int) = BstNode(key, NullNode(), NullNode())
>>
>> which appears to be good for type-safety, and is (sometimes) slightly 
>> faster and less cumbersome than Nullables.
>>
>> On Sunday, October 30, 2016 at 6:24:42 PM UTC-4, Ángel de Vicente wrote:
>>>
>>> Hi, 
>>>
>>> by searching in the web I found 
>>> (
>>> http://stackoverflow.com/questions/36383517/how-to-implement-bst-in-julia) 
>>>
>>> a way to make my BST code much cleaner (as posted below). Nevertheless, 
>>> I don't find this very ellegant, since the head node is of type Bst, 
>>> while the children are of type Nullable{Bst} (is this the 'canonical' 
>>> way 
>>> of building recursive data structures with Julia?). 
>>>
>>> But when I first read the code in SO, I thought that it was probably 
>>> wrong, since it does: 
>>>
>>> node.left = BST(key) 
>>> where node.left is of type Nullable{BST}. 
>>>
>>> Then I realized that automatic conversion from BST to Nullable{BST} is 
>>> done when assigning to node.left, so all is good. Coming from Fortran, 
>>> this is a bit odd for me... what are the rules for automatic conversion? 
>>>   
>>>
>>>
>>> Thanks a lot, 
>>> Ángel de Vicente 
>>>
>>>
>>>
>>>
>>>
>>> , 
>>> | module b 
>>> | 
>>> | type Bst 
>>> | val::Int 
>>> | left::Nullable{Bst} 
>>> | right::Nullable{Bst} 
>>> | end 
>>> | Bst(key::Int) = Bst(key, Nullable{Bst}(), Nullable{Bst}())   
>>> | 
>>> | "Given an array of Ints, it will create a BST tree, type: Bst" 
>>> | function build_bst(list::Array{Int,1}) 
>>> | head = list[1] 
>>> | tree = Bst(head) 
>>> | for e in list[2:end] 
>>> | place_bst(tree,e) 
>>> | end 
>>> | return tree 
>>> | end 
>>> | 
>>> | function place_bst(tree::Bst,e::Int) 
>>> | if e == tree.val 
>>> | println("Dropping $(e). No repeated values allowed") 
>>> | elseif e < tree.val 
>>> | if (isnull(tree.left)) 
>>> | tree.left = Bst(e) 
>>> | else 
>>> | place_bst(tree.left.value,e) 
>>> | end 
>>> | else 
>>> | if (isnull(tree.right)) 
>>> | tree.right = Bst(e) 
>>> | else 
>>> | place_bst(tree.right.value,e) 
>>> | end 
>>> | end 
>>> | end 
>>> | 
>>> | function print_bst(tree::Bst) 
>>> | if !isnull(tree.left) print_bst(tree.left.value) end 
>>> | println(tree.val) 
>>> | if !isnull(tree.right) print_bst(tree.right.value) end 
>>> | end 
>>> | 
>>> | end 
>>> ` 
>>>
>>> , 
>>> | julia> include("bst.jl") 
>>> | 
>>> | julia> b.print_bst( b.build_bst([4,5,10,3,20,-1,10])) 
>>> | Dropping 10. No repeated values allowed 
>>> | -1 
>>> | 3 
>>> | 4 
>>> | 5 
>>> | 10 
>>> | 20 
>>> | 
>>> | julia> 
>>> ` 
>>>
>>>
>>> -- 
>>> Ángel de Vicente 
>>> http://www.iac.es/galeria/angelv/   
>>>
>>

[julia-users] Re: Error calculating eigs of pentadiagonal matrix.

[Jeffrey Sarnoff]

I have one suggestion: see if Andreas' LinearAlgebra.jl does any better.


Pkg.clone(""https://github.com/andreasnoack/LinearAlgebra.jl;)
using LinearAlgebra
# ...



If there is still difficulty, you may look at eigenGeneral.jl 

 and eigenSelfAdjoint.jl 

 to 
find which more specific versions of eigvals/eigvals! is appropriate for 
your scenario.


On Wednesday, November 2, 2016 at 6:43:48 AM UTC-4, Alejandro Castellanos 
wrote:
>
> Hello.
>
> I am working with a pentadiagonal sparse matrix that represents a 2D 
> Schrodinger's time-independent equation. I first work the laplacian 
> expressed in Finite Differences form and then I apply the potential on the 
> same matrix.
>
> So far I've been able to validate my results for both an electron in a box 
> as well as a harmonic oscillator, but when I change to the following 
> potential of a dipole, Julia pretty much quits on me when I try to obtain 
> the eigenvalues and eigenvectors:
>
>   O = [round(L/2)-hx round(L/2)-hy]# --el ORIGEN (centro -- x,y) 
> del potencial.
>   Eps_o  = 8.854187817e10-12# --F*m^-1
>   C = 1/(4*pi*Eps_o)
>   D = 1e-21#C*m^2/s# --Debyes)
>   pe= 1.8*D 
>   *P(X,Y)  = -(C)*pe*(Y/X)*(1/( (X)^2 + (Y)^2)   )*# --How the 
> potential gets described.
>  
> #--I'm aware there's singularities in the potential.
> #--and here's how I apply the potential to my sparse matrix.
>
>   Vi  = Float64[]# --container for the potential.
>   for j=Y  for i=X  push!(Vi,P(i,j))   end  end@ --applying the potential.
>
>
> I use this command: *l, v = eigs(M,nev=15,which = :SM ,ritzvec=true)*
>
> My problem seems to be that there's an error that I can't get past:
>
> ERROR: LoadError: ArgumentError: matrix has one or more zero pivots
>>>
>>>  in #ldltfact!#10(::Float64, ::Function, 
 ::Base.SparseArrays.CHOLMOD.Factor{Float64}, 
 ::Base.SparseArrays.CHOLMOD.Sparse{Float64}) at ./sparse/cholmod.jl:1350
>>>
>>>  in (::Base.LinAlg.#kw##ldltfact!)(::Array{Any,1}, 
 ::Base.LinAlg.#ldltfact!, ::Base.SparseArrays.CHOLMOD.Factor{Float64}, 
 ::Base.SparseArrays.CHOLMOD.Sparse{Float64}) at ./:0
>>>
>>>  in #ldltfact#12(::Float64, ::Array{Int64,1}, ::Function, 
 ::Base.SparseArrays.CHOLMOD.Sparse{Float64}) at ./sparse/cholmod.jl:1386
>>>
>>>  in #ldltfact#13(::Array{Any,1}, ::Function, 
 ::Hermitian{Float64,SparseMatrixCSC{Float64,Int64}}) at 
 ./sparse/cholmod.jl:1426
>>>
>>>  in factorize(::SparseMatrixCSC{Float64,Int64}) at ./sparse/linalg.jl:897
>>>
>>>  in #_eigs#62(::Int64, ::Int64, ::Symbol, ::Float64, ::Int64, ::Void, 
 ::Array{Float64,1}, ::Bool, ::Base.LinAlg.#_eigs, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at 
 ./linalg/arnoldi.jl:251
>>>
>>>  in (::Base.LinAlg.#kw##_eigs)(::Array{Any,1}, ::Base.LinAlg.#_eigs, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at ./:0
>>>
>>>  in #eigs#55(::Array{Any,1}, ::Function, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at 
 ./linalg/arnoldi.jl:78
>>>
>>>  in (::Base.LinAlg.#kw##eigs)(::Array{Any,1}, ::Base.LinAlg.#eigs, 
 ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at ./:0
>>>
>>>  in #eigs#54(::Array{Any,1}, ::Function, 
 ::SparseMatrixCSC{Float64,Int64}) at ./linalg/arnoldi.jl:77
>>>
>>>  in (::Base.LinAlg.#kw##eigs)(::Array{Any,1}, ::Base.LinAlg.#eigs, 
 ::SparseMatrixCSC{Float64,Int64}) at ./:0
>>>
>>>  in include_from_node1(::String) at ./loading.jl:488
>>>
>>> while loading /home/alejandro/Desktop/ACAD/PROG/ACADEMIC_PROGRAMMING/FDM 
 (Finite_Difference_Method)/2D/SCHROD_DIP_2D/SCRATCH-2D-SI-DIPOLO2.jl, in 
 expression starting on line 106
>>>
>>>
>>> My question is, is there a way to work around it, or, am I completely 
> screwed?
>
> Thanks so much in advance.
>

Re: [julia-users] Re: avoid dollar $ interpolation in shell commands

[Stefan Karpinski]

I think that needs some additional parens: `echo $(ENV["PATH"])`. This is
in fact, exactly what you need – Julia commands in backticks are not run by
a shell so there is no shell to expand any environment variables, only
Julia can expand them.

On Wed, Nov 2, 2016 at 7:02 AM, Simon Byrne  wrote:

> Perhaps not quite what you had in mind, but
>
> `echo $ENV["PATH"]`
>
> should work
>
> On Wednesday, 2 November 2016 10:43:47 UTC, Christian Theil Have wrote:
>>
>> Hi,
>>
>> I've been trying to create a shell command that refers to an environment
>> variable, e.g.,
>>
>> echo $PATH
>>
>> Julia will interpolate $ in shell commands in backticks to Julia
>> variables, i.e., `echo $PATH`, will look for a Julia variable PATH.
>> What can I do if I really want to insist having a shell command that
>> includes a (non-quoted) dollar-sign? Currently,
>> my workaround is `sh -c "echo \$PATH"`, but this is not really
>> satisfactory.
>>
>> Best,
>> Christian
>>
>

[julia-users] Re: avoid dollar $ interpolation in shell commands

[Simon Byrne]

Perhaps not quite what you had in mind, but

`echo $ENV["PATH"]`

should work

On Wednesday, 2 November 2016 10:43:47 UTC, Christian Theil Have wrote:
>
> Hi,
>
> I've been trying to create a shell command that refers to an environment 
> variable, e.g., 
>
> echo $PATH
>
> Julia will interpolate $ in shell commands in backticks to Julia 
> variables, i.e., `echo $PATH`, will look for a Julia variable PATH. 
> What can I do if I really want to insist having a shell command that 
> includes a (non-quoted) dollar-sign? Currently,
> my workaround is `sh -c "echo \$PATH"`, but this is not really 
> satisfactory.
>
> Best,
> Christian
>

Re: [julia-users] avoid dollar $ interpolation in shell commands

[Stefan Karpinski]

Are you trying to get the shell to expand $PATH but not Julia?

On Wed, Nov 2, 2016 at 5:40 AM, Christian Theil Have <
christiantheilh...@gmail.com> wrote:

> Hi,
>
> I've been trying to create a shell command that refers to an environment
> variable, e.g.,
>
> echo $PATH
>
> Julia will interpolate $ in shell commands in backticks to Julia
> variables, i.e., `echo $PATH`, will look for a Julia variable PATH.
> What can I do if I really want to insist having a shell command that
> includes a (non-quoted) dollar-sign? Currently,
> my workaround is `sh -c "echo \$PATH"`, but this is not really
> satisfactory.
>
> Best,
> Christian
>

[julia-users] Error calculating eigs of pentadiagonal matrix.

[Alejandro Castellanos]

Hello.

I am working with a pentadiagonal sparse matrix that represents a 2D 
Schrodinger's time-independent equation. I first work the laplacian 
expressed in Finite Differences form and then I apply the potential on the 
same matrix.

So far I've been able to validate my results for both an electron in a box 
as well as a harmonic oscillator, but when I change to the following 
potential of a dipole, Julia pretty much quits on me when I try to obtain 
the eigenvalues and eigenvectors:

  O = [round(L/2)-hx round(L/2)-hy]# --el ORIGEN (centro -- x,y) 
del potencial.
  Eps_o  = 8.854187817e10-12# --F*m^-1
  C = 1/(4*pi*Eps_o)
  D = 1e-21#C*m^2/s# --Debyes)
  pe= 1.8*D 
  *P(X,Y)  = -(C)*pe*(Y/X)*(1/( (X)^2 + (Y)^2)   )*# --How the 
potential gets described.
 
#--I'm aware there's singularities in the potential.
#--and here's how I apply the potential to my sparse matrix.

  Vi  = Float64[]# --container for the potential.
  for j=Y  for i=X  push!(Vi,P(i,j))   end  end@ --applying the potential.


I use this command: *l, v = eigs(M,nev=15,which = :SM ,ritzvec=true)*

My problem seems to be that there's an error that I can't get past:

ERROR: LoadError: ArgumentError: matrix has one or more zero pivots
>>
>>  in #ldltfact!#10(::Float64, ::Function, 
>>> ::Base.SparseArrays.CHOLMOD.Factor{Float64}, 
>>> ::Base.SparseArrays.CHOLMOD.Sparse{Float64}) at ./sparse/cholmod.jl:1350
>>
>>  in (::Base.LinAlg.#kw##ldltfact!)(::Array{Any,1}, 
>>> ::Base.LinAlg.#ldltfact!, ::Base.SparseArrays.CHOLMOD.Factor{Float64}, 
>>> ::Base.SparseArrays.CHOLMOD.Sparse{Float64}) at ./:0
>>
>>  in #ldltfact#12(::Float64, ::Array{Int64,1}, ::Function, 
>>> ::Base.SparseArrays.CHOLMOD.Sparse{Float64}) at ./sparse/cholmod.jl:1386
>>
>>  in #ldltfact#13(::Array{Any,1}, ::Function, 
>>> ::Hermitian{Float64,SparseMatrixCSC{Float64,Int64}}) at 
>>> ./sparse/cholmod.jl:1426
>>
>>  in factorize(::SparseMatrixCSC{Float64,Int64}) at ./sparse/linalg.jl:897
>>
>>  in #_eigs#62(::Int64, ::Int64, ::Symbol, ::Float64, ::Int64, ::Void, 
>>> ::Array{Float64,1}, ::Bool, ::Base.LinAlg.#_eigs, 
>>> ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at 
>>> ./linalg/arnoldi.jl:251
>>
>>  in (::Base.LinAlg.#kw##_eigs)(::Array{Any,1}, ::Base.LinAlg.#_eigs, 
>>> ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at ./:0
>>
>>  in #eigs#55(::Array{Any,1}, ::Function, 
>>> ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at 
>>> ./linalg/arnoldi.jl:78
>>
>>  in (::Base.LinAlg.#kw##eigs)(::Array{Any,1}, ::Base.LinAlg.#eigs, 
>>> ::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at ./:0
>>
>>  in #eigs#54(::Array{Any,1}, ::Function, 
>>> ::SparseMatrixCSC{Float64,Int64}) at ./linalg/arnoldi.jl:77
>>
>>  in (::Base.LinAlg.#kw##eigs)(::Array{Any,1}, ::Base.LinAlg.#eigs, 
>>> ::SparseMatrixCSC{Float64,Int64}) at ./:0
>>
>>  in include_from_node1(::String) at ./loading.jl:488
>>
>> while loading /home/alejandro/Desktop/ACAD/PROG/ACADEMIC_PROGRAMMING/FDM 
>>> (Finite_Difference_Method)/2D/SCHROD_DIP_2D/SCRATCH-2D-SI-DIPOLO2.jl, in 
>>> expression starting on line 106
>>
>>
>> My question is, is there a way to work around it, or, am I completely 
screwed?

Thanks so much in advance.

[julia-users] avoid dollar $ interpolation in shell commands

[Christian Theil Have]

Hi,

I've been trying to create a shell command that refers to an environment 
variable, e.g., 

echo $PATH

Julia will interpolate $ in shell commands in backticks to Julia variables, 
i.e., `echo $PATH`, will look for a Julia variable PATH. 
What can I do if I really want to insist having a shell command that 
includes a (non-quoted) dollar-sign? Currently,
my workaround is `sh -c "echo \$PATH"`, but this is not really satisfactory.

Best,
Christian

Re: [julia-users] Re: Fast vector element-wise multiplication

[Patrick Kofod Mogensen]

Does that work for you? I have to write

A .= (*).(A,B)

On Wednesday, November 2, 2016 at 3:51:54 AM UTC+1, Chris Rackauckas wrote:
>
> It's the other way around. .* won't fuse because it's still an operator. 
> .= will. It you want .* to fuse, you can instead do:
>
> A .= *.(A,B)
>
> since this invokes the broadcast on *, instead of invoking .*. But that's 
> just a temporary thing.
>
> On Tuesday, November 1, 2016 at 7:27:40 PM UTC-7, Tom Breloff wrote:
>>
>> As I understand it, the .* will fuse, but the .= will not (until 0.6?), 
>> so A will be rebound to a newly allocated array.  If my understanding is 
>> wrong I'd love to know.  There have been many times in the last few days 
>> that I would have used it...
>>
>> On Tue, Nov 1, 2016 at 10:06 PM, Sheehan Olver  
>> wrote:
>>
>>> Ah, good point.  Though I guess that won't work til 0.6 since .* won't 
>>> auto-fuse yet? 
>>>
>>> Sent from my iPhone
>>>
>>> On 2 Nov. 2016, at 12:55, Chris Rackauckas  wrote:
>>>
>>> This is pretty much obsolete by the . fusing changes:
>>>
>>> A .= A.*B
>>>
>>> should be an in-place update of A scaled by B (Tomas' solution).
>>>
>>> On Tuesday, November 1, 2016 at 4:39:15 PM UTC-7, Sheehan Olver wrote:

 Should this be added to a package?  I imagine if the arrays are on the 
 GPU (AFArrays) then the operation could be much faster, and having a 
 consistent name would be helpful.


 On Wednesday, October 7, 2015 at 1:28:29 AM UTC+11, Lionel du Peloux 
 wrote:
>
> Dear all,
>
> I'm looking for the fastest way to do element-wise vector 
> multiplication in Julia. The best I could have done is the following 
> implementation which still runs 1.5x slower than the dot product. I 
> assume 
> the dot product would include such an operation ... and then do a 
> cumulative sum over the element-wise product.
>
> The MKL lib includes such an operation (v?Mul) but it seems OpenBLAS 
> does not. So my question is :
>
> 1) is there any chance I can do vector element-wise multiplication 
> faster then the actual dot product ?
> 2) why the built-in element-wise multiplication operator (*.) is much 
> slower than my own implementation for such a basic linealg operation 
> (full 
> julia) ? 
>
> Thank you,
> Lionel
>
> Best custom implementation :
>
> function xpy!{T<:Number}(A::Vector{T},B::Vector{T})
>   n = size(A)[1]
>   if n == size(B)[1]
> for i=1:n
>   @inbounds A[i] *= B[i]
> end
>   end
>   return A
> end
>
> Bench mark results (JuliaBox, A = randn(30) :
>
> function  CPU (s) GC (%)  ALLOCATION (bytes)  
> CPU (x) 
> dot(A,B)  1.58e-040.0016  
> 1.0 xpy!(A,B) 2.31e-040.0080  
> 1.5 
> NumericExtensions.multiply!(P,Q)  3.60e-040.0080  
> 2.3 xpy!(A,B) - no @inbounds check4.36e-040.0080  
> 2.8 
> P.*Q  2.52e-0350.36   2400512 
> 16.0
> 
>
>
>>

Re: [julia-users] Re: Fast vector element-wise multiplication

[Tim Holy]

Hmm, that's surprising. Looks like we're using generic broadcasting
machinery for that operation (check out what @which P.*P returns). Might be
good to add .* to this line:
https://github.com/JuliaLang/julia/blob/b7f1aa7554c71d3759702b9c2e14904ebdc94199/base/arraymath.jl#L69.
Want to make a pull request?

Best,
--Tim

Re: [julia-users] Re: Fast vector element-wise multiplication

[Sheehan Olver]

OK, good to know. I think putting the function in a package is overkill.





> On 2 Nov. 2016, at 6:35 pm, Chris Rackauckas  wrote:
> 
> Yes, this most likely won't help for GPU arrays because you likely don't want 
> to be looping through elements serially: you want to call a vectorized GPU 
> function which will do the computation in parallel on the GPU. ArrayFire's 
> mathematical operations are already overloaded to do this, but I don't think 
> they can fuse.
> 
> On Tuesday, November 1, 2016 at 8:06:12 PM UTC-7, Sheehan Olver wrote:
> Ah thanks!
> 
> Though I guess if I want the same code to work also on a GPU array then this 
> won't help?
> 
> Sent from my iPhone
> 
> On 2 Nov. 2016, at 13:51, Chris Rackauckas  
> wrote:
> 
>> It's the other way around. .* won't fuse because it's still an operator. .= 
>> will. It you want .* to fuse, you can instead do:
>> 
>> A .= *.(A,B)
>> 
>> since this invokes the broadcast on *, instead of invoking .*. But that's 
>> just a temporary thing.
>> 
>> On Tuesday, November 1, 2016 at 7:27:40 PM UTC-7, Tom Breloff wrote:
>> As I understand it, the .* will fuse, but the .= will not (until 0.6?), so A 
>> will be rebound to a newly allocated array.  If my understanding is wrong 
>> I'd love to know.  There have been many times in the last few days that I 
>> would have used it...
>> 
>> On Tue, Nov 1, 2016 at 10:06 PM, Sheehan Olver > wrote:
>> Ah, good point.  Though I guess that won't work til 0.6 since .* won't 
>> auto-fuse yet? 
>> 
>> Sent from my iPhone
>> 
>> On 2 Nov. 2016, at 12:55, Chris Rackauckas > wrote:
>> 
>>> This is pretty much obsolete by the . fusing changes:
>>> 
>>> A .= A.*B
>>> 
>>> should be an in-place update of A scaled by B (Tomas' solution).
>>> 
>>> On Tuesday, November 1, 2016 at 4:39:15 PM UTC-7, Sheehan Olver wrote:
>>> Should this be added to a package?  I imagine if the arrays are on the GPU 
>>> (AFArrays) then the operation could be much faster, and having a consistent 
>>> name would be helpful.
>>> 
>>> 
>>> On Wednesday, October 7, 2015 at 1:28:29 AM UTC+11, Lionel du Peloux wrote:
>>> Dear all,
>>> 
>>> I'm looking for the fastest way to do element-wise vector multiplication in 
>>> Julia. The best I could have done is the following implementation which 
>>> still runs 1.5x slower than the dot product. I assume the dot product would 
>>> include such an operation ... and then do a cumulative sum over the 
>>> element-wise product.
>>> 
>>> The MKL lib includes such an operation (v?Mul) but it seems OpenBLAS does 
>>> not. So my question is :
>>> 
>>> 1) is there any chance I can do vector element-wise multiplication faster 
>>> then the actual dot product ?
>>> 2) why the built-in element-wise multiplication operator (*.) is much 
>>> slower than my own implementation for such a basic linealg operation (full 
>>> julia) ? 
>>> 
>>> Thank you,
>>> Lionel
>>> 
>>> Best custom implementation :
>>> 
>>> function xpy!{T<:Number}(A::Vector{T},B::Vector{T})
>>>   n = size(A)[1]
>>>   if n == size(B)[1]
>>> for i=1:n
>>>   @inbounds A[i] *= B[i]
>>> end
>>>   end
>>>   return A
>>> end
>>> 
>>> Bench mark results (JuliaBox, A = randn(30) :
>>> 
>>> function  CPU (s) GC (%)  ALLOCATION (bytes)  
>>> CPU (x) 
>>> dot(A,B)  1.58e-040.0016  
>>> 1.0 
>>> xpy!(A,B) 2.31e-040.0080  
>>> 1.5 
>>> NumericExtensions.multiply!(P,Q)  3.60e-040.0080  
>>> 2.3 
>>> xpy!(A,B) - no @inbounds check4.36e-040.0080  
>>> 2.8 
>>> P.*Q  2.52e-0350.36   2400512 
>>> 16.0
>>> 
>> 

Re: [julia-users] Re: Fast vector element-wise multiplication

[Chris Rackauckas]

Yes, this most likely won't help for GPU arrays because you likely don't 
want to be looping through elements serially: you want to call a vectorized 
GPU function which will do the computation in parallel on the GPU. 
ArrayFire's mathematical operations are already overloaded to do this, but 
I don't think they can fuse.

On Tuesday, November 1, 2016 at 8:06:12 PM UTC-7, Sheehan Olver wrote:
>
> Ah thanks!
>
> Though I guess if I want the same code to work also on a GPU array then 
> this won't help?
>
> Sent from my iPhone
>
> On 2 Nov. 2016, at 13:51, Chris Rackauckas  > wrote:
>
> It's the other way around. .* won't fuse because it's still an operator. 
> .= will. It you want .* to fuse, you can instead do:
>
> A .= *.(A,B)
>
> since this invokes the broadcast on *, instead of invoking .*. But that's 
> just a temporary thing.
>
> On Tuesday, November 1, 2016 at 7:27:40 PM UTC-7, Tom Breloff wrote:
>>
>> As I understand it, the .* will fuse, but the .= will not (until 0.6?), 
>> so A will be rebound to a newly allocated array.  If my understanding is 
>> wrong I'd love to know.  There have been many times in the last few days 
>> that I would have used it...
>>
>> On Tue, Nov 1, 2016 at 10:06 PM, Sheehan Olver  
>> wrote:
>>
>>> Ah, good point.  Though I guess that won't work til 0.6 since .* won't 
>>> auto-fuse yet? 
>>>
>>> Sent from my iPhone
>>>
>>> On 2 Nov. 2016, at 12:55, Chris Rackauckas  wrote:
>>>
>>> This is pretty much obsolete by the . fusing changes:
>>>
>>> A .= A.*B
>>>
>>> should be an in-place update of A scaled by B (Tomas' solution).
>>>
>>> On Tuesday, November 1, 2016 at 4:39:15 PM UTC-7, Sheehan Olver wrote:

 Should this be added to a package?  I imagine if the arrays are on the 
 GPU (AFArrays) then the operation could be much faster, and having a 
 consistent name would be helpful.


 On Wednesday, October 7, 2015 at 1:28:29 AM UTC+11, Lionel du Peloux 
 wrote:
>
> Dear all,
>
> I'm looking for the fastest way to do element-wise vector 
> multiplication in Julia. The best I could have done is the following 
> implementation which still runs 1.5x slower than the dot product. I 
> assume 
> the dot product would include such an operation ... and then do a 
> cumulative sum over the element-wise product.
>
> The MKL lib includes such an operation (v?Mul) but it seems OpenBLAS 
> does not. So my question is :
>
> 1) is there any chance I can do vector element-wise multiplication 
> faster then the actual dot product ?
> 2) why the built-in element-wise multiplication operator (*.) is much 
> slower than my own implementation for such a basic linealg operation 
> (full 
> julia) ? 
>
> Thank you,
> Lionel
>
> Best custom implementation :
>
> function xpy!{T<:Number}(A::Vector{T},B::Vector{T})
>   n = size(A)[1]
>   if n == size(B)[1]
> for i=1:n
>   @inbounds A[i] *= B[i]
> end
>   end
>   return A
> end
>
> Bench mark results (JuliaBox, A = randn(30) :
>
> function  CPU (s) GC (%)  ALLOCATION (bytes)  
> CPU (x) 
> dot(A,B)  1.58e-040.0016  
> 1.0 xpy!(A,B) 2.31e-040.0080  
> 1.5 
> NumericExtensions.multiply!(P,Q)  3.60e-040.0080  
> 2.3 xpy!(A,B) - no @inbounds check4.36e-040.0080  
> 2.8 
> P.*Q  2.52e-0350.36   2400512 
> 16.0
> 
>
>
>>

Re: [julia-users] Reducing complexity of OffsetArrays

[Tamas Papp]

Is there a general recommendation for dealing with the case when a
function encounters two arrays with different index sets? Eg

OffsetArray(1:5,1:5) + OffsetArray(1:5, -2:2)

currently gives a DimensionMismatch exception via promote_shape, so
perhaps one should simply rely on what the latter does. But one can
imagine other options too (eg all unrepresented indices as 0, etc). If
there is a blog post or issue summarizing the options, I would be
interested in reading it (could not find anything).

On Tue, Nov 01 2016, Tim Holy wrote:

> There's still a simple model: the indices are the *key* of the entry. Think
> about an array as a very special Dict. You could create a Dict with integer
> keys, let's say from -2:5. Presumably you wouldn't be exactly happy if
> there were some magical way that the number you originally stored as `d[-1]
> = 3.2` were alternatively accessible as `d[2]`, simply because the smallest
> index was -2 and therefore 3.2 is the "second" entry?
>
> Like a Dict, for an array the value always goes with the key (the indices).
> Perhaps this will help:
> ```
> julia> using OffsetArrays
>
> julia> a = OffsetArray(rand(11), -5:5)
> OffsetArrays.OffsetArray{Float64,1,Array{Float64,1}} with indices -5:5:
>  0.815289
>  0.0043941
>  0.00403153
>  0.478065
>  0.150709
>  0.256156
>  0.934703
>  0.672495
>  0.428721
>  0.242469
>  0.43742
>
> julia> idx = OffsetArray(-1:1, -1:1)
> OffsetArrays.OffsetArray{Int64,1,UnitRange{Int64}} with indices -1:1:
>  -1
>   0
>   1
>
> julia> b = a[idx]
> OffsetArrays.OffsetArray{Float64,1,Array{Float64,1}} with indices -1:1:
>  0.150709
>  0.256156
>  0.934703
>
> julia> a[-1]
> 0.15070935766983662
>
> julia> b[-1]
> 0.15070935766983662
> ```
> So indexing `b = a[idx]` means that `b[j] = a[idx[j]]`. Does that help?
>
> Best,
> --Tim
>
> On Tue, Nov 1, 2016 at 3:36 PM, Bob Portmann  wrote:
>
>> Like I said, no real practical experience yet. The increase in complexity
>> that I fear is the loss of, e.g., writing arr[2,3] and having it not be the
>> element in the 2nd row and third column (i.e., the loss of a simple model
>> of how things are laid out). Maybe my fears are unfounded. Others don't
>> seem concerned it would seem.
>>
>> I'll check out those packages that you mention.
>>
>> Thanks,
>> Bob
>>
>> On Sun, Oct 30, 2016 at 2:29 PM, Tim Holy  wrote:
>>
>>> I'm afraid I still don't understand the claimed big increment in
>>> complexity. First, let's distinguish "generic offset arrays" from the
>>> OffsetArrays.jl package. If you're happy using OffsetArrays, you don't have
>>> to write your own offset-array type. Being able to use an established &
>>> tested package reduces your burden a lot, and you can ignore the second
>>> half of the devdocs page entirely.
>>>
>>> If you just want to *use* OffsetArrays.jl, the basic changes in coding
>>> style for writing indices-aware code are:
>>>
>>> - any place you used to call `size`, you probably want to call `indices`
>>> instead (and likely make minor adjustments elsewhere, since `incides`
>>> returns a tuple-of-ranges---but such changes tend to be very obvious);
>>> - check all uses of `similar`; some will stay as-is, other will migrate
>>> to `similar(f, inds)` style.
>>>
>>> In my experience, that's just about it. The devdocs goes into quite a lot
>>> of detail to explain the rationale, but really the actual changes are quite
>>> small. While you can't quite do it via `grep` and `sed`, to me that just
>>> doesn't seem complicated.
>>>
>>> Where the pain comes is that if you're converting old code, you sometimes
>>> have to think your way through it again---"hmm, what do I really mean by
>>> this index"? If your code had complicated indexing the first time you wrote
>>> it, unfortunately you're going to have to think about it carefully again;
>>> so in some cases, "porting" code is almost as bad as writing it the first
>>> time. However, if you write indices-aware code in the first place, in my
>>> experience the added burden is almost negligible, and in quite a few cases
>>> the ability to offset array indices makes things *easier* (e.g., "padding"
>>> an array on its edges is oh-so-much-clearer than it used to be, it's like a
>>> different world). That's the whole reason I implemented this facility in
>>> julia-0.5: to make life easier, not to make it harder. (Personally I think
>>> the whole argument over 0-based and 1-based indexing is stupid; it's the
>>> ability to use arbitrary indices that I find interesting & useful, and it
>>> makes most of my code prettier.)
>>>
>>> For examples of packages that use OffsetArrays, check the following:
>>> - CatIndices
>>> - FFTViews
>>> - ImageFiltering
>>>
>>> ImageFiltering is a mixed bag: there's a small performance penalty in a
>>> few cases (even if you use @unsafe) because that LLVM doesn't always
>>> optimize code as well as it could in principle (maybe @polly will help
>>> someday...). Because image filtering is an