Re: [julia-users] Re: Capture the output of Julia's console

[Steven G. Johnson]

On Thursday, July 3, 2014 9:20:55 PM UTC-4, Laszlo Hars wrote:
>
> Looking into Steve's code we see it cheats. Our problem has been that the 
> Julia console output does not appear on STDOUT, only the results of print() 
> do. Steve's code evaluates the input expression and then prints it. 
>

The point I have been trying to make is that you probably shouldn't be 
using the REPL ("console") at all for this sort of thing, which is not what 
the REPL was designed for; you should be writing your own read/print 
script.  Outside of the REPL, you have no choice but to use print (or 
similar) if you want to see a result.

Re: [julia-users] Re: Why is string concatenation done with * not +

[Laszlo Hars]

Of course, 2str, 2*str and str*2 could be equivalent, as they are for other 
data types. For me two (copies of) str is just more natural than str1 times 
str2. Similarly, "add" str2 to str1 for concatenation follows the natural 
language better. Also, you could define str1-str2 as deleting str2 from 
(the beginning/end of) str1, if it was there. (even though str2/str1 works, 
too). You can find in algebra ample examples for both multiplicative and 
additive notations for structures, but either way the notation of string 
concatenation is the least of our difficulties when learning Julia.

On Thursday, July 3, 2014 10:12:47 AM UTC-6, Stefan Karpinski wrote:
>
> On Thu, Jul 3, 2014 at 12:09 PM, Patrick O'Leary  > wrote:
>
>> I do find the generalization to string exponentiation -> repetition is 
>> pretty beautiful.
>
>
> This is my favorite part about the * choice. From str+str it's not at all 
> obvious whether 2str or str*2 is the right choice for string repetition. I 
> also agree that's fascinating how attached people get to string 
> concatenation operators. Don't get Jeff started on string interpolation, 
> which is essentially a fancy string concatenation syntax.
>  

Re: [julia-users] Re: Capture the output of Julia's console

[Laszlo Hars]

Looking into Steve's code we see it cheats. Our problem has been that the 
Julia console output does not appear on STDOUT, only the results of print() 
do. Steve's code evaluates the input expression and then prints it. What we 
see in STDOUT is not the Julia console output, but results of "println("RESULT 
= ", result)". We can have this effect without an infinite loop, what I 
ended up using during the last couple of days:
const STDOUT_orig = STDOUT

function evalh(s::String) # paste to console: evalh(""" 
""")\n
try
rd,wr = redirect_stdout()
s = eval(Base.parse_input_line(s))
close(wr) # needed for readall()
s = readall(rd) * (s == nothing ? "" : string(s))
catch s
finally
redirect_stdout(STDOUT_orig)
end
clipboard(s) # return result/error-message
end

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Donald Lacombe]

Johan,

I think there may be an issue with the Data Frames package as I get the 
following:

julia> data = readtable("test.csv",header=false)

6x2 DataFrame:

x1 x2

[1,] 1  7

[2,] 2  8

[3,] 3  9

[4,] 4 10

[5,] 5 11

[6,] 6 12



julia> convert(Array,data)

MethodError(convert,(Array{T,N},6x2 DataFrame:

x1 x2

[1,] 1  7

[2,] 2  8

[3,] 3  9

[4,] 4 10

[5,] 5 11

[6,] 6 12

))


julia> dropna(data)

ErrorException("dropna not defined")


I read the documentation and they both say the same thing but it doesn't seem 
to work in my case.


Thoughts?


Thanks,

Don


On Thursday, July 3, 2014 7:54:49 PM UTC-4, Johan Sigfrids wrote:
>
> You can use dropna() to convert a DataArray to a Array. This will 
> obviously drop any missing values. 
>
> On Friday, July 4, 2014 2:08:55 AM UTC+3, Donald Lacombe wrote:
>>
>> Patrick (and others),
>>
>> Another issue that has reared it's ugly head is that when I read the data 
>> using the Data Frames package, I get the following:
>>
>> data = readtable("ct_coord_2.csv",header=false)
>>
>> 8x2 DataFrame:
>>
>>   x1  x2
>>
>> [1,]-73.3712  41.225
>>
>> [2,]-72.1065 41.4667
>>
>> [3,]-73.2453 41.7925
>>
>> [4,]-71.9876   41.83
>>
>> [5,]-72.3365  41.855
>>
>> [6,]-72.7328 41.8064
>>
>> [7,]-72.5231 41.4354
>>
>> [8,]-72.8999 41.3488
>>
>>
>> julia> xc = data[:,1]
>>
>> 8-element DataArray{Float64,1}:
>>
>>  -73.3712
>>
>>  -72.1065
>>
>>  -73.2453
>>
>>  -71.9876
>>
>>  -72.3365
>>
>>  -72.7328
>>
>>  -72.5231
>>
>>  -72.8999
>>
>>
>> julia> yc = data[:,2]
>>
>> 8-element DataArray{Float64,1}:
>>
>>  41.225 
>>
>>  41.4667
>>
>>  41.7925
>>
>>  41.83  
>>
>>  41.855 
>>
>>  41.8064
>>
>>  41.4354
>>
>>  41.3488
>>
>>
>> julia> xc=xc'
>>
>> 1x8 DataArray{Float64,2}:
>>
>>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>>
>>
>> julia> yc=yc'
>>
>> 1x8 DataArray{Float64,2}:
>>
>>  41.225  41.4667  41.7925  41.83  41.855  41.8064  41.4354  41.3488
>>
>>
>> julia> temp = [xc;yc]
>>
>> 2x8 DataArray{Float64,2}:
>>
>>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>>
>>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488
>>
>>
>> julia> R = pairwise(Euclidean(),temp)
>>
>> MethodError(At_mul_B!,(
>>
>> 8x8 Array{Float64,2}:
>>
>>  2.7273e-316   2.7273e-316   2.67478e-315  …  2.7273e-316   2.7273e-316 
>>
>>  2.67736e-315  2.67736e-315  2.67736e-315 2.72726e-316  2.72726e-316
>>
>>  2.67727e-315  2.67727e-315  2.67727e-315 2.67727e-315  2.67727e-315
>>
>>  2.67727e-315  2.67727e-315  2.67727e-315 2.67727e-315  2.67727e-315
>>
>>  4.94066e-324  4.94066e-324  4.94066e-324 9.88131e-324  4.94066e-324
>>
>>  2.76235e-318  2.76235e-318  2.76235e-318  …  2.76235e-318  2.76235e-318
>>
>>  4.94066e-324  4.94066e-324  4.94066e-324 9.88131e-324  4.94066e-324
>>
>>  4.94066e-324  4.94066e-324  4.94066e-324 9.88131e-324  4.94066e-324,
>>
>>
>> 2x8 DataArray{Float64,2}:
>>
>>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>>
>>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488,
>>
>>
>> 2x8 DataArray{Float64,2}:
>>
>>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>>
>>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488))
>>
>>
>> I do not think that the Distance package likes the types that is input into 
>> the function, i.e. the vectors are DataArrays instead of Arrays. It works 
>> just fine when I used Tony's idea:
>>
>>
>>  julia> data = readcsv("ct_coord_2.csv",Float64)
>>
>> 8x2 Array{Float64,2}:
>>
>>  -73.3712  41.225 
>>
>>  -72.1065  41.4667
>>
>>  -73.2453  41.7925
>>
>>  -71.9876  41.83  
>>
>>  -72.3365  41.855 
>>
>>  -72.7328  41.8064
>>
>>  -72.5231  41.4354
>>
>>  -72.8999  41.3488
>>
>>
>> julia> xc = data[:,1]
>>
>> 8-element Array{Float64,1}:
>>
>>  -73.3712
>>
>>  -72.1065
>>
>>  -73.2453
>>
>>  -71.9876
>>
>>  -72.3365
>>
>>  -72.7328
>>
>>  -72.5231
>>
>>  -72.8999
>>
>>
>> julia> yc = data[:,2]
>>
>> 8-element Array{Float64,1}:
>>
>>  41.225 
>>
>>  41.4667
>>
>>  41.7925
>>
>>  41.83  
>>
>>  41.855 
>>
>>  41.8064
>>
>>  41.4354
>>
>>  41.3488
>>
>>
>> julia> xc=xc'
>>
>> 1x8 Array{Float64,2}:
>>
>>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>>
>>
>> julia> yc=yc'
>>
>> 1x8 Array{Float64,2}:
>>
>>  41.225  41.4667  41.7925  41.83  41.855  41.8064  41.4354  41.3488
>>
>>
>> julia> temp = [xc;yc]
>>
>> 2x8 Array{Float64,2}:
>>
>>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>>
>>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488
>>
>>
>> julia> R = pairwise(Euclidean(),temp)
>>
>> 8x8 Array{Float64,2}:
>>
>>  0.0   1.28762   0.581327  1.51014   …  0.863479  0.873799  0.487347
>>
>>  1.28762   0.0   1.18451   0.382214 0.712542  0.417808  0.802085
>>
>>  0.581327  1.18451   0.0

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Donald Lacombe]

Dear Johan,

Tank you for this bit of information. It seems to me that the DataFrames 
package might become the defacto manner in which data is imported into 
Julia but I'd still like to have both options open.

Thank you all again,
Don 

On Thursday, July 3, 2014 7:54:49 PM UTC-4, Johan Sigfrids wrote:
>
> You can use dropna() to convert a DataArray to a Array. This will 
> obviously drop any missing values. 
>
> On Friday, July 4, 2014 2:08:55 AM UTC+3, Donald Lacombe wrote:
>>
>> Patrick (and others),
>>
>> Another issue that has reared it's ugly head is that when I read the data 
>> using the Data Frames package, I get the following:
>>
>> data = readtable("ct_coord_2.csv",header=false)
>>
>> 8x2 DataFrame:
>>
>>   x1  x2
>>
>> [1,]-73.3712  41.225
>>
>> [2,]-72.1065 41.4667
>>
>> [3,]-73.2453 41.7925
>>
>> [4,]-71.9876   41.83
>>
>> [5,]-72.3365  41.855
>>
>> [6,]-72.7328 41.8064
>>
>> [7,]-72.5231 41.4354
>>
>> [8,]-72.8999 41.3488
>>
>>
>> julia> xc = data[:,1]
>>
>> 8-element DataArray{Float64,1}:
>>
>>  -73.3712
>>
>>  -72.1065
>>
>>  -73.2453
>>
>>  -71.9876
>>
>>  -72.3365
>>
>>  -72.7328
>>
>>  -72.5231
>>
>>  -72.8999
>>
>>
>> julia> yc = data[:,2]
>>
>> 8-element DataArray{Float64,1}:
>>
>>  41.225 
>>
>>  41.4667
>>
>>  41.7925
>>
>>  41.83  
>>
>>  41.855 
>>
>>  41.8064
>>
>>  41.4354
>>
>>  41.3488
>>
>>
>> julia> xc=xc'
>>
>> 1x8 DataArray{Float64,2}:
>>
>>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>>
>>
>> julia> yc=yc'
>>
>> 1x8 DataArray{Float64,2}:
>>
>>  41.225  41.4667  41.7925  41.83  41.855  41.8064  41.4354  41.3488
>>
>>
>> julia> temp = [xc;yc]
>>
>> 2x8 DataArray{Float64,2}:
>>
>>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>>
>>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488
>>
>>
>> julia> R = pairwise(Euclidean(),temp)
>>
>> MethodError(At_mul_B!,(
>>
>> 8x8 Array{Float64,2}:
>>
>>  2.7273e-316   2.7273e-316   2.67478e-315  …  2.7273e-316   2.7273e-316 
>>
>>  2.67736e-315  2.67736e-315  2.67736e-315 2.72726e-316  2.72726e-316
>>
>>  2.67727e-315  2.67727e-315  2.67727e-315 2.67727e-315  2.67727e-315
>>
>>  2.67727e-315  2.67727e-315  2.67727e-315 2.67727e-315  2.67727e-315
>>
>>  4.94066e-324  4.94066e-324  4.94066e-324 9.88131e-324  4.94066e-324
>>
>>  2.76235e-318  2.76235e-318  2.76235e-318  …  2.76235e-318  2.76235e-318
>>
>>  4.94066e-324  4.94066e-324  4.94066e-324 9.88131e-324  4.94066e-324
>>
>>  4.94066e-324  4.94066e-324  4.94066e-324 9.88131e-324  4.94066e-324,
>>
>>
>> 2x8 DataArray{Float64,2}:
>>
>>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>>
>>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488,
>>
>>
>> 2x8 DataArray{Float64,2}:
>>
>>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>>
>>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488))
>>
>>
>> I do not think that the Distance package likes the types that is input into 
>> the function, i.e. the vectors are DataArrays instead of Arrays. It works 
>> just fine when I used Tony's idea:
>>
>>
>>  julia> data = readcsv("ct_coord_2.csv",Float64)
>>
>> 8x2 Array{Float64,2}:
>>
>>  -73.3712  41.225 
>>
>>  -72.1065  41.4667
>>
>>  -73.2453  41.7925
>>
>>  -71.9876  41.83  
>>
>>  -72.3365  41.855 
>>
>>  -72.7328  41.8064
>>
>>  -72.5231  41.4354
>>
>>  -72.8999  41.3488
>>
>>
>> julia> xc = data[:,1]
>>
>> 8-element Array{Float64,1}:
>>
>>  -73.3712
>>
>>  -72.1065
>>
>>  -73.2453
>>
>>  -71.9876
>>
>>  -72.3365
>>
>>  -72.7328
>>
>>  -72.5231
>>
>>  -72.8999
>>
>>
>> julia> yc = data[:,2]
>>
>> 8-element Array{Float64,1}:
>>
>>  41.225 
>>
>>  41.4667
>>
>>  41.7925
>>
>>  41.83  
>>
>>  41.855 
>>
>>  41.8064
>>
>>  41.4354
>>
>>  41.3488
>>
>>
>> julia> xc=xc'
>>
>> 1x8 Array{Float64,2}:
>>
>>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>>
>>
>> julia> yc=yc'
>>
>> 1x8 Array{Float64,2}:
>>
>>  41.225  41.4667  41.7925  41.83  41.855  41.8064  41.4354  41.3488
>>
>>
>> julia> temp = [xc;yc]
>>
>> 2x8 Array{Float64,2}:
>>
>>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>>
>>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488
>>
>>
>> julia> R = pairwise(Euclidean(),temp)
>>
>> 8x8 Array{Float64,2}:
>>
>>  0.0   1.28762   0.581327  1.51014   …  0.863479  0.873799  0.487347
>>
>>  1.28762   0.0   1.18451   0.382214 0.712542  0.417808  0.802085
>>
>>  0.581327  1.18451   0.0   1.25833  0.512668  0.805673  0.562309
>>
>>  1.51014   0.382214  1.25833   0.0  0.745667  0.665227  1.03141 
>>
>>  1.21144   0.451294  0.910982  0.349837 0.399323  0.459258  0.757372
>>
>>  0.863479  0.712542  0.512668  0.745667  …  0.0   0.426208  0.487124
>>
>>  0.873799  0.417808  0.805673  0.665227 0.426208  0.0   0.386557
>>
>>  0.487347  0.802085  0.562309 

Re: [julia-users] Re: Capture the output of Julia's console

[Laszlo Hars]

Steve's code works even without "pushdisplay(TextDisplay(STDOUT))", which 
tells us that the problem of not seeing regular Julia console output on 
STDOUT may be because we don't read it properly. We may have to wait, close 
the write pipe, redirect the output back to the original... or something 
else, like printing something. Maybe, the  "print(orig_STDOUT, s)" command 
does the trick?  This should be easy to Julia experts, but drives newbies 
crazy.

On Thursday, July 3, 2014 5:24:39 PM UTC-6, Laszlo Hars wrote:
>
> Oh, I see. It is not a 2-engine solution. It was not clear to me from 
> Steve's post.
> Pasting the code to the Julia console does work, but we need editing of 
> the results. Here are some simple test cases:
> 1+2
> RESULT = 3
>
> print(1+2)
> 3RESULT = nothing
>
> for i = 1:3
> println((i,i^3))
> end
> (1,1)
> (2,8)
> (3,27)
> RESULT = nothing
>
> The clipboard in the end is
> (1,1)(2,8)(3,27)RESULT = nothing
>
>
>
>
>
> On Thursday, July 3, 2014 5:12:32 PM UTC-6, Jameson wrote:
>>
>> pasting Steve's code into the windows terminal in 0.3 works for me also.
>>
>> although note that readavailable is also perfectly free to return only 
>> one character at time (or any amount, from 1 byte up to and including the 
>> amount of data that has been written to it -- it might not even need to 
>> return a complete UTF8 characters out of the stream). the only way to be 
>> certain you have captured all of the data that has been written to STDOUT 
>> is to back out your changes (remove it from the display list, 
>> `redirect_stdout(orig_STDOUT)`, and `close(wrstdout)`) then call 
>> `readall(rdstdout)`
>>
>>
>> On Thu, Jul 3, 2014 at 6:48 PM, Laszlo Hars  wrote:
>>
>>> Thanks, Steve. Good to know that something works under MacOS. 
>>> Unfortunately, I get nothing to the Windows clipboard with your 2-engine 
>>> method, which was the problem that started this thread. (Also, my 
>>> application does not need an infinite Julia loop: I can just surround the 
>>> code to be executed with output redirection Julia commands - if ever they 
>>> would work.)
>>>
>>>
>>> On Thursday, July 3, 2014 2:48:57 PM UTC-6, Steven G. Johnson wrote:

 It works for me on MacOS.  e.g. putting the code below into a file 
 capture.jl, then running
   julia capture.jl
 I can then type e.g. display("foo") and "foo" gets included in the text 
 copied to the clipboard.

 #
 const orig_STDOUT = STDOUT
 rdstdout, wrstdout = redirect_stdout()
 pushdisplay(TextDisplay(STDOUT))

 while true
 try
 result = eval(Base.parse_input_line(STDIN))
 println("RESULT = ", result)
 catch e
 print("EXCEPTION = ")
 Base.showerror(STDOUT, e)
 end
 s = readavailable(rdstdout)
 clipboard(s)
 print(orig_STDOUT, s)
 end

  
>>

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Johan Sigfrids]

You can use dropna() to convert a DataArray to a Array. This will obviously 
drop any missing values. 

On Friday, July 4, 2014 2:08:55 AM UTC+3, Donald Lacombe wrote:
>
> Patrick (and others),
>
> Another issue that has reared it's ugly head is that when I read the data 
> using the Data Frames package, I get the following:
>
> data = readtable("ct_coord_2.csv",header=false)
>
> 8x2 DataFrame:
>
>   x1  x2
>
> [1,]-73.3712  41.225
>
> [2,]-72.1065 41.4667
>
> [3,]-73.2453 41.7925
>
> [4,]-71.9876   41.83
>
> [5,]-72.3365  41.855
>
> [6,]-72.7328 41.8064
>
> [7,]-72.5231 41.4354
>
> [8,]-72.8999 41.3488
>
>
> julia> xc = data[:,1]
>
> 8-element DataArray{Float64,1}:
>
>  -73.3712
>
>  -72.1065
>
>  -73.2453
>
>  -71.9876
>
>  -72.3365
>
>  -72.7328
>
>  -72.5231
>
>  -72.8999
>
>
> julia> yc = data[:,2]
>
> 8-element DataArray{Float64,1}:
>
>  41.225 
>
>  41.4667
>
>  41.7925
>
>  41.83  
>
>  41.855 
>
>  41.8064
>
>  41.4354
>
>  41.3488
>
>
> julia> xc=xc'
>
> 1x8 DataArray{Float64,2}:
>
>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>
>
> julia> yc=yc'
>
> 1x8 DataArray{Float64,2}:
>
>  41.225  41.4667  41.7925  41.83  41.855  41.8064  41.4354  41.3488
>
>
> julia> temp = [xc;yc]
>
> 2x8 DataArray{Float64,2}:
>
>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>
>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488
>
>
> julia> R = pairwise(Euclidean(),temp)
>
> MethodError(At_mul_B!,(
>
> 8x8 Array{Float64,2}:
>
>  2.7273e-316   2.7273e-316   2.67478e-315  …  2.7273e-316   2.7273e-316 
>
>  2.67736e-315  2.67736e-315  2.67736e-315 2.72726e-316  2.72726e-316
>
>  2.67727e-315  2.67727e-315  2.67727e-315 2.67727e-315  2.67727e-315
>
>  2.67727e-315  2.67727e-315  2.67727e-315 2.67727e-315  2.67727e-315
>
>  4.94066e-324  4.94066e-324  4.94066e-324 9.88131e-324  4.94066e-324
>
>  2.76235e-318  2.76235e-318  2.76235e-318  …  2.76235e-318  2.76235e-318
>
>  4.94066e-324  4.94066e-324  4.94066e-324 9.88131e-324  4.94066e-324
>
>  4.94066e-324  4.94066e-324  4.94066e-324 9.88131e-324  4.94066e-324,
>
>
> 2x8 DataArray{Float64,2}:
>
>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>
>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488,
>
>
> 2x8 DataArray{Float64,2}:
>
>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>
>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488))
>
>
> I do not think that the Distance package likes the types that is input into 
> the function, i.e. the vectors are DataArrays instead of Arrays. It works 
> just fine when I used Tony's idea:
>
>
>  julia> data = readcsv("ct_coord_2.csv",Float64)
>
> 8x2 Array{Float64,2}:
>
>  -73.3712  41.225 
>
>  -72.1065  41.4667
>
>  -73.2453  41.7925
>
>  -71.9876  41.83  
>
>  -72.3365  41.855 
>
>  -72.7328  41.8064
>
>  -72.5231  41.4354
>
>  -72.8999  41.3488
>
>
> julia> xc = data[:,1]
>
> 8-element Array{Float64,1}:
>
>  -73.3712
>
>  -72.1065
>
>  -73.2453
>
>  -71.9876
>
>  -72.3365
>
>  -72.7328
>
>  -72.5231
>
>  -72.8999
>
>
> julia> yc = data[:,2]
>
> 8-element Array{Float64,1}:
>
>  41.225 
>
>  41.4667
>
>  41.7925
>
>  41.83  
>
>  41.855 
>
>  41.8064
>
>  41.4354
>
>  41.3488
>
>
> julia> xc=xc'
>
> 1x8 Array{Float64,2}:
>
>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>
>
> julia> yc=yc'
>
> 1x8 Array{Float64,2}:
>
>  41.225  41.4667  41.7925  41.83  41.855  41.8064  41.4354  41.3488
>
>
> julia> temp = [xc;yc]
>
> 2x8 Array{Float64,2}:
>
>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>
>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488
>
>
> julia> R = pairwise(Euclidean(),temp)
>
> 8x8 Array{Float64,2}:
>
>  0.0   1.28762   0.581327  1.51014   …  0.863479  0.873799  0.487347
>
>  1.28762   0.0   1.18451   0.382214 0.712542  0.417808  0.802085
>
>  0.581327  1.18451   0.0   1.25833  0.512668  0.805673  0.562309
>
>  1.51014   0.382214  1.25833   0.0  0.745667  0.665227  1.03141 
>
>  1.21144   0.451294  0.910982  0.349837 0.399323  0.459258  0.757372
>
>  0.863479  0.712542  0.512668  0.745667  …  0.0   0.426208  0.487124
>
>  0.873799  0.417808  0.805673  0.665227 0.426208  0.0   0.386557
>
>  0.487347  0.802085  0.562309  1.03141  0.487124  0.386557  0.0 
>
>
> There seems to be some issue with the Distance package not accepting Data 
> Frames. Of course, the readcsv works fine but this might be an issue for 
> others as well.
>
>
> Thanks,
>
> Don
>
>
>
> On Thursday, July 3, 2014 6:49:18 PM UTC-4, Patrick O'Leary wrote:
>>
>> On Thursday, July 3, 2014 5:36:23 PM UTC-5, Donald Lacombe wrote:
>>>
>>> I'm no GIS expert (I'm an applied econometrician) and the code I've 
>>> written seems to work. The Distance package also works with my "real" data 
>>> which a

Re: [julia-users] Re: Capture the output of Julia's console

[Laszlo Hars]

Oh, I see. It is not a 2-engine solution. It was not clear to me from 
Steve's post.
Pasting the code to the Julia console does work, but we need editing of the 
results. Here are some simple test cases:
1+2
RESULT = 3

print(1+2)
3RESULT = nothing

for i = 1:3
println((i,i^3))
end
(1,1)
(2,8)
(3,27)
RESULT = nothing

The clipboard in the end is
(1,1)(2,8)(3,27)RESULT = nothing





On Thursday, July 3, 2014 5:12:32 PM UTC-6, Jameson wrote:
>
> pasting Steve's code into the windows terminal in 0.3 works for me also.
>
> although note that readavailable is also perfectly free to return only one 
> character at time (or any amount, from 1 byte up to and including the 
> amount of data that has been written to it -- it might not even need to 
> return a complete UTF8 characters out of the stream). the only way to be 
> certain you have captured all of the data that has been written to STDOUT 
> is to back out your changes (remove it from the display list, 
> `redirect_stdout(orig_STDOUT)`, and `close(wrstdout)`) then call 
> `readall(rdstdout)`
>
>
> On Thu, Jul 3, 2014 at 6:48 PM, Laszlo Hars  > wrote:
>
>> Thanks, Steve. Good to know that something works under MacOS. 
>> Unfortunately, I get nothing to the Windows clipboard with your 2-engine 
>> method, which was the problem that started this thread. (Also, my 
>> application does not need an infinite Julia loop: I can just surround the 
>> code to be executed with output redirection Julia commands - if ever they 
>> would work.)
>>
>>
>> On Thursday, July 3, 2014 2:48:57 PM UTC-6, Steven G. Johnson wrote:
>>>
>>> It works for me on MacOS.  e.g. putting the code below into a file 
>>> capture.jl, then running
>>>   julia capture.jl
>>> I can then type e.g. display("foo") and "foo" gets included in the text 
>>> copied to the clipboard.
>>>
>>> #
>>> const orig_STDOUT = STDOUT
>>> rdstdout, wrstdout = redirect_stdout()
>>> pushdisplay(TextDisplay(STDOUT))
>>>
>>> while true
>>> try
>>> result = eval(Base.parse_input_line(STDIN))
>>> println("RESULT = ", result)
>>> catch e
>>> print("EXCEPTION = ")
>>> Base.showerror(STDOUT, e)
>>> end
>>> s = readavailable(rdstdout)
>>> clipboard(s)
>>> print(orig_STDOUT, s)
>>> end
>>>
>>>  
>

Re: [julia-users] Re: Capture the output of Julia's console

[Jameson Nash]

pasting Steve's code into the windows terminal in 0.3 works for me also.

although note that readavailable is also perfectly free to return only one
character at time (or any amount, from 1 byte up to and including the
amount of data that has been written to it -- it might not even need to
return a complete UTF8 characters out of the stream). the only way to be
certain you have captured all of the data that has been written to STDOUT
is to back out your changes (remove it from the display list,
`redirect_stdout(orig_STDOUT)`, and `close(wrstdout)`) then call
`readall(rdstdout)`


On Thu, Jul 3, 2014 at 6:48 PM, Laszlo Hars  wrote:

> Thanks, Steve. Good to know that something works under MacOS.
> Unfortunately, I get nothing to the Windows clipboard with your 2-engine
> method, which was the problem that started this thread. (Also, my
> application does not need an infinite Julia loop: I can just surround the
> code to be executed with output redirection Julia commands - if ever they
> would work.)
>
>
> On Thursday, July 3, 2014 2:48:57 PM UTC-6, Steven G. Johnson wrote:
>>
>> It works for me on MacOS.  e.g. putting the code below into a file
>> capture.jl, then running
>>   julia capture.jl
>> I can then type e.g. display("foo") and "foo" gets included in the text
>> copied to the clipboard.
>>
>> #
>> const orig_STDOUT = STDOUT
>> rdstdout, wrstdout = redirect_stdout()
>> pushdisplay(TextDisplay(STDOUT))
>>
>> while true
>> try
>> result = eval(Base.parse_input_line(STDIN))
>> println("RESULT = ", result)
>> catch e
>> print("EXCEPTION = ")
>> Base.showerror(STDOUT, e)
>> end
>> s = readavailable(rdstdout)
>> clipboard(s)
>> print(orig_STDOUT, s)
>> end
>>
>>

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Donald Lacombe]

Patrick (and others),

Another issue that has reared it's ugly head is that when I read the data 
using the Data Frames package, I get the following:

data = readtable("ct_coord_2.csv",header=false)

8x2 DataFrame:

  x1  x2

[1,]-73.3712  41.225

[2,]-72.1065 41.4667

[3,]-73.2453 41.7925

[4,]-71.9876   41.83

[5,]-72.3365  41.855

[6,]-72.7328 41.8064

[7,]-72.5231 41.4354

[8,]-72.8999 41.3488


julia> xc = data[:,1]

8-element DataArray{Float64,1}:

 -73.3712

 -72.1065

 -73.2453

 -71.9876

 -72.3365

 -72.7328

 -72.5231

 -72.8999


julia> yc = data[:,2]

8-element DataArray{Float64,1}:

 41.225 

 41.4667

 41.7925

 41.83  

 41.855 

 41.8064

 41.4354

 41.3488


julia> xc=xc'

1x8 DataArray{Float64,2}:

 -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999


julia> yc=yc'

1x8 DataArray{Float64,2}:

 41.225  41.4667  41.7925  41.83  41.855  41.8064  41.4354  41.3488


julia> temp = [xc;yc]

2x8 DataArray{Float64,2}:

 -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999

  41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488


julia> R = pairwise(Euclidean(),temp)

MethodError(At_mul_B!,(

8x8 Array{Float64,2}:

 2.7273e-316   2.7273e-316   2.67478e-315  …  2.7273e-316   2.7273e-316 

 2.67736e-315  2.67736e-315  2.67736e-315 2.72726e-316  2.72726e-316

 2.67727e-315  2.67727e-315  2.67727e-315 2.67727e-315  2.67727e-315

 2.67727e-315  2.67727e-315  2.67727e-315 2.67727e-315  2.67727e-315

 4.94066e-324  4.94066e-324  4.94066e-324 9.88131e-324  4.94066e-324

 2.76235e-318  2.76235e-318  2.76235e-318  …  2.76235e-318  2.76235e-318

 4.94066e-324  4.94066e-324  4.94066e-324 9.88131e-324  4.94066e-324

 4.94066e-324  4.94066e-324  4.94066e-324 9.88131e-324  4.94066e-324,


2x8 DataArray{Float64,2}:

 -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999

  41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488,


2x8 DataArray{Float64,2}:

 -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999

  41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488))


I do not think that the Distance package likes the types that is input into the 
function, i.e. the vectors are DataArrays instead of Arrays. It works just fine 
when I used Tony's idea:


 julia> data = readcsv("ct_coord_2.csv",Float64)

8x2 Array{Float64,2}:

 -73.3712  41.225 

 -72.1065  41.4667

 -73.2453  41.7925

 -71.9876  41.83  

 -72.3365  41.855 

 -72.7328  41.8064

 -72.5231  41.4354

 -72.8999  41.3488


julia> xc = data[:,1]

8-element Array{Float64,1}:

 -73.3712

 -72.1065

 -73.2453

 -71.9876

 -72.3365

 -72.7328

 -72.5231

 -72.8999


julia> yc = data[:,2]

8-element Array{Float64,1}:

 41.225 

 41.4667

 41.7925

 41.83  

 41.855 

 41.8064

 41.4354

 41.3488


julia> xc=xc'

1x8 Array{Float64,2}:

 -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999


julia> yc=yc'

1x8 Array{Float64,2}:

 41.225  41.4667  41.7925  41.83  41.855  41.8064  41.4354  41.3488


julia> temp = [xc;yc]

2x8 Array{Float64,2}:

 -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999

  41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488


julia> R = pairwise(Euclidean(),temp)

8x8 Array{Float64,2}:

 0.0   1.28762   0.581327  1.51014   …  0.863479  0.873799  0.487347

 1.28762   0.0   1.18451   0.382214 0.712542  0.417808  0.802085

 0.581327  1.18451   0.0   1.25833  0.512668  0.805673  0.562309

 1.51014   0.382214  1.25833   0.0  0.745667  0.665227  1.03141 

 1.21144   0.451294  0.910982  0.349837 0.399323  0.459258  0.757372

 0.863479  0.712542  0.512668  0.745667  …  0.0   0.426208  0.487124

 0.873799  0.417808  0.805673  0.665227 0.426208  0.0   0.386557

 0.487347  0.802085  0.562309  1.03141  0.487124  0.386557  0.0 


There seems to be some issue with the Distance package not accepting Data 
Frames. Of course, the readcsv works fine but this might be an issue for others 
as well.


Thanks,

Don



On Thursday, July 3, 2014 6:49:18 PM UTC-4, Patrick O'Leary wrote:
>
> On Thursday, July 3, 2014 5:36:23 PM UTC-5, Donald Lacombe wrote:
>>
>> I'm no GIS expert (I'm an applied econometrician) and the code I've 
>> written seems to work. The Distance package also works with my "real" data 
>> which are the centroids of the counties in Connecticut and I tested it with 
>> Euclidean, Cityblock, and SqEuclidean.
>>
>
> Glad you got something working. Whether those distances are accurate 
> enough depends on how the points are arranged and what you plan to do with 
> it--I can see where it wouldn't make much difference in this case. I can't 
> let the statisticians and image processing folks have all the technical 
> conversation fun in this mailing list, though!
>

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Patrick O'Leary]

On Thursday, July 3, 2014 5:36:23 PM UTC-5, Donald Lacombe wrote:
>
> I'm no GIS expert (I'm an applied econometrician) and the code I've 
> written seems to work. The Distance package also works with my "real" data 
> which are the centroids of the counties in Connecticut and I tested it with 
> Euclidean, Cityblock, and SqEuclidean.
>

Glad you got something working. Whether those distances are accurate enough 
depends on how the points are arranged and what you plan to do with it--I 
can see where it wouldn't make much difference in this case. I can't let 
the statisticians and image processing folks have all the technical 
conversation fun in this mailing list, though!

Re: [julia-users] Re: Capture the output of Julia's console

[Laszlo Hars]

Thanks, Steve. Good to know that something works under MacOS. 
Unfortunately, I get nothing to the Windows clipboard with your 2-engine 
method, which was the problem that started this thread. (Also, my 
application does not need an infinite Julia loop: I can just surround the 
code to be executed with output redirection Julia commands - if ever they 
would work.)

On Thursday, July 3, 2014 2:48:57 PM UTC-6, Steven G. Johnson wrote:
>
> It works for me on MacOS.  e.g. putting the code below into a file 
> capture.jl, then running
>   julia capture.jl
> I can then type e.g. display("foo") and "foo" gets included in the text 
> copied to the clipboard.
>
> #
> const orig_STDOUT = STDOUT
> rdstdout, wrstdout = redirect_stdout()
> pushdisplay(TextDisplay(STDOUT))
>
> while true
> try
> result = eval(Base.parse_input_line(STDIN))
> println("RESULT = ", result)
> catch e
> print("EXCEPTION = ")
> Base.showerror(STDOUT, e)
> end
> s = readavailable(rdstdout)
> clipboard(s)
> print(orig_STDOUT, s)
> end
>
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[Pierre-Yves Gérardy]

On Thursday, July 3, 2014 6:12:47 PM UTC+2, Stefan Karpinski wrote:
>
> On Thu, Jul 3, 2014 at 12:09 PM, Patrick O'Leary  > wrote:
>
>> I do find the generalization to string exponentiation -> repetition is 
>> pretty beautiful.
>
>
> This is my favorite part about the * choice. From str+str it's not at all 
> obvious whether 2str or str*2 is the right choice for string repetition. I 
> also agree that's fascinating how attached people get to string 
> concatenation operators. Don't get Jeff started on string interpolation, 
> which is essentially a fancy string concatenation syntax.
>

FWIW, Lua uses  ..  for concatenation.  The operator is right 
associative... I don't know why.

—Pierre-Yves

Re: [julia-users] Help: K-Means Clustering Algorithm

[Paulo Castro]

Hi John,

Thanks for the tip, but actually I'm not using this function for 
production. I was reading the "Programming Collective Intelligence", and 
trying to implement the examples in Julia rather than Python (with some 
complications as missing packages, like Beatiful Soup, but thats ok...). 
So, this is an exercise to help me with understanding these algorithms, and 
learn more Julia at the same time. 

The next book I'll try this is, guess what, "Machine Learning for hackers"! 
Hope that the transition of the algorithms on that book is easier.

Thanks again!

Em quinta-feira, 3 de julho de 2014 19h29min37s UTC-3, John Myles White 
escreveu:
>
> Hi Paulo,
>
> Rather than implement k-means from scratch, I'd encourage you to use the 
> implementation in the Clustering.jl package.
>
>  -- John
>
> On Jul 3, 2014, at 2:51 PM, Paulo Castro  > wrote:
>
> Hi guys,
>
> I'm trying to implement the K-Means Clustering Algorithm, but I'm having 
> some problems. The function I wrote:
>
> function kcluster(data; distance = pearson, k=4)
> # Generate a list of tuples of the min and max values of each column 
> of "data"
> ranges = [(minimum(data[:,i]), maximum(data[:,i])) for i in 1:size(
> data,2)]
>
> # Create k randomly placed centroids
> centroids = [rand()*ranges[j][2] - ranges[j][1] + ranges[j][1] for i 
> in 1:k, j in 1:length(ranges)]
>
> lastmatches = Any[]
> for t in 1:100
> println("Iteration $t")
> bestmatches = [Int[] for i in 1:k]
>
> # Get best matches for each cluster
> for j in 1:size(data, 1)
> row = data[j, :]
> bestmatch = 1
> bestd = distance(centroids[bestmatch, :], row)
>
> for i in 1:k
> d = distance(centroids[i, :], row)
> if d < bestd
> bestd = d
> bestmatch  = i
> end
> end
>
> push!(bestmatches[bestmatch], j)
> end
>
> if lastmatches == bestmatches
> return lastmatches
> end
>
> lastmatches = bestmatches
>
> # Move clusters to the average of its matches
> numcols = size(data, 2)
> for i in 1:k
> avgs = zeros(1, numcols)
> if length(bestmatches[i]) > 0
> for row in bestmatches[i]
> avgs += data[row, :]
> end
>
> avgs /= length(bestmatches[i])
> centroids[i, :] = avgs
> end
> end
> end
>
> return lastmatches
> end
>
> The "data" argument is a two dimensional Array, each row representing an 
> individual, and each column its position on space.
>
> The problem is the following: the same algorithm in Python (with the same 
> "data" input), use to stop near iteration #5, and in Julia it always goes 
> to the iteration #100. The not-empty clusters on Python are also smaller, 
> therefore there are less empty clusters. Can somebody find why it never 
> enters the "if lastmatches == bestmatches" block?
>
> Sorry about my poor english
>
>
>

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Donald Lacombe]

Dear Patrick,

Yes, I agree...I actually have some MATLAB code that calculates pairwise 
distances using a Great Circle formula. The Econometrics Toolbox also 
contains a Dealunay algorithm that uses the centroids to calculate 
contiguous entities.

I'm no GIS expert (I'm an applied econometrician) and the code I've written 
seems to work. The Distance package also works with my "real" data which 
are the centroids of the counties in Connecticut and I tested it with 
Euclidean, Cityblock, and SqEuclidean.

Once again, thank you all for the help. I'm hoping this thread can help 
others and get them into Julia as well.

Regards,
Don

On Thursday, July 3, 2014 12:34:28 AM UTC-4, Patrick O'Leary wrote:
>
> (/me removes Julia hat, replaces with navigation hat)
>
> That distance measurement probably isn't going to do quite what you want 
> it to do, particularly over such a large area. It's an okay approximation 
> in CONUS, but biased--1 degree latitude isn't the same distance as 1 degree 
> longitude. For points further north this gets worse. You have a few options 
> for more accuracy:
>
> You can put all of your coordinates in a local level frame. All the 
> necessary formulas and constants are conveniently provided in MATLAB's 
> Aerospace Blockset documentation: 
> http://www.mathworks.com/help/aeroblks/llatoflatearth.html. Choose 
> something like the centroid lat/lon as the "initial" values, which will act 
> as the origin of the reference frame. Note that lat/lon will need to be 
> converted to radians.
>
> For longer distances, you will get better results with something like the 
> haversine formula, which accounts for the curvature of the earth (
> https://en.wikipedia.org/wiki/Haversine_formula). That would probably 
> make for a decent contribution to Distance.jl, and is pretty easy to 
> implement.
>
> For (substantial!) extra credit, you could implement a version that 
> accounts for the flattening of the ellipsoid (
> https://en.wikipedia.org/wiki/Geodesics_on_an_ellipsoid, 
> https://en.wikipedia.org/wiki/Vincenty%27s_formulae). That would probably 
> not be accepted by Distance.jl, and is unlikely to be worthwhile for your 
> application.
>
> On Wednesday, July 2, 2014 7:05:21 PM UTC-5, Donald Lacombe wrote:
>>
>> Actually, another issue with the type information.
>>
>> Instead of using random coordinates, I used actual latitude and longitude 
>> coordinates from a CSV file like so:
>>
>> data = readcsv("ct_coord.csv");
>>
>> temp = [xc';yc']
>>
>> 2x8 Array{Any,2}:
>>
>>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>>
>>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488
>>
>>
>> Now, the type here is {Any,2} and this seems to be giving the Distance 
>> package problems:
>>
>>
>>
>> R = pairwise(Euclidean(),temp)
>>
>> MethodError(fptype,(Any,))
>>
>>
>> Julia seems to be unhappy with this type but I'm not sure how to correct 
>> this which would seem to require that the data being read in are of Float 
>> type.
>>
>>
>> Again, thank you for all of the help.
>>
>>
>> Don
>>
>>
>>
>> On Wednesday, July 2, 2014 7:10:09 PM UTC-4, Donald Lacombe wrote:
>>>
>>> Patrick,
>>>
>>> Thank you for the reply! I will try your suggestion and hopefully get a 
>>> better grasp of these issues.
>>>
>>> Thank you all gain for all of the help. It cannot be stressed enough 
>>> that the friendly and truly helpful comments will help the Julia community 
>>> grow.
>>>
>>> Don
>>>
>>> On Wednesday, July 2, 2014 5:31:55 PM UTC-4, Patrick O'Leary wrote:

 The second parameter to the Array type is the number of dimensions of 
 the array. "Row vectors" are implemented with 2-dimensional arrays 
 (a.k.a., 
 "matrices"), since Vectors (a.k.a. Array{T, 1} for all types T) are 
 interpreted as columns.

 Since pairwise() generates all of the distances simultaneously, you'll 
 need to slice its results to use it in sortperm(), following your original 
 loop implementation. Each slice will need to be a Vector. If you slice 
 columns, you get Vector slices for free. If you slice rows, the shape will 
 be maintained, so you get a row back. You can flatten this to a Vector 
 with 
 the vec() function.

 Hope this helps!

 On Wednesday, July 2, 2014 4:23:52 PM UTC-5, Donald Lacombe wrote:
>
> After thinking about this issue, another couple of question came to 
> mind.
>
> When I create a row vector, say xc = randn(1,5), the results indicate 
> that the vector is e.g.
>
> xc = rand(1,5)
>
> 1x5 Array{Float64,2}:
>
>  0.989421  0.718148  0.499914  0.13024  0.939856
>
>
> The type is {Float64,2}.
>
>
> Questions:
>
>
> 1) What does the "2" mean in {Float64,2}? If I create xc = rand(5) the 
> type is {Float64,1}.
>
>
> 2) The sortperm function only seems to accept {Float64,1} types. The 
> Euclidean distance cod

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Donald Lacombe]

Dear Tony,

Thank you for pointing this out. Worked like a charm and the distance were 
calculated just fine.

Thanks,
Don

On Wednesday, July 2, 2014 9:46:06 PM UTC-4, Tony Kelman wrote:
>
> If you know all of the data in the csv file is numerical, you can provide 
> a result type to readcsv, say readcsv("ct_coord.csv", Float64). See 
> help(readdlm) for additional options for things like removing header rows, 
> etc. If the data is of mixed types, then you may find readtable in the 
> DataFrames package more capable.
>
>
> On Wednesday, July 2, 2014 5:05:21 PM UTC-7, Donald Lacombe wrote:
>>
>> Actually, another issue with the type information.
>>
>> Instead of using random coordinates, I used actual latitude and longitude 
>> coordinates from a CSV file like so:
>>
>> data = readcsv("ct_coord.csv");
>>
>> temp = [xc';yc']
>>
>> 2x8 Array{Any,2}:
>>
>>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>>
>>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488
>>
>>
>> Now, the type here is {Any,2} and this seems to be giving the Distance 
>> package problems:
>>
>>
>>
>> R = pairwise(Euclidean(),temp)
>>
>> MethodError(fptype,(Any,))
>>
>>
>> Julia seems to be unhappy with this type but I'm not sure how to correct 
>> this which would seem to require that the data being read in are of Float 
>> type.
>>
>>
>> Again, thank you for all of the help.
>>
>>
>> Don
>>
>>
>>
>> On Wednesday, July 2, 2014 7:10:09 PM UTC-4, Donald Lacombe wrote:
>>>
>>> Patrick,
>>>
>>> Thank you for the reply! I will try your suggestion and hopefully get a 
>>> better grasp of these issues.
>>>
>>> Thank you all gain for all of the help. It cannot be stressed enough 
>>> that the friendly and truly helpful comments will help the Julia community 
>>> grow.
>>>
>>> Don
>>>
>>> On Wednesday, July 2, 2014 5:31:55 PM UTC-4, Patrick O'Leary wrote:

 The second parameter to the Array type is the number of dimensions of 
 the array. "Row vectors" are implemented with 2-dimensional arrays 
 (a.k.a., 
 "matrices"), since Vectors (a.k.a. Array{T, 1} for all types T) are 
 interpreted as columns.

 Since pairwise() generates all of the distances simultaneously, you'll 
 need to slice its results to use it in sortperm(), following your original 
 loop implementation. Each slice will need to be a Vector. If you slice 
 columns, you get Vector slices for free. If you slice rows, the shape will 
 be maintained, so you get a row back. You can flatten this to a Vector 
 with 
 the vec() function.

 Hope this helps!

 On Wednesday, July 2, 2014 4:23:52 PM UTC-5, Donald Lacombe wrote:
>
> After thinking about this issue, another couple of question came to 
> mind.
>
> When I create a row vector, say xc = randn(1,5), the results indicate 
> that the vector is e.g.
>
> xc = rand(1,5)
>
> 1x5 Array{Float64,2}:
>
>  0.989421  0.718148  0.499914  0.13024  0.939856
>
>
> The type is {Float64,2}.
>
>
> Questions:
>
>
> 1) What does the "2" mean in {Float64,2}? If I create xc = rand(5) the 
> type is {Float64,1}.
>
>
> 2) The sortperm function only seems to accept {Float64,1} types. The 
> Euclidean distance code create types of {Float64,2} but I need 
> {Float64,1} for the sortperm function. Do I need to convert these before 
> using this command?
>
>
> I'm probably missing something really basic so apologies for the query.
>
>
> Thanks,
>
> Don
>
>
> On Wednesday, July 2, 2014 4:20:55 PM UTC-4, Donald Lacombe wrote:
>>
>> Greetings, part 2...
>>
>> After doing some tests, I found that this code works just fine:
>>
>> julia> using Distance
>>
>> Warning: could not import Base.foldl into NumericExtensions
>>
>> Warning: could not import Base.foldr into NumericExtensions
>>
>> Warning: could not import Base.sum! into NumericExtensions
>>
>> Warning: could not import Base.maximum! into NumericExtensions
>>
>> Warning: could not import Base.minimum! into NumericExtensions
>>
>>
>>
>> julia> xc = rand(8)'
>>
>> 1x8 Array{Float64,2}:
>>
>>  0.30107  0.479169  0.230607  0.65126  0.386921  0.455316  0.921496  
>> 0.244873
>>
>>
>> julia> yc = rand(8)'
>>
>> 1x8 Array{Float64,2}:
>>
>>  0.866199  0.767794  0.76163  0.262925  …  0.742765  0.980952  0.424966
>>
>>
>> julia> temp = [xc ; yc]
>>
>> 2x8 Array{Float64,2}:
>>
>>  0.30107   0.479169  0.230607  0.65126   …  0.455316  0.921496  0.244873
>>
>>  0.866199  0.767794  0.76163   0.262925 0.742765  0.980952  0.424966
>>
>>
>> julia> R = pairwise(Euclidean(),temp)
>>
>> 8x8 Array{Float64,2}:
>>
>>  0.0   0.203477   0.126094  0.697548  …  0.197554   0.63

Re: [julia-users] Help: K-Means Clustering Algorithm

[John Myles White]

Hi Paulo,

Rather than implement k-means from scratch, I'd encourage you to use the 
implementation in the Clustering.jl package.

 -- John

On Jul 3, 2014, at 2:51 PM, Paulo Castro  wrote:

> Hi guys,
> 
> I'm trying to implement the K-Means Clustering Algorithm, but I'm having some 
> problems. The function I wrote:
> 
> function kcluster(data; distance = pearson, k=4)
> # Generate a list of tuples of the min and max values of each column of 
> "data"
> ranges = [(minimum(data[:,i]), maximum(data[:,i])) for i in 
> 1:size(data,2)]
> 
> # Create k randomly placed centroids
> centroids = [rand()*ranges[j][2] - ranges[j][1] + ranges[j][1] for i in 
> 1:k, j in 1:length(ranges)]
> 
> lastmatches = Any[]
> for t in 1:100
> println("Iteration $t")
> bestmatches = [Int[] for i in 1:k]
> 
> # Get best matches for each cluster
> for j in 1:size(data, 1)
> row = data[j, :]
> bestmatch = 1
> bestd = distance(centroids[bestmatch, :], row)
> 
> for i in 1:k
> d = distance(centroids[i, :], row)
> if d < bestd
> bestd = d
> bestmatch  = i
> end
> end
> 
> push!(bestmatches[bestmatch], j)
> end
> 
> if lastmatches == bestmatches
> return lastmatches
> end
> 
> lastmatches = bestmatches
> 
> # Move clusters to the average of its matches
> numcols = size(data, 2)
> for i in 1:k
> avgs = zeros(1, numcols)
> if length(bestmatches[i]) > 0
> for row in bestmatches[i]
> avgs += data[row, :]
> end
> 
> avgs /= length(bestmatches[i])
> centroids[i, :] = avgs
> end
> end
> end
> 
> return lastmatches
> end
> 
> The "data" argument is a two dimensional Array, each row representing an 
> individual, and each column its position on space.
> 
> The problem is the following: the same algorithm in Python (with the same 
> "data" input), use to stop near iteration #5, and in Julia it always goes to 
> the iteration #100. The not-empty clusters on Python are also smaller, 
> therefore there are less empty clusters. Can somebody find why it never 
> enters the "if lastmatches == bestmatches" block?
> 
> Sorry about my poor english

[julia-users] Help: K-Means Clustering Algorithm

[Paulo Castro]

Hi guys,

I'm trying to implement the K-Means Clustering Algorithm, but I'm having 
some problems. The function I wrote:

function kcluster(data; distance = pearson, k=4)
# Generate a list of tuples of the min and max values of each column of 
"data"
ranges = [(minimum(data[:,i]), maximum(data[:,i])) for i in 1:size(data,
2)]

# Create k randomly placed centroids
centroids = [rand()*ranges[j][2] - ranges[j][1] + ranges[j][1] for i in 
1:k, j in 1:length(ranges)]

lastmatches = Any[]
for t in 1:100
println("Iteration $t")
bestmatches = [Int[] for i in 1:k]

# Get best matches for each cluster
for j in 1:size(data, 1)
row = data[j, :]
bestmatch = 1
bestd = distance(centroids[bestmatch, :], row)

for i in 1:k
d = distance(centroids[i, :], row)
if d < bestd
bestd = d
bestmatch  = i
end
end

push!(bestmatches[bestmatch], j)
end

if lastmatches == bestmatches
return lastmatches
end

lastmatches = bestmatches

# Move clusters to the average of its matches
numcols = size(data, 2)
for i in 1:k
avgs = zeros(1, numcols)
if length(bestmatches[i]) > 0
for row in bestmatches[i]
avgs += data[row, :]
end

avgs /= length(bestmatches[i])
centroids[i, :] = avgs
end
end
end

return lastmatches
end

The "data" argument is a two dimensional Array, each row representing an 
individual, and each column its position on space.

The problem is the following: the same algorithm in Python (with the same 
"data" input), use to stop near iteration #5, and in Julia it always goes 
to the iteration #100. The not-empty clusters on Python are also smaller, 
therefore there are less empty clusters. Can somebody find why it never 
enters the "if lastmatches == bestmatches" block?

Sorry about my poor english

[julia-users] Re: Why does this dispatch occur? (parametric types)

[Stefan Schwarz]

Basically a multi-method or a multi-dispatch method, in this case, is a 
hash or dictionary
whose key is the tuple of the types of the input arguments and whose value 
is the
implementation.

The problem with this scheme is, what if the key does not return an 
implementation.

In your case you use the Union *Number* as a parameter type on the 
non-parameterised
and for the parameterised function definition of foo.

Your parameterised definition has stronger binding, since julia is all to 
multi-dispatching.

Well. There is a load of discussion about how to find a function that best 
match.
This is all related to contravariance and covariance, 

Basically you override the non-parametrised definition of foo.

interestingly, in C++, if I am a bit more specific. This behaves the way I 
expect it should:

int foo(int a) 
{
return 1;
}

template
T foo(T a)
{
return 2;
}

And if i print this for *foo(2), foo(-1), foo(3.14)* I get: *1 1 2*

Which is exactly the same, if I define this in Julia.

So in conclusion I think, and please anybody correct me if i am wrong. 
Mutli-Dispatch functions
are first class citizens when it comes to dispatching. That is why you get 
these results.

I really hope this helps.

Stefan


{
return 1;
}

Re: [julia-users] Re: Capture the output of Julia's console

[Steven G. Johnson]

It works for me on MacOS.  e.g. putting the code below into a file 
capture.jl, then running
  julia capture.jl
I can then type e.g. display("foo") and "foo" gets included in the text 
copied to the clipboard.

#
const orig_STDOUT = STDOUT
rdstdout, wrstdout = redirect_stdout()
pushdisplay(TextDisplay(STDOUT))

while true
try
result = eval(Base.parse_input_line(STDIN))
println("RESULT = ", result)
catch e
print("EXCEPTION = ")
Base.showerror(STDOUT, e)
end
s = readavailable(rdstdout)
clipboard(s)
print(orig_STDOUT, s)
end

Re: [julia-users] Macros versus expression objects

[Patrick O'Leary]

Leaving out the dreaded "h" word--that's a whole other can of worms--at run 
time, after LLVM has fully lowered us down to the machine, all you have is 
native code. The AST is gone, and there's nothing left to modify! In 
practice, this does not seem to be a substantial limitation, and is more 
than made up for by the benefits of JIT compilation.

For a nice introduction to the path taken by Julia code from entry to 
execution, see Leah Hanson's exploration of the introspection tools: 
http://blog.leahhanson.us/julia-introspects.html

On Thursday, July 3, 2014 2:22:29 PM UTC-5, Andrew McKinlay wrote:
>
> But I thought Julia was homoiconic. Can't a Julia program modify itself at 
> run-time? 
>
> On Saturday, June 21, 2014 3:02:35 PM UTC-4, Patrick O'Leary wrote:
>>
>> The answer to your question about the second part of Jameson's response 
>> is the first part of Jameson's response--at compile time you can still 
>> modify the syntax tree of the program.
>>
>> On Saturday, June 21, 2014 1:50:45 PM UTC-5, Andrew McKinlay wrote:
>>>
>>> What can I do at compile-time that I can't at run-time?
>>> On Jun 21, 2014 2:49 PM, "Jameson Nash"  wrote:
>>>
 A macro inserts the result back into the AST. and it is called at 
 compile-time, not run-time. 

 On Saturday, June 21, 2014, Andrew McKinlay  
 wrote:

> What's the difference between writing macros versus functions that 
> take `Expr` objects? Is there anything you can't do with a function that 
> takes expression objects? Are there any advantages of using macros beyond 
> no having to quote the code you pass as an argument?
>
  

Re: [julia-users] Macros versus expression objects

[Andrew McKinlay]

But I thought Julia was homoiconic. Can't a Julia program modify itself at 
run-time? 

On Saturday, June 21, 2014 3:02:35 PM UTC-4, Patrick O'Leary wrote:
>
> The answer to your question about the second part of Jameson's response is 
> the first part of Jameson's response--at compile time you can still modify 
> the syntax tree of the program.
>
> On Saturday, June 21, 2014 1:50:45 PM UTC-5, Andrew McKinlay wrote:
>>
>> What can I do at compile-time that I can't at run-time?
>> On Jun 21, 2014 2:49 PM, "Jameson Nash" > 
>> wrote:
>>
>>> A macro inserts the result back into the AST. and it is called at 
>>> compile-time, not run-time. 
>>>
>>> On Saturday, June 21, 2014, Andrew McKinlay >> > wrote:
>>>
 What's the difference between writing macros versus functions that take 
 `Expr` objects? Is there anything you can't do with a function that takes 
 expression objects? Are there any advantages of using macros beyond no 
 having to quote the code you pass as an argument?

>>>  

[julia-users] Why does this dispatch occur? (parametric types)

[Andrew McKinlay]

Why does
foo{T<:Number}(x::T) = 1
foo(x::Number) = 2

println(foo(3))
result in
1
?

Is there any difference between the first method definition and the second?

Does the first method completely shadow the second?

When would I want to use one definition over the other?

Re: [julia-users] Re: Sorting surprises

[Stefan Karpinski]

You can also define your own subtype of Order. See base/order.jl.

> On Jul 3, 2014, at 2:57 PM, Keith Campbell  wrote:
> 
> Functors might be a workaround.  See e.g.
> http://numericextensionsjl.readthedocs.org/en/latest/functors.html#motivating-example
> 
>> 

[julia-users] Re: Sorting surprises

[Keith Campbell]

Functors might be a workaround.  See e.g.
http://numericextensionsjl.readthedocs.org/en/latest/functors.html#motivating-example


>

Re: [julia-users] Re: Decreasing range, should it work?

[Ivar Nesje]

Just a note for people considering using @tonyhffong's Lint.jl 
.

It will now give a warning if you have a range `1:0` with literal numbers.

Ivar

kl. 18:50:36 UTC+2 torsdag 3. juli 2014 skrev Jay Kickliter følgende:
>
> Thanks everyone for the examples. I was trying to do something similar to 
> what Douglas illustrated.

[julia-users] Using PyCall in julia on Ubuntu with python3

[mequersat]

This post is just some minor issue I ran into, but it might be nice for 
others to find a fix here.


Trying to get the package PyCall (https://github.com/stevengj/PyCall.jl) to 
import modules (e.g. python3-numpy), this error occurs:

julia> using PyCall

julia> @pyimport numpy
ERROR: PyError (PyImport_ImportModule) 
ImportError('No module named numpy',)


To make PyCall work with python3, the following environment variable needs 
to be set:

julia> ENV["PYTHON"]="python3"


If that doesn't work, try:

julia> ENV["PYTHON"]="/usr/bin/python3"


PyCall should now be able to import the python3-* modules which are 
installed via Ubuntu's package manager.

Re: [julia-users] Sorting surprises

[Stefan Karpinski]

This is largely a known issue: we don't specialize functions like sort on the 
values of function arguments. I'm not sure, however, why using a generic 
function is twice as slow as using an anonymous one, and I'm also not entirely 
sure why there's so much allocation.

> On Jul 3, 2014, at 1:43 PM, gentlebeldin  wrote:
> 
> I'm porting some of my programs (solutions of Project Euler problems, btw) 
> from Java to Julia, to check claims concerning performance. Don't you worry, 
> no spoilers, here. But there is a solution where I needed sorting. As long 
> that's sorting by natural order, that seems to work ok, and the Julia version 
> is almost (but not quite) as fast as the Java program. But as soon as I 
> introduce a transformation...
> Here are some results illustrating what I mean:
> 
> julia> a=rand(100)
> 100-element Array{Float64,1}:
>  ⋮
> 
> julia> @elapsed sort(a)
> 0.20693414
> 
> julia> @elapsed sort(a,by=identity)
> 0.210779277
> 
> julia> @elapsed sort(a,by=x->x)
> 2.501326137
> 
> julia> f(x)=x
> f (generic function with 1 method)
> 
> julia> @elapsed sort(a,by=f)
> 5.012442935
> 
> julia> @allocated sort(a)
> 8000192
> 
> julia> @allocated sort(a,by=f)
> 1623226064
> 
> Any thoughts what eats up all that time, and all that memory?
> 

[julia-users] Sorting surprises

[gentlebeldin]

I'm porting some of my programs (solutions of Project Euler problems, btw) 
from Java to Julia, to check claims concerning performance. Don't you 
worry, no spoilers, here. But there is a solution where I needed sorting. 
As long that's sorting by natural order, that seems to work ok, and the 
Julia version is almost (but not quite) as fast as the Java program. But as 
soon as I introduce a transformation...
Here are some results illustrating what I mean:

julia> a=rand(100)
100-element Array{Float64,1}:
 ⋮

julia> @elapsed sort(a)
0.20693414

julia> @elapsed sort(a,by=identity)
0.210779277

julia> @elapsed sort(a,by=x->x)
2.501326137

julia> f(x)=x
f (generic function with 1 method)

julia> @elapsed sort(a,by=f)
5.012442935

julia> @allocated sort(a)
8000192

julia> @allocated sort(a,by=f)
1623226064

Any thoughts what eats up all that time, and all that memory?

[julia-users] Re: Tagging a package

[Ben Ward]

Ok I found the issue relating to this problem:

https://github.com/JuliaLang/julia/issues/5998

I deleted the Julia Package manager token on GitHub as suggested and it now 
works!

On Thursday, July 3, 2014 3:57:20 AM UTC+1, Ben Ward wrote:
>
> Hi,
>
> I'm trying to update a package for the first time with the new package 
> manager commands like tag and so on:
>
> *julia> **Pkg.publish()*
>
> *INFO: Validating METADATA*
>
> *INFO: Pushing Phylogenetics permanent tags: v0.0.2*
>
> Permission denied (publickey).
>
> fatal: Could not read from remote repository.
>
>
>
> Please make sure you have the correct access rights
>
> and the repository exists.
>
> *ERROR: failed process: Process(`git 
> --work-tree=/Users/axolotlfan9250/.julia/v0.3/Phylogenetics 
> --git-dir=/Users/axolotlfan9250/.julia/v0.3/Phylogenetics/.git push -q 
> origin refs/tags/v0.0.2:refs/tags/v0.0.2`, ProcessExited(128)) [128]*
>
> * in wait at ./task.jl:279*
>
> * in wait at ./task.jl:189*
>
> * in wait at task.jl:48*
>
> * in sync_end at ./task.jl:306*
>
> * in publish at pkg/entry.jl:314*
>
> * in anonymous at pkg/dir.jl:28*
>
> * in cd at file.jl:20*
>
> * in cd at pkg/dir.jl:28*
>
> * in publish at pkg.jl:57*
>
>
>
> I'm not 100% sure why I'm getting this, shouldn't it just send a PR to 
> METADATA? I'm not 100% clear on how this works - do I need a fork of 
> METADATA still? The process that fails looks like it's trying to push 
> something to ward9250/Phylogenetics.jl? In which case I wonder if it's a 
> naming issue Phylogenetics in .julia/v0.3/ and Phylogenetics.jl for the 
> repo?
>

[julia-users] Re: Tagging a package

[Ben Ward]

I've fixed the public key issue so now I get further - I get an error when 
it comes to entering my password (it is correct!), something to do with a 
token.

julia> Pkg.publish()

 

INFO: Validating METADATA 

INFO: Pushing Phylogenetics permanent tags: v0.0.2 

INFO: Submitting METADATA changes 

INFO: Forking JuliaLang/METADATA.jl to ward9250 

Enter host password for user 'ward9250': 

ERROR: key not found: "token" 

 in getindex at dict.jl:615 

 in token at pkg/github.jl:53 

 in req at pkg/github.jl:61 

 in POST at pkg/github.jl:74 

 in fork at pkg/github.jl:87 

 in pull_request at pkg/entry.jl:290 

 in publish at pkg/entry.jl:357 

 in anonymous at pkg/dir.jl:28 

 in cd at file.jl:20 

 in cd at pkg/dir.jl:28 

 in publish at pkg.jl:57



On Thursday, July 3, 2014 3:57:20 AM UTC+1, Ben Ward wrote:
>
> Hi,
>
> I'm trying to update a package for the first time with the new package 
> manager commands like tag and so on:
>
> *julia> **Pkg.publish()*
>
> *INFO: Validating METADATA*
>
> *INFO: Pushing Phylogenetics permanent tags: v0.0.2*
>
> Permission denied (publickey).
>
> fatal: Could not read from remote repository.
>
>
>
> Please make sure you have the correct access rights
>
> and the repository exists.
>
> *ERROR: failed process: Process(`git 
> --work-tree=/Users/axolotlfan9250/.julia/v0.3/Phylogenetics 
> --git-dir=/Users/axolotlfan9250/.julia/v0.3/Phylogenetics/.git push -q 
> origin refs/tags/v0.0.2:refs/tags/v0.0.2`, ProcessExited(128)) [128]*
>
> * in wait at ./task.jl:279*
>
> * in wait at ./task.jl:189*
>
> * in wait at task.jl:48*
>
> * in sync_end at ./task.jl:306*
>
> * in publish at pkg/entry.jl:314*
>
> * in anonymous at pkg/dir.jl:28*
>
> * in cd at file.jl:20*
>
> * in cd at pkg/dir.jl:28*
>
> * in publish at pkg.jl:57*
>
>
>
> I'm not 100% sure why I'm getting this, shouldn't it just send a PR to 
> METADATA? I'm not 100% clear on how this works - do I need a fork of 
> METADATA still? The process that fails looks like it's trying to push 
> something to ward9250/Phylogenetics.jl? In which case I wonder if it's a 
> naming issue Phylogenetics in .julia/v0.3/ and Phylogenetics.jl for the 
> repo?
>

Re: [julia-users] Re: Decreasing range, should it work?

[Jay Kickliter]

Thanks everyone for the examples. I was trying to do something similar to what 
Douglas illustrated.

Re: [julia-users] metaprogramming nested functions

[Bryan A. Knowles]

Moreorless. Maybe call it @unquote?
```julia
function foo(val)
ex = "print($val)"
@unquote(ex)
end
```

Re: [julia-users] OS X dlopen() Problem

[Bob Nnamtrop]

I have the same problem in a package I am developing. The solution that I
came up with is similar to:

cd("/opt/intel/ipp/lib/") do
dlopen("libipps")
end

w/ this inside an init function (although I call ccall, not dlopen). And
with hooks to set the directory. Seems to work ok.

Bob


On Thu, Jul 3, 2014 at 9:36 AM, Jameson Nash  wrote:

> The output of otool appears to indicate that it is built such that it can
> only be loaded by changing the working directory (because of ./). This is
> not advisable from a package distribution standpoint, but we see that this
> is what Intel did, unfortunately. I think you could use install_name_tool
> from Xcode to edit it
>
> I have some thoughts for improving this in 0.4.
>
>
> On Thursday, July 3, 2014, Jay Kickliter  wrote:
>
>> I misspoke, here's the output of tool:
>>
>> $ otool -L /opt/intel/ipp/lib/libipps.dylib
>> /opt/intel/ipp/lib/libipps.dylib:
>>  ./libipps-8.1.dylib (compatibility version 8.1.0, current version 8.1.0)
>> ./libippcore-8.1.dylib (compatibility version 8.1.0, current version
>> 8.1.0)
>>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 169.3.0)
>>
>>
>> I can load both libippcore and libSystem when I start Julia from ~/, but
>> I have to cd( "/opt/intel/ipp/lib" ) in order to to open libipps:
>>
>> julia> DL_LOAD_PATH
>> 5-element Array{Union(ASCIIString,UTF8String),1}:
>>  "@executable_path/../lib/julia"
>>  "@executable_path/../lib"
>>  "/opt/local/bin"
>>  "/opt/intel/lib/intel64"
>>  "/opt/intel/ipp/lib"
>>
>> julia> dlopen("libSystem.B")
>> Ptr{Void} @0x7fe7ee2a7070
>>
>> julia> dlopen("libippcore")
>> Ptr{Void} @0x7fe7ee011160
>>
>> julia> dlopen("libipps")
>> ERROR: could not load module libipps: dlopen(libipps.dylib, 1): image not
>> found
>>  in dlopen at c.jl:19
>>
>> julia> cd( "/opt/intel/ipp/lib/" )
>>
>> julia> dlopen("libipps")
>> Ptr{Void} @0x7fe7ea69cc10
>>
>> I've exhausted my limited troubleshooting skills in this area. Any
>> suggestions?
>>
>> I forgot to mention that IPP is Intel Integrated Performance Primitives.
>>
>> On Thursday, July 3, 2014 7:30:44 AM UTC-6, Jay Kickliter wrote:
>>>
>>> I'm trying to open libipps.dylib in OS X. If I push the path to
>>> DL_LOAD_PATH, Julia can't find it. But if I cd() to that path, it loads it
>>> fine. The weird thing is that it can find libippcore.dylib just fine with
>>> without having to cd() to the libraries' location.
>>>
>>> Here's what I tried:
>>>
>>> julia> push!( DL_LOAD_PATH, "/opt/intel/ipp/lib" )
>>> 4-element Array{Union(ASCIIString,UTF8String),1}:
>>>  "@executable_path/../lib/julia"
>>>  "@executable_path/../lib"
>>>  "/opt/local/lib"
>>>  "/opt/intel/ipp/lib"
>>>
>>> julia> dlopen( "libipps" )
>>> ERROR: could not load module libipps: dlopen(libipps.dylib, 1): image
>>> not found
>>>  in dlopen at c.jl:19
>>>
>>> julia> cd( "/opt/intel/ipp/lib" )
>>>
>>> julia> dlopen( "libipps" )
>>> Ptr{Void} @0x7fc5aad99330
>>>
>>> Am I making a rookie mistake? I tried first loading the two other
>>> libraries that libipps depends on. I could't only get one of them to load
>>> (libippcore).
>>>
>>

Re: [julia-users] Re: Why is string concatenation done with * not +

[Stefan Karpinski]

On Thu, Jul 3, 2014 at 12:09 PM, Patrick O'Leary 
wrote:

> I do find the generalization to string exponentiation -> repetition is
> pretty beautiful.


This is my favorite part about the * choice. From str+str it's not at all
obvious whether 2str or str*2 is the right choice for string repetition. I
also agree that's fascinating how attached people get to string
concatenation operators. Don't get Jeff started on string interpolation,
which is essentially a fancy string concatenation syntax.

Re: [julia-users] Re: Why is string concatenation done with * not +

[yi lu]

What a beautiful comment. :)


On Thu, Jul 3, 2014 at 11:48 PM, Gregg Reynolds  wrote:

> On Thu, Jul 3, 2014 at 9:45 AM, Stefan Karpinski 
> wrote:
>
>> On Thu, Jul 3, 2014 at 9:42 AM, Ivar Nesje  wrote:
>>
>>> We should really create a simple system where you can get those hints
>>> printed in the REPL, without defining more methods.
>>
>>
>> Yes, I think we should really pursue this avenue.
>>
>> For what it's worth - and perhaps something since I'm the original
>> perpetrator of the str*str concatenation syntax - I've come to regret this
>> operator choice. My reasoning at this point is that we want our operators
>> to have fairly "pure" meanings. I chose str*str because concatenation can
>> be viewed as a kind of multiplication in the ring of string patterns
>> (alternation in the regex sense is the addition operation, the empty string
>> is the unit and the non-matching pattern is the zero). However, many
>> operations can be viewed as a form of multiplication. In the max-plus
>> algebra , for example,
>> addition is the multiplication operator. So, at this point I think we
>> should stick to very pure classical meanings for operators in Base - the
>> Base.* function should be just addition of numbers in the classical sense,
>> not the broader sense of addition in any conceivable ring.
>>
>
> Hi!
>
> I would add "minimal" and "intuitive".  I agree '*' is an unfortunate
> choice for a string concat op, but I don't see a problem with '+' -
> mathematics routinely overloads symbols, and I don't see any strictly
> mathematical reason to privilege commutativity as an essential component of
> the meaning of '+'.  Commutativity is an add-on that comes after the more
> primitive sense of accumulation, which is what concatenation is.  You can't
> build a brick wall from the top down.  I think its a pretty safe bet that
> nobody would ever be tempted to think "ab" + "cd" = "cd" + "ab", ditto for
> "++".  On the other hand, if you want to minimize overloading, an
> alternative notation (my fav), used by Z and ML, among other languages, is
> '^'; since that's already taken, maybe '^^'.
>
> In any case, str * str isn't all that tragic; think of it as a beauty
> mark, a flaw that makes the whole face more beautify. ;)
>
> -Gregg Reynolds
>
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[Patrick O'Leary]

On Thursday, July 3, 2014 9:46:12 AM UTC-5, Stefan Karpinski wrote:
>
> For what it's worth – and perhaps something since I'm the original 
> perpetrator of the str*str concatenation syntax – I've come to regret this 
> operator choice.
>

Since everyone else likes to disagree with this operator choice, I'll just 
mention that after some initial confusion I've come around. It's not 
something I use all that often, but I do find the generalization to string 
exponentiation -> repetition is pretty beautiful.

What fascinates me about the whole thing is that people get really attached 
to string concatenation operators... 

Re: [julia-users] Re: Why is string concatenation done with * not +

[Gregg Reynolds]

On Thu, Jul 3, 2014 at 9:45 AM, Stefan Karpinski 
wrote:

> On Thu, Jul 3, 2014 at 9:42 AM, Ivar Nesje  wrote:
>
>> We should really create a simple system where you can get those hints
>> printed in the REPL, without defining more methods.
>
>
> Yes, I think we should really pursue this avenue.
>
> For what it's worth – and perhaps something since I'm the original
> perpetrator of the str*str concatenation syntax – I've come to regret this
> operator choice. My reasoning at this point is that we want our operators
> to have fairly "pure" meanings. I chose str*str because concatenation can
> be viewed as a kind of multiplication in the ring of string patterns
> (alternation in the regex sense is the addition operation, the empty string
> is the unit and the non-matching pattern is the zero). However, many
> operations can be viewed as a form of multiplication. In the max-plus
> algebra , for example,
> addition is the multiplication operator. So, at this point I think we
> should stick to very pure classical meanings for operators in Base – the
> Base.* function should be just addition of numbers in the classical sense,
> not the broader sense of addition in any conceivable ring.
>

Hi!

I would add "minimal" and "intuitive".  I agree '*' is an unfortunate
choice for a string concat op, but I don't see a problem with '+' -
mathematics routinely overloads symbols, and I don't see any strictly
mathematical reason to privilege commutativity as an essential component of
the meaning of '+'.  Commutativity is an add-on that comes after the more
primitive sense of accumulation, which is what concatenation is.  You can't
build a brick wall from the top down.  I think its a pretty safe bet that
nobody would ever be tempted to think "ab" + "cd" = "cd" + "ab", ditto for
"++".  On the other hand, if you want to minimize overloading, an
alternative notation (my fav), used by Z and ML, among other languages, is
'^'; since that's already taken, maybe '^^'.

In any case, str * str isn't all that tragic; think of it as a beauty mark,
a flaw that makes the whole face more beautify. ;)

-Gregg Reynolds

Re: [julia-users] How do I declare a baremodule in a macro?

[Eric Davies]

Okay, looks like I continue to have problems. 

julia> macro modcreate(name, block)
   Expr(:module, false, esc(name::Symbol), Expr(:begin))
   for ex in block.args
   eval(esc(name), ex)
   end
   end

julia> @modcreate foobar begin
   arf = 6
   barf = 6
   end
ERROR: type: eval: expected Module, got Expr

I feel like this should work. Am I completely off or is there some dumb 
mistake I'm making?

On Wednesday, 2 July 2014 23:21:33 UTC-5, Jameson wrote:
>
> macro modcreate(name)
> Expr(:module, false, esc(name::Symbol), Expr(:begin))
> end
>
>
> On Thu, Jul 3, 2014 at 12:00 AM, Eric Davies  > wrote:
>
>> Hi all,
>>
>> I'm working on a multipass configuration file package and I'm having 
>> difficulty executing my ideas (I'm not great at the metaprogramming stuff 
>> yet). I want to create a baremodule in a macro and have it available to the 
>> scope containing the macro. I want to be able to pass the name of the 
>> baremodule as an argument to the macro. Unfortunately, every (probably 
>> terrible) strategy I try seems to give the error "name not defined" (where 
>> name is the argument to the macro containing the desired module name).
>>
>> I want it to work like this (toy example):
>>
>> julia> @modcreate foo
>>
>> julia> typeof(foo)
>> Module
>>
>> Can anyone suggest possible contents for the macro that might produce the 
>> above behaviour?
>>
>> Thanks,
>> Eric
>>
>
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[John Myles White]

Because Julia uses multiple dispatch, an effort is being made to ensure that 
all functions always mean the same thing. So the mathematical case affects the 
non-mathematical case.

I'm checking out of this conversation now so that I can get back to my actual 
job. I'm confident Stefan will make a good decision about this in due time.

 -- John

On Jul 3, 2014, at 8:34 AM, yi lu  wrote:

> When you talk about convention, you regard julia language as a programming 
> language like MATLAB or a more general purpose language? Again, it is all 
> about string concatenation, not operations on a ring.
> 
> 
> On Thu, Jul 3, 2014 at 11:13 PM, John Myles White  
> wrote:
> That is true, but the convention exists nonetheless. Consider, for example, 
> this branch of the combinatorics literature: 
> http://en.wikipedia.org/wiki/Square-free_word 
>  -- John
> 
> 
> On Jul 3, 2014, at 8:09 AM, yi lu  wrote:
> 
>> I know abstract algebra. When talking about string concatenation, a monoid 
>> is enough. It is true that in a ring, "+" is a commutative operator, and "*" 
>> no commutative required, however, a ring is far beyond what needed to do a 
>> string concatenation job.
>> 
>> 
>> On Thu, Jul 3, 2014 at 10:59 PM, John Myles White  
>> wrote:
>> This is just the standard convention in mathematics. See just about any 
>> textbook on abstract algebra for a discussion of the reasons.
>> 
>> I think it's safe to say that `+` will never be string concatenation, so 
>> it's better to focus energy on other proposals.
>> 
>>  -- John
>> 
>> On Jul 3, 2014, at 7:57 AM, yi lu  wrote:
>> 
>>> @John I know that "*" means no commutative, but I see no reason "+" has a 
>>> meaning of commutative.
>>> 
>>> 
>>> On Thu, Jul 3, 2014 at 10:53 PM, Stefan Karpinski  
>>> wrote:
>>> That's even worse.
>>> 
>>> 
>>> On Thu, Jul 3, 2014 at 10:52 AM, yi lu  
>>> wrote:
>>> I will vote for "+", although I learn mathematics. Maybe that is why I am 
>>> not a mathematician.
>>> 
>>> Yi
>>> 
>>> 
>>> On Thu, Jul 3, 2014 at 10:45 PM, Stefan Karpinski  
>>> wrote:
>>> On Thu, Jul 3, 2014 at 9:42 AM, Ivar Nesje  wrote:
>>> We should really create a simple system where you can get those hints 
>>> printed in the REPL, without defining more methods.
>>> 
>>> Yes, I think we should really pursue this avenue.
>>> 
>>> For what it's worth – and perhaps something since I'm the original 
>>> perpetrator of the str*str concatenation syntax – I've come to regret this 
>>> operator choice. My reasoning at this point is that we want our operators 
>>> to have fairly "pure" meanings. I chose str*str because concatenation can 
>>> be viewed as a kind of multiplication in the ring of string patterns 
>>> (alternation in the regex sense is the addition operation, the empty string 
>>> is the unit and the non-matching pattern is the zero). However, many 
>>> operations can be viewed as a form of multiplication. In the max-plus 
>>> algebra, for example, addition is the multiplication operator. So, at this 
>>> point I think we should stick to very pure classical meanings for operators 
>>> in Base – the Base.* function should be just addition of numbers in the 
>>> classical sense, not the broader sense of addition in any conceivable ring.
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 

Re: [julia-users] Re: Why is string concatenation done with * not +

[yi lu]

However, to be honest, I don't need much of the string functions. I only
need functions that operate vectors or matrices.


On Thu, Jul 3, 2014 at 11:34 PM, yi lu 
wrote:

> When you talk about convention, you regard julia language as a programming
> language like MATLAB or a more general purpose language? Again, it is all
> about string concatenation, not operations on a ring.
>
>
> On Thu, Jul 3, 2014 at 11:13 PM, John Myles White <
> johnmyleswh...@gmail.com> wrote:
>
>> That is true, but the convention exists nonetheless. Consider, for
>> example, this branch of the combinatorics literature:
>> http://en.wikipedia.org/wiki/Square-free_word
>>
>>  -- John
>>
>>
>> On Jul 3, 2014, at 8:09 AM, yi lu  wrote:
>>
>> I know abstract algebra. When talking about string concatenation, a
>> monoid  is enough. It is true that
>> in a ring, "+" is a commutative operator, and "*" no commutative required,
>> however, a ring is far beyond what needed to do a string concatenation job.
>>
>>
>> On Thu, Jul 3, 2014 at 10:59 PM, John Myles White <
>> johnmyleswh...@gmail.com> wrote:
>>
>>> This is just the standard convention in mathematics. See just about any
>>> textbook on abstract algebra for a discussion of the reasons.
>>>
>>> I think it's safe to say that `+` will never be string concatenation, so
>>> it's better to focus energy on other proposals.
>>>
>>>  -- John
>>>
>>> On Jul 3, 2014, at 7:57 AM, yi lu  wrote:
>>>
>>> @John I know that "*" means no commutative, but I see no reason "+" has
>>> a meaning of commutative.
>>>
>>>
>>> On Thu, Jul 3, 2014 at 10:53 PM, Stefan Karpinski 
>>> wrote:
>>>
 That's even worse.


 On Thu, Jul 3, 2014 at 10:52 AM, yi lu 
 wrote:

> I will vote for "+", although I learn mathematics. Maybe that is why I
> am not a mathematician.
>
> Yi
>
>
> On Thu, Jul 3, 2014 at 10:45 PM, Stefan Karpinski <
> ste...@karpinski.org> wrote:
>
>> On Thu, Jul 3, 2014 at 9:42 AM, Ivar Nesje  wrote:
>>
>>> We should really create a simple system where you can get those
>>> hints printed in the REPL, without defining more methods.
>>
>>
>> Yes, I think we should really pursue this avenue.
>>
>> For what it's worth - and perhaps something since I'm the original
>> perpetrator of the str*str concatenation syntax - I've come to regret 
>> this
>> operator choice. My reasoning at this point is that we want our operators
>> to have fairly "pure" meanings. I chose str*str because concatenation can
>> be viewed as a kind of multiplication in the ring of string patterns
>> (alternation in the regex sense is the addition operation, the empty 
>> string
>> is the unit and the non-matching pattern is the zero). However, many
>> operations can be viewed as a form of multiplication. In the max-plus
>> algebra , for
>> example, addition is the multiplication operator. So, at this point I 
>> think
>> we should stick to very pure classical meanings for operators in Base - 
>> the
>> Base.* function should be just addition of numbers in the classical 
>> sense,
>> not the broader sense of addition in any conceivable ring.
>>
>>
>

>>>
>>>
>>
>>
>

Re: [julia-users] OS X dlopen() Problem

[Jameson Nash]

The output of otool appears to indicate that it is built such that it can
only be loaded by changing the working directory (because of ./). This is
not advisable from a package distribution standpoint, but we see that this
is what Intel did, unfortunately. I think you could use install_name_tool
from Xcode to edit it

I have some thoughts for improving this in 0.4.


On Thursday, July 3, 2014, Jay Kickliter  wrote:

> I misspoke, here's the output of tool:
>
> $ otool -L /opt/intel/ipp/lib/libipps.dylib
> /opt/intel/ipp/lib/libipps.dylib:
> ./libipps-8.1.dylib (compatibility version 8.1.0, current version 8.1.0)
> ./libippcore-8.1.dylib (compatibility version 8.1.0, current version 8.1.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 169.3.0)
>
>
> I can load both libippcore and libSystem when I start Julia from ~/, but I
> have to cd( "/opt/intel/ipp/lib" ) in order to to open libipps:
>
> julia> DL_LOAD_PATH
> 5-element Array{Union(ASCIIString,UTF8String),1}:
>  "@executable_path/../lib/julia"
>  "@executable_path/../lib"
>  "/opt/local/bin"
>  "/opt/intel/lib/intel64"
>  "/opt/intel/ipp/lib"
>
> julia> dlopen("libSystem.B")
> Ptr{Void} @0x7fe7ee2a7070
>
> julia> dlopen("libippcore")
> Ptr{Void} @0x7fe7ee011160
>
> julia> dlopen("libipps")
> ERROR: could not load module libipps: dlopen(libipps.dylib, 1): image not
> found
>  in dlopen at c.jl:19
>
> julia> cd( "/opt/intel/ipp/lib/" )
>
> julia> dlopen("libipps")
> Ptr{Void} @0x7fe7ea69cc10
>
> I've exhausted my limited troubleshooting skills in this area. Any
> suggestions?
>
> I forgot to mention that IPP is Intel Integrated Performance Primitives.
>
> On Thursday, July 3, 2014 7:30:44 AM UTC-6, Jay Kickliter wrote:
>>
>> I'm trying to open libipps.dylib in OS X. If I push the path to
>> DL_LOAD_PATH, Julia can't find it. But if I cd() to that path, it loads it
>> fine. The weird thing is that it can find libippcore.dylib just fine with
>> without having to cd() to the libraries' location.
>>
>> Here's what I tried:
>>
>> julia> push!( DL_LOAD_PATH, "/opt/intel/ipp/lib" )
>> 4-element Array{Union(ASCIIString,UTF8String),1}:
>>  "@executable_path/../lib/julia"
>>  "@executable_path/../lib"
>>  "/opt/local/lib"
>>  "/opt/intel/ipp/lib"
>>
>> julia> dlopen( "libipps" )
>> ERROR: could not load module libipps: dlopen(libipps.dylib, 1): image not
>> found
>>  in dlopen at c.jl:19
>>
>> julia> cd( "/opt/intel/ipp/lib" )
>>
>> julia> dlopen( "libipps" )
>> Ptr{Void} @0x7fc5aad99330
>>
>> Am I making a rookie mistake? I tried first loading the two other
>> libraries that libipps depends on. I could't only get one of them to load
>> (libippcore).
>>
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[yi lu]

When you talk about convention, you regard julia language as a programming
language like MATLAB or a more general purpose language? Again, it is all
about string concatenation, not operations on a ring.


On Thu, Jul 3, 2014 at 11:13 PM, John Myles White 
wrote:

> That is true, but the convention exists nonetheless. Consider, for
> example, this branch of the combinatorics literature:
> http://en.wikipedia.org/wiki/Square-free_word
>
>  -- John
>
>
> On Jul 3, 2014, at 8:09 AM, yi lu  wrote:
>
> I know abstract algebra. When talking about string concatenation, a monoid
>  is enough. It is true that in a
> ring, "+" is a commutative operator, and "*" no commutative required,
> however, a ring is far beyond what needed to do a string concatenation job.
>
>
> On Thu, Jul 3, 2014 at 10:59 PM, John Myles White <
> johnmyleswh...@gmail.com> wrote:
>
>> This is just the standard convention in mathematics. See just about any
>> textbook on abstract algebra for a discussion of the reasons.
>>
>> I think it's safe to say that `+` will never be string concatenation, so
>> it's better to focus energy on other proposals.
>>
>>  -- John
>>
>> On Jul 3, 2014, at 7:57 AM, yi lu  wrote:
>>
>> @John I know that "*" means no commutative, but I see no reason "+" has a
>> meaning of commutative.
>>
>>
>> On Thu, Jul 3, 2014 at 10:53 PM, Stefan Karpinski 
>> wrote:
>>
>>> That's even worse.
>>>
>>>
>>> On Thu, Jul 3, 2014 at 10:52 AM, yi lu 
>>> wrote:
>>>
 I will vote for "+", although I learn mathematics. Maybe that is why I
 am not a mathematician.

 Yi


 On Thu, Jul 3, 2014 at 10:45 PM, Stefan Karpinski >>> > wrote:

> On Thu, Jul 3, 2014 at 9:42 AM, Ivar Nesje  wrote:
>
>> We should really create a simple system where you can get those hints
>> printed in the REPL, without defining more methods.
>
>
> Yes, I think we should really pursue this avenue.
>
> For what it's worth - and perhaps something since I'm the original
> perpetrator of the str*str concatenation syntax - I've come to regret this
> operator choice. My reasoning at this point is that we want our operators
> to have fairly "pure" meanings. I chose str*str because concatenation can
> be viewed as a kind of multiplication in the ring of string patterns
> (alternation in the regex sense is the addition operation, the empty 
> string
> is the unit and the non-matching pattern is the zero). However, many
> operations can be viewed as a form of multiplication. In the max-plus
> algebra , for example,
> addition is the multiplication operator. So, at this point I think we
> should stick to very pure classical meanings for operators in Base - the
> Base.* function should be just addition of numbers in the classical sense,
> not the broader sense of addition in any conceivable ring.
>
>

>>>
>>
>>
>
>

Re: [julia-users] Re: Decreasing range, should it work?

[Douglas Bates]

On Thursday, July 3, 2014 10:15:31 AM UTC-5, Stefan Karpinski wrote:
>
> Oh yikes. That's not good at all. Python has the good behavior too.
>

This causes many "zero-length" problems in R because a

  for (i in 1:length(v)) {
   ...
 } 

>
loop is executed twice for a zero-length array, usually resulting in an 
indexing error.  It may indeed be part of the R FAQ that you should write 
the loop in R as

  for (i in seq(along = v)) {
   ...
 } 

>
to get the correct edge-case behavior.

This alone is enough to discourage such an interpretation of 1:0



> On Jul 3, 2014, at 10:22 AM, John Myles White  > wrote:
>
> Sadly, R does not. 1:0 expands to c(1, 0). This is something that has 
> burned a lot of people in my experience. I imagine this is inherited from S.
>
>  — John
>
> On Jul 3, 2014, at 2:05 AM, Tobias Knopp  > wrote:
>
> Just as a side note (I entirely agree with Stefan), Matlab behaves the 
> same as Julia:
>
> >> 3:1
>
> ans =
>
>Empty matrix: 1-by-0
>
>
> Am Donnerstag, 3. Juli 2014 03:38:32 UTC+2 schrieb Stefan Karpinski:
>>
>> It changes the meaning of a:b in a capricious way based on their values, 
>> which, while often appealing for the immediate situation – and thus rampant 
>> in dynamic languages – is almost always terrible for writing predictable, 
>> reliable code. 
>>
>>
>> On Wed, Jul 2, 2014 at 1:07 PM, Jay Kickliter  
>> wrote:
>>
>>> I assume that when I wake up at 5 AM to finish some DSP code. Really, it 
>>> was just a stupid mistake. From a non-programmer's perspective (me), it 
>>> seemed like it should have work. If you think that would be dangerous, I'll 
>>> take your word for it.
>>>
>>>
>>> On Wednesday, July 2, 2014 8:26:10 AM UTC-6, Stefan Karpinski wrote:
>>>
 Why would one assume that the default step size is -1 when the start is 
 bigger than the stop? The documentation for ranges clearly says that the 
 default step size is 1 unconditionally, not that it is sign(stop-start). 
 That would, by the way, be a very dangerous behavior. Perhaps a sidebar on 
 the colon syntax is warranted in the manual control flow section on for 
 loops, including examples of empty ranges and ranges that count downwards.


 On Wed, Jul 2, 2014 at 9:53 AM, Jay Kickliter  
 wrote:

> I just realized that it works if I rewrite the range as 10:-1:1. It 
> seems to me that either big:small should work with a default step size of 
> -1, or the documentation needs a note. 
>
>
> On Wednesday, July 2, 2014 7:32:10 AM UTC-6, Jay Kickliter wrote:
>>
>> Are they meant to work? I could only find one meaning of them not 
>> working (issue 5778 
>> ).
>>
>> Here's an example:
>>
>> julia> for i = 1:10
>>
>>println(i)
>>
>>end
>>
>> 1
>>
>> 2
>>
>> 3
>>
>> 4
>>
>> 5
>>
>> 6
>>
>> 7
>>
>> 8
>>
>> 9
>>
>> 10
>>
>>
>> julia> for i = 10:1
>>
>>println(i)
>>
>>end
>>
>>
>> julia> 
>>
>

>>
>

[julia-users] Re: ANN: Contour.jl

[Tomas Lycken]

The purpose of the Contour.jl package isn’t really to provide that part of 
the functionality - but rather an abstraction over *finding* the contours 
in the first place, that plotting packages can make use of. If you only 
want the contours in order to plot them, it’s better to use one of the 
plotting packages directly.

Contour plots are already available in PyPlot (using the matplotlib api 
), and at 
least to some extent in Gadfly 
. I don’t know if or how 
Winston or others do contour plots, but if they can, they'll probably show 
them off in the docs =)

// T

On Wednesday, July 2, 2014 4:16:32 PM UTC+2, Andrei Berceanu wrote:

Great work, congratulations for the package. I have a short question.
> Once I get an array of Curve2 type, how can I get a graphical 
> representation of it? I mean, in Winston/Gaston/PyPlot/whatever.
>
> On Sunday, June 29, 2014 12:34:28 AM UTC+2, Tomas Lycken wrote:
>>
>> Huzzah!
>>
>> We’ve just released Contour.jl , 
>> a light-weight package that provides an algorithm to calculate iso-lines of 
>> a scalar 2D-field f(x,y), such as those shown on a contour plot. The 
>> current implementation uses the Marching Squares 
>>  algorithm, and returns 
>> the contour lines in an array of ContourLevel instances, that provide an 
>> abstraction over the actual implementation of curves as geometrical 
>> objects. Currently lists of Vector2s from ImmutableArrays are used to 
>> represent curves, but the idea is that if e.g. a package with general 
>> geometry items emerges, we can seemlessly switch to that.
>>
>> Our hopes is that other packages that have use for isolines (e.g. all 
>> plotting packages that want to plot contours) use this package instead of 
>> each carrying their own implementation, but use cases are of course not 
>> limited to plotting. (I wanted to put this together because I needed to 
>> calculate volumes inside axisymmetric isosurfaces, and this solved a large 
>> part of that problem…)
>>
>> Please, kick the tires and see what you can do with this! =)
>>
>> Finally, a big thanks to Darwin Darakananda 
>> , who’s done almost all the coding.
>>
>> // Tomas
>> ​
>>
> ​

[julia-users] Re: OS X dlopen() Problem

[Jay Kickliter]

I misspoke, here's the output of tool:

$ otool -L /opt/intel/ipp/lib/libipps.dylib
/opt/intel/ipp/lib/libipps.dylib:
./libipps-8.1.dylib (compatibility version 8.1.0, current version 8.1.0)
./libippcore-8.1.dylib (compatibility version 8.1.0, current version 8.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
169.3.0)


I can load both libippcore and libSystem when I start Julia from ~/, but I 
have to cd( "/opt/intel/ipp/lib" ) in order to to open libipps:

julia> DL_LOAD_PATH
5-element Array{Union(ASCIIString,UTF8String),1}:
 "@executable_path/../lib/julia"
 "@executable_path/../lib"  
 "/opt/local/bin"   
 "/opt/intel/lib/intel64"   
 "/opt/intel/ipp/lib"   

julia> dlopen("libSystem.B")
Ptr{Void} @0x7fe7ee2a7070

julia> dlopen("libippcore")
Ptr{Void} @0x7fe7ee011160

julia> dlopen("libipps")
ERROR: could not load module libipps: dlopen(libipps.dylib, 1): image not 
found
 in dlopen at c.jl:19

julia> cd( "/opt/intel/ipp/lib/" )

julia> dlopen("libipps")
Ptr{Void} @0x7fe7ea69cc10

I've exhausted my limited troubleshooting skills in this area. Any 
suggestions? 

I forgot to mention that IPP is Intel Integrated Performance Primitives.

On Thursday, July 3, 2014 7:30:44 AM UTC-6, Jay Kickliter wrote:
>
> I'm trying to open libipps.dylib in OS X. If I push the path to 
> DL_LOAD_PATH, Julia can't find it. But if I cd() to that path, it loads it 
> fine. The weird thing is that it can find libippcore.dylib just fine with 
> without having to cd() to the libraries' location.
>
> Here's what I tried:
>
> julia> push!( DL_LOAD_PATH, "/opt/intel/ipp/lib" )
> 4-element Array{Union(ASCIIString,UTF8String),1}:
>  "@executable_path/../lib/julia"
>  "@executable_path/../lib"  
>  "/opt/local/lib"   
>  "/opt/intel/ipp/lib"   
>
> julia> dlopen( "libipps" )
> ERROR: could not load module libipps: dlopen(libipps.dylib, 1): image not 
> found
>  in dlopen at c.jl:19
>
> julia> cd( "/opt/intel/ipp/lib" )
>
> julia> dlopen( "libipps" )
> Ptr{Void} @0x7fc5aad99330
>
> Am I making a rookie mistake? I tried first loading the two other 
> libraries that libipps depends on. I could't only get one of them to load 
> (libippcore).
>

Re: [julia-users] Re: Decreasing range, should it work?

[Stefan Karpinski]

Oh yikes. That's not good at all. Python has the good behavior too.

> On Jul 3, 2014, at 10:22 AM, John Myles White  
> wrote:
> 
> Sadly, R does not. 1:0 expands to c(1, 0). This is something that has burned 
> a lot of people in my experience. I imagine this is inherited from S.
> 
>  — John
> 
>> On Jul 3, 2014, at 2:05 AM, Tobias Knopp  wrote:
>> 
>> Just as a side note (I entirely agree with Stefan), Matlab behaves the same 
>> as Julia:
>> 
>> >> 3:1
>> 
>> ans =
>> 
>>Empty matrix: 1-by-0
>> 
>> 
>> Am Donnerstag, 3. Juli 2014 03:38:32 UTC+2 schrieb Stefan Karpinski:
>>> 
>>> It changes the meaning of a:b in a capricious way based on their values, 
>>> which, while often appealing for the immediate situation – and thus rampant 
>>> in dynamic languages – is almost always terrible for writing predictable, 
>>> reliable code.
>>> 
>>> 
>>> On Wed, Jul 2, 2014 at 1:07 PM, Jay Kickliter  wrote:
 I assume that when I wake up at 5 AM to finish some DSP code. Really, it 
 was just a stupid mistake. From a non-programmer's perspective (me), it 
 seemed like it should have work. If you think that would be dangerous, 
 I'll take your word for it.
 
 
> On Wednesday, July 2, 2014 8:26:10 AM UTC-6, Stefan Karpinski wrote:
> Why would one assume that the default step size is -1 when the start is 
> bigger than the stop? The documentation for ranges clearly says that the 
> default step size is 1 unconditionally, not that it is sign(stop-start). 
> That would, by the way, be a very dangerous behavior. Perhaps a sidebar 
> on the colon syntax is warranted in the manual control flow section on 
> for loops, including examples of empty ranges and ranges that count 
> downwards.
> 
> 
>> On Wed, Jul 2, 2014 at 9:53 AM, Jay Kickliter  
>> wrote:
>> I just realized that it works if I rewrite the range as 10:-1:1. It 
>> seems to me that either big:small should work with a default step size 
>> of -1, or the documentation needs a note. 
>> 
>> 
>>> On Wednesday, July 2, 2014 7:32:10 AM UTC-6, Jay Kickliter wrote:
>>> Are they meant to work? I could only find one meaning of them not 
>>> working (issue 5778).
>>> 
>>> Here's an example:
>>> 
>>> julia> for i = 1:10
>>>println(i)
>>>end
>>> 1
>>> 2
>>> 3
>>> 4
>>> 5
>>> 6
>>> 7
>>> 8
>>> 9
>>> 10
>>> 
>>> julia> for i = 10:1
>>>println(i)
>>>end
>>> 
>>> julia> 
> 

Re: [julia-users] Re: Why is string concatenation done with * not +

[John Myles White]

That is true, but the convention exists nonetheless. Consider, for example, 
this branch of the combinatorics literature: 
http://en.wikipedia.org/wiki/Square-free_word

 -- John

On Jul 3, 2014, at 8:09 AM, yi lu  wrote:

> I know abstract algebra. When talking about string concatenation, a monoid is 
> enough. It is true that in a ring, "+" is a commutative operator, and "*" no 
> commutative required, however, a ring is far beyond what needed to do a 
> string concatenation job.
> 
> 
> On Thu, Jul 3, 2014 at 10:59 PM, John Myles White  
> wrote:
> This is just the standard convention in mathematics. See just about any 
> textbook on abstract algebra for a discussion of the reasons.
> 
> I think it's safe to say that `+` will never be string concatenation, so it's 
> better to focus energy on other proposals.
> 
>  -- John
> 
> On Jul 3, 2014, at 7:57 AM, yi lu  wrote:
> 
>> @John I know that "*" means no commutative, but I see no reason "+" has a 
>> meaning of commutative.
>> 
>> 
>> On Thu, Jul 3, 2014 at 10:53 PM, Stefan Karpinski  
>> wrote:
>> That's even worse.
>> 
>> 
>> On Thu, Jul 3, 2014 at 10:52 AM, yi lu  wrote:
>> I will vote for "+", although I learn mathematics. Maybe that is why I am 
>> not a mathematician.
>> 
>> Yi
>> 
>> 
>> On Thu, Jul 3, 2014 at 10:45 PM, Stefan Karpinski  
>> wrote:
>> On Thu, Jul 3, 2014 at 9:42 AM, Ivar Nesje  wrote:
>> We should really create a simple system where you can get those hints 
>> printed in the REPL, without defining more methods.
>> 
>> Yes, I think we should really pursue this avenue.
>> 
>> For what it's worth – and perhaps something since I'm the original 
>> perpetrator of the str*str concatenation syntax – I've come to regret this 
>> operator choice. My reasoning at this point is that we want our operators to 
>> have fairly "pure" meanings. I chose str*str because concatenation can be 
>> viewed as a kind of multiplication in the ring of string patterns 
>> (alternation in the regex sense is the addition operation, the empty string 
>> is the unit and the non-matching pattern is the zero). However, many 
>> operations can be viewed as a form of multiplication. In the max-plus 
>> algebra, for example, addition is the multiplication operator. So, at this 
>> point I think we should stick to very pure classical meanings for operators 
>> in Base – the Base.* function should be just addition of numbers in the 
>> classical sense, not the broader sense of addition in any conceivable ring.
>> 
>> 
>> 
>> 
> 
> 

Re: [julia-users] Re: Why is string concatenation done with * not +

[Stefan Karpinski]

Please read my email about why * is not good for string concatenation. Then
reread the same email replacing * with +.


On Thu, Jul 3, 2014 at 11:09 AM, yi lu 
wrote:

> I know abstract algebra. When talking about string concatenation, a monoid
>  is enough. It is true that in a
> ring, "+" is a commutative operator, and "*" no commutative required,
> however, a ring is far beyond what needed to do a string concatenation job.
>
>
> On Thu, Jul 3, 2014 at 10:59 PM, John Myles White <
> johnmyleswh...@gmail.com> wrote:
>
>> This is just the standard convention in mathematics. See just about any
>> textbook on abstract algebra for a discussion of the reasons.
>>
>> I think it's safe to say that `+` will never be string concatenation, so
>> it's better to focus energy on other proposals.
>>
>>  -- John
>>
>> On Jul 3, 2014, at 7:57 AM, yi lu  wrote:
>>
>> @John I know that "*" means no commutative, but I see no reason "+" has a
>> meaning of commutative.
>>
>>
>> On Thu, Jul 3, 2014 at 10:53 PM, Stefan Karpinski 
>> wrote:
>>
>>> That's even worse.
>>>
>>>
>>> On Thu, Jul 3, 2014 at 10:52 AM, yi lu 
>>> wrote:
>>>
 I will vote for "+", although I learn mathematics. Maybe that is why I
 am not a mathematician.

 Yi


 On Thu, Jul 3, 2014 at 10:45 PM, Stefan Karpinski >>> > wrote:

> On Thu, Jul 3, 2014 at 9:42 AM, Ivar Nesje  wrote:
>
>> We should really create a simple system where you can get those hints
>> printed in the REPL, without defining more methods.
>
>
> Yes, I think we should really pursue this avenue.
>
> For what it's worth – and perhaps something since I'm the original
> perpetrator of the str*str concatenation syntax – I've come to regret this
> operator choice. My reasoning at this point is that we want our operators
> to have fairly "pure" meanings. I chose str*str because concatenation can
> be viewed as a kind of multiplication in the ring of string patterns
> (alternation in the regex sense is the addition operation, the empty 
> string
> is the unit and the non-matching pattern is the zero). However, many
> operations can be viewed as a form of multiplication. In the max-plus
> algebra , for example,
> addition is the multiplication operator. So, at this point I think we
> should stick to very pure classical meanings for operators in Base – the
> Base.* function should be just addition of numbers in the classical sense,
> not the broader sense of addition in any conceivable ring.
>
>

>>>
>>
>>
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[yi lu]

I know abstract algebra. When talking about string concatenation, a monoid
 is enough. It is true that in a ring,
"+" is a commutative operator, and "*" no commutative required, however, a
ring is far beyond what needed to do a string concatenation job.


On Thu, Jul 3, 2014 at 10:59 PM, John Myles White 
wrote:

> This is just the standard convention in mathematics. See just about any
> textbook on abstract algebra for a discussion of the reasons.
>
> I think it's safe to say that `+` will never be string concatenation, so
> it's better to focus energy on other proposals.
>
>  -- John
>
> On Jul 3, 2014, at 7:57 AM, yi lu  wrote:
>
> @John I know that "*" means no commutative, but I see no reason "+" has a
> meaning of commutative.
>
>
> On Thu, Jul 3, 2014 at 10:53 PM, Stefan Karpinski 
> wrote:
>
>> That's even worse.
>>
>>
>> On Thu, Jul 3, 2014 at 10:52 AM, yi lu 
>> wrote:
>>
>>> I will vote for "+", although I learn mathematics. Maybe that is why I
>>> am not a mathematician.
>>>
>>> Yi
>>>
>>>
>>> On Thu, Jul 3, 2014 at 10:45 PM, Stefan Karpinski 
>>> wrote:
>>>
 On Thu, Jul 3, 2014 at 9:42 AM, Ivar Nesje  wrote:

> We should really create a simple system where you can get those hints
> printed in the REPL, without defining more methods.


 Yes, I think we should really pursue this avenue.

 For what it's worth - and perhaps something since I'm the original
 perpetrator of the str*str concatenation syntax - I've come to regret this
 operator choice. My reasoning at this point is that we want our operators
 to have fairly "pure" meanings. I chose str*str because concatenation can
 be viewed as a kind of multiplication in the ring of string patterns
 (alternation in the regex sense is the addition operation, the empty string
 is the unit and the non-matching pattern is the zero). However, many
 operations can be viewed as a form of multiplication. In the max-plus
 algebra , for example,
 addition is the multiplication operator. So, at this point I think we
 should stick to very pure classical meanings for operators in Base - the
 Base.* function should be just addition of numbers in the classical sense,
 not the broader sense of addition in any conceivable ring.


>>>
>>
>
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[John Myles White]

This is just the standard convention in mathematics. See just about any 
textbook on abstract algebra for a discussion of the reasons.

I think it's safe to say that `+` will never be string concatenation, so it's 
better to focus energy on other proposals.

 -- John

On Jul 3, 2014, at 7:57 AM, yi lu  wrote:

> @John I know that "*" means no commutative, but I see no reason "+" has a 
> meaning of commutative.
> 
> 
> On Thu, Jul 3, 2014 at 10:53 PM, Stefan Karpinski  
> wrote:
> That's even worse.
> 
> 
> On Thu, Jul 3, 2014 at 10:52 AM, yi lu  wrote:
> I will vote for "+", although I learn mathematics. Maybe that is why I am not 
> a mathematician.
> 
> Yi
> 
> 
> On Thu, Jul 3, 2014 at 10:45 PM, Stefan Karpinski  
> wrote:
> On Thu, Jul 3, 2014 at 9:42 AM, Ivar Nesje  wrote:
> We should really create a simple system where you can get those hints printed 
> in the REPL, without defining more methods.
> 
> Yes, I think we should really pursue this avenue.
> 
> For what it's worth – and perhaps something since I'm the original 
> perpetrator of the str*str concatenation syntax – I've come to regret this 
> operator choice. My reasoning at this point is that we want our operators to 
> have fairly "pure" meanings. I chose str*str because concatenation can be 
> viewed as a kind of multiplication in the ring of string patterns 
> (alternation in the regex sense is the addition operation, the empty string 
> is the unit and the non-matching pattern is the zero). However, many 
> operations can be viewed as a form of multiplication. In the max-plus 
> algebra, for example, addition is the multiplication operator. So, at this 
> point I think we should stick to very pure classical meanings for operators 
> in Base – the Base.* function should be just addition of numbers in the 
> classical sense, not the broader sense of addition in any conceivable ring.
> 
> 
> 
> 

Re: [julia-users] Re: Why is string concatenation done with * not +

[yi lu]

@John I know that "*" means no commutative, but I see no reason "+" has a
meaning of commutative.


On Thu, Jul 3, 2014 at 10:53 PM, Stefan Karpinski 
wrote:

> That's even worse.
>
>
> On Thu, Jul 3, 2014 at 10:52 AM, yi lu 
> wrote:
>
>> I will vote for "+", although I learn mathematics. Maybe that is why I am
>> not a mathematician.
>>
>> Yi
>>
>>
>> On Thu, Jul 3, 2014 at 10:45 PM, Stefan Karpinski 
>> wrote:
>>
>>> On Thu, Jul 3, 2014 at 9:42 AM, Ivar Nesje  wrote:
>>>
 We should really create a simple system where you can get those hints
 printed in the REPL, without defining more methods.
>>>
>>>
>>> Yes, I think we should really pursue this avenue.
>>>
>>> For what it's worth - and perhaps something since I'm the original
>>> perpetrator of the str*str concatenation syntax - I've come to regret this
>>> operator choice. My reasoning at this point is that we want our operators
>>> to have fairly "pure" meanings. I chose str*str because concatenation can
>>> be viewed as a kind of multiplication in the ring of string patterns
>>> (alternation in the regex sense is the addition operation, the empty string
>>> is the unit and the non-matching pattern is the zero). However, many
>>> operations can be viewed as a form of multiplication. In the max-plus
>>> algebra , for example,
>>> addition is the multiplication operator. So, at this point I think we
>>> should stick to very pure classical meanings for operators in Base - the
>>> Base.* function should be just addition of numbers in the classical sense,
>>> not the broader sense of addition in any conceivable ring.
>>>
>>>
>>
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[Stefan Karpinski]

That's even worse.


On Thu, Jul 3, 2014 at 10:52 AM, yi lu 
wrote:

> I will vote for "+", although I learn mathematics. Maybe that is why I am
> not a mathematician.
>
> Yi
>
>
> On Thu, Jul 3, 2014 at 10:45 PM, Stefan Karpinski 
> wrote:
>
>> On Thu, Jul 3, 2014 at 9:42 AM, Ivar Nesje  wrote:
>>
>>> We should really create a simple system where you can get those hints
>>> printed in the REPL, without defining more methods.
>>
>>
>> Yes, I think we should really pursue this avenue.
>>
>> For what it's worth – and perhaps something since I'm the original
>> perpetrator of the str*str concatenation syntax – I've come to regret this
>> operator choice. My reasoning at this point is that we want our operators
>> to have fairly "pure" meanings. I chose str*str because concatenation can
>> be viewed as a kind of multiplication in the ring of string patterns
>> (alternation in the regex sense is the addition operation, the empty string
>> is the unit and the non-matching pattern is the zero). However, many
>> operations can be viewed as a form of multiplication. In the max-plus
>> algebra , for example,
>> addition is the multiplication operator. So, at this point I think we
>> should stick to very pure classical meanings for operators in Base – the
>> Base.* function should be just addition of numbers in the classical sense,
>> not the broader sense of addition in any conceivable ring.
>>
>>
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[yi lu]

I will vote for "+", although I learn mathematics. Maybe that is why I am
not a mathematician.

Yi


On Thu, Jul 3, 2014 at 10:45 PM, Stefan Karpinski 
wrote:

> On Thu, Jul 3, 2014 at 9:42 AM, Ivar Nesje  wrote:
>
>> We should really create a simple system where you can get those hints
>> printed in the REPL, without defining more methods.
>
>
> Yes, I think we should really pursue this avenue.
>
> For what it's worth - and perhaps something since I'm the original
> perpetrator of the str*str concatenation syntax - I've come to regret this
> operator choice. My reasoning at this point is that we want our operators
> to have fairly "pure" meanings. I chose str*str because concatenation can
> be viewed as a kind of multiplication in the ring of string patterns
> (alternation in the regex sense is the addition operation, the empty string
> is the unit and the non-matching pattern is the zero). However, many
> operations can be viewed as a form of multiplication. In the max-plus
> algebra , for example,
> addition is the multiplication operator. So, at this point I think we
> should stick to very pure classical meanings for operators in Base - the
> Base.* function should be just addition of numbers in the classical sense,
> not the broader sense of addition in any conceivable ring.
>
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[Stefan Karpinski]

On Thu, Jul 3, 2014 at 9:42 AM, Ivar Nesje  wrote:

> We should really create a simple system where you can get those hints
> printed in the REPL, without defining more methods.


Yes, I think we should really pursue this avenue.

For what it's worth – and perhaps something since I'm the original
perpetrator of the str*str concatenation syntax – I've come to regret this
operator choice. My reasoning at this point is that we want our operators
to have fairly "pure" meanings. I chose str*str because concatenation can
be viewed as a kind of multiplication in the ring of string patterns
(alternation in the regex sense is the addition operation, the empty string
is the unit and the non-matching pattern is the zero). However, many
operations can be viewed as a form of multiplication. In the max-plus
algebra , for example,
addition is the multiplication operator. So, at this point I think we
should stick to very pure classical meanings for operators in Base – the
Base.* function should be just addition of numbers in the classical sense,
not the broader sense of addition in any conceivable ring.

Re: [julia-users] Re: Why is string concatenation done with * not +

[Ivar Nesje]

Of course, Here is the link: https://github.com/JuliaLang/julia/issues/7512

kl. 16:32:00 UTC+2 torsdag 3. juli 2014 skrev Samuel Colvin følgende:
>
> Larger scope makes a lot of sense.
>
> Please give a link to the issue here once it's created.
>
> On Thursday, 3 July 2014 15:17:22 UTC+1, Tobias Knopp wrote:
>>
>> Great, thanks!
>>
>> Am Donnerstag, 3. Juli 2014 16:10:08 UTC+2 schrieb Ivar Nesje:
>>>
>>> I don't think so. I'll open one.
>>>
>>> kl. 16:06:42 UTC+2 torsdag 3. juli 2014 skrev Tobias Knopp følgende:

 Ivar, I absolutely agree with you. This should be handled in a larger 
 scope. Do we have an issue for this yet?

 Am Donnerstag, 3. Juli 2014 15:42:09 UTC+2 schrieb Ivar Nesje:
>
> I would strongly argue against
>
> +(a::String, b::String) == Error("Use * for string concatenation")
>
> We have plenty of cases where we want to give a more helpful 
> `MethodError`. We should really create a simple system where you can get 
> those hints printed in the REPL, without defining more methods.
>
> The display of MethodError is defined in 
> https://github.com/JuliaLang/julia/blob/0df386db18dd186c7b0bffc74149fc6b0e51c67d/base/replutil.jl#L110
>  
> and it would be easy to have a lookup table at the end of that function 
> to 
> see if one of the "banned" methods (with usefull, more concistent 
> alternaltives) were called.
>
> Ivar
>
> kl. 15:11:43 UTC+2 torsdag 3. juli 2014 skrev Samuel Colvin følgende:
>>
>> Fundamentally I don't think it matters which mathematical operator we 
>> use for an operation that's not strictly mathematical (or at least most 
>> users don't think of as mathematical), everyone is quite happy with "x = 
>> 4" 
>> not having it's rigorous meaning of "x == 4". As long as there's a 
>> compact 
>> and clear way of doing string concatenation I'm happy. 
>>
>> If most people want * that's fine especially as there would need to 
>> be a very good reason to change it now.
>>
>> The point is that we should make it as easy as possible for people to 
>> transition to Julia from other languages, and this is one potential 
>> stumbling block.
>>
>> I agree with Tobias's suggestion of a REPL, IJulia only +(s1::String, 
>> s2::String) that throws an informative error.
>>
>> For my part I've updated Julia By Example 
>>  to give an 
>> example and a link to this discussion.
>>
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[Samuel Colvin]

Larger scope makes a lot of sense.

Please give a link to the issue here once it's created.

On Thursday, 3 July 2014 15:17:22 UTC+1, Tobias Knopp wrote:
>
> Great, thanks!
>
> Am Donnerstag, 3. Juli 2014 16:10:08 UTC+2 schrieb Ivar Nesje:
>>
>> I don't think so. I'll open one.
>>
>> kl. 16:06:42 UTC+2 torsdag 3. juli 2014 skrev Tobias Knopp følgende:
>>>
>>> Ivar, I absolutely agree with you. This should be handled in a larger 
>>> scope. Do we have an issue for this yet?
>>>
>>> Am Donnerstag, 3. Juli 2014 15:42:09 UTC+2 schrieb Ivar Nesje:

 I would strongly argue against

 +(a::String, b::String) == Error("Use * for string concatenation")

 We have plenty of cases where we want to give a more helpful 
 `MethodError`. We should really create a simple system where you can get 
 those hints printed in the REPL, without defining more methods.

 The display of MethodError is defined in 
 https://github.com/JuliaLang/julia/blob/0df386db18dd186c7b0bffc74149fc6b0e51c67d/base/replutil.jl#L110
  
 and it would be easy to have a lookup table at the end of that function to 
 see if one of the "banned" methods (with usefull, more concistent 
 alternaltives) were called.

 Ivar

 kl. 15:11:43 UTC+2 torsdag 3. juli 2014 skrev Samuel Colvin følgende:
>
> Fundamentally I don't think it matters which mathematical operator we 
> use for an operation that's not strictly mathematical (or at least most 
> users don't think of as mathematical), everyone is quite happy with "x = 
> 4" 
> not having it's rigorous meaning of "x == 4". As long as there's a 
> compact 
> and clear way of doing string concatenation I'm happy. 
>
> If most people want * that's fine especially as there would need to be 
> a very good reason to change it now.
>
> The point is that we should make it as easy as possible for people to 
> transition to Julia from other languages, and this is one potential 
> stumbling block.
>
> I agree with Tobias's suggestion of a REPL, IJulia only +(s1::String, 
> s2::String) that throws an informative error.
>
> For my part I've updated Julia By Example 
>  to give an 
> example and a link to this discussion.
>

Re: [julia-users] Re: Decreasing range, should it work?

[John Myles White]

Sadly, R does not. 1:0 expands to c(1, 0). This is something that has burned a 
lot of people in my experience. I imagine this is inherited from S.

 — John

On Jul 3, 2014, at 2:05 AM, Tobias Knopp  wrote:

> Just as a side note (I entirely agree with Stefan), Matlab behaves the same 
> as Julia:
> 
> >> 3:1
> 
> ans =
> 
>Empty matrix: 1-by-0
> 
> 
> Am Donnerstag, 3. Juli 2014 03:38:32 UTC+2 schrieb Stefan Karpinski:
> It changes the meaning of a:b in a capricious way based on their values, 
> which, while often appealing for the immediate situation – and thus rampant 
> in dynamic languages – is almost always terrible for writing predictable, 
> reliable code.
> 
> 
> On Wed, Jul 2, 2014 at 1:07 PM, Jay Kickliter  wrote:
> I assume that when I wake up at 5 AM to finish some DSP code. Really, it was 
> just a stupid mistake. From a non-programmer's perspective (me), it seemed 
> like it should have work. If you think that would be dangerous, I'll take 
> your word for it.
> 
> 
> On Wednesday, July 2, 2014 8:26:10 AM UTC-6, Stefan Karpinski wrote:
> Why would one assume that the default step size is -1 when the start is 
> bigger than the stop? The documentation for ranges clearly says that the 
> default step size is 1 unconditionally, not that it is sign(stop-start). That 
> would, by the way, be a very dangerous behavior. Perhaps a sidebar on the 
> colon syntax is warranted in the manual control flow section on for loops, 
> including examples of empty ranges and ranges that count downwards.
> 
> 
> On Wed, Jul 2, 2014 at 9:53 AM, Jay Kickliter  wrote:
> I just realized that it works if I rewrite the range as 10:-1:1. It seems to 
> me that either big:small should work with a default step size of -1, or the 
> documentation needs a note. 
> 
> 
> On Wednesday, July 2, 2014 7:32:10 AM UTC-6, Jay Kickliter wrote:
> Are they meant to work? I could only find one meaning of them not working 
> (issue 5778).
> 
> Here's an example:
> 
> julia> for i = 1:10
>println(i)
>end
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> 10
> 
> julia> for i = 10:1
>println(i)
>end
> 
> julia> 
> 
> 

Re: [julia-users] Re: Why is string concatenation done with * not +

[Tobias Knopp]

Great, thanks!

Am Donnerstag, 3. Juli 2014 16:10:08 UTC+2 schrieb Ivar Nesje:
>
> I don't think so. I'll open one.
>
> kl. 16:06:42 UTC+2 torsdag 3. juli 2014 skrev Tobias Knopp følgende:
>>
>> Ivar, I absolutely agree with you. This should be handled in a larger 
>> scope. Do we have an issue for this yet?
>>
>> Am Donnerstag, 3. Juli 2014 15:42:09 UTC+2 schrieb Ivar Nesje:
>>>
>>> I would strongly argue against
>>>
>>> +(a::String, b::String) == Error("Use * for string concatenation")
>>>
>>> We have plenty of cases where we want to give a more helpful 
>>> `MethodError`. We should really create a simple system where you can get 
>>> those hints printed in the REPL, without defining more methods.
>>>
>>> The display of MethodError is defined in 
>>> https://github.com/JuliaLang/julia/blob/0df386db18dd186c7b0bffc74149fc6b0e51c67d/base/replutil.jl#L110
>>>  
>>> and it would be easy to have a lookup table at the end of that function to 
>>> see if one of the "banned" methods (with usefull, more concistent 
>>> alternaltives) were called.
>>>
>>> Ivar
>>>
>>> kl. 15:11:43 UTC+2 torsdag 3. juli 2014 skrev Samuel Colvin følgende:

 Fundamentally I don't think it matters which mathematical operator we 
 use for an operation that's not strictly mathematical (or at least most 
 users don't think of as mathematical), everyone is quite happy with "x = 
 4" 
 not having it's rigorous meaning of "x == 4". As long as there's a compact 
 and clear way of doing string concatenation I'm happy. 

 If most people want * that's fine especially as there would need to be 
 a very good reason to change it now.

 The point is that we should make it as easy as possible for people to 
 transition to Julia from other languages, and this is one potential 
 stumbling block.

 I agree with Tobias's suggestion of a REPL, IJulia only +(s1::String, 
 s2::String) that throws an informative error.

 For my part I've updated Julia By Example 
  to give an 
 example and a link to this discussion.

>>>

Re: [julia-users] Re: Why is string concatenation done with * not +

[Ivar Nesje]

I don't think so. I'll open one.

kl. 16:06:42 UTC+2 torsdag 3. juli 2014 skrev Tobias Knopp følgende:
>
> Ivar, I absolutely agree with you. This should be handled in a larger 
> scope. Do we have an issue for this yet?
>
> Am Donnerstag, 3. Juli 2014 15:42:09 UTC+2 schrieb Ivar Nesje:
>>
>> I would strongly argue against
>>
>> +(a::String, b::String) == Error("Use * for string concatenation")
>>
>> We have plenty of cases where we want to give a more helpful 
>> `MethodError`. We should really create a simple system where you can get 
>> those hints printed in the REPL, without defining more methods.
>>
>> The display of MethodError is defined in 
>> https://github.com/JuliaLang/julia/blob/0df386db18dd186c7b0bffc74149fc6b0e51c67d/base/replutil.jl#L110
>>  
>> and it would be easy to have a lookup table at the end of that function to 
>> see if one of the "banned" methods (with usefull, more concistent 
>> alternaltives) were called.
>>
>> Ivar
>>
>> kl. 15:11:43 UTC+2 torsdag 3. juli 2014 skrev Samuel Colvin følgende:
>>>
>>> Fundamentally I don't think it matters which mathematical operator we 
>>> use for an operation that's not strictly mathematical (or at least most 
>>> users don't think of as mathematical), everyone is quite happy with "x = 4" 
>>> not having it's rigorous meaning of "x == 4". As long as there's a compact 
>>> and clear way of doing string concatenation I'm happy. 
>>>
>>> If most people want * that's fine especially as there would need to be a 
>>> very good reason to change it now.
>>>
>>> The point is that we should make it as easy as possible for people to 
>>> transition to Julia from other languages, and this is one potential 
>>> stumbling block.
>>>
>>> I agree with Tobias's suggestion of a REPL, IJulia only +(s1::String, 
>>> s2::String) that throws an informative error.
>>>
>>> For my part I've updated Julia By Example 
>>>  to give an 
>>> example and a link to this discussion.
>>>
>>

Re: [julia-users] Re: Why is string concatenation done with * not +

[Tobias Knopp]

Ivar, I absolutely agree with you. This should be handled in a larger 
scope. Do we have an issue for this yet?

Am Donnerstag, 3. Juli 2014 15:42:09 UTC+2 schrieb Ivar Nesje:
>
> I would strongly argue against
>
> +(a::String, b::String) == Error("Use * for string concatenation")
>
> We have plenty of cases where we want to give a more helpful 
> `MethodError`. We should really create a simple system where you can get 
> those hints printed in the REPL, without defining more methods.
>
> The display of MethodError is defined in 
> https://github.com/JuliaLang/julia/blob/0df386db18dd186c7b0bffc74149fc6b0e51c67d/base/replutil.jl#L110
>  
> and it would be easy to have a lookup table at the end of that function to 
> see if one of the "banned" methods (with usefull, more concistent 
> alternaltives) were called.
>
> Ivar
>
> kl. 15:11:43 UTC+2 torsdag 3. juli 2014 skrev Samuel Colvin følgende:
>>
>> Fundamentally I don't think it matters which mathematical operator we use 
>> for an operation that's not strictly mathematical (or at least most users 
>> don't think of as mathematical), everyone is quite happy with "x = 4" not 
>> having it's rigorous meaning of "x == 4". As long as there's a compact and 
>> clear way of doing string concatenation I'm happy. 
>>
>> If most people want * that's fine especially as there would need to be a 
>> very good reason to change it now.
>>
>> The point is that we should make it as easy as possible for people to 
>> transition to Julia from other languages, and this is one potential 
>> stumbling block.
>>
>> I agree with Tobias's suggestion of a REPL, IJulia only +(s1::String, 
>> s2::String) that throws an informative error.
>>
>> For my part I've updated Julia By Example 
>>  to give an 
>> example and a link to this discussion.
>>
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[Ivar Nesje]

I would strongly argue against

+(a::String, b::String) == Error("Use * for string concatenation")

We have plenty of cases where we want to give a more helpful `MethodError`. 
We should really create a simple system where you can get those hints 
printed in the REPL, without defining more methods.

The display of MethodError is defined 
in 
https://github.com/JuliaLang/julia/blob/0df386db18dd186c7b0bffc74149fc6b0e51c67d/base/replutil.jl#L110
 
and it would be easy to have a lookup table at the end of that function to 
see if one of the "banned" methods (with usefull, more concistent 
alternaltives) were called.

Ivar

kl. 15:11:43 UTC+2 torsdag 3. juli 2014 skrev Samuel Colvin følgende:
>
> Fundamentally I don't think it matters which mathematical operator we use 
> for an operation that's not strictly mathematical (or at least most users 
> don't think of as mathematical), everyone is quite happy with "x = 4" not 
> having it's rigorous meaning of "x == 4". As long as there's a compact and 
> clear way of doing string concatenation I'm happy. 
>
> If most people want * that's fine especially as there would need to be a 
> very good reason to change it now.
>
> The point is that we should make it as easy as possible for people to 
> transition to Julia from other languages, and this is one potential 
> stumbling block.
>
> I agree with Tobias's suggestion of a REPL, IJulia only +(s1::String, 
> s2::String) that throws an informative error.
>
> For my part I've updated Julia By Example 
>  to give an 
> example and a link to this discussion.
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[Eric Davies]

I think the '+' is not as prevalent as you might think. 

MATLAB: ['foo' 'bar']
R: paste('foo', 'bar', sep="")
Python/C++/Ruby: "foo" + "bar"
Perl/PHP: "foo" . "bar"
C: strcat(bufcontainingfoo, "bar")
Mathematica: "foo" <> "bar"

People coming from MATLAB and R (probably a very large portion of those 
trying Julia) are already used to something else. There may be a lot of 
Python programmers as well, but Julia isn't trying to target Python users 
specifically.

I think having a +(String, String) defined with a helpful error would be a 
good idea, and I don't think it needs to be confined to the REPL (unless 
something in the language depends on seeing method missing errors).

On Thursday, 3 July 2014 08:11:43 UTC-5, Samuel Colvin wrote:
>
> Fundamentally I don't think it matters which mathematical operator we use 
> for an operation that's not strictly mathematical (or at least most users 
> don't think of as mathematical), everyone is quite happy with "x = 4" not 
> having it's rigorous meaning of "x == 4". As long as there's a compact and 
> clear way of doing string concatenation I'm happy. 
>
> If most people want * that's fine especially as there would need to be a 
> very good reason to change it now.
>
> The point is that we should make it as easy as possible for people to 
> transition to Julia from other languages, and this is one potential 
> stumbling block.
>
> I agree with Tobias's suggestion of a REPL, IJulia only +(s1::String, 
> s2::String) that throws an informative error.
>
> For my part I've updated Julia By Example 
>  to give an 
> example and a link to this discussion.
>

[julia-users] OS X dlopen() Problem

[Jay Kickliter]

I'm trying to open libipps.dylib in OS X. If I push the path to 
DL_LOAD_PATH, Julia can't find it. But if I cd() to that path, it loads it 
fine. The weird thing is that it can find libippcore.dylib just fine with 
without having to cd() to the libraries' location.

Here's what I tried:

julia> push!( DL_LOAD_PATH, "/opt/intel/ipp/lib" )
4-element Array{Union(ASCIIString,UTF8String),1}:
 "@executable_path/../lib/julia"
 "@executable_path/../lib"  
 "/opt/local/lib"   
 "/opt/intel/ipp/lib"   

julia> dlopen( "libipps" )
ERROR: could not load module libipps: dlopen(libipps.dylib, 1): image not 
found
 in dlopen at c.jl:19

julia> cd( "/opt/intel/ipp/lib" )

julia> dlopen( "libipps" )
Ptr{Void} @0x7fc5aad99330

Am I making a rookie mistake? I tried first loading the two other libraries 
that libipps depends on. I could't only get one of them to load 
(libippcore).

Re: [julia-users] Re: Why is string concatenation done with * not +

[Samuel Colvin]

Fundamentally I don't think it matters which mathematical operator we use 
for an operation that's not strictly mathematical (or at least most users 
don't think of as mathematical), everyone is quite happy with "x = 4" not 
having it's rigorous meaning of "x == 4". As long as there's a compact and 
clear way of doing string concatenation I'm happy. 

If most people want * that's fine especially as there would need to be a 
very good reason to change it now.

The point is that we should make it as easy as possible for people to 
transition to Julia from other languages, and this is one potential 
stumbling block.

I agree with Tobias's suggestion of a REPL, IJulia only +(s1::String, 
s2::String) that throws an informative error.

For my part I've updated Julia By Example 
 to give an example 
and a link to this discussion.

Re: [julia-users] How do I declare a baremodule in a macro?

[Eric Davies]

Thanks! I need to get used to creating/manipulating Expr objects. 

Do you know if there's a more in-depth Julia metaprogramming guide out 
there? The manual just scratches the surface.

On Wednesday, 2 July 2014 23:21:33 UTC-5, Jameson wrote:
>
> macro modcreate(name)
> Expr(:module, false, esc(name::Symbol), Expr(:begin))
> end
>
>
> On Thu, Jul 3, 2014 at 12:00 AM, Eric Davies  > wrote:
>
>> Hi all,
>>
>> I'm working on a multipass configuration file package and I'm having 
>> difficulty executing my ideas (I'm not great at the metaprogramming stuff 
>> yet). I want to create a baremodule in a macro and have it available to the 
>> scope containing the macro. I want to be able to pass the name of the 
>> baremodule as an argument to the macro. Unfortunately, every (probably 
>> terrible) strategy I try seems to give the error "name not defined" (where 
>> name is the argument to the macro containing the desired module name).
>>
>> I want it to work like this (toy example):
>>
>> julia> @modcreate foo
>>
>> julia> typeof(foo)
>> Module
>>
>> Can anyone suggest possible contents for the macro that might produce the 
>> above behaviour?
>>
>> Thanks,
>> Eric
>>
>
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[Patrick O'Leary]

On Thursday, July 3, 2014 6:59:54 AM UTC-5, Francesco Bonazzi wrote:
>
> On Wednesday, July 2, 2014 9:48:26 PM UTC+2, John Myles White wrote:
>>
>> String concatenation is not commutative. Addition is generally used for 
>> commutative operations. So if you're a mathematician, using addition for 
>> string concatentation seems very wrong.
>>
>
> In Wolfram Mathematica there is a multiplication operator for scalars 
> (i.e. * or space), commutative, and a multiplication operator for matrices 
> (i.e. "."), non-commutative. In any case, Mathematica does not allow to 
> define custom types, maybe that's the reason they decided to have distinct 
> operators. In contrast, the commutativity of product arguments may be 
> determined by their types in Julia.
>

Julia, following MATLAB, also has distinct operators: `*` and `.*`. The 
first implements matrix multiplication, and the second scalar/elementwise. 
Of course, when there is only one element--scalar arguments--these 
operations do the same thing. 

Re: [julia-users] Re: Why is string concatenation done with * not +

[Francesco Bonazzi]

On Wednesday, July 2, 2014 9:48:26 PM UTC+2, John Myles White wrote:
>
> String concatenation is not commutative. Addition is generally used for 
> commutative operations. So if you're a mathematician, using addition for 
> string concatentation seems very wrong.
>

In Wolfram Mathematica there is a multiplication operator for scalars (i.e. 
* or space), commutative, and a multiplication operator for matrices (i.e. 
"."), non-commutative. In any case, Mathematica does not allow to define 
custom types, maybe that's the reason they decided to have distinct 
operators. In contrast, the commutativity of product arguments may be 
determined by their types in Julia. 

[julia-users] Added Bhattacharyya and Hellinger distances to Distance.jl

[Robert Feldt]

Hi,

I added Bhattacharyya and Hellinger distances to Distance.jl and submitted 
a pull request:

https://github.com/JuliaStats/Distance.jl/pull/23

but if someone is eager it is available in my fork:

https://github.com/robertfeldt/Distance.jl

These distances between probability distributions are quite useful, for 
more info see:

http://en.wikipedia.org/wiki/Bhattacharyya_distance

I hope someone finds them useful,

Robert Feldt

Re: [julia-users] Re: Why is string concatenation done with * not +

[Tobias Knopp]

I am absolutely ok that string concatenation is done with *
One just as to get used to it. The issue seems that some popular languages 
use + instead.

I kind of like Samuels suggestion to give better error messages but this 
would essentially mean to implement + and throw an error.
This would be not so nice because + would be listed as a valid method for 
strings what it actually is not. Not sure how to handle this.
Maybe one could have some error throwing methods that are only there at the 
REPL?

Am Donnerstag, 3. Juli 2014 12:26:37 UTC+2 schrieb Stefan Schwarz:
>
> @John. Never agreed more. Perfect reasoning. 
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[Stefan Schwarz]

@John. Never agreed more. Perfect reasoning. 

[julia-users] Re: Gaussian filtering

[Tobias Knopp]

Images.jl

imfilter_gaussian(My2DArray,[3,3])

Am Donnerstag, 3. Juli 2014 11:33:27 UTC+2 schrieb Andrei Berceanu:
>
> In what package could I find a function like Mathematica's 
> `GaussianFilter` (
> http://reference.wolfram.com/mathematica/ref/GaussianFilter.html)?
> I am particularly interested in the method which accepts a 2D Array as 
> input (with values representing intensities) and returns the filtered array 
> as output.
>

[julia-users] Gaussian filtering

[Andrei Berceanu]

In what package could I find a function like Mathematica's `GaussianFilter` 
(http://reference.wolfram.com/mathematica/ref/GaussianFilter.html)?
I am particularly interested in the method which accepts a 2D Array as 
input (with values representing intensities) and returns the filtered array 
as output.

Re: [julia-users] Re: Decreasing range, should it work?

[Tobias Knopp]

Just as a side note (I entirely agree with Stefan), Matlab behaves the same 
as Julia:

>> 3:1

ans =

   Empty matrix: 1-by-0


Am Donnerstag, 3. Juli 2014 03:38:32 UTC+2 schrieb Stefan Karpinski:
>
> It changes the meaning of a:b in a capricious way based on their values, 
> which, while often appealing for the immediate situation – and thus rampant 
> in dynamic languages – is almost always terrible for writing predictable, 
> reliable code. 
>
>
> On Wed, Jul 2, 2014 at 1:07 PM, Jay Kickliter  > wrote:
>
>> I assume that when I wake up at 5 AM to finish some DSP code. Really, it 
>> was just a stupid mistake. From a non-programmer's perspective (me), it 
>> seemed like it should have work. If you think that would be dangerous, I'll 
>> take your word for it.
>>
>>
>> On Wednesday, July 2, 2014 8:26:10 AM UTC-6, Stefan Karpinski wrote:
>>
>>> Why would one assume that the default step size is -1 when the start is 
>>> bigger than the stop? The documentation for ranges clearly says that the 
>>> default step size is 1 unconditionally, not that it is sign(stop-start). 
>>> That would, by the way, be a very dangerous behavior. Perhaps a sidebar on 
>>> the colon syntax is warranted in the manual control flow section on for 
>>> loops, including examples of empty ranges and ranges that count downwards.
>>>
>>>
>>> On Wed, Jul 2, 2014 at 9:53 AM, Jay Kickliter  
>>> wrote:
>>>
 I just realized that it works if I rewrite the range as 10:-1:1. It 
 seems to me that either big:small should work with a default step size of 
 -1, or the documentation needs a note. 


 On Wednesday, July 2, 2014 7:32:10 AM UTC-6, Jay Kickliter wrote:
>
> Are they meant to work? I could only find one meaning of them not 
> working (issue 5778 ).
>
> Here's an example:
>
> julia> for i = 1:10
>
>println(i)
>
>end
>
> 1
>
> 2
>
> 3
>
> 4
>
> 5
>
> 6
>
> 7
>
> 8
>
> 9
>
> 10
>
>
> julia> for i = 10:1
>
>println(i)
>
>end
>
>
> julia> 
>

>>>
>

Re: [julia-users] Re: more questions about sorted associative array

[Mauro]

Hi Steve,

> Thanks for the responses!  I will look into using the 'state' for the 
> iterator that can be later dereferenced.  Indeed, one has to be careful 
> that the iterator could point to a data item that has been changed or 
> deleted.  In C++, for each container operation there is a specification of 
> whether iterators are invalidated by the operation.

In Julia the convention is that there is no guarantee that it's safe to
change the collection whilst you're iterating over it (Python does the same, I
think).

Then, from the rest of your email, I'm not sure whether you are aware
that the user will almost never call start, next and done.  For example
to iterate over the keys of an ordinary dictionary:

for k in keys(mydict)
... 
end

Or here an example on making a new array iterator:

import Base:start, next, done

immutable EvenIt
ar::Vector
end
# (state needn't be the index)
start(ri::EvenIt) = 1
next(ri::EvenIt, state) = (ri.ar[2*state], state+1)
done(ri::EvenIt, state) = 2*state>length(ri.ar)
# convenience user-function
eveniter(ar::Vector) = EvenIt(ar)

# user usage:
for e in eveniter(ar)
println(e)
end


> As for multiple ways to index, the example I have in mind is as follows: if 
> m is the associative map, (k,v) is a key-value pair, and i is an iterator 
> (the pointer kind, like in C++) to (k,v), then m[k] should return v, while 
> m[i] should return (k,v).  But I am asking the forum whether a distinctive 
> syntax is available for the second variant.

So, I'm not sure the need for a second way of indexing for what you want
to do here.  (However, it could be a neat thing to do at times.  For
your use case it may be nice to use the normal `m[key]` as well as
`m` to get item at index i.  The other case which comes to mind are
Fortran co-arrays, where one index is a normal array index and the other
indexes the processor on which the array is located.)

> Finally, with regard to the third issue, perhaps I didn't express my 
> question well.  Suppose someone uses my 2-3 trees and has a statement in 
> his/her code such as 
>   i = next(m,i)
> where m is the map and i is an iterator (of the pointer kind).  This 
> statement is supposed to advance to the next item according to the 
> sort-order of keys.  My routine that gets invoked is as follows:
>
> function nextloc{K,D}(t::BalancedTree{K,D}, i::Int)
> if i == 2
> error("Attempt to advance past end of balanced tree")
> end
> ii = i
> p = t.data[i].parent
> while true
> newp, newii = nextloc0(t, p, ii)
> if newii == 2 || t.data[newii].parent > 0
> return newii
> end
> p, ii = newp, newii
> end
> end
>
> Now, suppose instead the user writes:
>
> @inbounds i = next(m,i)
>
> Then I would want a different (faster, less safe) version of 'nextloc' 
> invoked.  In the different version, the preliminary safety-test whether 
> i==2 is omitted, and the array subscript operations within my code are all 
> prefixed by @inbounds.  So my question to the forum is whether my tree code 
> can detect whether the user has put an @inbounds declaration in his/her 
> code when it invokes my routines.

The `done` function should make sure that `next` is never called with a
`state` out of bounds (see my example above).  In fact, this is the sole
purpose of `done`.  So, no need for checking in next.

> Thanks,
> Steve
>
>
> P.S. If you want to look at my code, please 
> see: https://www.dropbox.com/s/021yc196j55d5yd/baltree.jl[1]  This code is 
> very preliminary and has not even been executed, except for insert and 
> next.  (See the test routine test2(), which seems to work.)  The 'delete' 
> code is currently a hack, and I need to write a proper delete code that 
> shrinks the tree.

Having had a very brief look at your code.  I think the
iterator-helper-type usually just wraps the thing it wants to iterate as
I did in above example.  The `state` variable is then what you have as
`address` in your MapIterator.