Re: [julia-users] Basic DataFrame Subsetting Question

[bernhard]

Thank you Tom. This works fine.
But what if I have an expression? Let's say I derive the expression ex by 
some algorithm (e.g. a decision tree) and then want to apply it to a 
DataFrame. How do I get the last line of this code to work?


using DataFrames
using DataFramesMeta


df = DataFrame(x1 = 1:3, x2 = [2, 1, 2],x3 = [22, 21, 20]);
df[(df[:x3] .< 22) & (df[:x2] .== 2), :]
df_filtered=@where(df, (:x3 .< 22) & (:x2 .== 2))
ex=:((:x3 .< 22) & (:x2 .== 2))
df_filtered2=@where(df,eval(ex))




Am Montag, 2. März 2015 17:29:30 UTC+1 schrieb tshort:
>
> Here are a couple of ways:
>
> julia> df = DataFrame(x1 = 1:3, x2 = [2, 1, 2],x3 = [22, 21, 20]);
>
> julia> df[(df[:x3] .< 22) & (df[:x2] .== 2), :]
> 1x3 DataFrames.DataFrame
> | Row | x1 | x2 | x3 |
> |-||||
> | 1   | 3  | 2  | 20 |
>
> julia> using DataFramesMeta
>
> julia> @where(df, (:x3 .< 22) & (:x2 .== 2))
> 1x3 DataFrames.DataFrame
> | Row | x1 | x2 | x3 |
> |-||||
> | 1   | 3  | 2  | 20 |
>
>
> On Mon, Mar 2, 2015 at 3:09 AM, bernhard > 
> wrote:
>
>> Hi all
>>
>> Can anyone tell me how to make this work in the current version of Julia? 
>> v"0.3.4"
>> I would even prefer to be able to evaluate an expression and receive the 
>> index of the rows which match the results. The code could look similar to 
>> this
>>
>> df = DataFrame(x1 = 1:3, x2 = [2, 1, 2],x3 = [22, 21, 20])
>> ex=:((x3 .< 22) & (x2 .== 2))
>>
>> rows_matching_the_condition=df[eval(ex)] #if this would work, it would 
>> return the subset I guess and not the index vector though
>>
>>
>> Am Freitag, 27. September 2013 22:38:49 UTC+2 schrieb Stefan Karpinski:
>>
>>> Using single & and | should work too.
>>>
>>> On Friday, September 27, 2013, Andrew Gendreau wrote:
>>>
 Makes sense, thanks Joosep

 On Friday, September 27, 2013 4:04:13 PM UTC-4, Joosep Pata wrote:
>
> The following works as one would expect. 
>
> df[:((a .== 1) .+ (b .== 2)), :] #or 
> df[:((a .== 1) .* (b .== 2)), :] #and 
>
> My non-expert explanation is the following: 
> both subexpressions return a DataArray of bools, for which the logical 
> operator && is not defined (what would it mean for an array to have a 
> single true/false value?), but the elementwise product via .* is. The 
> DataFrame is "masked" via the resulting vector of bools.   
>
> Joosep 
>
> On Sep 27, 2013, at 10:49 PM, Andrew Gendreau  
> wrote: 
>
> > Hi, 
> > 
> > I'm just getting started with working with programming languages in 
> general and am trying to learn Julia alongside R.  I'm running into a 
> problem when subsetting within DataFrames in Julia, specifically when I 
> try 
> to do so based on two conditions.  For reference, I'm working off the 
> syntax on the DataFrames subsetting page:  
> http://juliastats.github.io/DataFrames.jl/subsets.html 
> > 
> > These work as expected: 
> > 
> > julia> df2[:(Ozone .> 5), :] 
> > 5x2 DataFrame: 
> > Ozone Temp 
> > [1,]6   86 
> > [2,]7   87 
> > [3,]8   88 
> > [4,]9   89 
> > [5,]   10   90 
> > 
> > 
> > julia> df2[:(Temp .> 88), :] 
> > 2x2 DataFrame: 
> > Ozone Temp 
> > [1,]9   89 
> > [2,]   10   90 
> > 
> > 
> > But when I try to combine them: 
> > 
> > 
> > julia> df2[:(Ozone .> 5 && Temp .> 88), :] 
> > ERROR: type: non-boolean (DataArray{Bool,1}) used in boolean context 
> >  in anonymous at C:\Users\andrew.gendreau\AppData\Roaming\Julia\
> packages\DataFrames\src\dataframe.jl:1466 
> > 
> > 
> > julia> df2[:(Ozone .> 5 & Temp .> 88), :] 
> > 0x2 DataFrame: 
> >   Ozone Temp 
> > 
> > 
> > Any ideas on what I'm doing wrong?   select(:(Ozone .> 5 & Temp .> 
> 88), df2)  doesn't seem to work either (returns an empty SubDataFrame). 
> > 
> > Thank you, 
> > Andrew 
>
>
>

[julia-users] Re: ANN: Meetup for the Bay area Julia users on Feb 21 evening

[Julia Quantum]

Videos and slides are now online at 
http://juliaquantum.github.io/news/2015/03/berkeley-meetup-videos-online/index.html

Feel free to spread over networks! 

On Monday, February 16, 2015 at 1:04:46 PM UTC-7, Xiaodong Qi wrote:
>
> Dear Julia users in the Bay area,
>
> I am glad to announce a meetup session in Berkeley, California, USA on Feb 
> 21. There are three invited speakers talking about their experiences on 
> using Julia for optimization, statistics, parallel computing and quantum 
> science applications. People from SQuInT (southwest quantum information 
> network) workshop, developers & researchers from Stanford and universities 
> nearby are also invited for discussions of developing related Julia 
> packages during the free interaction session starting from 9:25pm. 
>
> Time: 7:30pm-10:00pm. 
> Place: Room Berkeley, DoubleTree Hilton Hotel, 200 Marina Blvd. Berkeley, 
> California 94710 USA
> Register: http://goo.gl/forms/T5qnGPndSE
>
> Talks: 
>
> Talk 1: Predictive Analysis in Julia - An overview of the
> JuMP package for optimization
> Speaker: Philip Thomas from StaffJoy
> Content: This talk focuses on expressing problems including linear
> programming and integer programming in the JuMP metalanguage. Possibly
> with some introduction to general optimization problems.
>
> Talk 2: Convex.jl: Optimization for Everyone
> Speakers: David Deng and Karanveer, possibly also with Jenny Hong
> and Madeleine Udell from Stanford.
> Content: This talk will start with a brief overview of how the
> Convex.jl package works and the types of problems it can solve, and
> really showcase how convenient it is to use. It will be clear that
> Convex.jl is easily usable by just about anyone for their basic
> optimization needs. One or two more involved applications of using
> Convex.jl to solve real world problems will be demonstrated from a good
> pool of examples. Hopefully there will be an example on quantum tomography.
>
> Talk 3: Quantum Statistical Simulations with Julia
> Speaker: Katharine Hyatt from UCSB
> Content: Using computers to probe quantum systems is becoming more
> and more common in condensed matter physics research. Many of the
> commonly used languages and techniques in this space are either
> difficult to learn or not performant. Julia has allowed us to quickly
> develop and test codes for a variety of commonly used algorithms,
> including exact diagonalization and quantum Monte Carlo. Its parallel
> features, including some MPI and GPGPU integration, make it particularly
> attractive for many quantum simulation problems. I'll discuss what
> features of Julia have been most useful for us when working on these
> simulations and the developments we're most excited about.
>
> More details can be found here: 
> https://github.com/JuliaQuantum/JuliaQuantum.github.io/issues/15
>
> Feel free to forward this message to anyone who might be interested. 
> Thanks.
>
> Contact: JuliaQuantum organization via  quantumjulia AT gmail DoT com
>

Re: [julia-users] Ipopt.jl won't build

[Tony Kelman]

Though if you're on OSX, then it's a good thing that Elliot saw this, and 
as in https://github.com/JuliaOpt/Ipopt.jl/issues/30 you shouldn't have to 
deal with compiling from source because the package should just download a 
binary using Homebrew.jl. The fact that it isn't is a different bug 
somewhere.

As a temporary fix, you can comment out these 
lines 
https://github.com/JuliaOpt/Ipopt.jl/blob/99b85463ca408aefb4931d2ebaaa97cf5f821acc/deps/build.jl#L42-L45
 
in Ipopt/deps/build.jl, delete Ipopt/deps/src and rerun Pkg.build("Ipopt").


On Monday, March 2, 2015 at 10:20:58 PM UTC-8, Elliot Saba wrote:
>
> Looks like it's downloading to 1.3.0, when it should be downloading as 
> 1.3.0.tar.gz
> -E
>
> On Mon, Mar 2, 2015 at 7:32 PM, Gabriel Mihalache  > wrote:
>
>> It's trying to download a dependency but the link is broken and it fails.
>>
>> Did anyone manage to find a way around this? Especially since I won't be 
>> using the AMPL stuff anyway.
>>
>> Thank you!
>>
>>
>> Running script for downloading the source code for the ASL
>>
>> Downloading the source code from Github...
>> --2015-03-02 22:28:50--  https://github.com/ampl/mp/archive/1.3.0.tar.gz
>> Resolving github.com... 192.30.252.128
>> Connecting to github.com|192.30.252.128|:443... connected.
>> HTTP request sent, awaiting response... 302 Found
>> Location: https://codeload.github.com/ampl/mp/tar.gz/1.3.0 [following]
>> --2015-03-02 22:28:51--  https://codeload.github.com/ampl/mp/tar.gz/1.3.0
>> Resolving codeload.github.com... 192.30.252.145
>> Connecting to codeload.github.com|192.30.252.145|:443... connected.
>> HTTP request sent, awaiting response... 200 OK
>> Length: 1322272 (1.3M) [application/x-gzip]
>> Saving to: “1.3.0”
>>
>> 100%[=>]
>>  
>> 1,322,272   6.06M/s   in 0.2s
>>
>> 2015-03-02 22:28:51 (6.06 MB/s) - “1.3.0” saved [1322272/1322272]
>>
>> Download finished.
>> Unpacking the source code...
>> gzip: 1.3.0.tar.gz: No such file or directory
>>
>>
>

[julia-users] Re: Ipopt.jl won't build

[Tony Kelman]

This should probably have been reported as an issue to Ipopt.jl 
at https://github.com/JuliaOpt/Ipopt.jl, or to the upstream COIN-OR Ipopt 
mailing list. There's also a julia-opt mailing list that's more 
specifically oriented towards the JuliaOpt set of packages than the general 
julia-users list.

I haven't seen this problem before, and if it had been reported anywhere 
then I would've seen by now. It's a little 
like https://projects.coin-or.org/Ipopt/ticket/256 but with a different 
message, so probably a different underlying cause.

When reporting bugs, please specify as much relevant information as 
possible. What platform are you on, is the single most important one here. 
I'm going to assume Linux (if so, which distribution?), but since you 
haven't specified then for all we know you might be using something exotic 
like FreeBSD where this hasn't been tested yet.

Which of wget, curl, or fetch do you have installed?

-Tony


On Monday, March 2, 2015 at 7:32:12 PM UTC-8, Gabriel Mihalache wrote:
>
> It's trying to download a dependency but the link is broken and it fails.
>
> Did anyone manage to find a way around this? Especially since I won't be 
> using the AMPL stuff anyway.
>
> Thank you!
>
>
> Running script for downloading the source code for the ASL
>
> Downloading the source code from Github...
> --2015-03-02 22:28:50--  https://github.com/ampl/mp/archive/1.3.0.tar.gz
> Resolving github.com... 192.30.252.128
> Connecting to github.com|192.30.252.128|:443... connected.
> HTTP request sent, awaiting response... 302 Found
> Location: https://codeload.github.com/ampl/mp/tar.gz/1.3.0 [following]
> --2015-03-02 22:28:51--  https://codeload.github.com/ampl/mp/tar.gz/1.3.0
> Resolving codeload.github.com... 192.30.252.145
> Connecting to codeload.github.com|192.30.252.145|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 1322272 (1.3M) [application/x-gzip]
> Saving to: “1.3.0”
>
> 100%[=>]
>  
> 1,322,272   6.06M/s   in 0.2s
>
> 2015-03-02 22:28:51 (6.06 MB/s) - “1.3.0” saved [1322272/1322272]
>
> Download finished.
> Unpacking the source code...
> gzip: 1.3.0.tar.gz: No such file or directory
>
>

Re: [julia-users] Ipopt.jl won't build

[Elliot Saba]

Looks like it's downloading to 1.3.0, when it should be downloading as
1.3.0.tar.gz
-E

On Mon, Mar 2, 2015 at 7:32 PM, Gabriel Mihalache 
wrote:

> It's trying to download a dependency but the link is broken and it fails.
>
> Did anyone manage to find a way around this? Especially since I won't be
> using the AMPL stuff anyway.
>
> Thank you!
>
>
> Running script for downloading the source code for the ASL
>
> Downloading the source code from Github...
> --2015-03-02 22:28:50--  https://github.com/ampl/mp/archive/1.3.0.tar.gz
> Resolving github.com... 192.30.252.128
> Connecting to github.com|192.30.252.128|:443... connected.
> HTTP request sent, awaiting response... 302 Found
> Location: https://codeload.github.com/ampl/mp/tar.gz/1.3.0 [following]
> --2015-03-02 22:28:51--  https://codeload.github.com/ampl/mp/tar.gz/1.3.0
> Resolving codeload.github.com... 192.30.252.145
> Connecting to codeload.github.com|192.30.252.145|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 1322272 (1.3M) [application/x-gzip]
> Saving to: “1.3.0”
>
> 100%[=>]
> 1,322,272   6.06M/s   in 0.2s
>
> 2015-03-02 22:28:51 (6.06 MB/s) - “1.3.0” saved [1322272/1322272]
>
> Download finished.
> Unpacking the source code...
> gzip: 1.3.0.tar.gz: No such file or directory
>
>

[julia-users] Ipopt.jl won't build

[Gabriel Mihalache]

It's trying to download a dependency but the link is broken and it fails.

Did anyone manage to find a way around this? Especially since I won't be 
using the AMPL stuff anyway.

Thank you!


Running script for downloading the source code for the ASL

Downloading the source code from Github...
--2015-03-02 22:28:50--  https://github.com/ampl/mp/archive/1.3.0.tar.gz
Resolving github.com... 192.30.252.128
Connecting to github.com|192.30.252.128|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/ampl/mp/tar.gz/1.3.0 [following]
--2015-03-02 22:28:51--  https://codeload.github.com/ampl/mp/tar.gz/1.3.0
Resolving codeload.github.com... 192.30.252.145
Connecting to codeload.github.com|192.30.252.145|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1322272 (1.3M) [application/x-gzip]
Saving to: “1.3.0”

100%[=>]
 
1,322,272   6.06M/s   in 0.2s

2015-03-02 22:28:51 (6.06 MB/s) - “1.3.0” saved [1322272/1322272]

Download finished.
Unpacking the source code...
gzip: 1.3.0.tar.gz: No such file or directory

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

[MA Laforge]

Indeed.  I think that is the problem: Julia's "using" statement is tightly 
coupled to the module import functionality.

>From my understanding, the C++ "using namespace N1::N2::N3" directive 
simply informs the compiler to use shorthand notation for all 
variables/functions present in namespace N1::N2::N3.  You do not actually 
"Import" anything new.  In fact, with C++: the contents of that module are 
usually compiled independently in another library file anyways.  I don't 
think the using directive affects the linker either (at least not directly).

On Monday, March 2, 2015 at 5:59:30 PM UTC-5, ele...@gmail.com wrote:
>
> The C++ "using namespace" and Julia "using module" are not quite the same 
> thing.  The C++ namespace is a top level entity that is created and 
> initialized as part of the C++ startup code and the "using" just makes the 
> names of these global entities available within the scope.   The Julia 
> "using" imports, and thus creates, the module for the first time, and Julia 
> modules can contain statements that run at initialization, whereas C++ 
> namespaces can only contain declarations.  
>
> But if the Julia "using" is within the function, when should the actual 
> import and initialize and execute the statements be done?  Every time the 
> function is called is very expensive.  Hoist the import out of the function 
> to the top level, but doing this naively (ie putting the hoisted import 
> just before the function) will then affect all code following the function 
>  Have a "pseudo" top- level visible only to the function adds a complete 
> new complication to the name management code.  But then what happens if the 
> module is imported into two functions, how is its initialization managed? 
> Or the top level and the function?
>
> So for now the "simpler is better" approach is to have the user manage 
> importing at the top level only.
>
> Cheers
> Lex
>
> On Tuesday, March 3, 2015 at 7:23:33 AM UTC+10, Josh Langsfeld wrote:
>>
>> It's discussed in the FAQ so there must be a good reason for it, though 
>> no rationale is mentioned.
>>
>>
>> http://docs.julialang.org/en/latest/manual/faq/#can-i-use-using-or-import-inside-a-function
>>
>> On Monday, March 2, 2015 at 3:00:21 PM UTC-5, Patrick O'Leary wrote:
>>>
>>> On Saturday, February 28, 2015 at 11:06:38 AM UTC-6, MA Laforge wrote:

 C++ provides "using namespace X" to "make available" the contents of X 
 to the current scope.  This even works on un-named scopes within a 
 function:

>>>
>>> (etc.)
>>>
>>> I know this is something that's come up before, and I think rejected--I 
>>> think because it causes conflicts with multiple dispatch? But I can't seem 
>>> to find the thread(s).
>>>
>>> I can't create a hard conflict in a quick mental search for an example, 
>>> but I can create some level of confusion:
>>>
>>> module Foo
>>> bar::Int = 1
>>> end
>>>
>>> module Baz
>>> bar::Float64 = 27.3
>>> with module Foo # not current Julia syntax
>>> bar #which bar is this?
>>> end
>>> end
>>>
>>

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

[MA Laforge]

Your comment sounds alot like what Stefan said:
https://groups.google.com/d/msg/julia-users/UvBff9QVKaA/P10-LRLezCUJ

I admit I don't fully appreciate why this is a *technical* problem.  Most 
scoping rules would dictate that you should be referring to the *most 
local* version of the value.  In your case bar would come from module Foo.

On the other hand, I can envisage a scary situation arising by adding 
variables to the Foo module *after* the code for Baz has been completed & 
verified.  To avoid this potentially disastrous event: the Julia compiler 
might have to err out.

On Monday, March 2, 2015 at 3:00:21 PM UTC-5, Patrick O'Leary wrote:
>
> I know this is something that's come up before, and I think rejected--I 
> think because it causes conflicts with multiple dispatch? But I can't seem 
> to find the thread(s).
>
> I can't create a hard conflict in a quick mental search for an example, 
> but I can create some level of confusion:
>
> module Foo
> bar::Int = 1
> end
>
> module Baz
> bar::Float64 = 27.3
> with module Foo # not current Julia syntax
> bar #which bar is this?
> end
> end
>

Re: [julia-users] Re: Functions in degrees

[MA Laforge]

:+1
That's a good point.  I have myself experienced problems calculating mean 
when periodicity is not taken into account.

As for dimensionless quantities: I see no issue assigning a type to them 
(other than a potential re-design of the Julia libraries... gross). In 
fact, I expect alot of convenience with *typical* use cases.

The real question is how much programming overhead is required to use these 
types (assuming the compiler does the grunt work reducing the *performance* 
overhead).

For example, you can easily/quickly obtain "typeless" values with "val":
abstract Unit
val(x::Unit) = x.v
abstract Angle <: Unit
immutable type Radians{T<:Number} <: Angle
   v::T
end
unitlessVal = val(Radians(pi))

(See: 
https://github.com/ma-laforge/testcases/blob/master/units_test/units_test_angles.jl
)

On Monday, March 2, 2015 at 8:14:27 AM UTC-5, Yuuki Soho wrote:
>
> One advantage of having a Radian type would be to have circular statistics 
> built-in, mainly mean, var, std or cor. Other languages usually have 
> special functions or packages for that (circmean).
>

Re: [julia-users] Functions in degrees

[ggggg]

It's not really relevant to Julia, but there are many who would argue that 
there should be a base unit for angles. My personal favorite consequence of 
this choice is that Torque and Energy appear to have the same units.

For example:

Issue 10: the SI needs a base unit of angle ‘Angle’ is as tangible a 
geometric quantity as length, but the SI does not have a corresponding base 
quantity or unit for angle. The radian is a derived unit in the SI, defined 
from the identity s = r · θ (in which r is the radius of a circle and s is 
the length of the arc subtended by the angle θ ). From this definition, the 
radian has the unit m/m, and is said to be a dimensionless derived unit 
[34]. This definition has several undesirable consequences for rotational 
quantities, for example the SI unit for a rate of rotation is a ‘per 
second’, without any reference to the angle through which rotation takes 
place, or its unit [50]. There is ongoing confusion in textbooks about when 
radian units should be inserted or deleted in quantity expressions [51, 
52]. 

>From The next 50 years of the SI: a review of the opportunities for the 
e-Science age 



On Monday, March 2, 2015 at 11:05:00 AM UTC-7, Kevin Squire wrote:
>
> (Sorry, I missed the bottom of your message where you distinguish 
> "dimensionless" and "unitless".)
>
> On Monday, March 2, 2015, Gustavo Goretkin  > wrote:
>
>> Radian has dimensions of [(arc) length] / [(radius) length], so it's 
>> dimensionless because the two dimensions of [length] cancel out. 
>> Turn has dimensions of [(arc) length] / [(circumference) length], so it's 
>> just as dimensionless as Radian, right? 
>>
>> https://en.wikipedia.org/wiki/Dimensionless_quantity#Properties seems to 
>> make a distinction between "dimension(less)" and "unit(less)". I think it 
>> could make sense to have types to distinguish among different dimensionless 
>> quantities that have different units.
>>
>> On Wednesday, February 5, 2014 at 10:38:12 AM UTC-5, Stefan Karpinski 
>> wrote:
>>>
>>> I rather like the Degree type idea. Radians are unitless so they don't 
>>> need a type – i.e. PiMultiple is just the default for all trig functions. 
>>> You could, however, also have things angular units like Turns.
>>>
>>>
>>> On Wed, Feb 5, 2014 at 7:48 AM, Johan Sigfrids  
>>> wrote:
>>>
 Oh, you beat me to it. I was just about to say that using a Degree type 
 and dispatching on it would be a lot more Julian. In fact, I had this 
 great 
 idea on how to use the degree sign to construct degrees:

 module DegreeModule

 export Degree, DegreeSign, °

 immutable Degree{T<:Number} <:Number
 d::T
 end

 immutable DegreeSign
 filler::Bool
 end

 const ° = DegreeSign(true)

 *(num::Number, s::DegreeSign) = Degree(num)

 Base.sin(d::Degree) = sinpi(d.d/180)

 end



 Then it would Just Work™:

 using DegreeModule

 Degree(125)   # ==> Degree{Int64}(125)

 130°  # ==> Degree{Int64}(130)

 sin(180°) # ==> 0.0

 I'm not familiar enough with Julia to know if that is the best way to 
 construct the degree sign functionality, but I thought it was kinda 
 elegant. 


 On Wednesday, February 5, 2014 12:18:38 PM UTC+2, Simon Byrne wrote:
>
> As I understand it, the original reason for the degree functions was 
> for matlab compatibility, but they were later modified (and pi-multiple 
> functions sinpi/cospi introduced) so as to be more accurate outside the 
> the 
> interval [-pi/2,pi/2], as Ivar points out. Note that we haven't improved 
> on 
> the naive approach on values within this interval, e.g. 
>
> julia> sind(30)
>
> 0.49994
> Matlab gets this wrong as well, but lies about it:
>
> >> sind(30)
>
> ans =
>
> 0.5000
>
> >> sind(30)-0.5
>
> ans =
>
>   -5.5511e-17
>
> As to their use, I don't know about the degree functions, but the 
> sinpi/cospi functions are actually used internally in a couple of places, 
> in the definition of sinc and a couple of the bessel functions.
>
> However that doesn't mean the interface couldn't be improved. One 
> possible approach I've been thinking about is defining "degree" and 
> "pi-multiple" types
>
> immutable Degree <: Real
>   deg::Float64
> end
>
> immutable PiMultiple <: Real
>   mult::Float64
> end
>
> In this way we could leverage multiple dispatch: i.e. sind(x) becomes 
> sin(Degree(x)) and sinpi(x) becomes sin(PiMultiple(x)). Of course, since 
> julia doesn't (yet) provide a way to dispatch on return types, there's 
> not 
> an easy way to define the corresponding inverse functions, but this is 
> typically 

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

[elextr]

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

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

So for now the "simpler is better" approach is to have the user manage 
importing at the top level only.

Cheers
Lex

On Tuesday, March 3, 2015 at 7:23:33 AM UTC+10, Josh Langsfeld wrote:
>
> It's discussed in the FAQ so there must be a good reason for it, though no 
> rationale is mentioned.
>
>
> http://docs.julialang.org/en/latest/manual/faq/#can-i-use-using-or-import-inside-a-function
>
> On Monday, March 2, 2015 at 3:00:21 PM UTC-5, Patrick O'Leary wrote:
>>
>> On Saturday, February 28, 2015 at 11:06:38 AM UTC-6, MA Laforge wrote:
>>>
>>> C++ provides "using namespace X" to "make available" the contents of X 
>>> to the current scope.  This even works on un-named scopes within a function:
>>>
>>
>> (etc.)
>>
>> I know this is something that's come up before, and I think rejected--I 
>> think because it causes conflicts with multiple dispatch? But I can't seem 
>> to find the thread(s).
>>
>> I can't create a hard conflict in a quick mental search for an example, 
>> but I can create some level of confusion:
>>
>> module Foo
>> bar::Int = 1
>> end
>>
>> module Baz
>> bar::Float64 = 27.3
>> with module Foo # not current Julia syntax
>> bar #which bar is this?
>> end
>> end
>>
>

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

[Josh Langsfeld]

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

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

On Monday, March 2, 2015 at 3:00:21 PM UTC-5, Patrick O'Leary wrote:
>
> On Saturday, February 28, 2015 at 11:06:38 AM UTC-6, MA Laforge wrote:
>>
>> C++ provides "using namespace X" to "make available" the contents of X to 
>> the current scope.  This even works on un-named scopes within a function:
>>
>
> (etc.)
>
> I know this is something that's come up before, and I think rejected--I 
> think because it causes conflicts with multiple dispatch? But I can't seem 
> to find the thread(s).
>
> I can't create a hard conflict in a quick mental search for an example, 
> but I can create some level of confusion:
>
> module Foo
> bar::Int = 1
> end
>
> module Baz
> bar::Float64 = 27.3
> with module Foo # not current Julia syntax
> bar #which bar is this?
> end
> end
>

[julia-users] Re: Passing an Array of Arrays (::Array{Array{T, N},1}) to a function

[Michael Bullman]

Just a general statement, I really do want to thank you guys for helping 
out. I'm not the best programmer in the world so thank you guys (and gals) 
for being patient

[julia-users] Re: Passing an Array of Arrays (::Array{Array{T, N},1}) to a function

[Michael Bullman]

wow! good catch! I forgot the sim time. Major d'oh moment. 

Thank you helping me out with this.

On Monday, March 2, 2015 at 3:43:05 PM UTC-5, Matt Bauman wrote:
>
> The first case is a little complicated, and there are several tricky 
> issues involved in passing types like arrays of arrays.  But you're right, 
> the second method should work just as well — it looks like you've forgotten 
> either your seed or the sim_time when you tried to call run (there's only 
> one Int64 argument before your time_file).
>
> For the first case, you'll want to use a parametric method (
> http://docs.julialang.org/en/release-0.3/manual/methods.html#parametric-methods),
>  
> paying careful attention to type invariance (
> http://docs.julialang.org/en/release-0.3/manual/types.html?highlight=invariant#man-parametric-types).
>  
>  And then you'll need to make sure that all methods that create your arrays 
> of arrays are type stable in order for the method to match.  In general, 
> I've found this to be not worth the hassle — there's no generally no need 
> to make your method signatures that precise.
>
> On Monday, March 2, 2015 at 3:23:27 PM UTC-5, Michael Bullman wrote:
>>
>> Hi all, 
>>
>> First off thanks for all the help I've gotten the last few weeks in this 
>> group. It's been very helpful. 
>>
>>
>> I want to pass an Array of Arrays to a run() function I have in a small 
>> simulation program. When I do typeof() of my data structure in the command 
>> line (REPL?) I get
>>
>> julia> typeof(time_test) 
>>
>> Array{Array{Fyle,N},1}
>>
>> Where "Fyle" is a type I made with some properties like filesize, and other 
>> fields. 
>>
>> My question is, when I try to pass this data structure to my run() function 
>> I get the a few different errors messages, depending on how I try to 
>> implement it. 
>>
>> First Attempt:
>> function run(algo::String, path1::String, path2::String, path3::String, 
>> path4::String, path5::String, seed::Int64, sim_time::Int64, 
>> time_file::Array{Array{Fyle,N},1})
>>
>> Error message: 
>> ERROR: N not defined
>>  in include at /usr/bin/../lib64/julia/sys.so
>>  in include_from_node1 at /usr/bin/../lib64/julia/sys.so
>>
>> I then made a couple attempts to get rid of N but they all threw errors, so 
>> then I thought. I'll just define the variable name and get rid of typing
>>
>> 2nd Attempt:
>> function run(algo::String, path1::String, path2::String, path3::String, 
>> path4::String, path5::String, seed::Int64, sim_time::Int64, time_file)
>>
>> Error:
>> ERROR: `run` has no method matching run(::ASCIIString, ::ASCIIString, 
>> ::ASCIIString, ::ASCIIString, ::ASCIIString, ::ASCIIString, ::Int64, 
>> ::Array{Array{Fyle,N},1})
>>
>> I thought if I didn't try to declare a type it would just accept the data 
>> structure, but this doesn't seem to be the case. 
>>
>>
>> any help is greatly appreciated
>>
>> Thanks 
>>
>

[julia-users] Re: Passing an Array of Arrays (::Array{Array{T, N},1}) to a function

[Matt Bauman]

The first case is a little complicated, and there are several tricky issues 
involved in passing types like arrays of arrays.  But you're right, the 
second method should work just as well — it looks like you've forgotten 
either your seed or the sim_time when you tried to call run (there's only 
one Int64 argument before your time_file).

For the first case, you'll want to use a parametric method 
(http://docs.julialang.org/en/release-0.3/manual/methods.html#parametric-methods),
 
paying careful attention to type invariance 
(http://docs.julialang.org/en/release-0.3/manual/types.html?highlight=invariant#man-parametric-types).
 
 And then you'll need to make sure that all methods that create your arrays 
of arrays are type stable in order for the method to match.  In general, 
I've found this to be not worth the hassle — there's no generally no need 
to make your method signatures that precise.

On Monday, March 2, 2015 at 3:23:27 PM UTC-5, Michael Bullman wrote:
>
> Hi all, 
>
> First off thanks for all the help I've gotten the last few weeks in this 
> group. It's been very helpful. 
>
>
> I want to pass an Array of Arrays to a run() function I have in a small 
> simulation program. When I do typeof() of my data structure in the command 
> line (REPL?) I get
>
> julia> typeof(time_test) 
>
> Array{Array{Fyle,N},1}
>
> Where "Fyle" is a type I made with some properties like filesize, and other 
> fields. 
>
> My question is, when I try to pass this data structure to my run() function I 
> get the a few different errors messages, depending on how I try to implement 
> it. 
>
> First Attempt:
> function run(algo::String, path1::String, path2::String, path3::String, 
> path4::String, path5::String, seed::Int64, sim_time::Int64, 
> time_file::Array{Array{Fyle,N},1})
>
> Error message: 
> ERROR: N not defined
>  in include at /usr/bin/../lib64/julia/sys.so
>  in include_from_node1 at /usr/bin/../lib64/julia/sys.so
>
> I then made a couple attempts to get rid of N but they all threw errors, so 
> then I thought. I'll just define the variable name and get rid of typing
>
> 2nd Attempt:
> function run(algo::String, path1::String, path2::String, path3::String, 
> path4::String, path5::String, seed::Int64, sim_time::Int64, time_file)
>
> Error:
> ERROR: `run` has no method matching run(::ASCIIString, ::ASCIIString, 
> ::ASCIIString, ::ASCIIString, ::ASCIIString, ::ASCIIString, ::Int64, 
> ::Array{Array{Fyle,N},1})
>
> I thought if I didn't try to declare a type it would just accept the data 
> structure, but this doesn't seem to be the case. 
>
>
> any help is greatly appreciated
>
> Thanks 
>

[julia-users] Re: Passing an Array of Arrays (::Array{Array{T, N},1}) to a function

[Michael Bullman]

I learned to program in Java, so I carried a lot of OOP habits over from 
that. 

I'm calling run() from a main() function

function main(seed::Int64, sim_time::Int64) 

srand(seed)


time_file = Array{Fyle}[]


println("Initializing Input Files...")

for t in sim_time

#Creates the number of files to be added to the file queue.

#These will then be added to the nodes based on whichever algorithm 
is currently running.

file_count = round(num_files(t),0)

fileq = Fyle[]




#populated each fileq

for f in 1:file_count


push!(fileq,Fyle(get_filesize()))


end


push!(time_file, fileq)

   end

...
string declarations...

#Runs simulation   run(lb1, path1, path2, path3, path4, path5, seed, time_file)


Thanks for the help



On Monday, March 2, 2015 at 3:33:21 PM UTC-5, Jay Kickliter wrote:
>
> can you post a little more detail of how you define and call the 
> functions? It will probably easier to troubleshoot that way. 
>
> Posted from my pocket computer

[julia-users] Passing an Array of Arrays (::Array{Array{T, N},1}) to a function

[Jay Kickliter]

can you post a little more detail of how you define and call the functions? It 
will probably easier to troubleshoot that way. 

Posted from my pocket computer

[julia-users] Passing an Array of Arrays (::Array{Array{T, N},1}) to a function

[Michael Bullman]

Hi all, 

First off thanks for all the help I've gotten the last few weeks in this 
group. It's been very helpful. 


I want to pass an Array of Arrays to a run() function I have in a small 
simulation program. When I do typeof() of my data structure in the command 
line (REPL?) I get

julia> typeof(time_test) 

Array{Array{Fyle,N},1}

Where "Fyle" is a type I made with some properties like filesize, and other 
fields. 

My question is, when I try to pass this data structure to my run() function I 
get the a few different errors messages, depending on how I try to implement 
it. 

First Attempt:
function run(algo::String, path1::String, path2::String, path3::String, 
path4::String, path5::String, seed::Int64, sim_time::Int64, 
time_file::Array{Array{Fyle,N},1})

Error message: 
ERROR: N not defined
 in include at /usr/bin/../lib64/julia/sys.so
 in include_from_node1 at /usr/bin/../lib64/julia/sys.so

I then made a couple attempts to get rid of N but they all threw errors, so 
then I thought. I'll just define the variable name and get rid of typing

2nd Attempt:
function run(algo::String, path1::String, path2::String, path3::String, 
path4::String, path5::String, seed::Int64, sim_time::Int64, time_file)

Error:
ERROR: `run` has no method matching run(::ASCIIString, ::ASCIIString, 
::ASCIIString, ::ASCIIString, ::ASCIIString, ::ASCIIString, ::Int64, 
::Array{Array{Fyle,N},1})

I thought if I didn't try to declare a type it would just accept the data 
structure, but this doesn't seem to be the case. 


any help is greatly appreciated

Thanks 

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

[Patrick O'Leary]

On Saturday, February 28, 2015 at 11:06:38 AM UTC-6, MA Laforge wrote:
>
> C++ provides "using namespace X" to "make available" the contents of X to 
> the current scope.  This even works on un-named scopes within a function:
>

(etc.)

I know this is something that's come up before, and I think rejected--I 
think because it causes conflicts with multiple dispatch? But I can't seem 
to find the thread(s).

I can't create a hard conflict in a quick mental search for an example, but 
I can create some level of confusion:

module Foo
bar::Int = 1
end

module Baz
bar::Float64 = 27.3
with module Foo # not current Julia syntax
bar #which bar is this?
end
end

[julia-users] Re: [julia-dev] Re: CALL FOR PARTICIPATION: JuliaCon 2015, June 24-28, MIT

[Jiahao Chen]

> It looks to me like the talks you asked about are here
https://www.youtube.com/channel/UCXeOiWjj3rcYUQqfgelTDWQ

Thanks for the link!

Re: [julia-users] Re: pmap not respecting srand set seed settings

[Andreas Noack]

Steve, I don't think that method works. The mapping between the argument to
srand and the internal state of the MT is quite complicated. We are calling
a seed function in the library we are using that maps an integer to a state
vector so srand(1) and srand(2) end up as two quite different streams. I
think this is quite on purpose to avoid that many of the same streams get
repeated over and over. Also, I think the seed function tries to select a
state vector that doesn't require you to burn numbers.

2015-02-28 17:35 GMT-05:00 Ivar Nesje :

> If you find evidence that there is anything wrong with the first N random
> numbers in the standard Random Number Generator (RNG) in Julia, we would
> consider that a bug, fix it, and release a new point release faster than a
> Lenovo CTO is able to arrange a meeting with someone who understands the
> https protocol.
>
> You should still be aware that we optimize for speed and statistical bias,
> so you should not rely on the built-in RNG for cryptography or other
> security related purposes.

Re: [julia-users] Trouble with simple probit regression not converging with glm

[Andreas Noack]

I don't see an obvious reason for this so please try to post this as an
issue on GLM.jl.

2015-02-27 10:47 GMT-05:00 Andrew Newman :

> Hi Julia-users,
>
> I am trying to run a few simple regressions on simulated data.  I had no
> problem with a logit and was able to run it using glm and subsequently
> match the results with a separate maximum likelihood.  I'm having a lot
> more trouble with the probit which doesn't seem to want to converge using
> glm.  Stata has no problem with convergence to the true parameters with the
> same data.  The simulated data are assumed to come from an underlying
> latent variable.
>
> Thanks in advance for any insights,
> Andrew
>
> *
>
> using DataFrames
> using Distributions
> using GLM
> srand(10001)
>
> N=1
> genX = Normal(0,3)
> genɛ = Normal()
> X = rand(genX,N)
> ɛ = rand(genɛ,N)
> α0 = 2
> α1 = -1
> Ystar = α0 + α1*X + ɛ
> Y = (Ystar.>0)*1.
> df = DataFrame(X=[X],Y=[Y])
>
> Probit = glm(Y ~ X, df, Binomial(), ProbitLink())
>

[julia-users] Re: Point test convex hull

[Miles Lubin]

There are certainly more efficient specialized solutions for low dimensions 
like 3D, but you can test whether a point is contained in the convex hull 
by solving a linear programming feasibility problem:

x = [1,1,1] # test point
Z = [1 0  # points along columns
 0 1
 0 0]
using JuMP
m = Model()
@defVar(m, 0 <= lambda[j=1:size(Z,2)] <= 1)

@addConstraint(m, inhull[i=1:length(x)], x[i] == sum{Z[i,j]*lambda[j], j = 1
:size(Z,2)})
@addConstraint(m, sum(lambda) == 1)
status = solve(m)
# Infeasible means not in the hull, Optimal means in the hull


On Monday, March 2, 2015 at 11:08:35 AM UTC-5, Robert Gates wrote:
>
> Dear Julia Users,
>
> does anyone know of a package capable of computing whether a point lies 
> inside or outside of a (3D) convex hull?
>
> I know that the solution to this problem is rather trivial, however, 
> before I reinvent the wheel, I figured some code might already be out 
> there. I checked the Julia interface to qhull (CHull.jl) but was unable to 
> find a quick fix in the qhull manual. I know that the GeometricalPredicates 
> package provides this functionality for triangles and tetrahedra, however, 
> I was looking for something more general.
>
> Best regards,
> Robert
>

Re: [julia-users] Functions in degrees

[Kevin Squire]

By dimensionless, I assume you mean unitless.

Just because a value unitless doesn't mean it can't have a type. In this
case, the type is more like a tag that indicated some information about the
quantity useful for dispatch. While "type" can indicate "unit", it doesn't
have to.

Cheers,
   Kevin

On Monday, March 2, 2015, Gustavo Goretkin 
wrote:

> Radian has dimensions of [(arc) length] / [(radius) length], so it's
> dimensionless because the two dimensions of [length] cancel out.
> Turn has dimensions of [(arc) length] / [(circumference) length], so it's
> just as dimensionless as Radian, right?
>
> https://en.wikipedia.org/wiki/Dimensionless_quantity#Properties seems to
> make a distinction between "dimension(less)" and "unit(less)". I think it
> could make sense to have types to distinguish among different dimensionless
> quantities that have different units.
>
> On Wednesday, February 5, 2014 at 10:38:12 AM UTC-5, Stefan Karpinski
> wrote:
>>
>> I rather like the Degree type idea. Radians are unitless so they don't
>> need a type – i.e. PiMultiple is just the default for all trig functions.
>> You could, however, also have things angular units like Turns.
>>
>>
>> On Wed, Feb 5, 2014 at 7:48 AM, Johan Sigfrids 
>> wrote:
>>
>>> Oh, you beat me to it. I was just about to say that using a Degree type
>>> and dispatching on it would be a lot more Julian. In fact, I had this great
>>> idea on how to use the degree sign to construct degrees:
>>>
>>> module DegreeModule
>>>
>>> export Degree, DegreeSign, °
>>>
>>> immutable Degree{T<:Number} <:Number
>>> d::T
>>> end
>>>
>>> immutable DegreeSign
>>> filler::Bool
>>> end
>>>
>>> const ° = DegreeSign(true)
>>>
>>> *(num::Number, s::DegreeSign) = Degree(num)
>>>
>>> Base.sin(d::Degree) = sinpi(d.d/180)
>>>
>>> end
>>>
>>>
>>>
>>> Then it would Just Work™:
>>>
>>> using DegreeModule
>>>
>>> Degree(125)   # ==> Degree{Int64}(125)
>>>
>>> 130°  # ==> Degree{Int64}(130)
>>>
>>> sin(180°) # ==> 0.0
>>>
>>> I'm not familiar enough with Julia to know if that is the best way to
>>> construct the degree sign functionality, but I thought it was kinda
>>> elegant.
>>>
>>>
>>> On Wednesday, February 5, 2014 12:18:38 PM UTC+2, Simon Byrne wrote:

 As I understand it, the original reason for the degree functions was
 for matlab compatibility, but they were later modified (and pi-multiple
 functions sinpi/cospi introduced) so as to be more accurate outside the the
 interval [-pi/2,pi/2], as Ivar points out. Note that we haven't improved on
 the naive approach on values within this interval, e.g.

 julia> sind(30)

 0.49994
 Matlab gets this wrong as well, but lies about it:

 >> sind(30)

 ans =

 0.5000

 >> sind(30)-0.5

 ans =

   -5.5511e-17

 As to their use, I don't know about the degree functions, but the
 sinpi/cospi functions are actually used internally in a couple of places,
 in the definition of sinc and a couple of the bessel functions.

 However that doesn't mean the interface couldn't be improved. One
 possible approach I've been thinking about is defining "degree" and
 "pi-multiple" types

 immutable Degree <: Real
   deg::Float64
 end

 immutable PiMultiple <: Real
   mult::Float64
 end

 In this way we could leverage multiple dispatch: i.e. sind(x) becomes
 sin(Degree(x)) and sinpi(x) becomes sin(PiMultiple(x)). Of course, since
 julia doesn't (yet) provide a way to dispatch on return types, there's not
 an easy way to define the corresponding inverse functions, but this is
 typically less of an issue in terms of numerical error due to the
 constrained output range (the exception being atan2, where something
 like this could be very useful
 .

 Simon

 On Wednesday, 5 February 2014 08:42:59 UTC, Ivar Nesje wrote:
>
> Hans W Borchers: Your definition is not equivalent.
>
> julia> sin(pi)
> 1.2246467991473532e-16
>
> julia> sind(180)
> 0.0
>
> julia> sinpi(1)
> 0
>
> julia> sin(big(pi))
> 1.096917440979352076742130626395698021050758236508687951179005716992142688513354e-77
> with 256 bits of precision
>
> The answer for sin(pi) is somewhat correct, because float(pi) is not
> the π you know from mathematics. It is the closest representable *IEEE
> 754* floating point number.
>
> Ivar
>
> kl. 09:31:42 UTC+1 onsdag 5. februar 2014 skrev Hans W Borchers
> følgende:
>>
>> You could easily add these two lines of function definitions to your
>> code.
>>
>> sind(x) = sin(degrees2radians(x))
>> cosd(x) = cos(degrees2radians(x))
>>
>> and your haversine function stands as is, not littered with
>> conversions.
>

Re: [julia-users] Functions in degrees

[Kevin Squire]

(Sorry, I missed the bottom of your message where you distinguish
"dimensionless" and "unitless".)

On Monday, March 2, 2015, Gustavo Goretkin 
wrote:

> Radian has dimensions of [(arc) length] / [(radius) length], so it's
> dimensionless because the two dimensions of [length] cancel out.
> Turn has dimensions of [(arc) length] / [(circumference) length], so it's
> just as dimensionless as Radian, right?
>
> https://en.wikipedia.org/wiki/Dimensionless_quantity#Properties seems to
> make a distinction between "dimension(less)" and "unit(less)". I think it
> could make sense to have types to distinguish among different dimensionless
> quantities that have different units.
>
> On Wednesday, February 5, 2014 at 10:38:12 AM UTC-5, Stefan Karpinski
> wrote:
>>
>> I rather like the Degree type idea. Radians are unitless so they don't
>> need a type – i.e. PiMultiple is just the default for all trig functions.
>> You could, however, also have things angular units like Turns.
>>
>>
>> On Wed, Feb 5, 2014 at 7:48 AM, Johan Sigfrids 
>> wrote:
>>
>>> Oh, you beat me to it. I was just about to say that using a Degree type
>>> and dispatching on it would be a lot more Julian. In fact, I had this great
>>> idea on how to use the degree sign to construct degrees:
>>>
>>> module DegreeModule
>>>
>>> export Degree, DegreeSign, °
>>>
>>> immutable Degree{T<:Number} <:Number
>>> d::T
>>> end
>>>
>>> immutable DegreeSign
>>> filler::Bool
>>> end
>>>
>>> const ° = DegreeSign(true)
>>>
>>> *(num::Number, s::DegreeSign) = Degree(num)
>>>
>>> Base.sin(d::Degree) = sinpi(d.d/180)
>>>
>>> end
>>>
>>>
>>>
>>> Then it would Just Work™:
>>>
>>> using DegreeModule
>>>
>>> Degree(125)   # ==> Degree{Int64}(125)
>>>
>>> 130°  # ==> Degree{Int64}(130)
>>>
>>> sin(180°) # ==> 0.0
>>>
>>> I'm not familiar enough with Julia to know if that is the best way to
>>> construct the degree sign functionality, but I thought it was kinda
>>> elegant.
>>>
>>>
>>> On Wednesday, February 5, 2014 12:18:38 PM UTC+2, Simon Byrne wrote:

 As I understand it, the original reason for the degree functions was
 for matlab compatibility, but they were later modified (and pi-multiple
 functions sinpi/cospi introduced) so as to be more accurate outside the the
 interval [-pi/2,pi/2], as Ivar points out. Note that we haven't improved on
 the naive approach on values within this interval, e.g.

 julia> sind(30)

 0.49994
 Matlab gets this wrong as well, but lies about it:

 >> sind(30)

 ans =

 0.5000

 >> sind(30)-0.5

 ans =

   -5.5511e-17

 As to their use, I don't know about the degree functions, but the
 sinpi/cospi functions are actually used internally in a couple of places,
 in the definition of sinc and a couple of the bessel functions.

 However that doesn't mean the interface couldn't be improved. One
 possible approach I've been thinking about is defining "degree" and
 "pi-multiple" types

 immutable Degree <: Real
   deg::Float64
 end

 immutable PiMultiple <: Real
   mult::Float64
 end

 In this way we could leverage multiple dispatch: i.e. sind(x) becomes
 sin(Degree(x)) and sinpi(x) becomes sin(PiMultiple(x)). Of course, since
 julia doesn't (yet) provide a way to dispatch on return types, there's not
 an easy way to define the corresponding inverse functions, but this is
 typically less of an issue in terms of numerical error due to the
 constrained output range (the exception being atan2, where something
 like this could be very useful
 .

 Simon

 On Wednesday, 5 February 2014 08:42:59 UTC, Ivar Nesje wrote:
>
> Hans W Borchers: Your definition is not equivalent.
>
> julia> sin(pi)
> 1.2246467991473532e-16
>
> julia> sind(180)
> 0.0
>
> julia> sinpi(1)
> 0
>
> julia> sin(big(pi))
> 1.096917440979352076742130626395698021050758236508687951179005716992142688513354e-77
> with 256 bits of precision
>
> The answer for sin(pi) is somewhat correct, because float(pi) is not
> the π you know from mathematics. It is the closest representable *IEEE
> 754* floating point number.
>
> Ivar
>
> kl. 09:31:42 UTC+1 onsdag 5. februar 2014 skrev Hans W Borchers
> følgende:
>>
>> You could easily add these two lines of function definitions to your
>> code.
>>
>> sind(x) = sin(degrees2radians(x))
>> cosd(x) = cos(degrees2radians(x))
>>
>> and your haversine function stands as is, not littered with
>> conversions.
>>
>>
>> On Tuesday, February 4, 2014 6:55:13 PM UTC+1, Jacob Quinn wrote:
>>>
>>> As someone who doesn't have to work with the functions very often or
>>> deal with degrees/ra

Re: [julia-users] Re: Functions in degrees

[Gustavo Goretkin]

Radian has dimensions of [(arc) length] / [(radius) length], so it's 
dimensionless because the two dimensions of [length] cancel out. 
Turn has dimensions of [(arc) length] / [(circumference) length], so it's 
just as dimensionless as Radian, right? 

https://en.wikipedia.org/wiki/Dimensionless_quantity#Properties seems to 
make a distinction between "dimension(less)" and "unit(less)". I think it 
could make sense to have types to distinguish among different dimensionless 
quantities that have different units.

On Wednesday, February 5, 2014 at 10:38:12 AM UTC-5, Stefan Karpinski wrote:
>
> I rather like the Degree type idea. Radians are unitless so they don't 
> need a type – i.e. PiMultiple is just the default for all trig functions. 
> You could, however, also have things angular units like Turns.
>
>
> On Wed, Feb 5, 2014 at 7:48 AM, Johan Sigfrids  > wrote:
>
>> Oh, you beat me to it. I was just about to say that using a Degree type 
>> and dispatching on it would be a lot more Julian. In fact, I had this great 
>> idea on how to use the degree sign to construct degrees:
>>
>> module DegreeModule
>>
>> export Degree, DegreeSign, °
>>
>> immutable Degree{T<:Number} <:Number
>> d::T
>> end
>>
>> immutable DegreeSign
>> filler::Bool
>> end
>>
>> const ° = DegreeSign(true)
>>
>> *(num::Number, s::DegreeSign) = Degree(num)
>>
>> Base.sin(d::Degree) = sinpi(d.d/180)
>>
>> end
>>
>>
>>
>> Then it would Just Work™:
>>
>> using DegreeModule
>>
>> Degree(125)   # ==> Degree{Int64}(125)
>>
>> 130°  # ==> Degree{Int64}(130)
>>
>> sin(180°) # ==> 0.0
>>
>> I'm not familiar enough with Julia to know if that is the best way to 
>> construct the degree sign functionality, but I thought it was kinda 
>> elegant. 
>>
>>
>> On Wednesday, February 5, 2014 12:18:38 PM UTC+2, Simon Byrne wrote:
>>>
>>> As I understand it, the original reason for the degree functions was for 
>>> matlab compatibility, but they were later modified (and pi-multiple 
>>> functions sinpi/cospi introduced) so as to be more accurate outside the the 
>>> interval [-pi/2,pi/2], as Ivar points out. Note that we haven't improved on 
>>> the naive approach on values within this interval, e.g. 
>>>
>>> julia> sind(30)
>>>
>>> 0.49994
>>> Matlab gets this wrong as well, but lies about it:
>>>
>>> >> sind(30)
>>>
>>> ans =
>>>
>>> 0.5000
>>>
>>> >> sind(30)-0.5
>>>
>>> ans =
>>>
>>>   -5.5511e-17
>>>
>>> As to their use, I don't know about the degree functions, but the 
>>> sinpi/cospi functions are actually used internally in a couple of places, 
>>> in the definition of sinc and a couple of the bessel functions.
>>>
>>> However that doesn't mean the interface couldn't be improved. One 
>>> possible approach I've been thinking about is defining "degree" and 
>>> "pi-multiple" types
>>>
>>> immutable Degree <: Real
>>>   deg::Float64
>>> end
>>>
>>> immutable PiMultiple <: Real
>>>   mult::Float64
>>> end
>>>
>>> In this way we could leverage multiple dispatch: i.e. sind(x) becomes 
>>> sin(Degree(x)) and sinpi(x) becomes sin(PiMultiple(x)). Of course, since 
>>> julia doesn't (yet) provide a way to dispatch on return types, there's not 
>>> an easy way to define the corresponding inverse functions, but this is 
>>> typically less of an issue in terms of numerical error due to the 
>>> constrained output range (the exception being atan2, where something 
>>> like this could be very useful 
>>> .
>>>
>>> Simon
>>>
>>> On Wednesday, 5 February 2014 08:42:59 UTC, Ivar Nesje wrote:

 Hans W Borchers: Your definition is not equivalent.

 julia> sin(pi) 
 1.2246467991473532e-16 

 julia> sind(180) 
 0.0

 julia> sinpi(1) 
 0

 julia> sin(big(pi)) 
 1.096917440979352076742130626395698021050758236508687951179005716992142688513354e-77
  
 with 256 bits of precision

 The answer for sin(pi) is somewhat correct, because float(pi) is not 
 the π you know from mathematics. It is the closest representable *IEEE 
 754* floating point number.

 Ivar

 kl. 09:31:42 UTC+1 onsdag 5. februar 2014 skrev Hans W Borchers 
 følgende:
>
> You could easily add these two lines of function definitions to your 
> code.
>
> sind(x) = sin(degrees2radians(x))
> cosd(x) = cos(degrees2radians(x))
>
> and your haversine function stands as is, not littered with 
> conversions.
>
>
> On Tuesday, February 4, 2014 6:55:13 PM UTC+1, Jacob Quinn wrote:
>>
>> As someone who doesn't have to work with the functions very often or 
>> deal with degrees/radians conversions, I actually have found it 
>> convenient 
>> to have the sind functions. It saves me time from having to remember 
>> what 
>> the conversion is or make my code uglier littered with degrees2radians() 
>> conversions, for example, 

[julia-users] Re: CALL FOR PARTICIPATION: JuliaCon 2015, June 24-28, MIT

[Christian Peel]

It looks to me like the talks you asked about are here 
https://www.youtube.com/channel/UCXeOiWjj3rcYUQqfgelTDWQ

On Tuesday, February 24, 2015 at 5:37:41 AM UTC-8, Jiahao Chen wrote:
>
> On Tuesday, February 24, 2015 at 1:12:18 AM UTC-5, Christian Peel wrote:
>>
>> Are you open to suggestions?  On Saturday in Berkeley we heard Katherine 
>> Hyatt give a great talk on using Julia for simulating quantum systems.  She 
>> also talked about how it was much easier to get people up to speed on Julia 
>> than 
>>
>  
> Yes, Xiaodong had asked for speakers and I'm glad Katherine was available. 
> Is the talk up somewhere?
>
> At the moment we're looking for voluntary contributions, as opposed to 
> volunteered contributions. :) Naturally, we hope that Katherine will submit 
> something on her own accord.
>  
>
>> BTW, I'd love to see Juliacon in the SF Bay area.
>>
>
> We'd need a critical mass of volunteers in the area for that to happen. If 
> you're willing to coordinate that effort for 2016, we'd be very interested. 
> :)
>
>

Re: [julia-users] Basic DataFrame Subsetting Question

[Tom Short]

Here are a couple of ways:

julia> df = DataFrame(x1 = 1:3, x2 = [2, 1, 2],x3 = [22, 21, 20]);

julia> df[(df[:x3] .< 22) & (df[:x2] .== 2), :]
1x3 DataFrames.DataFrame
| Row | x1 | x2 | x3 |
|-||||
| 1   | 3  | 2  | 20 |

julia> using DataFramesMeta

julia> @where(df, (:x3 .< 22) & (:x2 .== 2))
1x3 DataFrames.DataFrame
| Row | x1 | x2 | x3 |
|-||||
| 1   | 3  | 2  | 20 |


On Mon, Mar 2, 2015 at 3:09 AM, bernhard  wrote:

> Hi all
>
> Can anyone tell me how to make this work in the current version of Julia?
> v"0.3.4"
> I would even prefer to be able to evaluate an expression and receive the
> index of the rows which match the results. The code could look similar to
> this
>
> df = DataFrame(x1 = 1:3, x2 = [2, 1, 2],x3 = [22, 21, 20])
> ex=:((x3 .< 22) & (x2 .== 2))
>
> rows_matching_the_condition=df[eval(ex)] #if this would work, it would
> return the subset I guess and not the index vector though
>
>
> Am Freitag, 27. September 2013 22:38:49 UTC+2 schrieb Stefan Karpinski:
>
>> Using single & and | should work too.
>>
>> On Friday, September 27, 2013, Andrew Gendreau wrote:
>>
>>> Makes sense, thanks Joosep
>>>
>>> On Friday, September 27, 2013 4:04:13 PM UTC-4, Joosep Pata wrote:

 The following works as one would expect.

 df[:((a .== 1) .+ (b .== 2)), :] #or
 df[:((a .== 1) .* (b .== 2)), :] #and

 My non-expert explanation is the following:
 both subexpressions return a DataArray of bools, for which the logical
 operator && is not defined (what would it mean for an array to have a
 single true/false value?), but the elementwise product via .* is. The
 DataFrame is "masked" via the resulting vector of bools.

 Joosep

 On Sep 27, 2013, at 10:49 PM, Andrew Gendreau 
 wrote:

 > Hi,
 >
 > I'm just getting started with working with programming languages in
 general and am trying to learn Julia alongside R.  I'm running into a
 problem when subsetting within DataFrames in Julia, specifically when I try
 to do so based on two conditions.  For reference, I'm working off the
 syntax on the DataFrames subsetting page:  http://juliastats.github.io/
 DataFrames.jl/subsets.html
 >
 > These work as expected:
 >
 > julia> df2[:(Ozone .> 5), :]
 > 5x2 DataFrame:
 > Ozone Temp
 > [1,]6   86
 > [2,]7   87
 > [3,]8   88
 > [4,]9   89
 > [5,]   10   90
 >
 >
 > julia> df2[:(Temp .> 88), :]
 > 2x2 DataFrame:
 > Ozone Temp
 > [1,]9   89
 > [2,]   10   90
 >
 >
 > But when I try to combine them:
 >
 >
 > julia> df2[:(Ozone .> 5 && Temp .> 88), :]
 > ERROR: type: non-boolean (DataArray{Bool,1}) used in boolean context
 >  in anonymous at C:\Users\andrew.gendreau\AppData\Roaming\Julia\
 packages\DataFrames\src\dataframe.jl:1466
 >
 >
 > julia> df2[:(Ozone .> 5 & Temp .> 88), :]
 > 0x2 DataFrame:
 >   Ozone Temp
 >
 >
 > Any ideas on what I'm doing wrong?   select(:(Ozone .> 5 & Temp .>
 88), df2)  doesn't seem to work either (returns an empty SubDataFrame).
 >
 > Thank you,
 > Andrew

Re: [julia-users] Large matrix calculations don't finish, just get "[Process Completed}"

[Stefan Karpinski]

Does anything at all get printed before that? Any kind of error message?
Can you run Julia from a normal terminal and see what kind of an exit code
it terminates with? Is this an out-of-memory error? A segfault?

On Mon, Mar 2, 2015 at 4:11 AM, Milan Bouchet-Valat 
wrote:

> Le dimanche 01 mars 2015 à 23:20 -0500, Stefan Karpinski a écrit :
> > A little more detail about what you're doing may help. How are you
> > running this? What code are you using? The phrase "Process Completed"
> > doesn't appear anywhere in the Julia source code – are you using some
> > package?
> "Process completed" appears to be printed by Terminal.app when a program
> stops. Not sure whether it happens on normal exit or when crashing,
> though.
>
>
> Regards
>
> > On Sun, Mar 1, 2015 at 6:15 PM,  wrote:
> > I have just started using Julia for my Masters projects in the
> > last few months. I am trying to run a set of Finite Difference
> > solvers on matrices, but it seems that for matrices larger
> > than around 100x100 I get the message [Process Completed], but
> > no output. I tried saving the results to a file rather than
> > displaying them, but it made no difference.
> >
> >
> > Does anyone have any suggestions for how I might fix this?
> >
> >
> > Thanks
> >
> >
>

Re: [julia-users] Can I use Julia to read/modify/write LLVM IR?

[Stefan Karpinski]

On Thu, Feb 26, 2015 at 10:03 AM, Isaiah Norton 
wrote:

> Is LLVM IR code portable across different LLVM and Clang versions?
>
>
> No.
>

I was under the impression that the LLVM language was actually pretty
stable across versions, although the C++ API for creating and manipulating
it is not.

Re: [julia-users] How to store latitude and longitude in BST

[Stefan Karpinski]

It's kind of unclear what the connection to Julia here is. Can you give
more context?

On Sat, Feb 28, 2015 at 4:56 AM, Ketul Suthar  wrote:

> I am trying find given latitude and longitude is exist or not in my
> database. so forthat how to create Binary Search tree for storing latitude
> and longitude from my database.Any one has idea about how to store latitude
> and longitude in BST node. Is BST suitable data structure for storing
> latitude and longitude?
>

[julia-users] Point test convex hull

[Robert Gates]

Dear Julia Users,

does anyone know of a package capable of computing whether a point lies 
inside or outside of a (3D) convex hull?

I know that the solution to this problem is rather trivial, however, before 
I reinvent the wheel, I figured some code might already be out there. I 
checked the Julia interface to qhull (CHull.jl) but was unable to find a 
quick fix in the qhull manual. I know that the GeometricalPredicates 
package provides this functionality for triangles and tetrahedra, however, 
I was looking for something more general.

Best regards,
Robert

Re: [julia-users] How to html parse ?

[Stefan Karpinski]

No, like I said, this is a redirect to the page with the actual JSON data.

On Mon, Mar 2, 2015 at 10:51 AM, Paul Analyst  wrote:

> Thx,
> Now I am learning Gumbo.
>
> please see there:
>
> julia> JSON.parse(get("http://rp.pl";).data)
> ERROR: Unknown value
> Line: 0
> Around: ...^
> Ii posible the page to convert to JSON ?
> Paul
>
>
>
> W dniu 2015-03-02 o 16:46, Stefan Karpinski pisze:
>
>  James Porter has an HTML parsing package based on Google's Gumbo library:
>>
>> https://github.com/porterjamesj/Gumbo.jl
>>
>> However, what's happening here is that you're getting a 302 moved
>> response and the content is just a renderable version of that. What you
>> actually want to do is look at the response code and headers to figure out
>> what page to actually get and parse as JSON. Or you could use curl with the
>> appropriate options and it will do this for you.
>>
>
>

Re: [julia-users] How to html parse ?

[Paul Analyst]

Thx,
Now I am learning Gumbo.

please see there:

julia> JSON.parse(get("http://rp.pl";).data)
ERROR: Unknown value
Line: 0
Around: ...
James Porter has an HTML parsing package based on Google's Gumbo library:

https://github.com/porterjamesj/Gumbo.jl

However, what's happening here is that you're getting a 302 moved 
response and the content is just a renderable version of that. What 
you actually want to do is look at the response code and headers to 
figure out what page to actually get and parse as JSON. Or you could 
use curl with the appropriate options and it will do this for you.

Re: [julia-users] How to html parse ?

[Stefan Karpinski]

James Porter has an HTML parsing package based on Google's Gumbo library:

https://github.com/porterjamesj/Gumbo.jl

However, what's happening here is that you're getting a 302 moved response
and the content is just a renderable version of that. What you actually
want to do is look at the response code and headers to figure out what page
to actually get and parse as JSON. Or you could use curl with the
appropriate options and it will do this for you.

On Sun, Mar 1, 2015 at 4:07 PM, Paul Analyst  wrote:

>  Do You now any HTML parser for Julia who do it ?
> Paul
> W dniu 2015-03-01 o 22:04, Jameson Nash pisze:
>
> That page isn't a JSON formatted document. Perhaps you were looking for a
> HTML parser?
>
> On Sun, Mar 1, 2015 at 4:02 PM paul analyst  wrote:
>
>> For some pages JSON parser is OK, but most pages  no, like below.
>> How to html parse ?
>>
>> julia> get("http://rp.pl";).data
>> "> 2.0//EN\">\n\n302 Found\n> Found\nThe document has moved http://www4.rp.pl/\
>> ">here.\n\n"
>>
>> julia> JSON.parse(get("http://rp.pl";).data)
>> ERROR: Unknown value
>> Line: 0
>> Around: ...>^
>>
>>  in error at error.jl:19
>>
>> julia>
>>
>>
>> Paul
>>
>>
>

Re: [julia-users] Basic DataFrame Subsetting Question

[bernhard]

Hi all

Can anyone tell me how to make this work in the current version of Julia? 
v"0.3.4"
I would even prefer to be able to evaluate an expression and receive the 
index of the rows which match the results. The code could look similar to 
this

df = DataFrame(x1 = 1:3, x2 = [2, 1, 2],x3 = [22, 21, 20])
ex=:((x3 .< 22) & (x2 .== 2))

rows_matching_the_condition=df[eval(ex)] #if this would work, it would 
return the subset I guess and not the index vector though


Am Freitag, 27. September 2013 22:38:49 UTC+2 schrieb Stefan Karpinski:
>
> Using single & and | should work too.
>
> On Friday, September 27, 2013, Andrew Gendreau wrote:
>
>> Makes sense, thanks Joosep
>>
>> On Friday, September 27, 2013 4:04:13 PM UTC-4, Joosep Pata wrote:
>>>
>>> The following works as one would expect. 
>>>
>>> df[:((a .== 1) .+ (b .== 2)), :] #or 
>>> df[:((a .== 1) .* (b .== 2)), :] #and 
>>>
>>> My non-expert explanation is the following: 
>>> both subexpressions return a DataArray of bools, for which the logical 
>>> operator && is not defined (what would it mean for an array to have a 
>>> single true/false value?), but the elementwise product via .* is. The 
>>> DataFrame is "masked" via the resulting vector of bools.   
>>>
>>> Joosep 
>>>
>>> On Sep 27, 2013, at 10:49 PM, Andrew Gendreau  
>>> wrote: 
>>>
>>> > Hi, 
>>> > 
>>> > I'm just getting started with working with programming languages in 
>>> general and am trying to learn Julia alongside R.  I'm running into a 
>>> problem when subsetting within DataFrames in Julia, specifically when I try 
>>> to do so based on two conditions.  For reference, I'm working off the 
>>> syntax on the DataFrames subsetting page:  http://juliastats.github.io/
>>> DataFrames.jl/subsets.html 
>>> > 
>>> > These work as expected: 
>>> > 
>>> > julia> df2[:(Ozone .> 5), :] 
>>> > 5x2 DataFrame: 
>>> > Ozone Temp 
>>> > [1,]6   86 
>>> > [2,]7   87 
>>> > [3,]8   88 
>>> > [4,]9   89 
>>> > [5,]   10   90 
>>> > 
>>> > 
>>> > julia> df2[:(Temp .> 88), :] 
>>> > 2x2 DataFrame: 
>>> > Ozone Temp 
>>> > [1,]9   89 
>>> > [2,]   10   90 
>>> > 
>>> > 
>>> > But when I try to combine them: 
>>> > 
>>> > 
>>> > julia> df2[:(Ozone .> 5 && Temp .> 88), :] 
>>> > ERROR: type: non-boolean (DataArray{Bool,1}) used in boolean context 
>>> >  in anonymous at C:\Users\andrew.gendreau\AppData\Roaming\Julia\
>>> packages\DataFrames\src\dataframe.jl:1466 
>>> > 
>>> > 
>>> > julia> df2[:(Ozone .> 5 & Temp .> 88), :] 
>>> > 0x2 DataFrame: 
>>> >   Ozone Temp 
>>> > 
>>> > 
>>> > Any ideas on what I'm doing wrong?   select(:(Ozone .> 5 & Temp .> 
>>> 88), df2)  doesn't seem to work either (returns an empty SubDataFrame). 
>>> > 
>>> > Thank you, 
>>> > Andrew 
>>>
>>>

Re: [julia-users] SharedArray + pmap question

[René Donner]

If I run your code in the REPL I see the same behavior. Putting it into a 
function works:

julia> function test()
   S = SharedArray(Int, (3,))
   pmap(i->S[i], 1:3)
   end
test (generic function with 1 method)

julia> test()
3-element Array{Any,1}:
 0
 0
 0


The same holds true when you use an ordinary Array instead of a SharedArray.

Can someone explain the reason why anonymous functions referencing variables in 
the global scope are handled differently?




Am 01.03.2015 um 01:47 schrieb Max Shron :

> Hi all,
> 
> I looked around but have been unable to find an answer to this question. Here 
> is a very minimal example of how I'd like to use a SharedArray:
> 
> S = SharedArray(Int, (3))
> pmap((i -> S[i]), 1:3)
> 
> When I run this with julia -p 3 (with 0.3.6), I get the following error:
> 
> ERROR: S not defined
> 
> or with Master (0.4.0-dev+3631)
> 
> ERROR: UndefVarError: S not defined
> 
> If I call procs(S) I get back [1,2,3] as expected. What else do I need to do 
> to make S visible to the other processes? Presumably if I use @everywhere S = 
> SharedArray(Int, (3)) that defeats the purpose of SharedArray, right?
> 
> I'm running OS X 10.9.5.
> 
> Thanks,
> Max 

Re: [julia-users] exporting tables (ascii or LaTeX)

[Tamas Papp]

Thanks for the link -- I was not aware of this, so I wrote my own
library which can print as org-mode, Markdown, and some other
formats. Will make it public soon, I am finalizing the interface now.

Best,

Tamas

On Mon, Mar 02 2015, René Donner  wrote:

> I have to tried it myself yet, but did you see 
> https://github.com/scheinerman/LatexPrint.jl?
>
> Am 28.02.2015 um 10:52 schrieb Tamas Papp :
>
>> Hi,
>> 
>> I am solving some economic models in Julia. I have vectors that describe
>> various moments, for some data and then for a bunch of models. I would
>> like to export them to LaTeX, and if possible to ASCCI like org-mode.
>> 
>> | moment   | data | model1 | model2 | ... |
>> |--+--+++-|
>> | UE / 1m  | 0.37 |   0.37 |   0.37 | |
>> | UE / 12m | 0.59 |   0.90 |   0.89 | |
>> | ...  |  ||| |
>> 
>> I found LaTeX.jl, I am wondering if anyone can suggest another solution,
>> especially for the ASCII tables. Dumping in some format that Julia can
>> export to, then converting with some external tool would not be a
>> problem, especially since I could automate the whole thing from Julia.
>> 
>> Best,
>> 
>> Tamas

Re: [julia-users] exporting tables (ascii or LaTeX)

[René Donner]

I have to tried it myself yet, but did you see 
https://github.com/scheinerman/LatexPrint.jl?

Am 28.02.2015 um 10:52 schrieb Tamas Papp :

> Hi,
> 
> I am solving some economic models in Julia. I have vectors that describe
> various moments, for some data and then for a bunch of models. I would
> like to export them to LaTeX, and if possible to ASCCI like org-mode.
> 
> | moment   | data | model1 | model2 | ... |
> |--+--+++-|
> | UE / 1m  | 0.37 |   0.37 |   0.37 | |
> | UE / 12m | 0.59 |   0.90 |   0.89 | |
> | ...  |  ||| |
> 
> I found LaTeX.jl, I am wondering if anyone can suggest another solution,
> especially for the ASCII tables. Dumping in some format that Julia can
> export to, then converting with some external tool would not be a
> problem, especially since I could automate the whole thing from Julia.
> 
> Best,
> 
> Tamas

[julia-users] Re: beginning deep learning with 500 lines of Julia

[Zhixuan Yang]

Nice article and code indeed! I will try this in my project to see how well 
it works. :-) 

在 2015年2月28日星期六 UTC+8下午11:19:18，Deniz Yuret写道：
>
> KUnet.jl  (beginning deep 
> learning with 500 lines of Julia 
> 
> ) is out with its alpha release.  Only the basic functionality is in 
> place (i.e. backprop with relu, softmax, sgd, momentum, nesterov, adagrad, 
> dropout, l1-l2 regularization etc.) but the GPU functionality is in, its 
> speed is competitive with Caffe , and I 
> think convolutional and recurrent nets can be added without too much 
> effort.  I wrote a blog post 
> 
>  about 
> the code structure and there is some basic documentation 
> .  You can 
> send me suggestions for improvement (both in coding style and new 
> functionality) using comments 
>  
> to 
> the blog post 
> ,
>  
> or using issues  or pull 
> requests  on GitHub 
> .
>
> I tried to make the code (cpu/gpu) generic and high level.  Getting the 
> same code working on the GPU and the CPU in Julia proved to be a bit 
> challenging and showed that both a more standard treatment of CPU and GPU 
> arrays, and a standard syntax for in-place operations would be welcome 
> additions to the language.  I'd like to thank Tim Holy (CUDArt), Nick 
> Henderson (CUBLAS), and Simon Byrne (InplaceOps) for their generous help.
>
> best,
> deniz
>

Re: [julia-users] Re: Functions in degrees

[Yuuki Soho]

One advantage of having a Radian type would be to have circular statistics 
built-in, mainly mean, var, std or cor. Other languages usually have 
special functions or packages for that (circmean).

[julia-users] Re: Repmat speed

[Ivar Nesje]

Fixing the type declarations for inner and outer (Array{Int,1} instead of 
Array{Int}), and isolating the type unstable R array filling in a extra 
function, cut the time down from 1.5 to 1 second. There are still a huge 
difference though.

A ugly attempt is at https://github.com/julialang/julia/commit/fe359a4 

mandag 2. mars 2015 13.25.48 UTC+1 skrev Simon Kornblith følgende:
>
> Keyword arguments can add additional overhead when calling a function and 
> prevent its return type from being inferred properly, but the code that 
> runs is specialized for the types of the keyword arguments, so I don't 
> think keyword arguments alone explain this. But it looks like there is some 
> type instability inside repeat because it creates arrays where the number 
> of dimensions can't be inferred.
>
> Simon
>
> On Monday, March 2, 2015 at 5:35:15 AM UTC-5, Ivar Nesje wrote:
>>
>> The speed difference is because Julia doesn't specialize for specific 
>> types for keyword arguments, and type unstable code creates really slow 
>> loops in Julia.
>>
>> Thanks for reporting, I'll work on a fix.
>>
>> mandag 2. mars 2015 09.09.04 UTC+1 skrev antony schutz følgende:
>>>
>>> Hi Steven,
>>>
>>> Thanks for your answer but my question is a bit different.
>>> I'm not asking about creating a mesh grid and how or why doing it. 
>>> My question is more "naive": 
>>> Why the first method is faster than the 2 with only (well written) 1 
>>> line command.
>>>
>>> and a more general question is: why "repeat" is slower than "repmat"   , 
>>> for example: 
>>>
>>> *tic(); repmat([1:10],1000,1000); toc()*
>>>
>>> elapsed time: 0.035878247 seconds
>>>
>>>
>>> *tic(); **repeat([1:10],outer=[1000,1000]);** toc()*
>>>
>>> elapsed time: 1.176858309 seconds
>>>
>>> Thanks
>>>
>>>
>>> Le vendredi 27 février 2015 15:11:10 UTC+1, antony schutz a écrit :

 Hello, 

 I have a question about the best way to implement a grid similar to a 
 mesh grid: 
 My first intuition was to do the following: 

 nx = 256
 nb = 195

 kx = [-nx/2:-1+nx/2]

 tic()
 k1   = repmat(kx,1,nx)
 k1v = vec(k1)'#/nx
 k1m = repmat(k1v,nb,1)
 toc()
 # 0.0256 sec 

 Then I tried in one operation the following: 
 tic()
 ka = repeat(kx,outer=[nx,nb])'# reshape( 
 repeat(repeat(kx,inner=[nb]),outer=[nx]) ,nb,nx*nx )
 toc()
 # 0.477

 Does somebody knows why the repeat is ~20 times slower than the 
 repeat/vec/repmat 
 Is it the best way to do this ?

 Thanks in advance

 Bests.

 Antony

[julia-users] Re: beginning deep learning with 500 lines of Julia

[Yuuki Soho]

Nice article, it reminded me of my machine learning courses :)

The only comment I have is maybe use a bit more explicit names, like forw 
-> forward, xtst -> xtest

[julia-users] Re: Repmat speed

[Simon Kornblith]

Keyword arguments can add additional overhead when calling a function and 
prevent its return type from being inferred properly, but the code that 
runs is specialized for the types of the keyword arguments, so I don't 
think keyword arguments alone explain this. But it looks like there is some 
type instability inside repeat because it creates arrays where the number 
of dimensions can't be inferred.

Simon

On Monday, March 2, 2015 at 5:35:15 AM UTC-5, Ivar Nesje wrote:
>
> The speed difference is because Julia doesn't specialize for specific 
> types for keyword arguments, and type unstable code creates really slow 
> loops in Julia.
>
> Thanks for reporting, I'll work on a fix.
>
> mandag 2. mars 2015 09.09.04 UTC+1 skrev antony schutz følgende:
>>
>> Hi Steven,
>>
>> Thanks for your answer but my question is a bit different.
>> I'm not asking about creating a mesh grid and how or why doing it. 
>> My question is more "naive": 
>> Why the first method is faster than the 2 with only (well written) 1 line 
>> command.
>>
>> and a more general question is: why "repeat" is slower than "repmat"   , 
>> for example: 
>>
>> *tic(); repmat([1:10],1000,1000); toc()*
>>
>> elapsed time: 0.035878247 seconds
>>
>>
>> *tic(); **repeat([1:10],outer=[1000,1000]);** toc()*
>>
>> elapsed time: 1.176858309 seconds
>>
>> Thanks
>>
>>
>> Le vendredi 27 février 2015 15:11:10 UTC+1, antony schutz a écrit :
>>>
>>> Hello, 
>>>
>>> I have a question about the best way to implement a grid similar to a 
>>> mesh grid: 
>>> My first intuition was to do the following: 
>>>
>>> nx = 256
>>> nb = 195
>>>
>>> kx = [-nx/2:-1+nx/2]
>>>
>>> tic()
>>> k1   = repmat(kx,1,nx)
>>> k1v = vec(k1)'#/nx
>>> k1m = repmat(k1v,nb,1)
>>> toc()
>>> # 0.0256 sec 
>>>
>>> Then I tried in one operation the following: 
>>> tic()
>>> ka = repeat(kx,outer=[nx,nb])'# reshape( 
>>> repeat(repeat(kx,inner=[nb]),outer=[nx]) ,nb,nx*nx )
>>> toc()
>>> # 0.477
>>>
>>> Does somebody knows why the repeat is ~20 times slower than the 
>>> repeat/vec/repmat 
>>> Is it the best way to do this ?
>>>
>>> Thanks in advance
>>>
>>> Bests.
>>>
>>> Antony
>>>
>>>

Re: [julia-users] Re: how to remove the quotation marks ?

[paul analyst]

I see , Thx, propably this is nad way, ;)
Paul

W dniu poniedziałek, 2 marca 2015 13:01:36 UTC+1 użytkownik Tamas Papp 
napisał:
>
> I am afraid you are missing something fundamental here. 
>
> Those double quotes are not part of the strings, they are just a 
> printing convention that Julia uses (which coincides with the read 
> syntax). 
>
> Similarly, 
>
> julia> print([1,2,3]) 
> [1,2,3] 
>
> even though the array has no elements [ or ], not even ','. 
>
> You have to decide what you want. Using Darwin Darakananda's solution, 
> you can write those strings into a file, and then naturally they would 
> have no quotes. Or if you want to transform them to something else which 
> is still a string, then quotes will appear when the output is printed at 
> the REPL, even if it has no quotes. 
>
> By the way, these concepts are not specific to Julia. Unless you 
> understand the very basics of programming languages, you will have a 
> rather difficult time using Julia or any other language. 
>
> hope this helps, 
>
> Tamas 
>
> On Mon, Mar 02 2015, Paul Analyst > 
> wrote: 
>
> > look nice but result is "nothing" :) 
> > 
> > julia> a=map(println,[r]) 
> >  
> >  
> > 302 Found 
> >  
> > Found 
> > The document has moved http://www4.rp.pl/";>here. 
> >  
> > 
> > 1-element Array{Void,1}: 
> >   nothing 
> > Paul 
> > 
> > julia> 
> > W dniu 2015-03-02 o 06:51, Darwin Darakananda pisze: 
> >> How about something like 
> >> 
> >> | 
> >> map(println,["abc","def"]); 
> >> abc 
> >> def 
> >> | 
> >> 
> >> 
> >> 
> >> On Sunday, March 1, 2015 at 1:00:38 PM UTC-8, paul analyst wrote: 
> >> 
> >> I need :) 
> >> P 
> >> 
> >> W dniu niedziela, 1 marca 2015 20:47:15 UTC+1 użytkownik Simon 
> >> Danisch napisał: 
> >> 
> >> If I'm not mistaken, that's how an array of strings gets 
> >> displayed: 
> >> julia>["tets", "test"] 
> >> "test" 
> >> "test" 
> >> 
> >> So no need for removing them! 
> >> 
> >> Am Sonntag, 1. März 2015 19:51:40 UTC+1 schrieb paul analyst: 
> >> 
> >> Przetłumacz wiadomość na język polski 
> >> how to remove the quotation marks ?, like below.. 
> >> 
> >> julia> (split(bytestring(r.body),"\r\n")) 
> >> 180-element Array{SubString{UTF8String},1} 
> >> : 
> >>  "" 
> >> 
> >> 
> >>  "" 
> >> 
> >> 
> >>  "" 
> >> 
>
>

Re: [julia-users] Re: how to remove the quotation marks ?

[Tamas Papp]

I am afraid you are missing something fundamental here.

Those double quotes are not part of the strings, they are just a
printing convention that Julia uses (which coincides with the read
syntax).

Similarly,

julia> print([1,2,3])
[1,2,3]

even though the array has no elements [ or ], not even ','.

You have to decide what you want. Using Darwin Darakananda's solution,
you can write those strings into a file, and then naturally they would
have no quotes. Or if you want to transform them to something else which
is still a string, then quotes will appear when the output is printed at
the REPL, even if it has no quotes.

By the way, these concepts are not specific to Julia. Unless you
understand the very basics of programming languages, you will have a
rather difficult time using Julia or any other language.

hope this helps,

Tamas

On Mon, Mar 02 2015, Paul Analyst  wrote:

> look nice but result is "nothing" :)
>
> julia> a=map(println,[r])
> 
> 
> 302 Found
> 
> Found
> The document has moved http://www4.rp.pl/";>here.
> 
>
> 1-element Array{Void,1}:
>   nothing
> Paul
>
> julia>
> W dniu 2015-03-02 o 06:51, Darwin Darakananda pisze:
>> How about something like
>>
>> |
>> map(println,["abc","def"]);
>> abc
>> def
>> |
>>
>>
>>
>> On Sunday, March 1, 2015 at 1:00:38 PM UTC-8, paul analyst wrote:
>>
>> I need :)
>> P
>>
>> W dniu niedziela, 1 marca 2015 20:47:15 UTC+1 użytkownik Simon
>> Danisch napisał:
>>
>> If I'm not mistaken, that's how an array of strings gets
>> displayed:
>> julia>["tets", "test"]
>> "test"
>> "test"
>>
>> So no need for removing them!
>>
>> Am Sonntag, 1. März 2015 19:51:40 UTC+1 schrieb paul analyst:
>>
>> Przetłumacz wiadomość na język polski
>> how to remove the quotation marks ?, like below..
>>
>> julia> (split(bytestring(r.body),"\r\n"))
>> 180-element Array{SubString{UTF8String},1}
>> :
>>  ""
>>
>>
>>  ""
>>
>>
>>  ""
>>

[julia-users] Re: join dataframe columns

[pgs]

Johan
Thanks for this.
I also found that I could use .* to join two columns in a DataFrame.
Using a dot star to join! -  I found surprising - but it worked.
Regards


On Sunday, March 1, 2015 at 2:50:42 PM UTC, Johan Sigfrids wrote:
>
> With a DataFrame like:
>
> df = DataFrame(Name = ["Test", "Test2"], Name2 = ["A", "B"], Amt=[123,456])
>
> you could do something like this:
>
> df[:Name] = map((x,y) -> string(x, -, y), df[:Name], df[:Name2])
>
> Note that you will still have the Name2 column.
>
> On Sunday, March 1, 2015 at 12:35:01 AM UTC+2, pip7...@gmail.com wrote:
>>
>> Hi
>> How can I join 2 columns in a dataframe.
>>
>> e.g.
>> Dataframe 1
>>
>> RowName   Name2   Amt
>> 1 TestA   123
>> 2 Test2  B456
>> etc
>>
>> I want to be able to join Name and Name2 and use a separator like -
>> eg
>> RowName   Amt
>> 1 Test-A 123
>> 2 Test2-B456
>>
>> Regards
>>
>

Re: [julia-users] Re: how to remove the quotation marks ?

[Paul Analyst]

look nice but result is "nothing" :)

julia> a=map(println,[r])


302 Found

Found
The document has moved http://www4.rp.pl/";>here.


1-element Array{Void,1}:
 nothing
Paul

julia>
W dniu 2015-03-02 o 06:51, Darwin Darakananda pisze:

How about something like

|
map(println,["abc","def"]);
abc
def
|



On Sunday, March 1, 2015 at 1:00:38 PM UTC-8, paul analyst wrote:

I need :)
P

W dniu niedziela, 1 marca 2015 20:47:15 UTC+1 użytkownik Simon
Danisch napisał:

If I'm not mistaken, that's how an array of strings gets
displayed:
julia>["tets", "test"]
"test"
"test"

So no need for removing them!

Am Sonntag, 1. März 2015 19:51:40 UTC+1 schrieb paul analyst:

Przetłumacz wiadomość na język polski
how to remove the quotation marks ?, like below..

julia> (split(bytestring(r.body),"\r\n"))
180-element Array{SubString{UTF8String},1}
:
 ""


 ""


 ""

[julia-users] Re: Repmat speed

[Ivar Nesje]

The speed difference is because Julia doesn't specialize for specific types 
for keyword arguments, and type unstable code creates really slow loops in 
Julia.

Thanks for reporting, I'll work on a fix.

mandag 2. mars 2015 09.09.04 UTC+1 skrev antony schutz følgende:
>
> Hi Steven,
>
> Thanks for your answer but my question is a bit different.
> I'm not asking about creating a mesh grid and how or why doing it. 
> My question is more "naive": 
> Why the first method is faster than the 2 with only (well written) 1 line 
> command.
>
> and a more general question is: why "repeat" is slower than "repmat"   , 
> for example: 
>
> *tic(); repmat([1:10],1000,1000); toc()*
>
> elapsed time: 0.035878247 seconds
>
>
> *tic(); **repeat([1:10],outer=[1000,1000]);** toc()*
>
> elapsed time: 1.176858309 seconds
>
> Thanks
>
>
> Le vendredi 27 février 2015 15:11:10 UTC+1, antony schutz a écrit :
>>
>> Hello, 
>>
>> I have a question about the best way to implement a grid similar to a 
>> mesh grid: 
>> My first intuition was to do the following: 
>>
>> nx = 256
>> nb = 195
>>
>> kx = [-nx/2:-1+nx/2]
>>
>> tic()
>> k1   = repmat(kx,1,nx)
>> k1v = vec(k1)'#/nx
>> k1m = repmat(k1v,nb,1)
>> toc()
>> # 0.0256 sec 
>>
>> Then I tried in one operation the following: 
>> tic()
>> ka = repeat(kx,outer=[nx,nb])'# reshape( 
>> repeat(repeat(kx,inner=[nb]),outer=[nx]) ,nb,nx*nx )
>> toc()
>> # 0.477
>>
>> Does somebody knows why the repeat is ~20 times slower than the 
>> repeat/vec/repmat 
>> Is it the best way to do this ?
>>
>> Thanks in advance
>>
>> Bests.
>>
>> Antony
>>
>>

Re: [julia-users] Large matrix calculations don't finish, just get "[Process Completed}"

[Milan Bouchet-Valat]

Le dimanche 01 mars 2015 à 23:20 -0500, Stefan Karpinski a écrit :
> A little more detail about what you're doing may help. How are you
> running this? What code are you using? The phrase "Process Completed"
> doesn't appear anywhere in the Julia source code – are you using some
> package?
"Process completed" appears to be printed by Terminal.app when a program
stops. Not sure whether it happens on normal exit or when crashing,
though.


Regards

> On Sun, Mar 1, 2015 at 6:15 PM,  wrote:
> I have just started using Julia for my Masters projects in the
> last few months. I am trying to run a set of Finite Difference
> solvers on matrices, but it seems that for matrices larger
> than around 100x100 I get the message [Process Completed], but
> no output. I tried saving the results to a file rather than
> displaying them, but it made no difference.
> 
> 
> Does anyone have any suggestions for how I might fix this?
> 
> 
> Thanks
> 
> 

[julia-users] Re: Repmat speed

[antony schutz]

Hi Steven,

Thanks for your answer but my question is a bit different.
I'm not asking about creating a mesh grid and how or why doing it. 
My question is more "naive": 
Why the first method is faster than the 2 with only (well written) 1 line 
command.

and a more general question is: why "repeat" is slower than "repmat"   , 
for example: 

*tic(); repmat([1:10],1000,1000); toc()*

elapsed time: 0.035878247 seconds


*tic(); **repeat([1:10],outer=[1000,1000]);** toc()*

elapsed time: 1.176858309 seconds

Thanks


Le vendredi 27 février 2015 15:11:10 UTC+1, antony schutz a écrit :
>
> Hello, 
>
> I have a question about the best way to implement a grid similar to a mesh 
> grid: 
> My first intuition was to do the following: 
>
> nx = 256
> nb = 195
>
> kx = [-nx/2:-1+nx/2]
>
> tic()
> k1   = repmat(kx,1,nx)
> k1v = vec(k1)'#/nx
> k1m = repmat(k1v,nb,1)
> toc()
> # 0.0256 sec 
>
> Then I tried in one operation the following: 
> tic()
> ka = repeat(kx,outer=[nx,nb])'# reshape( 
> repeat(repeat(kx,inner=[nb]),outer=[nx]) ,nb,nx*nx )
> toc()
> # 0.477
>
> Does somebody knows why the repeat is ~20 times slower than the 
> repeat/vec/repmat 
> Is it the best way to do this ?
>
> Thanks in advance
>
> Bests.
>
> Antony
>
>