[julia-users] Re: Parse file with a certain extension

[Avik Sengupta]

Does this file contain valid Julia statements? In which case just `include` 
the file. 

Say you have a file called config.txt in the current director with the 
following text:

a=1

Then, on the REPL

julia include(config.txt)
1

julia a
1


If the statements are not valid Julia, then you'll have to implement your 
own parser. You can read the contents of the file into a string use 
`readall` 

julia x=readall(config.txt)
a=1\n


On Monday, 18 August 2014 06:33:37 UTC+1, Peter wrote:

  Suppose there is in Matlab a library that can read files with a certain 
 extension, say .xyz, and instruct Matlab what to do. The file would contain 
 instructions about dynamic systems with a certain number of variables, 
 shocks and so on. 

  Can I do the same thing in Julia and how?

  For example,

  Let's say I want to declare in a file with extension xyz a dynamic system 
 with 2 equations:
  x = x(-1) + y^2;
  y = y(-1);

  Thank you!
  

Re: [julia-users] What's wrong? A simple condition is not working. [L. == 1] ERROR: BoundsError() in getindex_bool_1d at array.jl:285

[Paul Analyst]

 Thx Tim:) I have !
julia A=read(dset)[:,1:2]
5x2 sparse matrix with 0 Int64 entries:

julia fid = jldopen(S.jld,r)
Julia data file version 0.0.2: S.jld

julia dset=fid[S]
JldDataset(HDF5 dataset: /S (file: S.jld),Julia data file version 0.0.2: 
S.jld)


julia A=read(dset)[1:3,:]
3x18 sparse matrix with 2 Int64 entries:
[1 ,  4]  =  1
[3 , 18]  =  -5

julia full(A)
3x18 Array{Int64,2}:
 0  0  0  1  0  0  0  0  0  0  0  0  0  0  0  0  0   0
 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0   0
 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  -5

julia full(S)
ERROR: S not defined

julia full(read(dset))
5x18 Array{Int64,2}:
 0  0  0  1  0  0  0  0  0  0  0  0  0  0  0  0  0   0
 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0   0
 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  -5
 0  0  0  0  0  0  2  0  0  0  0  0  0  0  0  0  0   0
 0  0  0  0  0  0  0  0  3  0  0  0  0  0  0  0  0   0

julia
Paul

W dniu 2014-08-17 20:25, paul analyst pisze:

Big thx, it work !
Paul

W dniu środa, 13 sierpnia 2014 13:42:09 UTC+2 użytkownik Andreas Noack 
napisał:


This one is a bit tricky. The reason is that L is a Matrix and
F[:,1] is a vector. Try F[:,1][vec(L.==0)]

Med venlig hilsen

Andreas Noack


2014-08-13 7:06 GMT-04:00 paul analyst paul.a...@mail.com
javascript::

F is dense
julia size(F)
(6237437,284)

julia size(L)
(6237437,1)

julia F[:,1][L.==0]
ERROR: BoundsError()
 in getindex_bool_1d at array.jl:285

julia L
6237437x1 sparse matrix with 20869 Int16 entries:
[66 ,   1]  =  1
[104,   1]  =  0

Paul

[julia-users] Re: Incorrect type conversion for ImmutableArrays

[Jan Kybic]

On Friday, August 15, 2014 12:13:42 PM UTC+2, Tobias Knopp wrote:

 This is a bug but I am not sure on which side. The convert function is 
 wrong because it does not create the type that is passed. But maybe Julia 
 should not create the immutable type when seeing this.

 Could you please file a bug on the ImmutableArrays.jl project page? I will 
 file one on the Julia bug tracker.



I have just reported the issue in ImmutableArrays.jl: 
https://github.com/twadleigh/ImmutableArrays.jl/issues/35 

Jan

[julia-users] Re: Incorrect type conversion for ImmutableArrays

[Tobias Knopp]

Thanks Jan,

as you may have seen, Jeff agrees that this is a bug in Julia as well. So 
you have found two bugs for one test case. Very helpful.

Cheers,

Tobi

Am Montag, 18. August 2014 11:12:05 UTC+2 schrieb Jan Kybic:



 On Friday, August 15, 2014 12:13:42 PM UTC+2, Tobias Knopp wrote:

 This is a bug but I am not sure on which side. The convert function is 
 wrong because it does not create the type that is passed. But maybe Julia 
 should not create the immutable type when seeing this.

 Could you please file a bug on the ImmutableArrays.jl project page? I 
 will file one on the Julia bug tracker.



 I have just reported the issue in ImmutableArrays.jl: 
 https://github.com/twadleigh/ImmutableArrays.jl/issues/35 

 Jan

[julia-users] Re: Simple parallel for loop example

[Joachim Dahl]

I came across this post wondering about the same.  After reading the 
current documentation it is not clear to me whether parallelizing such a 
loop using shared memory is easily achieved in Julia 0.3,  or if the same 
difficulty remains. 

Den torsdag den 7. november 2013 05.08.38 UTC+1 skrev Lars Ruthotto:

 I am relatively new to Julia and doing some simple experiments. So far, I 
 am very impressed by it's nice and intuitive syntax and performance. Good 
 job!

 However, I have a simple question regarding parallel for loops the manual 
 could not answer for me. Say I am interested in parallelizing this code

 a = zeros(10)
 for i=1:10
   a[i] = i
 end

 In the manual it is said (and I verified) that 

 a = zeros(10)
 @parallel for i=1:10
   a[i] = i
 end

 does not give the correct result. Unfortunately it does not say (or I 
 couldn't find it) how this can be done in Julia? Does anyone have an idea?

 Thanks!
 Lars

[julia-users] unwanted behaviour in logical indexing

[Davide Lasagna]

Hi all, 

Is this a bug or a feature?

julia idx = [1:10]
10-element Array{Int64,1}:
  1
  2
  3
  4
  5
  6
  7
  8
  9
 10

julia idx .!= 2  idx .!= 8
10-element BitArray{1}:
  true
 false
  true
  true
  true
  true
  true
  true
  true
  true

which appears wrong to me. However, by wrapping the two conditions by 
parenthesis:

julia (idx .!= 2)  (idx .!= 8)
10-element BitArray{1}:
  true
 false
  true
  true
  true
  true
  true
 false
  true
  true

which is the expected result. I would expect the two cases to give the same 
result, or at least, for the first one, to emit a sort of warning.

Davide

[julia-users] Capitalization of package names

[TR NS]

Is the capitalization of package names a standard convention we can count 
on?

[julia-users] Re: unwanted behaviour in logical indexing

[Johan Sigfrids]

Maybe you are running into #5187 
https://github.com/JuliaLang/julia/issues/5187?

On Monday, August 18, 2014 3:11:44 PM UTC+3, Davide Lasagna wrote:

 Hi all, 

 Is this a bug or a feature?

 julia idx = [1:10]
 10-element Array{Int64,1}:
   1
   2
   3
   4
   5
   6
   7
   8
   9
  10

 julia idx .!= 2  idx .!= 8
 10-element BitArray{1}:
   true
  false
   true
   true
   true
   true
   true
   true
   true
   true

 which appears wrong to me. However, by wrapping the two conditions by 
 parenthesis:

 julia (idx .!= 2)  (idx .!= 8)
 10-element BitArray{1}:
   true
  false
   true
   true
   true
   true
   true
  false
   true
   true

 which is the expected result. I would expect the two cases to give the 
 same result, or at least, for the first one, to emit a sort of warning.

 Davide

[julia-users] Re: Capitalization of package names

[Iain Dunning]

Yes, it is the Julia convention.
There is only one (registered) exception, which is prehistoric in Julia 
terms (kNN.jl)

On Monday, August 18, 2014 8:32:40 AM UTC-4, TR NS wrote:

 Is the capitalization of package names a standard convention we can count 
 on?

Re: [julia-users] Capitalization of package names

[Stefan Karpinski]

It is a convention, but it isn't required anywhere or guaranteed. You can
currently count on package names being ASCII.


On Mon, Aug 18, 2014 at 8:32 AM, TR NS transf...@gmail.com wrote:

 Is the capitalization of package names a standard convention we can count
 on?

Re: [julia-users] Vectorised boolean access to array elements

[David Higgins]

Thanks guys. I didn't think of using the dot.

David.

On Friday, 15 August 2014 18:53:43 UTC+2, Patrick O'Leary wrote:

 Because that might be subtle to see if you're not looking closely, and you 
 mentioned a MATLAB background, note that there is an additional dot before 
 the comparison operator--Julia uses the elementwise operator notation for 
 comparison operators as well as for elementwise multiplication and 
 division. Unlike their primitive arithmetical counterparts, though, that 
 notation is mandatory for comparison operators even when one argument is 
 scalar.

 On Friday, August 15, 2014 9:01:57 AM UTC-5, John Myles White wrote:

 a . 5 


 On Aug 15, 2014, at 3:53 AM, David Higgins daithio...@gmail.com 
 javascript: wrote: 

  Hi, 
  
  Is there a mechanism for vectorised logical access to array elements in 
 Julia? I basically mean, is there an equivalent to the Matlab notation 
  a[a5] 
  which should give all of the elements of a[] which have value less than 
 5. 
  
  I guess the feature I've not found is the ability to create the boolean 
 index vector 'a5'. I'm doing it with loops at present. 
  
  Thanks, 
  David. 
  

Re: [julia-users] Re: Capitalization of package names

[John Myles White]

I can probably register KNN.jl and deprecate kNN.jl.

 — John

On Aug 18, 2014, at 5:45 AM, Iain Dunning iaindunn...@gmail.com wrote:

 Yes, it is the Julia convention.
 There is only one (registered) exception, which is prehistoric in Julia terms 
 (kNN.jl)
 
 On Monday, August 18, 2014 8:32:40 AM UTC-4, TR NS wrote:
 Is the capitalization of package names a standard convention we can count on?

Re: [julia-users] Re: Capitalization of package names

[Stefan Karpinski]

This is not a good idea – it will cause endless problems on case-insensitive 
file systems like HFS+ on Macs.

 On Aug 18, 2014, at 10:08 AM, John Myles White johnmyleswh...@gmail.com 
 wrote:
 
 I can probably register KNN.jl and deprecate kNN.jl.
 
  — John
 
 On Aug 18, 2014, at 5:45 AM, Iain Dunning iaindunn...@gmail.com wrote:
 
 Yes, it is the Julia convention.
 There is only one (registered) exception, which is prehistoric in Julia 
 terms (kNN.jl)
 
 On Monday, August 18, 2014 8:32:40 AM UTC-4, TR NS wrote:
 Is the capitalization of package names a standard convention we can count 
 on?
 

Re: [julia-users] Re: Capitalization of package names

[John Myles White]

Good point. I guess we’ll have to watch until we put kNN.jl inside of another 
package before we can get rid of it.

 — John

On Aug 18, 2014, at 7:18 AM, Stefan Karpinski stefan.karpin...@gmail.com 
wrote:

 This is not a good idea – it will cause endless problems on case-insensitive 
 file systems like HFS+ on Macs.
 
 On Aug 18, 2014, at 10:08 AM, John Myles White johnmyleswh...@gmail.com 
 wrote:
 
 I can probably register KNN.jl and deprecate kNN.jl.
 
  — John
 
 On Aug 18, 2014, at 5:45 AM, Iain Dunning iaindunn...@gmail.com wrote:
 
 Yes, it is the Julia convention.
 There is only one (registered) exception, which is prehistoric in Julia 
 terms (kNN.jl)
 
 On Monday, August 18, 2014 8:32:40 AM UTC-4, TR NS wrote:
 Is the capitalization of package names a standard convention we can count 
 on?
 

Re: [julia-users] Re: Capitalization of package names

[Stefan Karpinski]

Yes, I think it's totally fine until it can be merged into another package.
The capitalization thing is a convention, not a rule. It's almost good to
have at least one package around that violates the convention so that we
can't assume that all packages start with an uppercase letter.


On Mon, Aug 18, 2014 at 10:21 AM, John Myles White johnmyleswh...@gmail.com
 wrote:

 Good point. I guess we’ll have to watch until we put kNN.jl inside of
 another package before we can get rid of it.

  — John

 On Aug 18, 2014, at 7:18 AM, Stefan Karpinski stefan.karpin...@gmail.com
 wrote:

 This is not a good idea – it will cause endless problems on
 case-insensitive file systems like HFS+ on Macs.

 On Aug 18, 2014, at 10:08 AM, John Myles White johnmyleswh...@gmail.com
 wrote:

 I can probably register KNN.jl and deprecate kNN.jl.

  — John

 On Aug 18, 2014, at 5:45 AM, Iain Dunning iaindunn...@gmail.com wrote:

 Yes, it is the Julia convention.
 There is only one (registered) exception, which is prehistoric in Julia
 terms (kNN.jl)

 On Monday, August 18, 2014 8:32:40 AM UTC-4, TR NS wrote:

 Is the capitalization of package names a standard convention we can count
 on?

[julia-users] Simple Integer DataFrame Automatic Conversion to Float (InexactError())

[Bradley Setzler]

Good morning,

I am looking for a simple way to convert an Integer DataFrame to a Float 
DataFrame. Here is an example of the problem:

julia using DataFrames
julia A=DataFrame([1 2; 3 4])
2x2 DataFrame:
x1 x2
[1,] 1 2
[2,] 3 4

With multiplication, there is no problem automatically converting to Float:

julia A*.5
2x2 DataFrame:
x1 x2
[1,] 0.5 1.0
[2,] 1.5 2.0

But with division, for example, the conversion fails:

julia A/2
InexactError()

Ideally, there would be a one-line command so that we don't have to worry 
about this issue, say DataFloat() of the form:

julia A=DataFloat(A)
2x2 DataFrame:
x1 x2
[1,] 1.0 2.0
[2,] 3.0 4.0

Does something like this exist?

Thanks,
Bradley

[julia-users] Backtrace doesn't show details of modules

[Martin Klein]

Hi,

I have the following problem, which makes debugging of my self-written 
module quite difficult. When an exception is thrown inside my module, the 
backtrace won't include the position of the error inside my module, but 
only the position where I call the function in my module. The following 
simple example illustrates the problem:

module ErrorTest

export foo

function foo(x)
# trigger exception
println(y)
end

end #module


Then when I'm using this module in run.jl:

using ErrorTest

foo(5)


I get the following backtrace:
ERROR: y not defined
 in include at ./boot.jl:245
 in process_options at ./client.jl:285
 in _start at ./client.jl:354
 in _start at /usr/local/bin/..//lib/julia/sys.so
while loading /home/martin/test/run.jl, in expression starting on line 3

As you can see, the backtrace doesn't reach into the module ErrorTest, so I 
don't get any information in which part of ErrorTest the error occurs (i.e. 
line 6 in my example). For larger and complicated modules, this makes 
debugging nearly impossible, since I don't even get information in which 
function in my module the error occurs. I'm currently using v0.3-rc4. Is 
this a bug or intented behaviour? I couldn't find any bug report about 
this. If this is intended, what is your usual approach to obtain a detailed 
backtrace when an error occurs inside a module?

Thanks,
Martin

Re: [julia-users] Simple Integer DataFrame Automatic Conversion to Float (InexactError())

[John Myles White]

Hi Bradley,

Would you consider using DataArrays for this? DataFrames no longer support 
these operations, so any upgrade in your setup would turn all of this code into 
errors.

All of these operations work on DataArrays already.

 — John

On Aug 18, 2014, at 7:28 AM, Bradley Setzler bradley.setz...@gmail.com wrote:

 
 
 Good morning,
 
 I am looking for a simple way to convert an Integer DataFrame to a Float 
 DataFrame. Here is an example of the problem:
 
 julia using DataFrames
 julia A=DataFrame([1 2; 3 4])
 2x2 DataFrame:
 x1 x2
 [1,] 1 2
 [2,] 3 4
 
 With multiplication, there is no problem automatically converting to Float:
 
 julia A*.5
 2x2 DataFrame:
 x1 x2
 [1,] 0.5 1.0
 [2,] 1.5 2.0
 
 But with division, for example, the conversion fails:
 
 julia A/2
 InexactError()
 
 Ideally, there would be a one-line command so that we don't have to worry 
 about this issue, say DataFloat() of the form:
 
 julia A=DataFloat(A)
 2x2 DataFrame:
 x1 x2
 [1,] 1.0 2.0
 [2,] 3.0 4.0
 
 Does something like this exist?
 
 Thanks,
 Bradley
 

[julia-users] Re: Simple parallel for loop example

[Bradley Setzler]

I found that the easiest way was to use two files - one file contains the 
function to be run in parallel, the other file uses Require() to load the 
function in parallel, and pmap to call the function.

I have a working example of the two-file approach here:
http://juliaeconomics.com/2014/06/18/parallel-processing-in-julia-bootstrapping-the-mle/

Best,
Bradley





On Wednesday, November 6, 2013 10:08:38 PM UTC-6, Lars Ruthotto wrote:

 I am relatively new to Julia and doing some simple experiments. So far, I 
 am very impressed by it's nice and intuitive syntax and performance. Good 
 job!

 However, I have a simple question regarding parallel for loops the manual 
 could not answer for me. Say I am interested in parallelizing this code

 a = zeros(10)
 for i=1:10
   a[i] = i
 end

 In the manual it is said (and I verified) that 

 a = zeros(10)
 @parallel for i=1:10
   a[i] = i
 end

 does not give the correct result. Unfortunately it does not say (or I 
 couldn't find it) how this can be done in Julia? Does anyone have an idea?

 Thanks!
 Lars

Re: [julia-users] Simple Integer DataFrame Automatic Conversion to Float (InexactError())

[Bradley Setzler]

Hi John,

Thanks for your reply, I'm getting the following:

julia A=DataArray([1 2; 3 4])
2x2 DataArray{Int64,2}:
1 2
3 4
julia A*.5
2x2 DataArray{Float64,2}:
0.5 1.0
1.5 2.0

julia A/2.
2x2 DataArray{Float64,2}:
0.5 1.0
1.5 2.0
julia A/2
InexactError()


So it converts to Float if divided by Float, but does not convert if 
divided by Integer.

Best,
Bradley



On Monday, August 18, 2014 9:31:43 AM UTC-5, John Myles White wrote:

 Hi Bradley, 

 Would you consider using DataArrays for this? DataFrames no longer support 
 these operations, so any upgrade in your setup would turn all of this code 
 into errors. 

 All of these operations work on DataArrays already. 

  — John 

 On Aug 18, 2014, at 7:28 AM, Bradley Setzler bradley...@gmail.com 
 javascript: wrote: 

  
  
  Good morning, 
  
  I am looking for a simple way to convert an Integer DataFrame to a Float 
 DataFrame. Here is an example of the problem: 
  
  julia using DataFrames 
  julia A=DataFrame([1 2; 3 4]) 
  2x2 DataFrame: 
  x1 x2 
  [1,] 1 2 
  [2,] 3 4 
  
  With multiplication, there is no problem automatically converting to 
 Float: 
  
  julia A*.5 
  2x2 DataFrame: 
  x1 x2 
  [1,] 0.5 1.0 
  [2,] 1.5 2.0 
  
  But with division, for example, the conversion fails: 
  
  julia A/2 
  InexactError() 
  
  Ideally, there would be a one-line command so that we don't have to 
 worry about this issue, say DataFloat() of the form: 
  
  julia A=DataFloat(A) 
  2x2 DataFrame: 
  x1 x2 
  [1,] 1.0 2.0 
  [2,] 3.0 4.0 
  
  Does something like this exist? 
  
  Thanks, 
  Bradley 
  

Re: [julia-users] Simple Integer DataFrame Automatic Conversion to Float (InexactError())

[John Myles White]

What versions are you using? This was a bug, but I think it’s been fixed on 0.3 
for some time.

 — John

On Aug 18, 2014, at 8:02 AM, Bradley Setzler bradley.setz...@gmail.com wrote:

 Hi John,
 
 Thanks for your reply, I'm getting the following:
 
 julia A=DataArray([1 2; 3 4])
 2x2 DataArray{Int64,2}:
 1 2
 3 4
 julia A*.5
 2x2 DataArray{Float64,2}:
 0.5 1.0
 1.5 2.0
 julia A/2.
 2x2 DataArray{Float64,2}:
 0.5 1.0
 1.5 2.0
 julia A/2
 InexactError()
 
 So it converts to Float if divided by Float, but does not convert if divided 
 by Integer.
 
 Best,
 Bradley
 
 
 
 On Monday, August 18, 2014 9:31:43 AM UTC-5, John Myles White wrote:
 Hi Bradley, 
 
 Would you consider using DataArrays for this? DataFrames no longer support 
 these operations, so any upgrade in your setup would turn all of this code 
 into errors. 
 
 All of these operations work on DataArrays already. 
 
  — John 
 
 On Aug 18, 2014, at 7:28 AM, Bradley Setzler bradley...@gmail.com wrote: 
 
  
  
  Good morning, 
  
  I am looking for a simple way to convert an Integer DataFrame to a Float 
  DataFrame. Here is an example of the problem: 
  
  julia using DataFrames 
  julia A=DataFrame([1 2; 3 4]) 
  2x2 DataFrame: 
  x1 x2 
  [1,] 1 2 
  [2,] 3 4 
  
  With multiplication, there is no problem automatically converting to Float: 
  
  julia A*.5 
  2x2 DataFrame: 
  x1 x2 
  [1,] 0.5 1.0 
  [2,] 1.5 2.0 
  
  But with division, for example, the conversion fails: 
  
  julia A/2 
  InexactError() 
  
  Ideally, there would be a one-line command so that we don't have to worry 
  about this issue, say DataFloat() of the form: 
  
  julia A=DataFloat(A) 
  2x2 DataFrame: 
  x1 x2 
  [1,] 1.0 2.0 
  [2,] 3.0 4.0 
  
  Does something like this exist? 
  
  Thanks, 
  Bradley 
  
 

Re: [julia-users] Backtrace doesn't show details of modules

[Tim Holy]

This has been fixed in julia 0.3.

--Tim

On Monday, August 18, 2014 06:42:56 AM Martin Klein wrote:
 Hi,
 
 I have the following problem, which makes debugging of my self-written
 module quite difficult. When an exception is thrown inside my module, the
 backtrace won't include the position of the error inside my module, but
 only the position where I call the function in my module. The following
 simple example illustrates the problem:
 
 module ErrorTest
 
 export foo
 
 function foo(x)
 # trigger exception
 println(y)
 end
 
 end #module
 
 
 Then when I'm using this module in run.jl:
 
 using ErrorTest
 
 foo(5)
 
 
 I get the following backtrace:
 ERROR: y not defined
  in include at ./boot.jl:245
  in process_options at ./client.jl:285
  in _start at ./client.jl:354
  in _start at /usr/local/bin/..//lib/julia/sys.so
 while loading /home/martin/test/run.jl, in expression starting on line 3
 
 As you can see, the backtrace doesn't reach into the module ErrorTest, so I
 don't get any information in which part of ErrorTest the error occurs (i.e.
 line 6 in my example). For larger and complicated modules, this makes
 debugging nearly impossible, since I don't even get information in which
 function in my module the error occurs. I'm currently using v0.3-rc4. Is
 this a bug or intented behaviour? I couldn't find any bug report about
 this. If this is intended, what is your usual approach to obtain a detailed
 backtrace when an error occurs inside a module?
 
 Thanks,
 Martin

[julia-users] Suggestion: Start using Julia 0.3-RC4

[John Myles White]

One of the best things you can do for the Julia community is to start using the 
release candidates of 0.3. Everyone will be better off if bugs are found now 
rather than when 0.3 is released. You can help make 0.3 a better release by 
installing one of the latest binaries and testing it out.

This is especially important for projects like DataFrames, which have fewer 
developer hours to spare on issues related to 0.2.

 — John

Re: [julia-users] We have typed functions, don't we?

[Rafael Fourquet]

I'm glad to report that the general and beautifully functional solution sum(
imap(sinc_plus_x, x)) is in fact as efficient as the devectorized
hand-written one!

It turns out I made the mistake to forget to forward an expression like
{Type{F}} to the imap iterator constructor (cf. code below), making it
specialized on DataType instead of sinc_plus_x. (While I can see why this
prevented inlining, I still don't understand this caused allocations).

For the record, here is a possible implementation of imap for functors
with 1 argument:

immutable imap{TF, X}
F::TF
x::X
end
imap{F, X}(::Type{F}, x::X) = imap{Type{F}, X}(F, x)

Base.start(i::imap) = start(i.x)
Base.next(i::imap, s) = ((v, s) = next(i.x, s); (i.F(v), s))
Base.done(i::imap, s) = done(i.x, s)

Re: [julia-users] Simple Integer DataFrame Automatic Conversion to Float (InexactError())

[Johan Sigfrids]

Multiplying a DataFrame by a scalar has been deprecated and will not work 
once you update to Julia 0.3 and the associated DataFrames version.

On Monday, August 18, 2014 6:10:44 PM UTC+3, Bradley Setzler wrote:

 Update: I found a 1-line command to convert everything in a DataFrame into 
 a Float that seems to work generally:

 data = data*1.0

 So, for example,
 julia A=DataFrame([1 2 ; 3 4])
 2x2 DataFrame:
 x1 x2
 [1,] 1 2
 [2,] 3 4
 julia A=A*1.0
 2x2 DataFrame:
 x1 x2
 [1,] 1.0 2.0
 [2,] 3.0 4.0

 Best,
 Bradley



 On Monday, August 18, 2014 10:02:02 AM UTC-5, Bradley Setzler wrote:

 Hi John,

 Thanks for your reply, I'm getting the following:

 julia A=DataArray([1 2; 3 4])
 2x2 DataArray{Int64,2}:
 1 2
 3 4
 julia A*.5
 2x2 DataArray{Float64,2}:
 0.5 1.0
 1.5 2.0

 julia A/2.
 2x2 DataArray{Float64,2}:
 0.5 1.0
 1.5 2.0
 julia A/2
 InexactError()


 So it converts to Float if divided by Float, but does not convert if 
 divided by Integer.

 Best,
 Bradley



 On Monday, August 18, 2014 9:31:43 AM UTC-5, John Myles White wrote:

 Hi Bradley, 

 Would you consider using DataArrays for this? DataFrames no longer 
 support these operations, so any upgrade in your setup would turn all of 
 this code into errors. 

 All of these operations work on DataArrays already. 

  — John 

 On Aug 18, 2014, at 7:28 AM, Bradley Setzler bradley...@gmail.com 
 wrote: 

  
  
  Good morning, 
  
  I am looking for a simple way to convert an Integer DataFrame to a 
 Float DataFrame. Here is an example of the problem: 
  
  julia using DataFrames 
  julia A=DataFrame([1 2; 3 4]) 
  2x2 DataFrame: 
  x1 x2 
  [1,] 1 2 
  [2,] 3 4 
  
  With multiplication, there is no problem automatically converting to 
 Float: 
  
  julia A*.5 
  2x2 DataFrame: 
  x1 x2 
  [1,] 0.5 1.0 
  [2,] 1.5 2.0 
  
  But with division, for example, the conversion fails: 
  
  julia A/2 
  InexactError() 
  
  Ideally, there would be a one-line command so that we don't have to 
 worry about this issue, say DataFloat() of the form: 
  
  julia A=DataFloat(A) 
  2x2 DataFrame: 
  x1 x2 
  [1,] 1.0 2.0 
  [2,] 3.0 4.0 
  
  Does something like this exist? 
  
  Thanks, 
  Bradley 
  

Re: [julia-users] Suggestion: Start using Julia 0.3-RC4

[Stefan Karpinski]

+1,000,000


On Mon, Aug 18, 2014 at 11:25 AM, John Myles White johnmyleswh...@gmail.com
 wrote:

 One of the best things you can do for the Julia community is to start
 using the release candidates of 0.3. Everyone will be better off if bugs
 are found now rather than when 0.3 is released. You can help make 0.3 a
 better release by installing one of the latest binaries and testing it out.

 This is especially important for projects like DataFrames, which have
 fewer developer hours to spare on issues related to 0.2.

  — John

[julia-users] Re: Suggestion: Start using Julia 0.3-RC4

[Thomas Covert]

is there a way to get this in homebrew?  for the last week or so, a 
homebrew --HEAD install gives the current 0.4 release.

On Monday, August 18, 2014 10:26:03 AM UTC-5, John Myles White wrote:

 One of the best things you can do for the Julia community is to start 
 using the release candidates of 0.3. Everyone will be better off if bugs 
 are found now rather than when 0.3 is released. You can help make 0.3 a 
 better release by installing one of the latest binaries and testing it out. 

 This is especially important for projects like DataFrames, which have 
 fewer developer hours to spare on issues related to 0.2. 

  — John 

Re: [julia-users] Capitalization of package names

[TR NS]

On Monday, August 18, 2014 8:45:58 AM UTC-4, Stefan Karpinski wrote:

 It is a convention, but it isn't required anywhere or guaranteed. You can 
 currently count on package names being ASCII.


Do you expect the ASCII part will eventually change too? If I can count on 
ASCII, that means I can pretty much count on the fact that foreign 
languages such as Chinese and Arabic, that do not have capitalization, will 
never be used for package names. And if that's always going to be the case, 
then it seems like the capitalization thing may as well just be a rule and 
not a convention. Of course, even if such languages are eventually 
supported, it could still be a rule with an exception for such languages.

I guess what I am saying, from the other way round, is if it's not going to 
be a rule, why even bother with the convention?

Re: [julia-users] Backtrace doesn't show details of modules

[Martin Klein]

Hm, this is strange. I'm using julia 0.3.0-rc4 and I'm getting the 
truncated backtrace shown above. I've compiled Julia from Git by checking 
out the v0.3.0-rc4 tag. This is on Debian Testing. Any ideas what is 
happening here?

Am Montag, 18. August 2014 17:18:51 UTC+2 schrieb Tim Holy:

 This has been fixed in julia 0.3. 

 --Tim 

 On Monday, August 18, 2014 06:42:56 AM Martin Klein wrote: 
  Hi, 
  
  I have the following problem, which makes debugging of my self-written 
  module quite difficult. When an exception is thrown inside my module, 
 the 
  backtrace won't include the position of the error inside my module, but 
  only the position where I call the function in my module. The following 
  simple example illustrates the problem: 
  
  module ErrorTest 
  
  export foo 
  
  function foo(x) 
  # trigger exception 
  println(y) 
  end 
  
  end #module 
  
  
  Then when I'm using this module in run.jl: 
  
  using ErrorTest 
  
  foo(5) 
  
  
  I get the following backtrace: 
  ERROR: y not defined 
   in include at ./boot.jl:245 
   in process_options at ./client.jl:285 
   in _start at ./client.jl:354 
   in _start at /usr/local/bin/..//lib/julia/sys.so 
  while loading /home/martin/test/run.jl, in expression starting on line 3 
  
  As you can see, the backtrace doesn't reach into the module ErrorTest, 
 so I 
  don't get any information in which part of ErrorTest the error occurs 
 (i.e. 
  line 6 in my example). For larger and complicated modules, this makes 
  debugging nearly impossible, since I don't even get information in which 
  function in my module the error occurs. I'm currently using v0.3-rc4. Is 
  this a bug or intented behaviour? I couldn't find any bug report about 
  this. If this is intended, what is your usual approach to obtain a 
 detailed 
  backtrace when an error occurs inside a module? 
  
  Thanks, 
  Martin 

Re: [julia-users] Capitalization of package names

[Stefan Karpinski]

On Mon, Aug 18, 2014 at 11:56 AM, TR NS transf...@gmail.com wrote:


 On Monday, August 18, 2014 8:45:58 AM UTC-4, Stefan Karpinski wrote:

 It is a convention, but it isn't required anywhere or guaranteed. You can
 currently count on package names being ASCII.


 Do you expect the ASCII part will eventually change too? If I can count on
 ASCII, that means I can pretty much count on the fact that foreign
 languages such as Chinese and Arabic, that do not have capitalization, will
 never be used for package names. And if that's always going to be the case,
 then it seems like the capitalization thing may as well just be a rule and
 not a convention. Of course, even if such languages are eventually
 supported, it could still be a rule with an exception for such languages.

 I guess what I am saying, from the other way round, is if it's not going
 to be a rule, why even bother with the convention?


The ASCII part seems like a good thing to stick to. Unicode support for
file names is not universal yet and is very likely to cause problems. ASCII
is pretty much the only thing you can count on working right in all file
systems.

Conventions are for people, not computers. None of the operating system,
the language or the package manager have any reason to care if a package
name is uppercase or not. It's nice for people if these things are somewhat
consistent, however. Since module names in Julia are uppercase by
convention, package names are too. But there's no good reason for the
language or the package manager to fail if a module or package isn't
uppercase. Why make things more rigid than they have to be?

What's the reason you want to rely on packages being capitalized?

[julia-users] Re: Suggestion: Start using Julia 0.3-RC4

[Bradley Setzler]

Thanks John. I'm currently installing 0.3 release candidate at your 
suggestion. It's been relatively easy to install - Mac users have to deal 
with the minor hassle of making hidden files visible and then deleting 
files associated with the old Julia version, but it was fine otherwise.

Julia Studio is having a tough time with 0.3 so I may need something else. 
Which IDE do you guys use/recommend?

Thanks,
Bradley



On Monday, August 18, 2014 10:26:03 AM UTC-5, John Myles White wrote:

 One of the best things you can do for the Julia community is to start 
 using the release candidates of 0.3. Everyone will be better off if bugs 
 are found now rather than when 0.3 is released. You can help make 0.3 a 
 better release by installing one of the latest binaries and testing it out. 

 This is especially important for projects like DataFrames, which have 
 fewer developer hours to spare on issues related to 0.2. 

  — John 

Re: [julia-users] Re: Suggestion: Start using Julia 0.3-RC4

[Stefan Karpinski]

On Mon, Aug 18, 2014 at 12:01 PM, Bradley Setzler bradley.setz...@gmail.com
 wrote:

 Mac users have to deal with the minor hassle of making hidden files
 visible and then deleting files associated with the old Julia version, but
 it was fine otherwise.


Are you talking about deleting old history files or something else? Is
there anything we can do to make this easier? Maybe display the exact
command they need to run in a terminal to do this?

Re: [julia-users] Re: Suggestion: Start using Julia 0.3-RC4

[Elliot Saba]

Hey Thomas. Once 0.3.0-rc4 was released, the non-head version of julia was
bumped to 0.3.0-rc4.
On Aug 18, 2014 11:42 AM, Thomas Covert thom.cov...@gmail.com wrote:

 is there a way to get this in homebrew?  for the last week or so, a
 homebrew --HEAD install gives the current 0.4 release.

 On Monday, August 18, 2014 10:26:03 AM UTC-5, John Myles White wrote:

 One of the best things you can do for the Julia community is to start
 using the release candidates of 0.3. Everyone will be better off if bugs
 are found now rather than when 0.3 is released. You can help make 0.3 a
 better release by installing one of the latest binaries and testing it out.

 This is especially important for projects like DataFrames, which have
 fewer developer hours to spare on issues related to 0.2.

  — John

[julia-users] Re: Suggestion: Start using Julia 0.3-RC4

[Johan Sigfrids]

For most Julia code I do I use IJulia 
https://github.com/JuliaLang/IJulia.jl. For more IDEish environment I use 
LightTable http://www.lighttable.com/, along with Juno aka Jupiter-LT 
https://github.com/one-more-minute/Jupiter-LT. Sometime I also just rely 
on Atom for simple text editor duties.

On Monday, August 18, 2014 7:01:26 PM UTC+3, Bradley Setzler wrote:

 Thanks John. I'm currently installing 0.3 release candidate at your 
 suggestion. It's been relatively easy to install - Mac users have to deal 
 with the minor hassle of making hidden files visible and then deleting 
 files associated with the old Julia version, but it was fine otherwise.

 Julia Studio is having a tough time with 0.3 so I may need something else. 
 Which IDE do you guys use/recommend?

 Thanks,
 Bradley



 On Monday, August 18, 2014 10:26:03 AM UTC-5, John Myles White wrote:

 One of the best things you can do for the Julia community is to start 
 using the release candidates of 0.3. Everyone will be better off if bugs 
 are found now rather than when 0.3 is released. You can help make 0.3 a 
 better release by installing one of the latest binaries and testing it out. 

 This is especially important for projects like DataFrames, which have 
 fewer developer hours to spare on issues related to 0.2. 

  — John 

Re: [julia-users] Re: Suggestion: Start using Julia 0.3-RC4

[Bradley Setzler]

Right, deleting the old history files. It's always better for us non-CS 
people to avoid handling hidden files. Would it ever be possible to upgrade 
Julia from within Julia? Like Pkg.update() for Julia version, something 
like Version.update(0.3.0)?

Best,
Bradley

On Monday, August 18, 2014 11:16:46 AM UTC-5, Stefan Karpinski wrote:

 On Mon, Aug 18, 2014 at 12:01 PM, Bradley Setzler bradley...@gmail.com 
 javascript: wrote:

 Mac users have to deal with the minor hassle of making hidden files 
 visible and then deleting files associated with the old Julia version, but 
 it was fine otherwise.


 Are you talking about deleting old history files or something else? Is 
 there anything we can do to make this easier? Maybe display the exact 
 command they need to run in a terminal to do this?

Re: [julia-users] Simple Integer DataFrame Automatic Conversion to Float (InexactError())

[Bradley Setzler]

Thanks, Johan. I have upgraded to 0.3 release candidate and see what you 
mean about scalar multiplication not working for DataFrame any more. I see 
also that DataArray successfully converts Integer to Float in the way John 
was describing earlier, which solves the original problem.

Problem solved, thanks guys,
Bradley



On Monday, August 18, 2014 10:32:25 AM UTC-5, Johan Sigfrids wrote:

 Multiplying a DataFrame by a scalar has been deprecated and will not work 
 once you update to Julia 0.3 and the associated DataFrames version.

 On Monday, August 18, 2014 6:10:44 PM UTC+3, Bradley Setzler wrote:

 Update: I found a 1-line command to convert everything in a DataFrame 
 into a Float that seems to work generally:

 data = data*1.0

 So, for example,
 julia A=DataFrame([1 2 ; 3 4])
 2x2 DataFrame:
 x1 x2
 [1,] 1 2
 [2,] 3 4
 julia A=A*1.0
 2x2 DataFrame:
 x1 x2
 [1,] 1.0 2.0
 [2,] 3.0 4.0

 Best,
 Bradley



 On Monday, August 18, 2014 10:02:02 AM UTC-5, Bradley Setzler wrote:

 Hi John,

 Thanks for your reply, I'm getting the following:

 julia A=DataArray([1 2; 3 4])
 2x2 DataArray{Int64,2}:
 1 2
 3 4
 julia A*.5
 2x2 DataArray{Float64,2}:
 0.5 1.0
 1.5 2.0

 julia A/2.
 2x2 DataArray{Float64,2}:
 0.5 1.0
 1.5 2.0
 julia A/2
 InexactError()


 So it converts to Float if divided by Float, but does not convert if 
 divided by Integer.

 Best,
 Bradley



 On Monday, August 18, 2014 9:31:43 AM UTC-5, John Myles White wrote:

 Hi Bradley, 

 Would you consider using DataArrays for this? DataFrames no longer 
 support these operations, so any upgrade in your setup would turn all of 
 this code into errors. 

 All of these operations work on DataArrays already. 

  — John 

 On Aug 18, 2014, at 7:28 AM, Bradley Setzler bradley...@gmail.com 
 wrote: 

  
  
  Good morning, 
  
  I am looking for a simple way to convert an Integer DataFrame to a 
 Float DataFrame. Here is an example of the problem: 
  
  julia using DataFrames 
  julia A=DataFrame([1 2; 3 4]) 
  2x2 DataFrame: 
  x1 x2 
  [1,] 1 2 
  [2,] 3 4 
  
  With multiplication, there is no problem automatically converting to 
 Float: 
  
  julia A*.5 
  2x2 DataFrame: 
  x1 x2 
  [1,] 0.5 1.0 
  [2,] 1.5 2.0 
  
  But with division, for example, the conversion fails: 
  
  julia A/2 
  InexactError() 
  
  Ideally, there would be a one-line command so that we don't have to 
 worry about this issue, say DataFloat() of the form: 
  
  julia A=DataFloat(A) 
  2x2 DataFrame: 
  x1 x2 
  [1,] 1.0 2.0 
  [2,] 3.0 4.0 
  
  Does something like this exist? 
  
  Thanks, 
  Bradley 
  

Re: [julia-users] Simple Integer DataFrame Automatic Conversion to Float (InexactError())

[John Myles White]

Thank you for upgrading. You've made our lives a lot easier. :)

 -- John

On Aug 18, 2014, at 9:28 AM, Bradley Setzler bradley.setz...@gmail.com wrote:

 Thanks, Johan. I have upgraded to 0.3 release candidate and see what you mean 
 about scalar multiplication not working for DataFrame any more. I see also 
 that DataArray successfully converts Integer to Float in the way John was 
 describing earlier, which solves the original problem.
 
 Problem solved, thanks guys,
 Bradley
 
 
 
 On Monday, August 18, 2014 10:32:25 AM UTC-5, Johan Sigfrids wrote:
 Multiplying a DataFrame by a scalar has been deprecated and will not work 
 once you update to Julia 0.3 and the associated DataFrames version.
 
 On Monday, August 18, 2014 6:10:44 PM UTC+3, Bradley Setzler wrote:
 Update: I found a 1-line command to convert everything in a DataFrame into a 
 Float that seems to work generally:
 
 data = data*1.0
 
 So, for example,
 julia A=DataFrame([1 2 ; 3 4])
 2x2 DataFrame:
 x1 x2
 [1,] 1 2
 [2,] 3 4
 julia A=A*1.0
 2x2 DataFrame:
 x1 x2
 [1,] 1.0 2.0
 [2,] 3.0 4.0
 
 Best,
 Bradley
 
 
 
 On Monday, August 18, 2014 10:02:02 AM UTC-5, Bradley Setzler wrote:
 Hi John,
 
 Thanks for your reply, I'm getting the following:
 
 julia A=DataArray([1 2; 3 4])
 2x2 DataArray{Int64,2}:
 1 2
 3 4
 julia A*.5
 2x2 DataArray{Float64,2}:
 0.5 1.0
 1.5 2.0
 julia A/2.
 2x2 DataArray{Float64,2}:
 0.5 1.0
 1.5 2.0
 julia A/2
 InexactError()
 
 So it converts to Float if divided by Float, but does not convert if divided 
 by Integer.
 
 Best,
 Bradley
 
 
 
 On Monday, August 18, 2014 9:31:43 AM UTC-5, John Myles White wrote:
 Hi Bradley, 
 
 Would you consider using DataArrays for this? DataFrames no longer support 
 these operations, so any upgrade in your setup would turn all of this code 
 into errors. 
 
 All of these operations work on DataArrays already. 
 
  — John 
 
 On Aug 18, 2014, at 7:28 AM, Bradley Setzler bradley...@gmail.com wrote: 
 
  
  
  Good morning, 
  
  I am looking for a simple way to convert an Integer DataFrame to a Float 
  DataFrame. Here is an example of the problem: 
  
  julia using DataFrames 
  julia A=DataFrame([1 2; 3 4]) 
  2x2 DataFrame: 
  x1 x2 
  [1,] 1 2 
  [2,] 3 4 
  
  With multiplication, there is no problem automatically converting to Float: 
  
  julia A*.5 
  2x2 DataFrame: 
  x1 x2 
  [1,] 0.5 1.0 
  [2,] 1.5 2.0 
  
  But with division, for example, the conversion fails: 
  
  julia A/2 
  InexactError() 
  
  Ideally, there would be a one-line command so that we don't have to worry 
  about this issue, say DataFloat() of the form: 
  
  julia A=DataFloat(A) 
  2x2 DataFrame: 
  x1 x2 
  [1,] 1.0 2.0 
  [2,] 3.0 4.0 
  
  Does something like this exist? 
  
  Thanks, 
  Bradley 
  
 

Re: [julia-users] Backtrace doesn't show details of modules

[Tim Holy]

Please say it isn't so...  :-(   (Is there an emoticon for deeply unhappy?) 
But I won't shoot the messenger :-).

Anyway, I'm using v0.3.0-rc4 also, but on Kubuntu 14.04. Can you file an issue, 
please?

--Tim

On Monday, August 18, 2014 08:58:12 AM Martin Klein wrote:
 Hm, this is strange. I'm using julia 0.3.0-rc4 and I'm getting the
 truncated backtrace shown above. I've compiled Julia from Git by checking
 out the v0.3.0-rc4 tag. This is on Debian Testing. Any ideas what is
 happening here?
 
 Am Montag, 18. August 2014 17:18:51 UTC+2 schrieb Tim Holy:
  This has been fixed in julia 0.3.
  
  --Tim
  
  On Monday, August 18, 2014 06:42:56 AM Martin Klein wrote:
   Hi,
   
   I have the following problem, which makes debugging of my self-written
   module quite difficult. When an exception is thrown inside my module,
  
  the
  
   backtrace won't include the position of the error inside my module, but
   only the position where I call the function in my module. The following
   simple example illustrates the problem:
   
   module ErrorTest
   
   export foo
   
   function foo(x)
   
   # trigger exception
   println(y)
   
   end
   
   end #module
   
   
   Then when I'm using this module in run.jl:
   
   using ErrorTest
   
   foo(5)
   
   
   I get the following backtrace:
   ERROR: y not defined
   
in include at ./boot.jl:245
in process_options at ./client.jl:285
in _start at ./client.jl:354
in _start at /usr/local/bin/..//lib/julia/sys.so
   
   while loading /home/martin/test/run.jl, in expression starting on line 3
   
   As you can see, the backtrace doesn't reach into the module ErrorTest,
  
  so I
  
   don't get any information in which part of ErrorTest the error occurs
  
  (i.e.
  
   line 6 in my example). For larger and complicated modules, this makes
   debugging nearly impossible, since I don't even get information in which
   function in my module the error occurs. I'm currently using v0.3-rc4. Is
   this a bug or intented behaviour? I couldn't find any bug report about
   this. If this is intended, what is your usual approach to obtain a
  
  detailed
  
   backtrace when an error occurs inside a module?
   
   Thanks,
   Martin

Re: [julia-users] We have typed functions, don't we?

[Tim Holy]

This is a really cool family of tricks. Time for me to start replacing some 
::Function specifiers in my argument lists...

--Tim

On Monday, August 18, 2014 09:00:22 PM Rafael Fourquet wrote:
 I'm glad to report that the general and beautifully functional solution sum(
 imap(sinc_plus_x, x)) is in fact as efficient as the devectorized
 hand-written one!
 
 It turns out I made the mistake to forget to forward an expression like
 {Type{F}} to the imap iterator constructor (cf. code below), making it
 specialized on DataType instead of sinc_plus_x. (While I can see why this
 prevented inlining, I still don't understand this caused allocations).
 
 For the record, here is a possible implementation of imap for functors
 with 1 argument:
 
 immutable imap{TF, X}
 F::TF
 x::X
 end
 imap{F, X}(::Type{F}, x::X) = imap{Type{F}, X}(F, x)
 
 Base.start(i::imap) = start(i.x)
 Base.next(i::imap, s) = ((v, s) = next(i.x, s); (i.F(v), s))
 Base.done(i::imap, s) = done(i.x, s)

[julia-users] help with improving performance of nested loops

[Florian Oswald]

Hi all,

i'm trying to improve the performance of this function:

https://gist.github.com/floswald/9e79f6f51c276becbd74

In a nutshell, I have got a high-dimensional array vbar (in this instance 
it is 9D), and I want to obtain another array EV (also 9D), by 
matrix-multiplying several dimensions of vbar with transition matrices - 
they are prefixed with G... in the function. The G's are square matrices, 
where row i has the probability of moving from state i to state j. (some of 
those matrices are actually 3D because they depend on an additional state, 
but that doesn't matter.)

I devectorized it already but wanted to see whether anyone out there has a 
suggestion.

thanks!
florian

Re: [julia-users] help with improving performance of nested loops

[Kevin Squire]

Have you run it through the profiler already?

On Monday, August 18, 2014, Florian Oswald florian.osw...@gmail.com wrote:

 Hi all,

 i'm trying to improve the performance of this function:

 https://gist.github.com/floswald/9e79f6f51c276becbd74

 In a nutshell, I have got a high-dimensional array vbar (in this instance
 it is 9D), and I want to obtain another array EV (also 9D), by
 matrix-multiplying several dimensions of vbar with transition matrices -
 they are prefixed with G... in the function. The G's are square matrices,
 where row i has the probability of moving from state i to state j. (some of
 those matrices are actually 3D because they depend on an additional state,
 but that doesn't matter.)

 I devectorized it already but wanted to see whether anyone out there has a
 suggestion.

 thanks!
 florian

Re: [julia-users] Capitalization of package names

[TR NS]

On Monday, August 18, 2014 12:13:12 PM UTC-4, Stefan Karpinski wrote:

 On Mon, Aug 18, 2014 at 11:56 AM, TR NS tran...@gmail.com javascript: 
 wrote:


 On Monday, August 18, 2014 8:45:58 AM UTC-4, Stefan Karpinski wrote:

 It is a convention, but it isn't required anywhere or guaranteed. You 
 can currently count on package names being ASCII.


 Do you expect the ASCII part will eventually change too? If I can count 
 on ASCII, that means I can pretty much count on the fact that foreign 
 languages such as Chinese and Arabic, that do not have capitalization, will 
 never be used for package names. And if that's always going to be the case, 
 then it seems like the capitalization thing may as well just be a rule and 
 not a convention. Of course, even if such languages are eventually 
 supported, it could still be a rule with an exception for such languages.

 I guess what I am saying, from the other way round, is if it's not going 
 to be a rule, why even bother with the convention?


 The ASCII part seems like a good thing to stick to. Unicode support for 
 file names is not universal yet and is very likely to cause problems. ASCII 
 is pretty much the only thing you can count on working right in all file 
 systems.

 Conventions are for people, not computers. None of the operating system, 
 the language or the package manager have any reason to care if a package 
 name is uppercase or not. It's nice for people if these things are somewhat 
 consistent, however. Since module names in Julia are uppercase by 
 convention, package names are too. But there's no good reason for the 
 language or the package manager to fail if a module or package isn't 
 uppercase. Why make things more rigid than they have to be?

 What's the reason you want to rely on packages being capitalized?


In Rosoman's Require.jl (https://github.com/jkroso/Require.jl) it would be 
nice if `@require foo` could mean local file, and `@import Foo` could mean 
a package. One can still use `@import ./Foo` to force local lookup if need 
be.  If the capitalization convention is close enough to being a rule to 
make no significant practical difference, then this would work and it would 
be nice b/c the code would read a little better. But if not, local imports 
will always have to have to be in the form of  `./foo`.

Re: [julia-users] Suitable way to implement DSL for linear constraints

[Miles Lubin]

You can ignore any LineNumberNodes in a block; they're used for generating 
backtraces. Also, dump() is a great tool for printing out expressions to 
inspect their structure.

On Monday, August 18, 2014 4:43:16 AM UTC-6, Tomas Krehlik wrote:

 Thanks, sometimes even small nudge helps. I have it almost working, but 
 have one last question. Why aren't the outputs of these two the same? The 
 macro return four times Expr while the operation on the expression returns 
 LineNumberNode in one case.

 macro test(ex)
 [println(typeof(ex.args[i])) for i=1:length(ex.args)]
 end

 @test begin
betaa(1,2,3) + 2.0 * betaa(2,3,1)=1
3.0 * betaa(2,1,3) + betaa(2,3,4) = 1000
end

 test = :(begin
   betaa(1,2,3) + 2.0 * betaa(2,3,1)=1
   3.0 * betaa(2,1,3) + betaa(2,3,4) = 1000
   end)

 [println(typeof(test.args[i])) for i=1:length(test.args)]

 Thanks, T.

 On Monday, 18 August 2014 06:27:00 UTC+2, Miles Lubin wrote:

 Using eval() within a macro is almost always not what you should be 
 doing. Macros should return code that may depend on the values of the input 
 symbolically. In general, I would try writing down the expression that you 
 want to generate, and then try to reproduce it in the macro, using 
 macroexpand() for debugging.

 On Saturday, August 16, 2014 1:39:59 PM UTC-6, Tomas Krehlik wrote:

 The packages are certainly cool, but do not achieve what I want. I 
 probably explained myself wrongly, so I have a minimal example, which I 
 would like to turn to macro and cannot make it work. :-/

 Here is how it works without macro:

 function β(from, to, lag)
 # vars, lags and ntyp should be taken from the already 
 estimated object
  col = fill(0.0, vars*lags + vars*ntyp)
  col[(from + to)*lag] = 1.0
  return col
 end

 function betaa(from, to, lag)
  return β(from, to, lag)
 end

 test = :(begin
betaa(1,2,3) + 2.0 * betaa(2,3,1)=1
3.0 * betaa(2,1,3) + betaa(2,3,4) = 1000
end)

 # Hardcode so far
 vars = 20
 lags = 15
 ntyp = 20
 ind = [typeof(test.args[i])==Expr for i=2:length(test.args)]
 ind = ([1:length(ind)][ind])+1
 R = apply(hcat,[eval(test.args[i].args[1]) for i=ind])
 r = [eval(test.args[i].args[2]) for i=ind]

 Gives the proper matrices, but when I do 
 macro restrictions(ex)
 vars = 20
 lags = 15
 ntyp = 20
 ind = [typeof(ex.args[i])==Expr for i=2:length(ex.args)]
 ind = ([1:length(ind)][ind])+1
 R = apply(hcat,[eval(ex.args[i].args[1]) for i=ind])
 r = [eval(ex.args[i].args[2]) for i=ind]
 (R, r)
 end

 @restrictions begin
betaa(1,2,3) + 2.0 * betaa(2,3,1)=1
3.0 * betaa(2,1,3) + betaa(2,3,4) = 1000
end

 It does not work and I have no idea why, probably still too advanced 
 concept for me. Also the size of the column that is returned from betaa 
 depends on size of the system, that will be stored in another variable so 
 it would be cool if the betaa function could be evaluated in the macro 
 environment so that it would use the vars, lags and ntyp from the within 
 macro.

 Thanks for any help with this.


 On Saturday, 16 August 2014 17:44:26 UTC+2, Miles Lubin wrote:

 JuMP is also a good place to look. 

 On Saturday, August 16, 2014 8:11:04 AM UTC-6, Stefan Karpinski wrote:

 Have you looked at CVX? I feel like it may be relevant.

 On Aug 16, 2014, at 8:47 AM, Tomas Krehlik tomas@gmail.com 
 wrote:

 I have a package that implements much of vector autoregression 
 estimation and I would like to develop a macro that would implement 
 domain 
 specific language for imposing linear restriction in multidimensional 
 time-series models. Of course, the user could input the restrictions 
 using 
 some matrices, however I tend to think that they will be much less 
 readable 
 than if I implement this macro and I hope it should not be that bad. 
 Typical example would be:

 restr = @restrictions begin
  2 beta[1,2,1] - beta[2,1,3] = 10
  beta[1,3,1] - beta[1,4,1] = 0
 end

 and the restr would be a tuple with matrix and vector after this.

 The beta has the following structure beta[from, to, lag]. The macro 
 should take each line and parse it and form proper restriction matrix R 
 that will be made from the signs and indexes at betas and vector r. So I 
 need to parse the signs, constants, and indeces of betas and the thing 
 that 
 is after the equality.

 Am I right that the right direction is parsing the lines with regular 
 expressions to create the right matrices, or do you have suggestion for 
 better approach? Any further reference for something similar (or useful 
 resource) that has been done before is also very appreciated.

 Related on that note, is there any function to return all matches from 
 regex? That seems to be the biggest bottleneck so far.

 Any comments appreciated. Thanks!

[julia-users] Re: unwanted behaviour in logical indexing

[Davide Lasagna]

Useful reading!

Thanks!

On Monday, August 18, 2014 1:36:24 PM UTC+1, Johan Sigfrids wrote:

 Maybe you are running into #5187 
 https://github.com/JuliaLang/julia/issues/5187?

 On Monday, August 18, 2014 3:11:44 PM UTC+3, Davide Lasagna wrote:

 Hi all, 

 Is this a bug or a feature?

 julia idx = [1:10]
 10-element Array{Int64,1}:
   1
   2
   3
   4
   5
   6
   7
   8
   9
  10

 julia idx .!= 2  idx .!= 8
 10-element BitArray{1}:
   true
  false
   true
   true
   true
   true
   true
   true
   true
   true

 which appears wrong to me. However, by wrapping the two conditions by 
 parenthesis:

 julia (idx .!= 2)  (idx .!= 8)
 10-element BitArray{1}:
   true
  false
   true
   true
   true
   true
   true
  false
   true
   true

 which is the expected result. I would expect the two cases to give the 
 same result, or at least, for the first one, to emit a sort of warning.

 Davide

Re: [julia-users] help with improving performance of nested loops

[Florian Oswald]

Hi!

yes. I find that

37 % of time spent at line 26
51 % of time spent at line 29

in the gist.

line 26  is

idx1 = idx9(is1,iz1,iy1,ip1,itau1,ia,ih,ij,age,p)

line 29 is

@inbounds tmp += m.vbar[idx1] * Gz[iz + p.nz * (iz1 + p.nz *
(ij-1)-1)] * Gyp[iy + p.ny * ((ip-1) + p.np * ((iy1-1) + p.ny *
((ip1-1) + p.np * (ij-1 ] * Gs[is + p.ns * (is1-1)] * Gtau[itau1]






On 18 August 2014 19:13, Kevin Squire kevin.squ...@gmail.com wrote:

 Have you run it through the profiler already?


 On Monday, August 18, 2014, Florian Oswald florian.osw...@gmail.com
 wrote:

 Hi all,

 i'm trying to improve the performance of this function:

 https://gist.github.com/floswald/9e79f6f51c276becbd74

 In a nutshell, I have got a high-dimensional array vbar (in this instance
 it is 9D), and I want to obtain another array EV (also 9D), by
 matrix-multiplying several dimensions of vbar with transition matrices -
 they are prefixed with G... in the function. The G's are square matrices,
 where row i has the probability of moving from state i to state j. (some of
 those matrices are actually 3D because they depend on an additional state,
 but that doesn't matter.)

 I devectorized it already but wanted to see whether anyone out there has
 a suggestion.

 thanks!
 florian

Re: [julia-users] help with improving performance of nested loops

[Jutho]

What are the dimensions (i.e. sizes) of these 9 dimensions? You might be 
interested in trying the tensorcontract routine from TensorOperations.jl 
and compare the method=:BLAS vs method=:native approach. Although I do 
assume that for a specific case like this (where basically every dimension 
is individually contracted with a matrix) there might be better approaches. 


Op maandag 18 augustus 2014 22:35:25 UTC+2 schreef Florian Oswald:

 Hi!

 yes. I find that 

 37 % of time spent at line 26
 51 % of time spent at line 29

 in the gist.

 line 26  is

 idx1 = idx9(is1,iz1,iy1,ip1,itau1,ia,ih,ij,age,p)


 line 29 is

 @inbounds tmp += m.vbar[idx1] * Gz[iz + p.nz * (iz1 + p.nz * (ij-1)-1)] * 
 Gyp[iy + p.ny * ((ip-1) + p.np * ((iy1-1) + p.ny * ((ip1-1) + p.np * 
 (ij-1 ] * Gs[is + p.ns * (is1-1)] * Gtau[itau1]







 On 18 August 2014 19:13, Kevin Squire kevin@gmail.com javascript: 
 wrote:

 Have you run it through the profiler already?


 On Monday, August 18, 2014, Florian Oswald florian...@gmail.com 
 javascript: wrote:

 Hi all,

 i'm trying to improve the performance of this function:

 https://gist.github.com/floswald/9e79f6f51c276becbd74

 In a nutshell, I have got a high-dimensional array vbar (in this 
 instance it is 9D), and I want to obtain another array EV (also 9D), by 
 matrix-multiplying several dimensions of vbar with transition matrices - 
 they are prefixed with G... in the function. The G's are square matrices, 
 where row i has the probability of moving from state i to state j. (some of 
 those matrices are actually 3D because they depend on an additional state, 
 but that doesn't matter.)

 I devectorized it already but wanted to see whether anyone out there has 
 a suggestion.

 thanks!
 florian

Re: [julia-users] help with improving performance of nested loops

[Florian Oswald]

sounds intriguing! will have a look at that TensorOperations.jl.
the size of the array is

*julia **size(m.EV)*

*(2,4,3,3,2,17,2,9,29)*


On 18 August 2014 22:27, Jutho juthohaege...@gmail.com wrote:

 What are the dimensions (i.e. sizes) of these 9 dimensions? You might be
 interested in trying the tensorcontract routine from TensorOperations.jl
 and compare the method=:BLAS vs method=:native approach. Although I do
 assume that for a specific case like this (where basically every dimension
 is individually contracted with a matrix) there might be better approaches.


 Op maandag 18 augustus 2014 22:35:25 UTC+2 schreef Florian Oswald:

 Hi!

 yes. I find that

 37 % of time spent at line 26
 51 % of time spent at line 29

 in the gist.

 line 26  is

 idx1 = idx9(is1,iz1,iy1,ip1,itau1,ia,ih,ij,age,p)



 line 29 is

 @inbounds tmp += m.vbar[idx1] * Gz[iz + p.nz * (iz1 + p.nz * (ij-1)-1)] * 
 Gyp[iy + p.ny * ((ip-1) + p.np * ((iy1-1) + p.ny * ((ip1-1) + p.np * 
 (ij-1 ] * Gs[is + p.ns * (is1-1)] * Gtau[itau1]








 On 18 August 2014 19:13, Kevin Squire kevin@gmail.com wrote:

 Have you run it through the profiler already?


 On Monday, August 18, 2014, Florian Oswald florian...@gmail.com wrote:

 Hi all,

 i'm trying to improve the performance of this function:

 https://gist.github.com/floswald/9e79f6f51c276becbd74

 In a nutshell, I have got a high-dimensional array vbar (in this
 instance it is 9D), and I want to obtain another array EV (also 9D), by
 matrix-multiplying several dimensions of vbar with transition matrices -
 they are prefixed with G... in the function. The G's are square matrices,
 where row i has the probability of moving from state i to state j. (some of
 those matrices are actually 3D because they depend on an additional state,
 but that doesn't matter.)

 I devectorized it already but wanted to see whether anyone out there
 has a suggestion.

 thanks!
 florian

Re: [julia-users] Re: Suggestion: Start using Julia 0.3-RC4

[Thomas Covert]

Gotcha.  I’m getting some OpenBLAS errors when I try to install this, and have 
filed an issue here: https://github.com/staticfloat/homebrew-julia/issues/102
On Aug 18, 2014, at 11:17 AM, Elliot Saba staticfl...@gmail.com wrote:

 Hey Thomas. Once 0.3.0-rc4 was released, the non-head version of julia was 
 bumped to 0.3.0-rc4.
 
 On Aug 18, 2014 11:42 AM, Thomas Covert thom.cov...@gmail.com wrote:
 is there a way to get this in homebrew?  for the last week or so, a homebrew 
 --HEAD install gives the current 0.4 release.
 
 On Monday, August 18, 2014 10:26:03 AM UTC-5, John Myles White wrote:
 One of the best things you can do for the Julia community is to start using 
 the release candidates of 0.3. Everyone will be better off if bugs are found 
 now rather than when 0.3 is released. You can help make 0.3 a better release 
 by installing one of the latest binaries and testing it out. 
 
 This is especially important for projects like DataFrames, which have fewer 
 developer hours to spare on issues related to 0.2. 
 
  — John 
 

Re: [julia-users] Capitalization of package names

[Stefan Karpinski]

./Foo isn't valid syntax, so that's not quite going to work. You could
do @require
./Foo instead. For what it's worth, I don't think that deciding whether
to load a file or package based on capitalization is a good idea. One
alternative would be to load a package if the argument is a symbol and load
a file if the argument is a string.



On Mon, Aug 18, 2014 at 2:40 PM, TR NS transf...@gmail.com wrote:



 On Monday, August 18, 2014 12:13:12 PM UTC-4, Stefan Karpinski wrote:

 On Mon, Aug 18, 2014 at 11:56 AM, TR NS tran...@gmail.com wrote:


 On Monday, August 18, 2014 8:45:58 AM UTC-4, Stefan Karpinski wrote:

 It is a convention, but it isn't required anywhere or guaranteed. You
 can currently count on package names being ASCII.


 Do you expect the ASCII part will eventually change too? If I can count
 on ASCII, that means I can pretty much count on the fact that foreign
 languages such as Chinese and Arabic, that do not have capitalization, will
 never be used for package names. And if that's always going to be the case,
 then it seems like the capitalization thing may as well just be a rule and
 not a convention. Of course, even if such languages are eventually
 supported, it could still be a rule with an exception for such languages.

 I guess what I am saying, from the other way round, is if it's not going
 to be a rule, why even bother with the convention?


 The ASCII part seems like a good thing to stick to. Unicode support for
 file names is not universal yet and is very likely to cause problems. ASCII
 is pretty much the only thing you can count on working right in all file
 systems.

 Conventions are for people, not computers. None of the operating system,
 the language or the package manager have any reason to care if a package
 name is uppercase or not. It's nice for people if these things are somewhat
 consistent, however. Since module names in Julia are uppercase by
 convention, package names are too. But there's no good reason for the
 language or the package manager to fail if a module or package isn't
 uppercase. Why make things more rigid than they have to be?

 What's the reason you want to rely on packages being capitalized?


 In Rosoman's Require.jl (https://github.com/jkroso/Require.jl) it would
 be nice if `@require foo` could mean local file, and `@import Foo` could
 mean a package. One can still use `@import ./Foo` to force local lookup if
 need be.  If the capitalization convention is close enough to being a rule
 to make no significant practical difference, then this would work and it
 would be nice b/c the code would read a little better. But if not, local
 imports will always have to have to be in the form of  `./foo`.

[julia-users] function version of

[ggggg]

Is there a named function that does what  does, eg (a,b) == ab? I 
actually want a multi argument version like $(a,b,c...).  Also is that 
the name of that function is not  and  is not overloadable? The same 
is not true of |. 

*julia **a = zeros(Bool,10);b=[randbool() for j=1:10];*

*julia **ab==b*

*false*

*julia **a|b==b*

*true*

*julia **|(a,b)==b*

*true*

*julia **(a,b)==b*


*ERROR: unsupported or misplaced expression *
*julia **(a,b) = ab*

*ERROR: syntax: invalid assignment location*

Julia even seems to think  is a function

*julia ***

* (generic function with 35 methods)*

Re: [julia-users] function version of

[Stefan Karpinski]

This are some of those few operators that need parens to be used in
function call syntax:

julia ()(3,5)
1

julia (|)(3,5)
7


This isn't required in unambiguous situations like as an argument to
another function:

julia reduce(|, 0:8)
15




On Mon, Aug 18, 2014 at 6:20 PM, g galenon...@gmail.com wrote:

 Is there a named function that does what  does, eg (a,b) == ab? I
 actually want a multi argument version like $(a,b,c...).  Also is that
 the name of that function is not  and  is not overloadable? The same
 is not true of |.

 *julia **a = zeros(Bool,10);b=[randbool() for j=1:10];*

 *julia **ab==b*

 *false*

 *julia **a|b==b*

 *true*

 *julia **|(a,b)==b*

 *true*

 *julia **(a,b)==b*


 *ERROR: unsupported or misplaced expression  *
 *julia **(a,b) = ab*

 *ERROR: syntax: invalid assignment location*

 Julia even seems to think  is a function

 *julia ***

 * (generic function with 35 methods)*

Re: [julia-users] function version of

[Elliot Saba]

Probably because of our special parsing of  in ccall invocations.
-E


On Mon, Aug 18, 2014 at 7:14 PM, Stefan Karpinski ste...@karpinski.org
wrote:

 Yeah, I forget exactly why you can't to that with  but there's some
 parsing ambiguity.


 On Mon, Aug 18, 2014 at 6:33 PM, g galenon...@gmail.com wrote:

 Ok, thanks.  Although it doesn't seem to be the case for |, eg |(true,
 false) works out of the box.


 On Monday, August 18, 2014 4:24:31 PM UTC-6, Stefan Karpinski wrote:

 This are some of those few operators that need parens to be used in
 function call syntax:

 julia ()(3,5)
 1

 julia (|)(3,5)
 7


 This isn't required in unambiguous situations like as an argument to
 another function:

 julia reduce(|, 0:8)
 15




 On Mon, Aug 18, 2014 at 6:20 PM, g galen...@gmail.com wrote:

 Is there a named function that does what  does, eg (a,b) == ab? I
 actually want a multi argument version like $(a,b,c...).  Also is that
 the name of that function is not  and  is not overloadable? The same
 is not true of |.

 *julia **a = zeros(Bool,10);b=[randbool() for j=1:10];*

 *julia **ab==b*

 *false*

 *julia **a|b==b*

 *true*

 *julia **|(a,b)==b*

 *true*

 *julia **(a,b)==b*


 *ERROR: unsupported or misplaced expression  *
 *julia **(a,b) = ab*

 *ERROR: syntax: invalid assignment location*

 Julia even seems to think  is a function

 *julia ***

 * (generic function with 35 methods)*

Re: [julia-users] function version of

[Stefan Karpinski]

That seems likely.

 On Aug 18, 2014, at 7:24 PM, Elliot Saba staticfl...@gmail.com wrote:
 
 Probably because of our special parsing of  in ccall invocations.
 -E
 
 
 On Mon, Aug 18, 2014 at 7:14 PM, Stefan Karpinski ste...@karpinski.org 
 wrote:
 Yeah, I forget exactly why you can't to that with  but there's some parsing 
 ambiguity.
 
 
 On Mon, Aug 18, 2014 at 6:33 PM, g galenon...@gmail.com wrote:
 Ok, thanks.  Although it doesn't seem to be the case for |, eg |(true, 
 false) works out of the box.
 
 
 On Monday, August 18, 2014 4:24:31 PM UTC-6, Stefan Karpinski wrote:
 This are some of those few operators that need parens to be used in 
 function call syntax:
 
 julia ()(3,5)
 1
 
 julia (|)(3,5)
 7
 
 This isn't required in unambiguous situations like as an argument to 
 another function:
 
 julia reduce(|, 0:8)
 15
 
 
 
 On Mon, Aug 18, 2014 at 6:20 PM, g galen...@gmail.com wrote:
 Is there a named function that does what  does, eg (a,b) == ab? I 
 actually want a multi argument version like $(a,b,c...).  Also is that 
 the name of that function is not  and  is not overloadable? The same 
 is not true of |. 
 
 julia a = zeros(Bool,10);b=[randbool() for j=1:10];
 
 julia ab==b
 
 false
 
 julia a|b==b
 
 true
 
 julia |(a,b)==b
 
 true
 
 julia (a,b)==b
 
 ERROR: unsupported or misplaced expression 
 
 julia (a,b) = ab
 
 ERROR: syntax: invalid assignment location
 
 
 Julia even seems to think  is a function
 julia 
 
  (generic function with 35 methods)