Re: [julia-users] Implicit call problem

[Toivo Henningsson]

What is state_info? A local variable? How would it help if implicit_match
could be invoked to do the conversion, it wouldn't have access to
state_info any more than +(::C, ::C) does?

I think that we will need a bit more context to be able to understand what
problem you are trying to solve, and how that can be best done in Julia.

Re: [julia-users] Implicit call problem

[Julia Tylors]

because myconvert function needs some state info which is only generated
within another function , ex :

@special foo(x::A,y::A)
(x+y) + (x+y)
end

@special generates state_info. So the definition down becomes implausible

+(x::C,y::C) = myconvert(A,x,state_info) + myconvert(A,y,state_info)

On Sat, Feb 27, 2016 at 11:43 PM, Toivo Henningsson 
wrote:

> Ok, I see the distinction as compared to regular type promotion.
> My point is that the Julia never does any implicit type conversion, if you
> want type conversion you have to invoke it yourself, such as by adding a
> method for +(::C, ::C) that does the conversion and adds the results.
>
> I think there's several reasons why Julia doesn't do implicit type
> conversion, including a) making it easier to understand what your code does
> and b) with multiple dispatch, it's not clear which method signature to
> convert the arguments to match.
>
> Why don't you want to provide a +(::C, ::C) method?

Re: [julia-users] reading compressed csv file?

[Tony Kelman]

Ivo,

It looks like https://github.com/JuliaLang/julia/pull/12807 would implement 
the suggestion to change open(command) to return just the process instead 
of a tuple, so indexing into the return from open(`gzcat myzippedfile.gz`) 
would no longer be necessary.

-Tony


On Saturday, February 27, 2016 at 8:14:41 PM UTC-8, ivo welch wrote:
>
>
> apologies for bothering everyone again.  is an easier solution planned for 
> the following R-equivalent construct?
>
> d <- read.csv(pipe("gzcat mygzippedfile.gz"))
>
>
> where gzcat could be an arbitrary alternative decompressor or input 
> filter, or is this likely to remain difficult for starters?
>
>

Re: [julia-users] Implicit call problem

[Toivo Henningsson]

Ok, I see the distinction as compared to regular type promotion. 
My point is that the Julia never does any implicit type conversion, if you want 
type conversion you have to invoke it yourself, such as by adding a method for 
+(::C, ::C) that does the conversion and adds the results.

I think there's several reasons why Julia doesn't do implicit type conversion, 
including a) making it easier to understand what your code does and b) with 
multiple dispatch, it's not clear which method signature to convert the 
arguments to match. 

Why don't you want to provide a +(::C, ::C) method?

Re: [julia-users] Implicit call problem

[Lutfullah Tomak]

You can use promote_rule and its promote_op(If it is basic ops I think 
-AddGun-MulFun-etc-) variant but it would be awkward.

Re: [julia-users] Implicit call problem

[Julia Tylors]

Yes, I have read it!
However, my question is not about promotion (converting mixed types to a
single common type), mine is more about figuring out when a method error
exists due to not matching + operator with (::C,::A) ,(::A,::C) or
(::C,::C) (I am not sure how Julia evaluates an expr (x+y) + (x+y) ) , but
resulting 3 situations is going to give a methodError due to not matching
parameter types. In this case, the compiler can fix it by implicitly
converting type Cs to type A by going through some conversion.

This is my question. So far I had no satisfactory answer.

Thanks

On Sat, Feb 27, 2016 at 10:21 PM, Toivo Henningsson 
wrote:

> Have you read about type promotion in the manual, eg
>
> http://docs.julialang.org/en/release-0.4/manual/conversion-and-promotion/
>
> Julia never does any automatic type promotion, you have to opt into it
> yourself by calling into the promotion machinery.

Re: [julia-users] Re: csv file reading header=TRUE default

[elextr]

Indeed, but its in the dataframes package documentation, its all about 
"readtables", and nowhere in dataframes documentation is "readcsv" 
mentioned.

On Sunday, February 28, 2016 at 3:58:15 PM UTC+10, ivo welch wrote:
>
>
> I see.  thank you.  it was a little confusing.  it was right under the 
> header
>
> Advanced Options for Reading CSV Files 
> 
>
>
> 
> Ivo Welch (ivo@gmail.com )
> http://www.ivo-welch.info/
> J. Fred Weston Distinguished Professor of Finance
> Anderson School at UCLA, C519
> Free Finance Textbook, http://book.ivo-welch.info/
> Exec Editor, Critical Finance Review, 
> http://www.critical-finance-review.org/
> Editor and Publisher, FAMe, http://www.fame-jagazine.com/
>
> On Sat, Feb 27, 2016 at 8:31 PM, > wrote:
>
>> The link below points to "readtables" but you are using "readcsv" as the 
>> command.
>>
>>
>> On Sunday, February 28, 2016 at 2:18:50 PM UTC+10, ivo welch wrote:
>>>
>>>
>>> I am a complete julia novice, so I may simply not understand the 
>>> following.  when I type
>>>
 julia> d=readcsv("myfile.csv")
 julia> typeof(d)
>>>
>>> Array{Any,2}
>>>
>>>
>>> I think this shows that it interprets the header as data, and sets the 
>>> columns to be of type "any".  alas 
>>> https://dataframesjl.readthedocs.org/en/latest/io.html#advanced-options-for-reading-csv-files
>>>  states 
>>> that `header::Bool – Use the information from the file’s header line to 
>>> determine column names. Defaults to true.`  but it only works if I force it 
>>> to true:
>>>
 julia> d=readcsv("myfile.csv", header=true)
 julia> typeof(d)
>>>
>>> Tuple{Array{Float64,2},Array{AbstractString,2}}  
>>>
>>>  
>>> seems to interpret the header as variable names.
>>>
>>> is header=true the default on readcsv, is the docs wrong, or am I doing 
>>> something wrong?
>>>
>>> /iaw
>>>
>>>
>

[julia-users] Implicit call problem

[Toivo Henningsson]

Have you read about type promotion in the manual, eg

http://docs.julialang.org/en/release-0.4/manual/conversion-and-promotion/

Julia never does any automatic type promotion, you have to opt into it yourself 
by calling into the promotion machinery. 

Re: [julia-users] Re: csv file reading header=TRUE default

[ivo welch]

I see.  thank you.  it was a little confusing.  it was right under the
header

Advanced Options for Reading CSV Files




Ivo Welch (ivo.we...@gmail.com)
http://www.ivo-welch.info/
J. Fred Weston Distinguished Professor of Finance
Anderson School at UCLA, C519
Free Finance Textbook, http://book.ivo-welch.info/
Exec Editor, Critical Finance Review,
http://www.critical-finance-review.org/
Editor and Publisher, FAMe, http://www.fame-jagazine.com/

On Sat, Feb 27, 2016 at 8:31 PM,  wrote:

> The link below points to "readtables" but you are using "readcsv" as the
> command.
>
>
> On Sunday, February 28, 2016 at 2:18:50 PM UTC+10, ivo welch wrote:
>>
>>
>> I am a complete julia novice, so I may simply not understand the
>> following.  when I type
>>
>>> julia> d=readcsv("myfile.csv")
>>> julia> typeof(d)
>>
>> Array{Any,2}
>>
>>
>> I think this shows that it interprets the header as data, and sets the
>> columns to be of type "any".  alas
>> https://dataframesjl.readthedocs.org/en/latest/io.html#advanced-options-for-reading-csv-files
>>  states
>> that `header::Bool – Use the information from the file’s header line to
>> determine column names. Defaults to true.`  but it only works if I force it
>> to true:
>>
>>> julia> d=readcsv("myfile.csv", header=true)
>>> julia> typeof(d)
>>
>> Tuple{Array{Float64,2},Array{AbstractString,2}}
>>
>>
>> seems to interpret the header as variable names.
>>
>> is header=true the default on readcsv, is the docs wrong, or am I doing
>> something wrong?
>>
>> /iaw
>>
>>

Re: [julia-users] Make the computer make a beep?

[Chris Rackauckas]

Couldn't get Atom to buzz at all with atom.beep(). print(`\a`) only works 
in the REPL and run(`beep`) doesn't work for me at all (on the Windows 
computer). Could you show me that 2-line Julia function?

On Saturday, February 27, 2016 at 4:11:53 PM UTC-8, FQ wrote:
>
> from normal REPL, you could do 
> print('\a') 
> which "prints" the bell character. i don't know how whether that works 
> for your configuration though. 
>
> given there's the program beep available and working on your system, you 
> could also do 
> run(`beep`) 
> note the backticks, see 
> http://docs.julialang.org/en/release-0.4/manual/running-external-programs/ 
>
> Am 28.02.2016 um 00:39 schrieb Chris Rackauckas: 
> > Hey, 
> >   I was wondering about a quick way to make the computer beep when code 
> > is finished. Usually there's a beep() function. The one in Julia at 
> > Base.Terminals.beep takes as input a terminal. Where do I find this 
> > terminal object? If it matters, I am using Juno with Atom. 
>
>

[julia-users] Re: csv file reading header=TRUE default

[elextr]

The link below points to "readtables" but you are using "readcsv" as the 
command.

On Sunday, February 28, 2016 at 2:18:50 PM UTC+10, ivo welch wrote:
>
>
> I am a complete julia novice, so I may simply not understand the 
> following.  when I type
>
>> julia> d=readcsv("myfile.csv")
>> julia> typeof(d)
>
> Array{Any,2}
>
>
> I think this shows that it interprets the header as data, and sets the 
> columns to be of type "any".  alas 
> https://dataframesjl.readthedocs.org/en/latest/io.html#advanced-options-for-reading-csv-files
>  states 
> that `header::Bool – Use the information from the file’s header line to 
> determine column names. Defaults to true.`  but it only works if I force it 
> to true:
>
>> julia> d=readcsv("myfile.csv", header=true)
>> julia> typeof(d)
>
> Tuple{Array{Float64,2},Array{AbstractString,2}}  
>
>  
> seems to interpret the header as variable names.
>
> is header=true the default on readcsv, is the docs wrong, or am I doing 
> something wrong?
>
> /iaw
>
>

[julia-users] csv file reading header=TRUE default

[ivo welch]

I am a complete julia novice, so I may simply not understand the following. 
 when I type

> julia> d=readcsv("myfile.csv")
> julia> typeof(d)

Array{Any,2}


I think this shows that it interprets the header as data, and sets the 
columns to be of type "any".  alas 
https://dataframesjl.readthedocs.org/en/latest/io.html#advanced-options-for-reading-csv-files
 states 
that `header::Bool – Use the information from the file’s header line to 
determine column names. Defaults to true.`  but it only works if I force it 
to true:

> julia> d=readcsv("myfile.csv", header=true)
> julia> typeof(d)

Tuple{Array{Float64,2},Array{AbstractString,2}}  

 
seems to interpret the header as variable names.

is header=true the default on readcsv, is the docs wrong, or am I doing 
something wrong?

/iaw

Re: [julia-users] reading compressed csv file?

[ivo welch]

apologies for bothering everyone again.  is an easier solution planned for 
the following R-equivalent construct?

d <- read.csv(pipe("gzcat mygzippedfile.gz"))


where gzcat could be an arbitrary alternative decompressor or input filter, 
or is this likely to remain difficult for starters?

Re: [julia-users] Make the computer make a beep?

[FQ]

from normal REPL, you could do
print('\a')
which "prints" the bell character. i don't know how whether that works
for your configuration though.

given there's the program beep available and working on your system, you
could also do
run(`beep`)
note the backticks, see
http://docs.julialang.org/en/release-0.4/manual/running-external-programs/

Am 28.02.2016 um 00:39 schrieb Chris Rackauckas:
> Hey,
>   I was wondering about a quick way to make the computer beep when code
> is finished. Usually there's a beep() function. The one in Julia at
> Base.Terminals.beep takes as input a terminal. Where do I find this
> terminal object? If it matters, I am using Juno with Atom.

Re: [julia-users] Make the computer make a beep?

[Mike Innes]

As it happens, you can do this from Atom itself; `C-Alt-I` to get to the
dev tools and `atom.beep()`.

It would be easy (as in two lines) to expose this as a Julia function, and
I can help with that if you're interested.

Of course, there may well be a simpler way to do it directly within Julia ;)

On Sat, 27 Feb 2016 at 23:39 Chris Rackauckas  wrote:

> Hey,
>   I was wondering about a quick way to make the computer beep when code is
> finished. Usually there's a beep() function. The one in Julia at
> Base.Terminals.beep takes as input a terminal. Where do I find this
> terminal object? If it matters, I am using Juno with Atom.
>

[julia-users] Make the computer make a beep?

[Chris Rackauckas]

Hey,
  I was wondering about a quick way to make the computer beep when code is 
finished. Usually there's a beep() function. The one in Julia at 
Base.Terminals.beep takes as input a terminal. Where do I find this 
terminal object? If it matters, I am using Juno with Atom.

[julia-users] Real-time user input

[Simon Danisch]

You could try GLVisualize... There is the mario example to get you started: 
http://www.glvisualize.com/examples/interactive/

Re: [julia-users] Re: Non-uniform interpolation in 1D

[Eric Forgy]

Quick note...

Grid.jl has some support for irregular grids, but is not documented (If I 
recall). I'm using it with linear interpolation on irregular grids, but don't 
remember if it can do irregular splines.

[julia-users] Re: ANN: JuMP 0.12 released

[Patrick Kofod Mogensen]

Very cool that you added user-defined functions (and AD). Congrats on the 
new version.

On Saturday, February 27, 2016 at 11:14:16 PM UTC+1, Miles Lubin wrote:
>
> The JuMP team is happy to announce the release of JuMP 0.12.
>
> This release features a complete rewrite of JuMP's automatic 
> differentiation functionality, which is the largest change in JuMP's 
> nonlinear optimization support since JuMP 0.5. Most of the changes are 
> under the hood, but as previously announced 
>  there are 
> a couple of syntax changes:
> - The first parameter to @defNLExpr *and* @defExpr should now be the 
> model object. All linear and nonlinear subexpressions are now attached to 
> their corresponding model.
> - If solving a sequence of nonlinear models, you should now use nonlinear 
> parameters instead of Julia's variable binding rules.
>
> Many nonlinear models should see performance improvements in JuMP 0.12, 
> let us know if you observe otherwise.
>
> We also now support user-defined functions 
>  
> and *automatic differentiation of user-defined functions*. This is quite 
> a significant new feature which allows users to integrate (almost) 
> arbitrary code as a nonlinear function within JuMP expressions, thanks to 
> ForwardDiff.jl . We're 
> looking forward to seeing how this feature can be used in practice; please 
> give us feedback on the syntax and any rough edges you run into.
>
> Other changes include:
> - Changed syntax for iterating over AffExpr objects
> - Stopping the solver from within a callback now causes the solver to 
> return :UserLimit instead of throwing an error.
> - getDual() now works for conic problems (thanks to Emre Yamangil)
>
> Given the large number of changes, bugs are possible. Please let us know 
> of any incorrect or confusing behavior.
>
> Miles, Iain, and Joey
>

[julia-users] ANN: JuMP 0.12 released

[Miles Lubin]

The JuMP team is happy to announce the release of JuMP 0.12.

This release features a complete rewrite of JuMP's automatic 
differentiation functionality, which is the largest change in JuMP's 
nonlinear optimization support since JuMP 0.5. Most of the changes are 
under the hood, but as previously announced 
 there are a 
couple of syntax changes:
- The first parameter to @defNLExpr *and* @defExpr should now be the model 
object. All linear and nonlinear subexpressions are now attached to their 
corresponding model.
- If solving a sequence of nonlinear models, you should now use nonlinear 
parameters instead of Julia's variable binding rules.

Many nonlinear models should see performance improvements in JuMP 0.12, let 
us know if you observe otherwise.

We also now support user-defined functions 
 and 
*automatic 
differentiation of user-defined functions*. This is quite a significant new 
feature which allows users to integrate (almost) arbitrary code as a 
nonlinear function within JuMP expressions, thanks to ForwardDiff.jl 
. We're looking forward to 
seeing how this feature can be used in practice; please give us feedback on 
the syntax and any rough edges you run into.

Other changes include:
- Changed syntax for iterating over AffExpr objects
- Stopping the solver from within a callback now causes the solver to 
return :UserLimit instead of throwing an error.
- getDual() now works for conic problems (thanks to Emre Yamangil)

Given the large number of changes, bugs are possible. Please let us know of 
any incorrect or confusing behavior.

Miles, Iain, and Joey

Re: [julia-users] Re: [julia-dev] Re: Google Summer of Code 2016 - Ideas Page

[Mauro]

Hi Jorge,

thanks for your interest!  I think this would be a welcome addition to
ODE.jl and I would like to see how this somewhat non-standard method
fits within the framework of ODE.jl.  I think this could make a strong
application.

A couple of things: I never participated in GSOC, so I don't know how to
proceed.  Whilst I did update the GSOC ODE.jl proposal, there may also
be other suitable mentors.  I guess that is something to be discussed.

Cheers,
Mauro

@Ilya: Jorge is a PhD student of the authors of TaylorSeries.jl.

On Fri, 2016-02-26 at 09:21, perez...@gmail.com wrote:
> Hi Mauro,
>
> I would like to submit a proposal to work on the ODE.jl package,
> for the GSoC. From my undergraduate and master thesis I have
> experience with the Taylor method for solving ODEs (ie., based on Taylor
> series expansions). This is a variable order, variable step
> size method, which uses automatic differentiation
> techniques in order to reach high order integration methods (30th, 40th
> order)
> which enable machine-epsilon precision with very competitive speeds.
> I think the Taylor method is important to include in the ODE.jl package,
> as it is very versatile and precise.
>
> Besides the utility of the Taylor method for ODEs integration, a DAEs
> solver can
> also be implemented using the Taylor models framework.
>
> I would be very happy to contribute to the ODE.jl package!
>
> Best regards,
>
> On Thursday, February 11, 2016 at 7:56:45 AM UTC-6, Mauro wrote:
>>
>>
>> It is desirable to have ode-solvers which are pure Julia.  Both to cut
>> down on dependencies and to allow easy hacking and development.
>> Further, Sundials.jl will not work with generic Julia datatypes (e.g. I
>> think Julia sparse matrices are not supported for Jacobians).  Thus,
>> ODE.jl is to stay and to be improved on.
>>
>> The currently ongoing work of which I'm aware is:
>> https://github.com/JuliaLang/ODE.jl/pull/49
>> https://github.com/JuliaLang/ODE.jl/pull/72
>>
>> Needed work is:
>> - more solvers
>> - a unified code structure/API
>> - parallelism(?)
>>
>> I'll try and update the GSoC description.
>>

Re: [julia-users] Implicit call problem

[Erik Schnetter]

Julia

Yes, that's what I suggested.

You could instead look at type promotion
.
Defining a rule that converts `(C, C)` to `(A, A)` might work, if you
declare the `implicit_match` function as type conversion.

-erik

On Sat, Feb 27, 2016 at 3:49 PM, Julia Tylors  wrote:
> abstract CC;
> type C <: CC
> #some stuff
> end
>
> +{T<:CC}(x::T, y::T) = convert(A,x) + convert(A,y)
>
>
> This is what you are saying right?
> If it is, I don't want to define any more + function, i want it to be
> handled by some sort of a dispatch trick, if it exists...
>
> On Saturday, February 27, 2016 at 12:29:57 PM UTC-8, Erik Schnetter wrote:
>>
>> You can define an abstract type CC that is a super type of C, and define a
>> fallback + operator for it that converts C to A. If an operator + for C is
>> defined, it will be used instead of the CC operator +.
>>
>> -erik
>>
>> On Saturday, February 27, 2016, Julia Tylors  wrote:
>> > Hi, I have a problem i need an implicit call, I wonder whether there is
>> > a way to do what i have in mind.
>> >
>> > +(x::A,y::A) = C(x,y)
>> > implicit_match(c::C) = #returns type A,
>> > function foo(x::A,Y::A)
>> >(x+y) + (x+y)
>> > end
>> >
>> >
>> > As you may see in the function foo, once (x+y) is executed, it returns
>> > an instance of type C.
>> > now second operation becomes in type C+C , but there is no function like
>> > +(c1::C, c2::C),  but i have a match function (implicit_match) which can
>> > return an instance of A by looking at the input instance of type C
>> > I want this implicit function to be executed once +(::C,::C) is not
>> > found.
>> > Can we do something like this?
>> > I don't like to define +(::C,::C) or generate +(::C,::C) using a macro.
>> > Thanks
>>
>> --
>> Erik Schnetter 
>> http://www.perimeterinstitute.ca/personal/eschnetter/
>>
>



-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

[julia-users] Re: Using .ji files

[Steven G. Johnson]

On Sunday, December 13, 2015 at 4:07:55 PM UTC-5, Leonardo wrote:
>
> Thanks, but I have still some trouble.
>
> I try to better explain my problems:
>
>1. .*ji file creation*: I can create a .ji file for a module with 
>precompilation (e.g. with Base.compilecache()); attempting to create 
>.ji file from a julia source using julia executable with command:
>$JULIA_HOME/bin/julia --output-ji out.ji -- src.jl
>it complains with following message:
>ERROR: could not open file boot.jl 
>
> Here is how compilecache runs julia --output-ji:

https://github.com/JuliaLang/julia/blob/eb172070217bf9ca8daef41092991f5a2e2c49eb/base/loading.jl#L449-L453


>1. *.ji file execution*: I don't know how to start a julia program 
>precompiled in .ji
>
> The undocumented low-level call to load a .ji file is, I believe:

Base._include_from_serialized(open(readbytes, "myfile.ji"))

However, this does not actually execute any code, it just loads the 
functions and constants and modules defined in that .ji file.   You still 
need to run some code in a .jl file that actually calls one of these 
functions.

You have to realize that the .ji file is not really the equivalent of a 
precompiled executable program.  It is more like a precompiled shared 
library.
 

Re: [julia-users] Implicit call problem

[Julia Tylors]

abstract CC;
type C <: CC
#some stuff
end

+{T<:CC}(x::T, y::T) = convert(A,x) + convert(A,y)


This is what you are saying right?
If it is, I don't want to define any more + function, i want it to be 
handled by some sort of a dispatch trick, if it exists...

On Saturday, February 27, 2016 at 12:29:57 PM UTC-8, Erik Schnetter wrote:
>
> You can define an abstract type CC that is a super type of C, and define a 
> fallback + operator for it that converts C to A. If an operator + for C is 
> defined, it will be used instead of the CC operator +.
>
> -erik
>
> On Saturday, February 27, 2016, Julia Tylors  > wrote:
> > Hi, I have a problem i need an implicit call, I wonder whether there is 
> a way to do what i have in mind.
> >
> > +(x::A,y::A) = C(x,y)
> > implicit_match(c::C) = #returns type A,
> > function foo(x::A,Y::A)
> >(x+y) + (x+y)
> > end
> >
> >
> > As you may see in the function foo, once (x+y) is executed, it returns 
> an instance of type C. 
> > now second operation becomes in type C+C , but there is no function like 
> +(c1::C, c2::C),  but i have a match function (implicit_match) which can 
> return an instance of A by looking at the input instance of type C
> > I want this implicit function to be executed once +(::C,::C) is not 
> found. 
> > Can we do something like this?
> > I don't like to define +(::C,::C) or generate +(::C,::C) using a macro.
> > Thanks
>
> -- 
> Erik Schnetter > 
> http://www.perimeterinstitute.ca/personal/eschnetter/
>
>

Re: [julia-users] Implicit call problem

[Erik Schnetter]

You can define an abstract type CC that is a super type of C, and define a
fallback + operator for it that converts C to A. If an operator + for C is
defined, it will be used instead of the CC operator +.

-erik

On Saturday, February 27, 2016, Julia Tylors  wrote:
> Hi, I have a problem i need an implicit call, I wonder whether there is a
way to do what i have in mind.
>
> +(x::A,y::A) = C(x,y)
> implicit_match(c::C) = #returns type A,
> function foo(x::A,Y::A)
>(x+y) + (x+y)
> end
>
>
> As you may see in the function foo, once (x+y) is executed, it returns an
instance of type C.
> now second operation becomes in type C+C , but there is no function like
+(c1::C, c2::C),  but i have a match function (implicit_match) which can
return an instance of A by looking at the input instance of type C
> I want this implicit function to be executed once +(::C,::C) is not
found.
> Can we do something like this?
> I don't like to define +(::C,::C) or generate +(::C,::C) using a macro.
> Thanks

-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

[julia-users] Real-time user input

[Christoph Ortner]

What is the simplest way (performance is not crucial) in Julia to implement 
a very basic game, say moonlander or similar, which needs to translate 
user-input into physics and produce graphical response.

Any links to packages, or examples would be greatly appreciated.

Thanks,
Christoph

[julia-users] Implicit call problem

[Julia Tylors]

Hi, I have a problem i need an implicit call, I wonder whether there is a 
way to do what i have in mind.


+(x::A,y::A) = C(x,y)
implicit_match(c::C) = #returns type A, 
function foo(x::A,Y::A)
   (x+y) + (x+y)
end 


As you may see in the function foo, once (x+y) is executed, it returns an 
instance of type C. 
now second operation becomes in type C+C , but there is no function like 
+(c1::C, c2::C),  but i have a match function (implicit_match) which can 
return an instance of A by looking at the input instance of type C
I want this implicit function to be executed once +(::C,::C) is not found. 

Can we do something like this?

I don't like to define +(::C,::C) or generate +(::C,::C) using a macro.

Thanks

Re: [julia-users] Re: [julia-dev] Re: Google Summer of Code 2016 - Ideas Page

[Ilya Orson]

The Taylor method for ODEs has alredy been implemented within the 
TaylorSeries.jl  package, 
although maybe not too user friendly. 
Check out the Kepler problem 

 example.

El viernes, 26 de febrero de 2016, 9:08:06 (UTC-6), pere...@gmail.com 
escribió:
>
> Hi Mauro,
>
> I would like to submit a proposal to work on the ODE.jl package,
> for the GSoC. From my undergraduate and master thesis I have
> experience with the Taylor method for solving ODEs (ie., based on Taylor
> series expansions). This is a variable order, variable step
> size method, which uses automatic differentiation
> techniques in order to reach high order integration methods (30th, 40th 
> order)
> which enable machine-epsilon precision with very competitive speeds.
> I think the Taylor method is important to include in the ODE.jl package,
> as it is very versatile and precise.
>
> Besides the utility of the Taylor method for ODEs integration, a DAEs 
> solver can
> also be implemented using the Taylor models framework.
>
> I would be very happy to contribute to the ODE.jl package!
>
> Best regards,
>
> On Thursday, February 11, 2016 at 7:56:45 AM UTC-6, Mauro wrote:
>>
>>
>> It is desirable to have ode-solvers which are pure Julia.  Both to cut 
>> down on dependencies and to allow easy hacking and development. 
>> Further, Sundials.jl will not work with generic Julia datatypes (e.g. I 
>> think Julia sparse matrices are not supported for Jacobians).  Thus, 
>> ODE.jl is to stay and to be improved on. 
>>
>> The currently ongoing work of which I'm aware is: 
>> https://github.com/JuliaLang/ODE.jl/pull/49 
>> https://github.com/JuliaLang/ODE.jl/pull/72 
>>
>> Needed work is: 
>> - more solvers 
>> - a unified code structure/API 
>> - parallelism(?) 
>>
>> I'll try and update the GSoC description. 
>>
>

[julia-users] Re: Julia and notepad++

[Ján Adamčák]

Hi Massimo,

Can you make a youtube tutorial how to install it & how to use it???

Thanks :)


Dňa sobota, 27. februára 2016 17:04:11 UTC+1 KK Sasa napísal(-a):
>
> Hi Massimo,
>
> What are the steps to install it?   I cannot make notepad++ recognize 
> it... Thanks!
>
> Best, Keith
>
> Massimo Corinaldesi於 2015年6月5日星期五 UTC+8上午1時26分56秒寫道：
>>
>> Starting from "Notepad++_2_Julia.ahk" and "Julia_Notepad++.xml" i have 
>> written a modified version of autohotkey script and a new theme for 
>> notepad++ (solarized colors). 
>> The script allows to: 
>> - run julia REPL line command and block command from notepad++ (no flick) 
>> - paste text on REPL with Control-V 
>> - scroll window REPL with Control-PageUp/PageDown 
>> - write greek letters on notepad++ 
>>
>> Download (dropbox):  julia_npp.zip 
>>    
>>
>> cameyo 
>>
>>
>>
>>
>>
>> -- 
>> View this message in context: 
>> http://julia-programming-language.2336112.n4.nabble.com/Julia-and-notepad-tp21094.html
>>  
>> Sent from the Julia Users mailing list archive at Nabble.com. 
>>
>

Re: [julia-users] map losing type information?

[Kristoffer Carlsson]

Yes, sorry. I did not read the question carefully enough.

On Saturday, February 27, 2016 at 1:25:23 PM UTC+1, Yichao Yu wrote:
>
> On Sat, Feb 27, 2016 at 4:49 AM, Kristoffer Carlsson 
> > wrote: 
> > Try it not in global scope. 
>
> Global scope has nothing to do with this, it only affect 
> comprehensions and nothing else schematically. 
>

Re: [julia-users] Re: Non-uniform interpolation in 1D

[Tim Holy]

FYI this is covered in the README:

https://github.com/tlycken/Interpolations.jl#gridded-interpolation

--Tim

On Saturday, February 27, 2016 07:57:07 AM Matt Bauman wrote:
> Interpolations is very similar, but it currently only supports linear and
> nearest-neighbor schemes for gridded interpolations:
> 
> using Interpolations
> 
> itp = interpolate((P_NOM,), ETA, Gridded(Linear())) # You pass the x-values
> as a tuple, since this generalizes to multi-dimensional coordinates
> println(itp[3.5])
> 
> x = linspace(1.5, 14.9, 1024)
> y = itp[x]
> 
> plot(x,y)
> 
> On Saturday, February 27, 2016 at 10:10:28 AM UTC-5, Uwe Fechner wrote:
> > Thanks. The following code works:
> > 
> > using Dierckx
> > 
> > P_NOM = [1.5, 2.2, 3.7, 5.6, 7.5, 11.2, 14.9]
> > ETA   = [93., 94., 94., 95., 95., 95.5, 95.5]
> > calc_eta = Spline1D(P_NOM, ETA, k=1)
> > 
> > println(calc_eta(3.5))
> > 
> > Nevertheless I would be interested how to do that with Interpolations.jl.
> > Sometimes you don't have Fortran available.
> > 
> > Best regards:
> > 
> > Uwe
> > 
> > On Saturday, February 27, 2016 at 3:58:11 PM UTC+1, Yichao Yu wrote:
> >> On Sat, Feb 27, 2016 at 9:40 AM, Uwe Fechner 
> >> 
> >> wrote:
> >>> Hello,
> >>> 
> >>> I don't think, that this works on a non-uniform grid. The array xg is
> >>> evenly spaced, and it
> >>> is NOT passed to the function InterpGrid.
> >> 
> >> I've recently tried Dierckx which support non-uniform interpolation. I
> >> only need very basic functions so I don't know if it has all the
> >> flexibility you need but it's probably worth a look if you haven't.
> >> 
> >>> Uwe
> >>> 
> >>> On Saturday, February 27, 2016 at 3:33:06 PM UTC+1, Cedric St-Jean 
wrote:
>  Hi Uwe,
>  
>  Have you tried Grid.jl? I haven't tried it, but this example looks like
>  it might work with a non-uniform grid.
>  
>  # Let's define a quadratic function in one dimension, and evaluate it
>  on an evenly-spaced grid of 5 points: c = 2.3  # center
>  a = 8.1  # quadratic coefficient
>  o = 1.6  # vertical offset
>  qfunc = x -> a*(x-c).^2 + o
>  xg = Float64[1:5]
>  y = qfunc(xg)
>  yi = InterpGrid(y, BCnil, InterpQuadratic)
>  
>  On Saturday, February 27, 2016 at 9:21:53 AM UTC-5, Uwe Fechner wrote:
> > Hello,
> > 
> > I am trying to port the following function from python to julia:
> > 
> > # -*- coding: utf-8 -*-
> > from scipy.interpolate import InterpolatedUnivariateSpline
> > import numpy as np
> > from pylab import plot
> > 
> > P_NOM = [1.5, 2.2, 3.7, 5.6, 7.5, 11.2, 14.9]
> > ETA   = [93., 94., 94., 95., 95., 95.5, 95.5]
> > 
> > calc_eta = InterpolatedUnivariateSpline(P_NOM, ETA, k=1)
> > 
> > # plotting code, only for testing
> > 
> > if __name__ == "__main__":
> > X = np.linspace(1.5, 14.9, 1024, endpoint=True)
> > ETA = []
> > 
> > for alpha in X:
> > eta = calc_eta(alpha)
> > ETA.append(eta)
> > 
> > plot(X, ETA)
> > 
> > The resulting plot is shown at the end of this posting.
> > 
> > How can I port this to Julia?
> > 
> > I am trying to use the package "Interpolations.jl", but I do not see
> > any
> > example, that shows the interpolation on a non-uniform grid.
> > 
> > For now I need only linear interpolation, but I want to use B-Splines
> > later.
> > 
> > Any hint appreciated!
> > 
> > Uwe Fechner
> > 
> > 
> > 
> >  > I/UTLksCCMIPo/s1600/LinearInterpolation.png>

[julia-users] Re: Julia and notepad++

[KK Sasa]

Hi Massimo,

What are the steps to install it?   I cannot make notepad++ recognize it... 
Thanks!

Best, Keith

Massimo Corinaldesi於 2015年6月5日星期五 UTC+8上午1時26分56秒寫道：
>
> Starting from "Notepad++_2_Julia.ahk" and "Julia_Notepad++.xml" i have 
> written a modified version of autohotkey script and a new theme for 
> notepad++ (solarized colors). 
> The script allows to: 
> - run julia REPL line command and block command from notepad++ (no flick) 
> - paste text on REPL with Control-V 
> - scroll window REPL with Control-PageUp/PageDown 
> - write greek letters on notepad++ 
>
> Download (dropbox):  julia_npp.zip 
>    
>
> cameyo 
>
>
>
>
>
> -- 
> View this message in context: 
> http://julia-programming-language.2336112.n4.nabble.com/Julia-and-notepad-tp21094.html
>  
> Sent from the Julia Users mailing list archive at Nabble.com. 
>

Re: [julia-users] Re: Non-uniform interpolation in 1D

[Matt Bauman]

Interpolations is very similar, but it currently only supports linear and 
nearest-neighbor schemes for gridded interpolations:

using Interpolations

itp = interpolate((P_NOM,), ETA, Gridded(Linear())) # You pass the x-values 
as a tuple, since this generalizes to multi-dimensional coordinates
println(itp[3.5])

x = linspace(1.5, 14.9, 1024)
y = itp[x]

plot(x,y)



On Saturday, February 27, 2016 at 10:10:28 AM UTC-5, Uwe Fechner wrote:
>
> Thanks. The following code works:
>
> using Dierckx
>
> P_NOM = [1.5, 2.2, 3.7, 5.6, 7.5, 11.2, 14.9]
> ETA   = [93., 94., 94., 95., 95., 95.5, 95.5]
> calc_eta = Spline1D(P_NOM, ETA, k=1)
>
> println(calc_eta(3.5))
>
> Nevertheless I would be interested how to do that with Interpolations.jl. 
> Sometimes you don't have Fortran available.
>
> Best regards:
>
> Uwe
>
> On Saturday, February 27, 2016 at 3:58:11 PM UTC+1, Yichao Yu wrote:
>>
>>
>>
>> On Sat, Feb 27, 2016 at 9:40 AM, Uwe Fechner  
>> wrote:
>>
>>> Hello,
>>>
>>> I don't think, that this works on a non-uniform grid. The array xg is 
>>> evenly spaced, and it 
>>> is NOT passed to the function InterpGrid.
>>>
>>>
>> I've recently tried Dierckx which support non-uniform interpolation. I 
>> only need very basic functions so I don't know if it has all the 
>> flexibility you need but it's probably worth a look if you haven't.
>>  
>>
>>> Uwe
>>>
>>>
>>> On Saturday, February 27, 2016 at 3:33:06 PM UTC+1, Cedric St-Jean wrote:

 Hi Uwe,

 Have you tried Grid.jl? I haven't tried it, but this example looks like 
 it might work with a non-uniform grid.

 # Let's define a quadratic function in one dimension, and evaluate it on 
 an evenly-spaced grid of 5 points:
 c = 2.3  # center
 a = 8.1  # quadratic coefficient
 o = 1.6  # vertical offset
 qfunc = x -> a*(x-c).^2 + o
 xg = Float64[1:5]
 y = qfunc(xg)
 yi = InterpGrid(y, BCnil, InterpQuadratic)




 On Saturday, February 27, 2016 at 9:21:53 AM UTC-5, Uwe Fechner wrote:
>
> Hello,
>
> I am trying to port the following function from python to julia:
>
> # -*- coding: utf-8 -*-
> from scipy.interpolate import InterpolatedUnivariateSpline
> import numpy as np
> from pylab import plot
>
> P_NOM = [1.5, 2.2, 3.7, 5.6, 7.5, 11.2, 14.9]
> ETA   = [93., 94., 94., 95., 95., 95.5, 95.5]
>
> calc_eta = InterpolatedUnivariateSpline(P_NOM, ETA, k=1)
>
> # plotting code, only for testing
> if __name__ == "__main__":
> X = np.linspace(1.5, 14.9, 1024, endpoint=True)
> ETA = []
> for alpha in X:
> eta = calc_eta(alpha)
> ETA.append(eta)
> plot(X, ETA)
>
> The resulting plot is shown at the end of this posting.
>
> How can I port this to Julia?
>
> I am trying to use the package "Interpolations.jl", but I do not see 
> any
> example, that shows the interpolation on a non-uniform grid.
>
> For now I need only linear interpolation, but I want to use B-Splines
> later.
>
> Any hint appreciated!
>
> Uwe Fechner
>
>
>
> 
>

>>

Re: [julia-users] Incrementally creating a tuple for.

[Kristoffer Carlsson]

Since I only care about square matrices, something like this was the 
fastest of the things I tried:

@generated function get_index{N}(t::NTuple{N}, i::Int, j::Int)
rows = Int(sqrt(N))
return quote
@inbounds v = t[(j-1) * $rows + i]
return v
end
end

@generated function loopdot_flatten{N, T}(A::NTuple{N, T}, B::NTuple{N, T}, 
i, j)
rows = Int(sqrt(N))
return quote
s = zero(T)*zero(T)
@inbounds @simd for k = 1:$rows
s += get_index(A, i, k) * get_index(B, k, j)
end
s
end
end

@generated function unrolled_matmult_flatten{N}(A::NTuple{N}, B::NTuple{N})
rows = Int(sqrt(N))
return Expr(:tuple, [:(loopdot_flatten(A, B, $i, $j)) for i=1:rows, 
j=1:rows]...)
end


function bench_flatten(A)
@time for i in 1:10^5
unrolled_matmult_flatten(A, A)
end
end

It ends up being about 2x slower for 9x9 matrices than a simple loop for 
vectors.

On Friday, February 26, 2016 at 8:27:51 PM UTC+1, Kristoffer Carlsson wrote:
>
> The non inlined version is 5 times slower on 0.5 than 0.4 as well.

[julia-users] Re: regression from 0.43 to 0.5dev, and back to 0.43 on fedora23

[Johannes Wagner]

as an example, the data looks like this:

v = rand(3)
r = rand(6000,3)
x = linspace(1.0, 2.0, 300) * (v./sqrt(sumabs2(v)))'

my function in 0.4 looks like this:

function s04(xl, rl)
result = zeros(size(xl,1))
for i = 1:size(xl,1)
dotprods = rl * xl[i,:]'   
  #1 loops, best of 3: 17.66 µs per loop
imexp  = exp(im .* dotprods)   
#1000 loops, best of 3: 172.33 µs per loop
sumprod  = sum(imexp) * sum(conj(imexp))   #1 
loops, best of 3: 21.04 µs per loop
result[i] = sumprod
end
return result
end

and using @timeit s04(x,r) gives 
10 loops, best of 3: 67.52 ms per loop
where most time is spend in the exp() calls. Now in 0.5dev, the individual 
parts have similar or actually better timings like the dot product:

function s05(xl, rl)
result = zeros(size(xl,1))
for i = 1:size(xl,1)
dotprods = rl * xl[i,:] 
   #1 loops, best of 3: 10.99 µs per loop
imexp  = exp(im .* dotprods)  #1000 
loops, best of 3: 158.50 µs per loop
sumprod  = sum(imexp) * sum(conj(imexp))  #1 loops, 
best of 3: 21.81 µs per loop
result[i] = sumprod
end
return result
end

but @timeit s05(x,r) always gives something ~70% worse runtime:
10 loops, best of 3: 113.80 ms per loop

the summing I replaced then by the blas counterpart, for a modest speedup:

sumprod  = Base.LinAlg.BLAS.asum(imexp) * 
Base.LinAlg.BLAS.asum(conj(imexp))  #1 loops, best of 3: 17.02 µs 
per loop
and the exp() call also runs a bit fast devectorized. But always the same 
on my Fedora23 workstation, individual calls inside the function have 
slightly better performance in 0.5dev, but the whole function is slower. 
And oddly enough only on my Fedora workstation! On a OS X laptop, those 
0.5dev speedups from the parts inside the loop translate in the expected 
speedup for the whole function!
So that puzzles me, perhaps someone can reproduce this with above function 
and input?

cheers, Johannes





On Friday, February 26, 2016 at 4:28:05 PM UTC+1, Kristoffer Carlsson wrote:
>
> What code and where is it spending time? You talk about openblas, does it 
> mean that blas got slower for you? How about peakflops() on the different 
> versions?
>
> On Friday, February 26, 2016 at 4:08:06 PM UTC+1, Johannes Wagner wrote:
>>
>> hey guys,
>> I just experienced something weird. I have some code that runs fine on 
>> 0.43, then I updated to 0.5dev to test the new Arrays, run same code and 
>> noticed it got about ~50% slower. Then I downgraded back to 0.43, ran the 
>> old code, but speed remained slow. I noticed while reinstalling 0.43, 
>> openblas-threads didn't get isntalled along with it. So I manually 
>> installed it, but no change. 
>> Does anyone has an idea what could be going on? LLVM on fedora23 is 3.7
>>
>> Cheers, Johannes
>>
>

[julia-users] Re: regression from 0.43 to 0.5dev, and back to 0.43 on fedora23

[Johannes Wagner]

spending time mostly on exp() calls on an array, other than that a dot 
product and a sum... openblas I only mentioned because it uninstalled 
openblas-threads while uninstalling julia 0.5 (by dnf dependency in fedora) 
and while installing again, openblas-threads did not get installed as 
dependency. I don't know how exactly this might affect runtime as I'm not 
sure how openblas is deployed in the background, especially if you are not 
calling base.LinAlg.BLAS functions explicitly...


On Friday, February 26, 2016 at 4:28:05 PM UTC+1, Kristoffer Carlsson wrote:
>
> What code and where is it spending time? You talk about openblas, does it 
> mean that blas got slower for you? How about peakflops() on the different 
> versions?
>
> On Friday, February 26, 2016 at 4:08:06 PM UTC+1, Johannes Wagner wrote:
>>
>> hey guys,
>> I just experienced something weird. I have some code that runs fine on 
>> 0.43, then I updated to 0.5dev to test the new Arrays, run same code and 
>> noticed it got about ~50% slower. Then I downgraded back to 0.43, ran the 
>> old code, but speed remained slow. I noticed while reinstalling 0.43, 
>> openblas-threads didn't get isntalled along with it. So I manually 
>> installed it, but no change. 
>> Does anyone has an idea what could be going on? LLVM on fedora23 is 3.7
>>
>> Cheers, Johannes
>>
>

[julia-users] Re: Using .ji files

[Samuel Gómez]

I'm afraid there is not still a solution. Isn't it?

I find the same problem :-(

Re: [julia-users] Re: regression from 0.43 to 0.5dev, and back to 0.43 on fedora23

[Johannes Wagner]

I did not compile them, just installed them from the nalimilan/julia and 
nalimilan/julia-nightlies  repos with dnf on fedora23.


On Friday, February 26, 2016 at 4:39:28 PM UTC+1, Yichao Yu wrote:
>
> On Fri, Feb 26, 2016 at 10:28 AM, Kristoffer Carlsson 
> > wrote: 
> > What code and where is it spending time? You talk about openblas, does 
> it 
> > mean that blas got slower for you? How about peakflops() on the 
> different 
> > versions? 
> > 
> > 
> > On Friday, February 26, 2016 at 4:08:06 PM UTC+1, Johannes Wagner wrote: 
> >> 
> >> hey guys, 
> >> I just experienced something weird. I have some code that runs fine on 
> >> 0.43, then I updated to 0.5dev to test the new Arrays, run same code 
> and 
> >> noticed it got about ~50% slower. Then I downgraded back to 0.43, ran 
> the 
> >> old code, but speed remained slow. I noticed while reinstalling 0.43, 
> >> openblas-threads didn't get isntalled along with it. So I manually 
> installed 
> >> it, but no change. 
> >> Does anyone has an idea what could be going on? LLVM on fedora23 is 3.7 
>
> Also, how did you install/compile the two versions. 
>
> >> 
> >> Cheers, Johannes 
>

Re: [julia-users] Re: Non-uniform interpolation in 1D

[Uwe Fechner]

Thanks. The following code works:

using Dierckx

P_NOM = [1.5, 2.2, 3.7, 5.6, 7.5, 11.2, 14.9]
ETA   = [93., 94., 94., 95., 95., 95.5, 95.5]
calc_eta = Spline1D(P_NOM, ETA, k=1)

println(calc_eta(3.5))

Nevertheless I would be interested how to do that with Interpolations.jl. 
Sometimes you don't have Fortran available.

Best regards:

Uwe

On Saturday, February 27, 2016 at 3:58:11 PM UTC+1, Yichao Yu wrote:
>
>
>
> On Sat, Feb 27, 2016 at 9:40 AM, Uwe Fechner  > wrote:
>
>> Hello,
>>
>> I don't think, that this works on a non-uniform grid. The array xg is 
>> evenly spaced, and it 
>> is NOT passed to the function InterpGrid.
>>
>>
> I've recently tried Dierckx which support non-uniform interpolation. I 
> only need very basic functions so I don't know if it has all the 
> flexibility you need but it's probably worth a look if you haven't.
>  
>
>> Uwe
>>
>>
>> On Saturday, February 27, 2016 at 3:33:06 PM UTC+1, Cedric St-Jean wrote:
>>>
>>> Hi Uwe,
>>>
>>> Have you tried Grid.jl? I haven't tried it, but this example looks like 
>>> it might work with a non-uniform grid.
>>>
>>> # Let's define a quadratic function in one dimension, and evaluate it on an 
>>> evenly-spaced grid of 5 points:
>>> c = 2.3  # center
>>> a = 8.1  # quadratic coefficient
>>> o = 1.6  # vertical offset
>>> qfunc = x -> a*(x-c).^2 + o
>>> xg = Float64[1:5]
>>> y = qfunc(xg)
>>> yi = InterpGrid(y, BCnil, InterpQuadratic)
>>>
>>>
>>>
>>>
>>> On Saturday, February 27, 2016 at 9:21:53 AM UTC-5, Uwe Fechner wrote:

 Hello,

 I am trying to port the following function from python to julia:

 # -*- coding: utf-8 -*-
 from scipy.interpolate import InterpolatedUnivariateSpline
 import numpy as np
 from pylab import plot

 P_NOM = [1.5, 2.2, 3.7, 5.6, 7.5, 11.2, 14.9]
 ETA   = [93., 94., 94., 95., 95., 95.5, 95.5]

 calc_eta = InterpolatedUnivariateSpline(P_NOM, ETA, k=1)

 # plotting code, only for testing
 if __name__ == "__main__":
 X = np.linspace(1.5, 14.9, 1024, endpoint=True)
 ETA = []
 for alpha in X:
 eta = calc_eta(alpha)
 ETA.append(eta)
 plot(X, ETA)

 The resulting plot is shown at the end of this posting.

 How can I port this to Julia?

 I am trying to use the package "Interpolations.jl", but I do not see any
 example, that shows the interpolation on a non-uniform grid.

 For now I need only linear interpolation, but I want to use B-Splines
 later.

 Any hint appreciated!

 Uwe Fechner



 

>>>
>

Re: [julia-users] Re: Non-uniform interpolation in 1D

[Yichao Yu]

On Sat, Feb 27, 2016 at 9:40 AM, Uwe Fechner 
wrote:

> Hello,
>
> I don't think, that this works on a non-uniform grid. The array xg is
> evenly spaced, and it
> is NOT passed to the function InterpGrid.
>
>
I've recently tried Dierckx which support non-uniform interpolation. I only
need very basic functions so I don't know if it has all the flexibility you
need but it's probably worth a look if you haven't.


> Uwe
>
>
> On Saturday, February 27, 2016 at 3:33:06 PM UTC+1, Cedric St-Jean wrote:
>>
>> Hi Uwe,
>>
>> Have you tried Grid.jl? I haven't tried it, but this example looks like
>> it might work with a non-uniform grid.
>>
>> # Let's define a quadratic function in one dimension, and evaluate it on an 
>> evenly-spaced grid of 5 points:
>> c = 2.3  # center
>> a = 8.1  # quadratic coefficient
>> o = 1.6  # vertical offset
>> qfunc = x -> a*(x-c).^2 + o
>> xg = Float64[1:5]
>> y = qfunc(xg)
>> yi = InterpGrid(y, BCnil, InterpQuadratic)
>>
>>
>>
>>
>> On Saturday, February 27, 2016 at 9:21:53 AM UTC-5, Uwe Fechner wrote:
>>>
>>> Hello,
>>>
>>> I am trying to port the following function from python to julia:
>>>
>>> # -*- coding: utf-8 -*-
>>> from scipy.interpolate import InterpolatedUnivariateSpline
>>> import numpy as np
>>> from pylab import plot
>>>
>>> P_NOM = [1.5, 2.2, 3.7, 5.6, 7.5, 11.2, 14.9]
>>> ETA   = [93., 94., 94., 95., 95., 95.5, 95.5]
>>>
>>> calc_eta = InterpolatedUnivariateSpline(P_NOM, ETA, k=1)
>>>
>>> # plotting code, only for testing
>>> if __name__ == "__main__":
>>> X = np.linspace(1.5, 14.9, 1024, endpoint=True)
>>> ETA = []
>>> for alpha in X:
>>> eta = calc_eta(alpha)
>>> ETA.append(eta)
>>> plot(X, ETA)
>>>
>>> The resulting plot is shown at the end of this posting.
>>>
>>> How can I port this to Julia?
>>>
>>> I am trying to use the package "Interpolations.jl", but I do not see any
>>> example, that shows the interpolation on a non-uniform grid.
>>>
>>> For now I need only linear interpolation, but I want to use B-Splines
>>> later.
>>>
>>> Any hint appreciated!
>>>
>>> Uwe Fechner
>>>
>>>
>>>
>>> 
>>>
>>

[julia-users] Re: Non-uniform interpolation in 1D

[Uwe Fechner]

Hello,

I don't think, that this works on a non-uniform grid. The array xg is 
evenly spaced, and it 
is NOT passed to the function InterpGrid.

Uwe

On Saturday, February 27, 2016 at 3:33:06 PM UTC+1, Cedric St-Jean wrote:
>
> Hi Uwe,
>
> Have you tried Grid.jl? I haven't tried it, but this example looks like it 
> might work with a non-uniform grid.
>
> # Let's define a quadratic function in one dimension, and evaluate it on an 
> evenly-spaced grid of 5 points:
> c = 2.3  # center
> a = 8.1  # quadratic coefficient
> o = 1.6  # vertical offset
> qfunc = x -> a*(x-c).^2 + o
> xg = Float64[1:5]
> y = qfunc(xg)
> yi = InterpGrid(y, BCnil, InterpQuadratic)
>
>
>
>
> On Saturday, February 27, 2016 at 9:21:53 AM UTC-5, Uwe Fechner wrote:
>>
>> Hello,
>>
>> I am trying to port the following function from python to julia:
>>
>> # -*- coding: utf-8 -*-
>> from scipy.interpolate import InterpolatedUnivariateSpline
>> import numpy as np
>> from pylab import plot
>>
>> P_NOM = [1.5, 2.2, 3.7, 5.6, 7.5, 11.2, 14.9]
>> ETA   = [93., 94., 94., 95., 95., 95.5, 95.5]
>>
>> calc_eta = InterpolatedUnivariateSpline(P_NOM, ETA, k=1)
>>
>> # plotting code, only for testing
>> if __name__ == "__main__":
>> X = np.linspace(1.5, 14.9, 1024, endpoint=True)
>> ETA = []
>> for alpha in X:
>> eta = calc_eta(alpha)
>> ETA.append(eta)
>> plot(X, ETA)
>>
>> The resulting plot is shown at the end of this posting.
>>
>> How can I port this to Julia?
>>
>> I am trying to use the package "Interpolations.jl", but I do not see any
>> example, that shows the interpolation on a non-uniform grid.
>>
>> For now I need only linear interpolation, but I want to use B-Splines
>> later.
>>
>> Any hint appreciated!
>>
>> Uwe Fechner
>>
>>
>>
>> 
>>
>

[julia-users] Re: Non-uniform interpolation in 1D

[Cedric St-Jean]

Actually, nevermind, I misread the documentation, Grid is for a 
regularly-spaced grid of points.

On Saturday, February 27, 2016 at 9:33:06 AM UTC-5, Cedric St-Jean wrote:
>
> Hi Uwe,
>
> Have you tried Grid.jl? I haven't tried it, but this example looks like it 
> might work with a non-uniform grid.
>
> # Let's define a quadratic function in one dimension, and evaluate it on an 
> evenly-spaced grid of 5 points:
> c = 2.3  # center
> a = 8.1  # quadratic coefficient
> o = 1.6  # vertical offset
> qfunc = x -> a*(x-c).^2 + o
> xg = Float64[1:5]
> y = qfunc(xg)
> yi = InterpGrid(y, BCnil, InterpQuadratic)
>
>
>
>
> On Saturday, February 27, 2016 at 9:21:53 AM UTC-5, Uwe Fechner wrote:
>>
>> Hello,
>>
>> I am trying to port the following function from python to julia:
>>
>> # -*- coding: utf-8 -*-
>> from scipy.interpolate import InterpolatedUnivariateSpline
>> import numpy as np
>> from pylab import plot
>>
>> P_NOM = [1.5, 2.2, 3.7, 5.6, 7.5, 11.2, 14.9]
>> ETA   = [93., 94., 94., 95., 95., 95.5, 95.5]
>>
>> calc_eta = InterpolatedUnivariateSpline(P_NOM, ETA, k=1)
>>
>> # plotting code, only for testing
>> if __name__ == "__main__":
>> X = np.linspace(1.5, 14.9, 1024, endpoint=True)
>> ETA = []
>> for alpha in X:
>> eta = calc_eta(alpha)
>> ETA.append(eta)
>> plot(X, ETA)
>>
>> The resulting plot is shown at the end of this posting.
>>
>> How can I port this to Julia?
>>
>> I am trying to use the package "Interpolations.jl", but I do not see any
>> example, that shows the interpolation on a non-uniform grid.
>>
>> For now I need only linear interpolation, but I want to use B-Splines
>> later.
>>
>> Any hint appreciated!
>>
>> Uwe Fechner
>>
>>
>>
>> 
>>
>

[julia-users] Re: Non-uniform interpolation in 1D

[Cedric St-Jean]

Hi Uwe,

Have you tried Grid.jl? I haven't tried it, but this example looks like it 
might work with a non-uniform grid.

# Let's define a quadratic function in one dimension, and evaluate it on an 
evenly-spaced grid of 5 points:
c = 2.3  # center
a = 8.1  # quadratic coefficient
o = 1.6  # vertical offset
qfunc = x -> a*(x-c).^2 + o
xg = Float64[1:5]
y = qfunc(xg)
yi = InterpGrid(y, BCnil, InterpQuadratic)




On Saturday, February 27, 2016 at 9:21:53 AM UTC-5, Uwe Fechner wrote:
>
> Hello,
>
> I am trying to port the following function from python to julia:
>
> # -*- coding: utf-8 -*-
> from scipy.interpolate import InterpolatedUnivariateSpline
> import numpy as np
> from pylab import plot
>
> P_NOM = [1.5, 2.2, 3.7, 5.6, 7.5, 11.2, 14.9]
> ETA   = [93., 94., 94., 95., 95., 95.5, 95.5]
>
> calc_eta = InterpolatedUnivariateSpline(P_NOM, ETA, k=1)
>
> # plotting code, only for testing
> if __name__ == "__main__":
> X = np.linspace(1.5, 14.9, 1024, endpoint=True)
> ETA = []
> for alpha in X:
> eta = calc_eta(alpha)
> ETA.append(eta)
> plot(X, ETA)
>
> The resulting plot is shown at the end of this posting.
>
> How can I port this to Julia?
>
> I am trying to use the package "Interpolations.jl", but I do not see any
> example, that shows the interpolation on a non-uniform grid.
>
> For now I need only linear interpolation, but I want to use B-Splines
> later.
>
> Any hint appreciated!
>
> Uwe Fechner
>
>
>
> 
>

[julia-users] Non-uniform interpolation in 1D

[Uwe Fechner]

Hello,

I am trying to port the following function from python to julia:

# -*- coding: utf-8 -*-
from scipy.interpolate import InterpolatedUnivariateSpline
import numpy as np
from pylab import plot

P_NOM = [1.5, 2.2, 3.7, 5.6, 7.5, 11.2, 14.9]
ETA   = [93., 94., 94., 95., 95., 95.5, 95.5]

calc_eta = InterpolatedUnivariateSpline(P_NOM, ETA, k=1)

# plotting code, only for testing
if __name__ == "__main__":
X = np.linspace(1.5, 14.9, 1024, endpoint=True)
ETA = []
for alpha in X:
eta = calc_eta(alpha)
ETA.append(eta)
plot(X, ETA)

The resulting plot is shown at the end of this posting.

How can I port this to Julia?

I am trying to use the package "Interpolations.jl", but I do not see any
example, that shows the interpolation on a non-uniform grid.

For now I need only linear interpolation, but I want to use B-Splines
later.

Any hint appreciated!

Uwe Fechner

[julia-users] Re: Polymorphic functions definition

[Adrian Salceanu]

Thanks, I managed to figure it out by re-re-re-reading the docs. I was 
suspecting that the answer will be about parametric types. 

function df_to_m{T<:Jinnie.Jinnie_Model}(df::DataFrames.DataFrame, m::T) # 
works!


sâmbătă, 27 februarie 2016, 09:31:23 UTC+1, Adrian Salceanu a scris:
>
> Hi, 
>
> I stumbled upon an issue in my code and I can't quite figure out the 
> behavior. Any hints would be much appreciated, thanks in advance. 
>
> So, I have a function: 
>
> function df_to_m(df::DataFrames.DataFrame, m::Jinnie_Model)
>
> It iterates over each row of the df DataFrame and instantiates the 
> corresponding m model type, returning an array of m model instances. 
>
> For example, say if I have this DataFrame (*df*)
>
> 1x3 DataFrames.DataFrame
> | Row | name| url   | updated_at   
> |
>
> |-|-|---|--|
> | 1   | "Bokeh" | "git://github.com/bokeh/Bokeh.jl.git" | "2016-02-10 
> 19:21:57.209996" |
>
> I would call 
>
> df_to_m(df, Jinnie.Package()) 
>
> and expect to get 
>
> 1-element Array{Any,1}:
>  Jinnie.Package("packages","name","Bokeh","git://
> github.com/bokeh/Bokeh.jl.git")
>
> where Jinnie_Model is an abstract type defined in the Jinnie module as
>
> abstract Jinnie_Model
>
> and Jinnie.Package extends Jinnie_Model
>
> type Package <: Jinnie_Model
>   _table_name::AbstractString
>   _id::AbstractString
>   name::AbstractString
>   url::AbstractString
>
>   Package(; name = "", url = "") = new("packages", "name", name, url)
> end
>
> However, the problem is that df_to_m does not want to accept subtypes of 
> Jinnie_Model: 
>
> ERROR: MethodError: `df_to_m` has no method matching 
> df_to_m(::DataFrames.DataFrame, ::Jinnie.Package)
> Closest candidates are:
>   df_to_m(::DataFrames.DataFrame, ::Jinnie.Jinnie_Model)
>
> If I drop the type constraint in the function's definition, it works 
> great, as expected: 
>
> function df_to_m(df::DataFrames.DataFrame, m) # this version works
>
> ==
>
> My questions are: 
>
> 1. how can I get the function to accept subtypes of Jinnie_Model while 
> keeping the type constraint? 
>
> 2. I don't like passing instances like Jinnie.Package() and I would 
> rather pass the type itself Jinnie.Package into the polymorphic function. 
> It's a crappy code smell so I must be doing something wrong. 
>
> I experimented with defining the function as 
>
> function df_to_m(df::DataFrames.DataFrame, m::Type{Jinnie.Jinnie_Model})
>
> but got the same error, polymorphism be damned. 
>
> ERROR: MethodError: `df_to_m` has no method matching 
> df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Package})
> Closest candidates are:
>   df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Jinnie_Model})
>
> How could the function be defined to work with the types itself (rather 
> than instances) and be polymorphic as intended? 
>
> Thanks for your time. 
>
> Cheers
>

[julia-users] Re: Polymorphic functions definition

[Adrian Salceanu]

Still not sure though how to go about using the actual types as params, 
rather than an instance of that type. 


sâmbătă, 27 februarie 2016, 14:56:47 UTC+1, Adrian Salceanu a scris:
>
> Thanks, I managed to figure it out by re-re-re-reading the docs. I was 
> suspecting that the answer will be about parametric types. 
>
> function df_to_m{T<:Jinnie.Jinnie_Model}(df::DataFrames.DataFrame, m::T) # 
> works!
>
> Is this the only way? I'm fine with it (it's very explicit upon reading) 
> but it's unexpected coming from OOP where you get polymorphism out of the 
> box (subtypes can be used instead of the parent type, without needing 
> anything else).
>
>
> sâmbătă, 27 februarie 2016, 09:31:23 UTC+1, Adrian Salceanu a scris:
>>
>> Hi, 
>>
>> I stumbled upon an issue in my code and I can't quite figure out the 
>> behavior. Any hints would be much appreciated, thanks in advance. 
>>
>> So, I have a function: 
>>
>> function df_to_m(df::DataFrames.DataFrame, m::Jinnie_Model)
>>
>> It iterates over each row of the df DataFrame and instantiates the 
>> corresponding m model type, returning an array of m model instances. 
>>
>> For example, say if I have this DataFrame (*df*)
>>
>> 1x3 DataFrames.DataFrame
>> | Row | name| url   | updated_at 
>>   |
>>
>> |-|-|---|--|
>> | 1   | "Bokeh" | "git://github.com/bokeh/Bokeh.jl.git" | "2016-02-10 
>> 19:21:57.209996" |
>>
>> I would call 
>>
>> df_to_m(df, Jinnie.Package()) 
>>
>> and expect to get 
>>
>> 1-element Array{Any,1}:
>>  Jinnie.Package("packages","name","Bokeh","git://
>> github.com/bokeh/Bokeh.jl.git")
>>
>> where Jinnie_Model is an abstract type defined in the Jinnie module as
>>
>> abstract Jinnie_Model
>>
>> and Jinnie.Package extends Jinnie_Model
>>
>> type Package <: Jinnie_Model
>>   _table_name::AbstractString
>>   _id::AbstractString
>>   name::AbstractString
>>   url::AbstractString
>>
>>   Package(; name = "", url = "") = new("packages", "name", name, url)
>> end
>>
>> However, the problem is that df_to_m does not want to accept subtypes of 
>> Jinnie_Model: 
>>
>> ERROR: MethodError: `df_to_m` has no method matching 
>> df_to_m(::DataFrames.DataFrame, ::Jinnie.Package)
>> Closest candidates are:
>>   df_to_m(::DataFrames.DataFrame, ::Jinnie.Jinnie_Model)
>>
>> If I drop the type constraint in the function's definition, it works 
>> great, as expected: 
>>
>> function df_to_m(df::DataFrames.DataFrame, m) # this version works
>>
>> ==
>>
>> My questions are: 
>>
>> 1. how can I get the function to accept subtypes of Jinnie_Model while 
>> keeping the type constraint? 
>>
>> 2. I don't like passing instances like Jinnie.Package() and I would 
>> rather pass the type itself Jinnie.Package into the polymorphic 
>> function. It's a crappy code smell so I must be doing something wrong. 
>>
>> I experimented with defining the function as 
>>
>> function df_to_m(df::DataFrames.DataFrame, m::Type{Jinnie.Jinnie_Model})
>>
>> but got the same error, polymorphism be damned. 
>>
>> ERROR: MethodError: `df_to_m` has no method matching 
>> df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Package})
>> Closest candidates are:
>>   df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Jinnie_Model})
>>
>> How could the function be defined to work with the types itself (rather 
>> than instances) and be polymorphic as intended? 
>>
>> Thanks for your time. 
>>
>> Cheers
>>
>

[julia-users] Re: Polymorphic functions definition

[Adrian Salceanu]

Thanks, I managed to figure it out by re-re-re-reading the docs. I was 
suspecting that the answer will be about parametric types. 

function df_to_m{T<:Jinnie.Jinnie_Model}(df::DataFrames.DataFrame, m::T) # 
works!

Is this the only way? I'm fine with it (it's very explicit upon reading) 
but it's unexpected coming from OOP where you get polymorphism out of the 
box (subtypes can be used instead of the parent type, without needing 
anything else).


sâmbătă, 27 februarie 2016, 09:31:23 UTC+1, Adrian Salceanu a scris:
>
> Hi, 
>
> I stumbled upon an issue in my code and I can't quite figure out the 
> behavior. Any hints would be much appreciated, thanks in advance. 
>
> So, I have a function: 
>
> function df_to_m(df::DataFrames.DataFrame, m::Jinnie_Model)
>
> It iterates over each row of the df DataFrame and instantiates the 
> corresponding m model type, returning an array of m model instances. 
>
> For example, say if I have this DataFrame (*df*)
>
> 1x3 DataFrames.DataFrame
> | Row | name| url   | updated_at   
> |
>
> |-|-|---|--|
> | 1   | "Bokeh" | "git://github.com/bokeh/Bokeh.jl.git" | "2016-02-10 
> 19:21:57.209996" |
>
> I would call 
>
> df_to_m(df, Jinnie.Package()) 
>
> and expect to get 
>
> 1-element Array{Any,1}:
>  Jinnie.Package("packages","name","Bokeh","git://
> github.com/bokeh/Bokeh.jl.git")
>
> where Jinnie_Model is an abstract type defined in the Jinnie module as
>
> abstract Jinnie_Model
>
> and Jinnie.Package extends Jinnie_Model
>
> type Package <: Jinnie_Model
>   _table_name::AbstractString
>   _id::AbstractString
>   name::AbstractString
>   url::AbstractString
>
>   Package(; name = "", url = "") = new("packages", "name", name, url)
> end
>
> However, the problem is that df_to_m does not want to accept subtypes of 
> Jinnie_Model: 
>
> ERROR: MethodError: `df_to_m` has no method matching 
> df_to_m(::DataFrames.DataFrame, ::Jinnie.Package)
> Closest candidates are:
>   df_to_m(::DataFrames.DataFrame, ::Jinnie.Jinnie_Model)
>
> If I drop the type constraint in the function's definition, it works 
> great, as expected: 
>
> function df_to_m(df::DataFrames.DataFrame, m) # this version works
>
> ==
>
> My questions are: 
>
> 1. how can I get the function to accept subtypes of Jinnie_Model while 
> keeping the type constraint? 
>
> 2. I don't like passing instances like Jinnie.Package() and I would 
> rather pass the type itself Jinnie.Package into the polymorphic function. 
> It's a crappy code smell so I must be doing something wrong. 
>
> I experimented with defining the function as 
>
> function df_to_m(df::DataFrames.DataFrame, m::Type{Jinnie.Jinnie_Model})
>
> but got the same error, polymorphism be damned. 
>
> ERROR: MethodError: `df_to_m` has no method matching 
> df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Package})
> Closest candidates are:
>   df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Jinnie_Model})
>
> How could the function be defined to work with the types itself (rather 
> than instances) and be polymorphic as intended? 
>
> Thanks for your time. 
>
> Cheers
>

[julia-users] Re: [ANN] GLVisualize

[Simon Danisch]

Thanks :)

>I wonder if it will be the Matplotlib of Julia

While possible, it will need quite a bit of work :) Offering the 
flexibility and usability of Matplotlib is no easy task! 
Right now the strength rather lies in interactivity and easy means to 
visualize animated and large data sets.

But there could be shortcuts like implementing a backend for Matplotlib 
first.

@Alan, I can create one ;)
Also, as you can see in http://www.glvisualize.com/examples/interactive/, 
something similar to @manipulate can be implemented in GLVisualize.

Am Freitag, 26. Februar 2016 23:11:02 UTC+1 schrieb Simon Danisch:
>
> Hi
>
> this is the first release of GLVisualize.jl 
> , a 2D/3D visualization 
> library completely written in Julia and OpenGL.
>
> You can find some crude documentation on glvisualize.com 
> .
> I hope to improve the examples and the documentation in the coming weeks.
> The biggest problem for most people right now will be a slightly flaky 
> camera and missing guides and labels.
> This is being worked on! If someone beats me to the guide/axis creation, 
> I'd be very happy. This could be a fun project to get started with 
> GLVisualize.
> Please feel free to open any issue concerning missing documentation, 
> discrepancies  and 
> bugs!
>
> Relation to GLPlot :
> GLPlot is now a thin wrapper for GLVisualize with a focus on plotting. 
> Since I concentrated mostly on finishing GLVisualize, it's a reeally thin 
> wrapper. 
> It basically just forwards all calls to GLVisualize, and adds a 
> boundingbox around the objects. 
> In the future, it should offer some basic UI, automatic creation of 
> axis/labels, screenshots and an alternative API that is more familiar to 
> people that are coming from other plotting libraries (e.g. functions like 
> surf, contourf, patches).
> If anyone has specific plans on how this could look like don't hesitate to 
> open issues and PR's!
>
> Outlook:
> I'd like to make GLVisualize more independent of the rendering backend by 
> using some backend agnostic geometry 
>  
> representation.
> This will make it easier to integrate backends like FireRender 
> , WebGL, Vulkan 
>  (why Vulkan 
> ), 
> or some text based backends like PDF/SVG.
>
> Furthermore, I'd like to improve the performance and interaction 
> possibilities.
>
> I have to thank the Julia Group for supporting me :) It's a pleasure to be 
> a part of the Julia community!
>
> I'm looking forward to the great visualizations you'll create!
>
> Best,
> Simon Danisch
>

Re: [julia-users] map losing type information?

[Yichao Yu]

On Sat, Feb 27, 2016 at 4:49 AM, Kristoffer Carlsson
 wrote:
> Try it not in global scope.

Global scope has nothing to do with this, it only affect
comprehensions and nothing else schematically.

[julia-users] Re: [ANN] GLVisualize

[Alan Edelman]

Haven't looked yet.  Is there an example that works with @manipulate?

On Sat, Feb 27, 2016 at 5:05 AM, Sisyphuss  wrote:

> It's just fantastic! I wonder if it will be the Matplotlib of Julia
>
>
> On Friday, February 26, 2016 at 11:11:02 PM UTC+1, Simon Danisch wrote:
>>
>> Hi
>>
>> this is the first release of GLVisualize.jl
>> , a 2D/3D visualization
>> library completely written in Julia and OpenGL.
>>
>> You can find some crude documentation on glvisualize.com
>> .
>> I hope to improve the examples and the documentation in the coming weeks.
>> The biggest problem for most people right now will be a slightly flaky
>> camera and missing guides and labels.
>> This is being worked on! If someone beats me to the guide/axis creation,
>> I'd be very happy. This could be a fun project to get started with
>> GLVisualize.
>> Please feel free to open any issue concerning missing documentation,
>> discrepancies  and
>> bugs!
>>
>> Relation to GLPlot :
>> GLPlot is now a thin wrapper for GLVisualize with a focus on plotting.
>> Since I concentrated mostly on finishing GLVisualize, it's a reeally thin
>> wrapper.
>> It basically just forwards all calls to GLVisualize, and adds a
>> boundingbox around the objects.
>> In the future, it should offer some basic UI, automatic creation of
>> axis/labels, screenshots and an alternative API that is more familiar to
>> people that are coming from other plotting libraries (e.g. functions like
>> surf, contourf, patches).
>> If anyone has specific plans on how this could look like don't hesitate
>> to open issues and PR's!
>>
>> Outlook:
>> I'd like to make GLVisualize more independent of the rendering backend by
>> using some backend agnostic geometry
>> 
>> representation.
>> This will make it easier to integrate backends like FireRender
>> , WebGL, Vulkan
>>  (why Vulkan
>> ),
>> or some text based backends like PDF/SVG.
>>
>> Furthermore, I'd like to improve the performance and interaction
>> possibilities.
>>
>> I have to thank the Julia Group for supporting me :) It's a pleasure to
>> be a part of the Julia community!
>>
>> I'm looking forward to the great visualizations you'll create!
>>
>> Best,
>> Simon Danisch
>>
>

Re: [julia-users] [ANN] GLVisualize

[Tim Holy]

Congrats and thanks, Simon! You've really moved mountains here.

The MIP demo is especially appreciated.

Best,
--Tim

On Friday, February 26, 2016 02:11:02 PM Simon Danisch wrote:
> Hi
> 
> this is the first release of GLVisualize.jl
> , a 2D/3D visualization library
> completely written in Julia and OpenGL.
> 
> You can find some crude documentation on glvisualize.com
> .
> I hope to improve the examples and the documentation in the coming weeks.
> The biggest problem for most people right now will be a slightly flaky
> camera and missing guides and labels.
> This is being worked on! If someone beats me to the guide/axis creation,
> I'd be very happy. This could be a fun project to get started with
> GLVisualize.
> Please feel free to open any issue concerning missing documentation,
> discrepancies  and
> bugs!
> 
> Relation to GLPlot :
> GLPlot is now a thin wrapper for GLVisualize with a focus on plotting.
> Since I concentrated mostly on finishing GLVisualize, it's a reeally thin
> wrapper.
> It basically just forwards all calls to GLVisualize, and adds a boundingbox
> around the objects.
> In the future, it should offer some basic UI, automatic creation of
> axis/labels, screenshots and an alternative API that is more familiar to
> people that are coming from other plotting libraries (e.g. functions like
> surf, contourf, patches).
> If anyone has specific plans on how this could look like don't hesitate to
> open issues and PR's!
> 
> Outlook:
> I'd like to make GLVisualize more independent of the rendering backend by
> using some backend agnostic geometry
> 
> representation.
> This will make it easier to integrate backends like FireRender
> , WebGL, Vulkan
>  (why Vulkan
> ),
> or some text based backends like PDF/SVG.
> 
> Furthermore, I'd like to improve the performance and interaction
> possibilities.
> 
> I have to thank the Julia Group for supporting me :) It's a pleasure to be
> a part of the Julia community!
> 
> I'm looking forward to the great visualizations you'll create!
> 
> Best,
> Simon Danisch

[julia-users] Deferred compilation after functions overhaul - PatternDispatch.jl

[Toivo Henningsson]

I've recently upgraded the PatternDispatch.jl 
 package to work with Julia 
0.4, and am trying to figure out if I can make it work with Julia master as 
well. However it seems that the functions overhaul will force me to find a 
somewhat new approach. I'll try to describe my problem below in the hope to 
get some ideas how it can be solved with a new Julia:

Example: Given pattern method definitions

@pattern f(x) =  x
@pattern f(2) = 42

the package generates code along the lines of

const f = (args...)->dispatch(args...)

match1(x) =  x
match2()  = 42

dispatch(x::Any) = match1(x_1)
function dispatch(x::Int64)
if x === 2; match2()
else;   match1(x)
end
end


The reason to create the closure f is to prevent the user from overloading 
the pattern function with regular methods, which might break the dispatch.

Here's the problem: When should the code given above be generated and 
compiled?

   - The definition for the closure f has to be emitted already from the 
   first macro invocation, to associate the name f with the pattern 
   function.
   - The rest of the code can't be generated before the last macro 
   invocation (@pattern f(2) = 42) has been encountered.

Ideally, we would like to generate the dispatch code the first time that f 
is called.

In previous Julia versions, I was able to make an initial dispatch method 
that would invoke code generation and then eval new overloads for the same 
function, hiding the old method with the generated ones. But after the 
function overhaul, I guess that f is compiled to use the old dispatch 
method when it is first called, and doesn't care that it becomes overloaded 
afterwards.

How can I make code generation happen the first time that f is called? The 
first thing that comes to mind is making f call a generated function that 
will generate the dispatch code. But as far as I can remember, there is no 
guarantee that code generation for the generated function waits for the 
first time that it is called. Would this be safe? Is there a better way?

[julia-users] [ANN] PatternDispatch v0.2 with Julia 0.4 support

[Toivo Henningsson]

I finally found some time to upgrade the PatternDispatch 
package to support Julia 0.4 
(and 0.3).
The package allows to overload functions based on patterns which can be 
more fine granular than matching argument types for each argument (as 
Julia's multiple dispatch does). A simple example is

@pattern f(x) =  x
@pattern f(2) = 42

 
where the second method matches only if the argument === 2.

[julia-users] Tutorials and examples on threading

[pevnak]

Hi All,
I know that julia does not have at the moment native support for threads, but 
it exist in an experimental branch. Is there any tutorial on this, such that 
average user can try it? I would like to try it speed my code. I do separate 
processes at the moment and I think the overhead is enormous.
Thanks a lot for the answers.
Tomas

[julia-users] Re: [ANN] GLVisualize

[Sisyphuss]

It's just fantastic! I wonder if it will be the Matplotlib of Julia

On Friday, February 26, 2016 at 11:11:02 PM UTC+1, Simon Danisch wrote:
>
> Hi
>
> this is the first release of GLVisualize.jl 
> , a 2D/3D visualization 
> library completely written in Julia and OpenGL.
>
> You can find some crude documentation on glvisualize.com 
> .
> I hope to improve the examples and the documentation in the coming weeks.
> The biggest problem for most people right now will be a slightly flaky 
> camera and missing guides and labels.
> This is being worked on! If someone beats me to the guide/axis creation, 
> I'd be very happy. This could be a fun project to get started with 
> GLVisualize.
> Please feel free to open any issue concerning missing documentation, 
> discrepancies  and 
> bugs!
>
> Relation to GLPlot :
> GLPlot is now a thin wrapper for GLVisualize with a focus on plotting. 
> Since I concentrated mostly on finishing GLVisualize, it's a reeally thin 
> wrapper. 
> It basically just forwards all calls to GLVisualize, and adds a 
> boundingbox around the objects. 
> In the future, it should offer some basic UI, automatic creation of 
> axis/labels, screenshots and an alternative API that is more familiar to 
> people that are coming from other plotting libraries (e.g. functions like 
> surf, contourf, patches).
> If anyone has specific plans on how this could look like don't hesitate to 
> open issues and PR's!
>
> Outlook:
> I'd like to make GLVisualize more independent of the rendering backend by 
> using some backend agnostic geometry 
>  
> representation.
> This will make it easier to integrate backends like FireRender 
> , WebGL, Vulkan 
>  (why Vulkan 
> ), 
> or some text based backends like PDF/SVG.
>
> Furthermore, I'd like to improve the performance and interaction 
> possibilities.
>
> I have to thank the Julia Group for supporting me :) It's a pleasure to be 
> a part of the Julia community!
>
> I'm looking forward to the great visualizations you'll create!
>
> Best,
> Simon Danisch
>

[julia-users] map losing type information?

[Kristoffer Carlsson]

Try it not in global scope. 

[julia-users] Polymorphic functions definition

[Adrian Salceanu]

Hi, 

I stumbled upon an issue in my code and I can't quite figure out the 
behavior. Any hints would be much appreciated, thanks in advance. 

So, I have a function: 

function df_to_m(df::DataFrames.DataFrame, m::Jinnie_Model)

It iterates over each row of the df DataFrame and instantiates the 
corresponding m model type, returning an array of m model instances. 

For example, say if I have this DataFrame (*df*)

1x3 DataFrames.DataFrame
| Row | name| url   | updated_at   
|
|-|-|---|--|
| 1   | "Bokeh" | "git://github.com/bokeh/Bokeh.jl.git" | "2016-02-10 
19:21:57.209996" |

I would call 

df_to_m(df, Jinnie.Package()) 

and expect to get 

1-element Array{Any,1}:
 Jinnie.Package("packages","name","Bokeh","git://github.com/bokeh/Bokeh.jl.git")

where Jinnie_Model is an abstract type defined in the Jinnie module as

abstract Jinnie_Model

and Jinnie.Package extends Jinnie_Model

type Package <: Jinnie_Model
  _table_name::AbstractString
  _id::AbstractString
  name::AbstractString
  url::AbstractString

  Package(; name = "", url = "") = new("packages", "name", name, url)
end

However, the problem is that df_to_m does not want to accept subtypes of 
Jinnie_Model: 

ERROR: MethodError: `df_to_m` has no method matching 
df_to_m(::DataFrames.DataFrame, ::Jinnie.Package)
Closest candidates are:
  df_to_m(::DataFrames.DataFrame, ::Jinnie.Jinnie_Model)

If I drop the type constraint in the function's definition, it works great, 
as expected: 

function df_to_m(df::DataFrames.DataFrame, m) # this version works

==

My questions are: 

1. how can I get the function to accept subtypes of Jinnie_Model while 
keeping the type constraint? 

2. I don't like passing instances like Jinnie.Package() and I would rather 
pass the type itself Jinnie.Package into the polymorphic function. It's a 
crappy code smell so I must be doing something wrong. 

I experimented with defining the function as 

function df_to_m(df::DataFrames.DataFrame, m::Type{Jinnie.Jinnie_Model})

but got the same error, polymorphism be damned. 

ERROR: MethodError: `df_to_m` has no method matching 
df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Package})
Closest candidates are:
  df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Jinnie_Model})

How could the function be defined to work with the types itself (rather 
than instances) and be polymorphic as intended? 

Thanks for your time. 

Cheers