[julia-users] Re: Any serious quant finance package for Julia?

[Avik Sengupta]

My hope has been that Ito would become the consolidated financial math 
package, with functionality similar to Quantlib. Unfortunately, while I 
laid down the base, I haven't made as much progress as I would have liked 
(primarily for lack of time), but I do hope to rectify that in the near 
future. Needless to say, contributions welcome. 


On Friday, 11 September 2015 07:05:39 UTC+1, Ferenc Szalma wrote:
>
> Are there any quant finance packages for Julia? I see some rudimentary 
> calendar and day-counting in Ito.js for example but not much for even a 
> simple yield2price or price2yield or any bond objects in Julia packages on 
> GitHub. What is the best approach, using C++ function/object from Quantlib, 
> to finance in Julia?
>

[julia-users] Any serious quant finance package for Julia?

[Ferenc Szalma]

Are there any quant finance packages for Julia? I see some rudimentary 
calendar and day-counting in Ito.js for example but not much for even a 
simple yield2price or price2yield or any bond objects in Julia packages on 
GitHub. What is the best approach, using C++ function/object from Quantlib, 
to finance in Julia?

[julia-users] Re: Error when including file with umlaut

[bernhard]

Thank. That does indeed solve the problem. My mistake.
Interestingly I have various other files with umlauts which are ANSI 
(according to notepad++) encoded and these work just fine (e.g. the 
attached test2.jl). There seems to be something peculiar about the test.jl 
file.

Am Donnerstag, 10. September 2015 19:22:15 UTC+2 schrieb Steven G. Johnson:
>
> Julia requires source code to be in the UTF-8 encoding of Unicode.  It 
> looks like you are using the non-Unicode iso-8859-1 (or Windows-1252) 
> encoding.
>


test2.jl
Description: Binary data

Re: [julia-users] Re: 'in' should carry out more typechecking

[Jeffrey Sarnoff]

"Is it coherent to ask whether any two things are equal"

def:  "yes" is the reply that follows recognized equality and "no" is the 
reply that does not
obs:  recognition of equality is situated  { ≟(2, 2)  ≟(2, *2*)  ≟(2, teuw) 
} 
yes






On Thursday, September 10, 2015 at 11:54:52 PM UTC-4, Jeff Bezanson wrote:
>
> I think there are some viable options here, for example making numbers 
> non-iterable, and/or doing some combination of checks and conversions. 
> However splitting Base for this purpose is nowhere near viable. It's a 
> cop-out design: we can't decide which behavior is right, so we just 
> give you both and make you pick. Very confusing. If you need to do 
> something extra to enable convenient mode, then it's not convenient. 
> Or, on the other side, if every style guide is going to recommend 
> enabling strict mode because otherwise your program is a mess, why 
> provide an alternative at all? 
>
> Unfortunately, at the bottom of this issue there is a fundamental 
> philosophical debate that may not be possible to resolve with design 
> choices. Namely, is equality a total theory? Is it coherent to ask 
> whether any two things are equal, or do the arguments first have to 
> clear some hurdle of commensurability? It's no secret that julia is 
> biased from the beginning towards the former, no-hurdles view. It 
> would be great if the two sides in this debate could just get along 
> somehow, but it doesn't seem like something we're likely to resolve 
> here. 
>
> On Thu, Sep 10, 2015 at 5:20 PM,  > 
> wrote: 
> > Jeff, 
> > 
> > Thanks very much for pointing out the issue that I opened last year.  I 
> had 
> > thought incorrectly that I had raised the matter of type-checking with 
> 'in' 
> > on this newsgroup rather than on github, which explains why I couldn't 
> > locate the previous discussion in my first post today. 
> > 
> > I am bringing the subject up again because I understand Julia much 
> better 
> > now, and I have realized that a main cause for the loose type-checking 
> is 
> > the plethora of methods in Base (e.g., the start/next/done functions 
> that 
> > turn a Float64 into an iterable) that create certain conveniences but 
> also 
> > create many possibilities for programmer blunders.  Now that I 
> understand 
> > the cause of the loose type-checking, I am able to propose a 
> (relatively) 
> > simple solution, which is to split Base into two parts: essentials and 
> > conveniences 
> > 
> > -- Steve 
> > 
> > 
> > On Thursday, September 10, 2015 at 2:31:39 PM UTC-4, Jeff Bezanson 
> wrote: 
> >> 
> >> If anybody is interested and missed it the first time around, there is 
> >> some good discussion of this in 
> >> https://github.com/JuliaLang/julia/issues/7903. 
> >> 
> >> On Thu, Sep 10, 2015 at 2:01 PM, Randy Zwitch 
> >>  wrote: 
> >> > How do you enumerate all of the cases that are "oddball"? 
> >> > 
> >> > julia> [1,2,3] in Any[[1],[2],[3],[1,2,3]] 
> >> > 
> >> > true 
> >> > 
> >> > 
> >> > julia> [1,2,3] in [[1],[2],[3],[1,2,3]] 
> >> > 
> >> > false 
> >> > 
> >> > 
> >> > In the first case, because I declare the array of type "Any", I have 
> an 
> >> > Array of Arrays (Array{Any, 1}). In that case, the "in" statement is 
> >> > perfectly valid to test for and is true. 
> >> > 
> >> > 
> >> > In the second case, you get false. What's difficult here is that I 
> think 
> >> > the 
> >> > compiler is confused due to the change in concentation syntax: 
> >> > 
> >> > 
> >> > julia> typeof([[1],[2],[3],[1,2,3]]) 
> >> > 
> >> > WARNING: [a,b,...] concatenation is deprecated; use [a;b;...] instead 
> >> > 
> >> >  in depwarn at ./deprecated.jl:73 
> >> > 
> >> >  in oldstyle_vcat_warning at ./abstractarray.jl:29 
> >> > 
> >> >  in vect at abstractarray.jl:32 
> >> > 
> >> > while loading no file, in expression starting on line 0 
> >> > 
> >> > Array{Int64,1} 
> >> > 
> >> > 
> >> > 
> >> > I'm not proposing a solution, just highlighting that it would be 
> pretty 
> >> > difficult to protect everyone from themselves. At some point, people 
> >> > need to 
> >> > be precise about what they mean. 
> >> > 
> >> > 
> >> > 
> >> > 
> >> > On Thursday, September 10, 2015 at 12:59:59 PM UTC-4, 
> >> > vav...@uwaterloo.ca 
> >> > wrote: 
> >> >> 
> >> >> About a year ago I proposed on this forum that 'in' should do more 
> >> >> type-checking.  For example, the expression 
> >> >> 
> >> >>[1,2,3] in [1,2,3,4] 
> >> >> 
> >> >> is almost certainly a programmer error.  But Julia accepts it 
> without 
> >> >> complaint and returns 'false'.  I myself have had problems with the 
> >> >> wrong 
> >> >> version of 'in' getting called and nonsensical results returned. 
> >> >> 
> >> >> The argument raised against this proposal was the following. 
>  According 
> >> >> to 
> >> >> Julia semantics, "a in b" is equivalent to 
> >> >> 
> >> >>  for x in b 
> >> >> if x==a 
> >> >>return true 
> >> >> end 
> >> >>  end 
> >> >>  retur

Re: [julia-users] Re: 'in' should carry out more typechecking

[Jeff Bezanson]

I think there are some viable options here, for example making numbers
non-iterable, and/or doing some combination of checks and conversions.
However splitting Base for this purpose is nowhere near viable. It's a
cop-out design: we can't decide which behavior is right, so we just
give you both and make you pick. Very confusing. If you need to do
something extra to enable convenient mode, then it's not convenient.
Or, on the other side, if every style guide is going to recommend
enabling strict mode because otherwise your program is a mess, why
provide an alternative at all?

Unfortunately, at the bottom of this issue there is a fundamental
philosophical debate that may not be possible to resolve with design
choices. Namely, is equality a total theory? Is it coherent to ask
whether any two things are equal, or do the arguments first have to
clear some hurdle of commensurability? It's no secret that julia is
biased from the beginning towards the former, no-hurdles view. It
would be great if the two sides in this debate could just get along
somehow, but it doesn't seem like something we're likely to resolve
here.

On Thu, Sep 10, 2015 at 5:20 PM,   wrote:
> Jeff,
>
> Thanks very much for pointing out the issue that I opened last year.  I had
> thought incorrectly that I had raised the matter of type-checking with 'in'
> on this newsgroup rather than on github, which explains why I couldn't
> locate the previous discussion in my first post today.
>
> I am bringing the subject up again because I understand Julia much better
> now, and I have realized that a main cause for the loose type-checking is
> the plethora of methods in Base (e.g., the start/next/done functions that
> turn a Float64 into an iterable) that create certain conveniences but also
> create many possibilities for programmer blunders.  Now that I understand
> the cause of the loose type-checking, I am able to propose a (relatively)
> simple solution, which is to split Base into two parts: essentials and
> conveniences
>
> -- Steve
>
>
> On Thursday, September 10, 2015 at 2:31:39 PM UTC-4, Jeff Bezanson wrote:
>>
>> If anybody is interested and missed it the first time around, there is
>> some good discussion of this in
>> https://github.com/JuliaLang/julia/issues/7903.
>>
>> On Thu, Sep 10, 2015 at 2:01 PM, Randy Zwitch
>>  wrote:
>> > How do you enumerate all of the cases that are "oddball"?
>> >
>> > julia> [1,2,3] in Any[[1],[2],[3],[1,2,3]]
>> >
>> > true
>> >
>> >
>> > julia> [1,2,3] in [[1],[2],[3],[1,2,3]]
>> >
>> > false
>> >
>> >
>> > In the first case, because I declare the array of type "Any", I have an
>> > Array of Arrays (Array{Any, 1}). In that case, the "in" statement is
>> > perfectly valid to test for and is true.
>> >
>> >
>> > In the second case, you get false. What's difficult here is that I think
>> > the
>> > compiler is confused due to the change in concentation syntax:
>> >
>> >
>> > julia> typeof([[1],[2],[3],[1,2,3]])
>> >
>> > WARNING: [a,b,...] concatenation is deprecated; use [a;b;...] instead
>> >
>> >  in depwarn at ./deprecated.jl:73
>> >
>> >  in oldstyle_vcat_warning at ./abstractarray.jl:29
>> >
>> >  in vect at abstractarray.jl:32
>> >
>> > while loading no file, in expression starting on line 0
>> >
>> > Array{Int64,1}
>> >
>> >
>> >
>> > I'm not proposing a solution, just highlighting that it would be pretty
>> > difficult to protect everyone from themselves. At some point, people
>> > need to
>> > be precise about what they mean.
>> >
>> >
>> >
>> >
>> > On Thursday, September 10, 2015 at 12:59:59 PM UTC-4,
>> > vav...@uwaterloo.ca
>> > wrote:
>> >>
>> >> About a year ago I proposed on this forum that 'in' should do more
>> >> type-checking.  For example, the expression
>> >>
>> >>[1,2,3] in [1,2,3,4]
>> >>
>> >> is almost certainly a programmer error.  But Julia accepts it without
>> >> complaint and returns 'false'.  I myself have had problems with the
>> >> wrong
>> >> version of 'in' getting called and nonsensical results returned.
>> >>
>> >> The argument raised against this proposal was the following.  According
>> >> to
>> >> Julia semantics, "a in b" is equivalent to
>> >>
>> >>  for x in b
>> >> if x==a
>> >>return true
>> >> end
>> >>  end
>> >>  return false
>> >>
>> >> But in fact, as the Julia 0.4 recent masters show, there are at least
>> >> two
>> >> cases in which 'in' does not follow these semantics and returns an
>> >> error if
>> >> it thinks the programmer made a mistake.  (See the trace below-- both
>> >> are
>> >> cases where Julia 0.4 changed behavior from 0.3).
>> >>
>> >> It is important for Julia to be vigilant about catching obvious
>> >> programmer
>> >> errors.  This will help improve its chances for use in introductory
>> >> programming courses at universities, among other reasons.
>> >>
>> >> I propose the following: In Julia 0.5, Base should be broken up into
>> >> Base
>> >> and ExpansiveBase.  Functions like in(x::Any,itr::Any) f

Re: [julia-users] fieldoffsets and the C macro offsetof

[J Luis]

Ok, couldn't resist to one more attempt and I may have found the issue. If 
you look at the n_alloc member in  here

https://github.com/joa-quim/GMT.jl/blob/master/src/libgmt_h.jl#L1445

and here

http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_resources.h#L543

you'll notice that it is size_t in C an Cint in Julia (converted with 
Clang). If I change the Julia type to Csize_t than the offsets are the same.

Now I'm really going to sleep.

sexta-feira, 11 de Setembro de 2015 às 04:07:53 UTC+1, J Luis escreveu:
>
> No, that's not the case. Pure C built with VS2013
>
> Ok, tomorrow I'll try to post links to code showing this case.
>
> sexta-feira, 11 de Setembro de 2015 às 04:03:48 UTC+1, Jameson escreveu:
>>
>> generally no, unless you are using C++11 features or ms-bitfields
>>
>> On Thu, Sep 10, 2015 at 11:01 PM J Luis  wrote:
>>
>>> Thanks, it's very late here and posting the case will take time. But one 
>>> thing before I go.
>>> The fact that I'm using a Julia compiled with mingw64 and accessing a 
>>> dll built with VS could explain this, no?
>>>
>>>
>>>
>>> sexta-feira, 11 de Setembro de 2015 às 03:47:12 UTC+1, Jameson escreveu:
>>>
 Yes (unless C doesn't have an equivalent representation), can you post 
 the case?

 On Thu, Sep 10, 2015 at 10:43 PM J Luis  wrote:

> Hi,
>
> When we have a immutable that mimics a C struct, are the results of 
> fieldoffsets() from the Julia side and offsetoff() at the C side supposed 
> to give the same result?
> (Well, I already found one case were they don't)
>

Re: [julia-users] fieldoffsets and the C macro offsetof

[J Luis]

No, that's not the case. Pure C built with VS2013

Ok, tomorrow I'll try to post links to code showing this case.

sexta-feira, 11 de Setembro de 2015 às 04:03:48 UTC+1, Jameson escreveu:
>
> generally no, unless you are using C++11 features or ms-bitfields
>
> On Thu, Sep 10, 2015 at 11:01 PM J Luis > 
> wrote:
>
>> Thanks, it's very late here and posting the case will take time. But one 
>> thing before I go.
>> The fact that I'm using a Julia compiled with mingw64 and accessing a dll 
>> built with VS could explain this, no?
>>
>>
>>
>> sexta-feira, 11 de Setembro de 2015 às 03:47:12 UTC+1, Jameson escreveu:
>>
>>> Yes (unless C doesn't have an equivalent representation), can you post 
>>> the case?
>>>
>>> On Thu, Sep 10, 2015 at 10:43 PM J Luis  wrote:
>>>
 Hi,

 When we have a immutable that mimics a C struct, are the results of 
 fieldoffsets() from the Julia side and offsetoff() at the C side supposed 
 to give the same result?
 (Well, I already found one case were they don't)

>>>

Re: [julia-users] fieldoffsets and the C macro offsetof

[Jameson Nash]

generally no, unless you are using C++11 features or ms-bitfields

On Thu, Sep 10, 2015 at 11:01 PM J Luis  wrote:

> Thanks, it's very late here and posting the case will take time. But one
> thing before I go.
> The fact that I'm using a Julia compiled with mingw64 and accessing a dll
> built with VS could explain this, no?
>
>
>
> sexta-feira, 11 de Setembro de 2015 às 03:47:12 UTC+1, Jameson escreveu:
>
>> Yes (unless C doesn't have an equivalent representation), can you post
>> the case?
>>
>> On Thu, Sep 10, 2015 at 10:43 PM J Luis  wrote:
>>
>>> Hi,
>>>
>>> When we have a immutable that mimics a C struct, are the results of
>>> fieldoffsets() from the Julia side and offsetoff() at the C side supposed
>>> to give the same result?
>>> (Well, I already found one case were they don't)
>>>
>>

Re: [julia-users] fieldoffsets and the C macro offsetof

[J Luis]

Thanks, it's very late here and posting the case will take time. But one 
thing before I go.
The fact that I'm using a Julia compiled with mingw64 and accessing a dll 
built with VS could explain this, no?


sexta-feira, 11 de Setembro de 2015 às 03:47:12 UTC+1, Jameson escreveu:
>
> Yes (unless C doesn't have an equivalent representation), can you post the 
> case?
>
> On Thu, Sep 10, 2015 at 10:43 PM J Luis > 
> wrote:
>
>> Hi,
>>
>> When we have a immutable that mimics a C struct, are the results of 
>> fieldoffsets() from the Julia side and offsetoff() at the C side supposed 
>> to give the same result?
>> (Well, I already found one case were they don't)
>>
>

Re: [julia-users] fieldoffsets and the C macro offsetof

[Jameson Nash]

Yes (unless C doesn't have an equivalent representation), can you post the
case?

On Thu, Sep 10, 2015 at 10:43 PM J Luis  wrote:

> Hi,
>
> When we have a immutable that mimics a C struct, are the results of
> fieldoffsets() from the Julia side and offsetoff() at the C side supposed
> to give the same result?
> (Well, I already found one case were they don't)
>

[julia-users] fieldoffsets and the C macro offsetof

[J Luis]

Hi,

When we have a immutable that mimics a C struct, are the results of 
fieldoffsets() from the Julia side and offsetoff() at the C side supposed 
to give the same result?
(Well, I already found one case were they don't)

Re: [julia-users] [ANN] Plots.jl, a plotting interface

[Tom Breloff]

Hi Miguel... Looking forward to your comments. The short answer is that it
depends on the situation. For functionality that just isn't possible for a
backend, I'll probably just throw an error (ideally with a message
describing other backends that can do what you're looking for). For some
cases, I might automatically replace the call with something similar. For
an example, I couldn't figure out how to make a "sticks" plot in Gadfly, so
I made a bar plot instead. I hope that the package authors can help me with
this process though... Sometimes there's undocumented functionality that
does what I need, and it would be a big help to have package authors
contribute.

I also want to hear from people on visualizations that aren't possible with
this API, as this all falls apart if you only cover some of your needs
through Plots.jl. Look at the TODO at the bottom of the readme for an idea
of my roadmap, and let me know if you want me to add to or prioritize
something.

On Thursday, September 10, 2015, Miguel Bazdresch 
wrote:

> Hi Tom,
>
> I'm the author of Gaston.jl. This looks interesting, and I'll take a
> closer look. I'm wondering, how do you plan to handle the different
> capabilities of each backend? Say, for example, that the user specifies a
> plot that Gaston can't handle -- maybe the marker type is not supported by
> Gnuplot, or something like that.
>
> -- mb
>
> On Thu, Sep 10, 2015 at 4:26 PM, Tom Breloff  > wrote:
>
>> This may be a slightly premature announcement, but I wanted to put it out
>> there so that people that have strong opinions have a chance to give their
>> thoughts.  Here's the link:
>>
>> https://github.com/tbreloff/Plots.jl
>>
>> Plots.jl is intended to be an API/interface that sits above other
>> plotting packages (backends) and gives the user simple, consistent, and
>> flexible plotting commands.  It's a problem when someone is used to a
>> package which is great for interactive plots, but then has to re-learn and
>> re-code new plots in another package when producing publication-quality
>> plots (or vice versa).  The same goes for switching between desktop GUIs
>> and javascript technologies... sometimes one package is better than another
>> for a specific task, and it's a shame to be forced to choose.
>>
>> I've implemented a bunch of functionality for both Gadfly.jl and Qwt.jl
>> backends.  See the examples to get a sense of how they differ.  I think
>> Vega.jl and UnicodePlots.jl might be next on my priority list, but please
>> let me know if I should prioritize differently.  Note: This is still a work
>> in progress, and I will probably change parts of the API, and not every
>> plot type is implemented yet.
>>
>> Please let me know comments, wish lists, etc.  Issues are great for
>> actionable items, comments can go here.  This effort was partially inspired
>> by various discussions here and on github, which prompted the forming of
>> https://github.com/JuliaPlot, and an effort to improve the plotting
>> landscape with tutorials and documentation.  If you're interested:
>> https://github.com/JuliaPlot/juliaplot_docs/issues
>>
>> Tom
>>
>
>

[julia-users] Re: How do I install Clang.jl on Windows 7?

[Chris Stook]

>
> Thanks for the suggestion.  BinDeps.debug gives the same error.
>
 

> BinDeps.debug("Clang") 
>

INFO: Reading build script...


 could not spawn `which llvm-config`: no such file or directory (ENOENT)

while loading C:\Users\Chris\.julia\v0.3\Clang\deps\build.jl, in expression 
starting on line 10
while loading In[3], in expression starting on line 1

 in _jl_spawn at process.jl:217 (repeats 2 times)



I'm slowly working through the instructions to compile julia with 
MinGW/MSYS2 so I can compile with BUILD_LLVM_CLANG=1

Chris
 

[julia-users] Re: How do I install Clang.jl on Windows 7?

[andrew cooke]

my guess (not a windows user) is that 

1 - it cannot build libraries because you don't have MSVC installed.  so 
you would have to already have installed libclang and libclang-dev.

2 - using BinDeps debug as described at 
https://github.com/JuliaLang/BinDeps.jl#diagnostics would help you work out 
why whatever you do have installed isn't being recognised as liclang and 
libclang-dev.

andrew

[julia-users] Re: installation problem mageia 5

[andrew cooke]

well, that file (build_d.hl) is certainly bad.  it is generated by the 
Makefile in the same directory - see the build_h.jl.phony target at the end 
of the file.  i am having a hard time working out how the code in that 
makefile could generate the mess of characters you see above.

i guess i'd try "make clean" and try again.

and maybe i am being super-naive, but i'd also check your system log for 
disk errors and the like.

andrew (not a julia expert, but it compiles ok for me on linux)

Re: [julia-users] [ANN] Plots.jl, a plotting interface

[Miguel Bazdresch]

Hi Tom,

I'm the author of Gaston.jl. This looks interesting, and I'll take a closer
look. I'm wondering, how do you plan to handle the different capabilities
of each backend? Say, for example, that the user specifies a plot that
Gaston can't handle -- maybe the marker type is not supported by Gnuplot,
or something like that.

-- mb

On Thu, Sep 10, 2015 at 4:26 PM, Tom Breloff  wrote:

> This may be a slightly premature announcement, but I wanted to put it out
> there so that people that have strong opinions have a chance to give their
> thoughts.  Here's the link:
>
> https://github.com/tbreloff/Plots.jl
>
> Plots.jl is intended to be an API/interface that sits above other plotting
> packages (backends) and gives the user simple, consistent, and flexible
> plotting commands.  It's a problem when someone is used to a package which
> is great for interactive plots, but then has to re-learn and re-code new
> plots in another package when producing publication-quality plots (or vice
> versa).  The same goes for switching between desktop GUIs and javascript
> technologies... sometimes one package is better than another for a specific
> task, and it's a shame to be forced to choose.
>
> I've implemented a bunch of functionality for both Gadfly.jl and Qwt.jl
> backends.  See the examples to get a sense of how they differ.  I think
> Vega.jl and UnicodePlots.jl might be next on my priority list, but please
> let me know if I should prioritize differently.  Note: This is still a work
> in progress, and I will probably change parts of the API, and not every
> plot type is implemented yet.
>
> Please let me know comments, wish lists, etc.  Issues are great for
> actionable items, comments can go here.  This effort was partially inspired
> by various discussions here and on github, which prompted the forming of
> https://github.com/JuliaPlot, and an effort to improve the plotting
> landscape with tutorials and documentation.  If you're interested:
> https://github.com/JuliaPlot/juliaplot_docs/issues
>
> Tom
>

[julia-users] How do I install Clang.jl on Windows 7?

[Chris Stook]

Here is what I tried so far...

Downloaded Clang for Windows (64-bit) from
http://llvm.org/releases/download.html

Is this libclang?  Where do I get libclang-dev?

Clang installation fails with the following message.

Installing MSVC integration...
Failed to find MSBuild toolsets directory.
MSVC integration install failed.
Press any key to continue . . . 

Trying to install Clang.jl anyway fails.

Pkg.add("Clang")

INFO: Installing Clang v0.0.5
INFO: Building Clang
[ ERROR: Clang 
]

could not spawn `which llvm-config`: no such file or directory (ENOENT)
while loading C:\Users\Chris\.julia\v0.3\Clang\deps\build.jl, in expression 
starting on line 10



[ BUILD ERRORS 
]

WARNING: Clang had build errors.

 - packages with build errors remain installed in C:\Users\Chris\.julia\v0.3
 - build the package(s) and all dependencies with `Pkg.build("Clang")`
 - build a single package by running its `deps/build.jl` script


INFO: Package database updated
INFO: METADATA is out-of-date — you may not have the latest version of Clang
INFO: Use `Pkg.update()` to get the latest versions of your packages




What do I need to do to make this work on a windows system?

Thanks,
Chris

Re: [julia-users] Convert an Array{Any,2} to an AbstractVector in Julia

[Scott T]

I think you might have that the wrong way round - the first run is slower 
on both of those benchmarks, and allocates more data. In fact, we expect 
the first run with @time to be slower, as the function needs to be 
JIT-compiled. Also, if it's the first time you've used the @time macro, the 
macro itself needs to be compiled. Only the second and subsequent @time 
runs of a given function represent the running time of the function itself 
- this is why it's recommended to ignore the first set of timing results 
when you are measuring these things.

Scott T

On Thursday, 10 September 2015 22:20:04 UTC+1, Charles Santana wrote:
>
> Many thanks, guys! Indeed reshape(a,length(a)) is much faster than doing 
> in the simplest way. However, it brings another question:
>
> When I ran the command:
>
> function myfunc1(corpus)
> wc = wordcloud(x = corpus[:])
> end
>
> function myfunc2(corpus)
> wc = wordcloud(x = reshape(corpus,length(corpus)))
> end
>
> I get the following performance:
>
> @time myfunc1(corpus)
>
> 1st running:  398.202 milliseconds (452 k allocations: 17406 KB)
> 2nd running: 144.181 microseconds (374 allocations: 20832 bytes)
> 3rd running:  99.270 microseconds (374 allocations: 20832 bytes)
> 4th running:  93.860 microseconds (374 allocations: 20832 bytes)
>
> @time myfunc2(corpus)
>
> 1st running:  4.102 milliseconds (2667 allocations: 136 KB)
> 2nd running: 110.182 microseconds (375 allocations: 20464 bytes)
> 3rd running:  130.949 microseconds (375 allocations: 20464 bytes)
> 4th running:  120.142 microseconds (375 allocations: 20464 bytes)
>
> It is clear that it is much faster and occupies much less memory in the 
> first running. And actually I only need to run it once. However I am 
> curious to know why would myfunc2 be slower than the myfunc1 as the number 
> of running increase?
>
> Thanks for everything!
>
> Best,
>
> Charles
>
> On 10 September 2015 at 19:24, Steven G. Johnson  > wrote:
>
>>
>>
>> On Thursday, September 10, 2015 at 10:39:58 AM UTC-4, Seth wrote:
>>>
>>> would vec() also work for you? It's supposed to be pretty fast.
>>>
 

>>>
>> vec(a) is equivalent to reshape(a, length(a)), and is fast because it 
>> doesn't make a copy of the data.
>>
>
>
>
> -- 
> Um axé! :)
>
> --
> Charles Novaes de Santana, PhD
> http://www.imedea.uib-csic.es/~charles
>

Re: [julia-users] Re: 'in' should carry out more typechecking

[vavasis]

Jeff,

Thanks very much for pointing out the issue that I opened last year.  I had 
thought incorrectly that I had raised the matter of type-checking with 'in' 
on this newsgroup rather than on github, which explains why I couldn't 
locate the previous discussion in my first post today.

I am bringing the subject up again because I understand Julia much better 
now, and I have realized that a main cause for the loose type-checking is 
the plethora of methods in Base (e.g., the start/next/done functions that 
turn a Float64 into an iterable) that create certain conveniences but also 
create many possibilities for programmer blunders.  Now that I understand 
the cause of the loose type-checking, I am able to propose a (relatively) 
simple solution, which is to split Base into two parts: essentials and 
conveniences

-- Steve


On Thursday, September 10, 2015 at 2:31:39 PM UTC-4, Jeff Bezanson wrote:
>
> If anybody is interested and missed it the first time around, there is 
> some good discussion of this in 
> https://github.com/JuliaLang/julia/issues/7903. 
>
> On Thu, Sep 10, 2015 at 2:01 PM, Randy Zwitch 
> > wrote: 
> > How do you enumerate all of the cases that are "oddball"? 
> > 
> > julia> [1,2,3] in Any[[1],[2],[3],[1,2,3]] 
> > 
> > true 
> > 
> > 
> > julia> [1,2,3] in [[1],[2],[3],[1,2,3]] 
> > 
> > false 
> > 
> > 
> > In the first case, because I declare the array of type "Any", I have an 
> > Array of Arrays (Array{Any, 1}). In that case, the "in" statement is 
> > perfectly valid to test for and is true. 
> > 
> > 
> > In the second case, you get false. What's difficult here is that I think 
> the 
> > compiler is confused due to the change in concentation syntax: 
> > 
> > 
> > julia> typeof([[1],[2],[3],[1,2,3]]) 
> > 
> > WARNING: [a,b,...] concatenation is deprecated; use [a;b;...] instead 
> > 
> >  in depwarn at ./deprecated.jl:73 
> > 
> >  in oldstyle_vcat_warning at ./abstractarray.jl:29 
> > 
> >  in vect at abstractarray.jl:32 
> > 
> > while loading no file, in expression starting on line 0 
> > 
> > Array{Int64,1} 
> > 
> > 
> > 
> > I'm not proposing a solution, just highlighting that it would be pretty 
> > difficult to protect everyone from themselves. At some point, people 
> need to 
> > be precise about what they mean. 
> > 
> > 
> > 
> > 
> > On Thursday, September 10, 2015 at 12:59:59 PM UTC-4, 
> vav...@uwaterloo.ca 
> > wrote: 
> >> 
> >> About a year ago I proposed on this forum that 'in' should do more 
> >> type-checking.  For example, the expression 
> >> 
> >>[1,2,3] in [1,2,3,4] 
> >> 
> >> is almost certainly a programmer error.  But Julia accepts it without 
> >> complaint and returns 'false'.  I myself have had problems with the 
> wrong 
> >> version of 'in' getting called and nonsensical results returned. 
> >> 
> >> The argument raised against this proposal was the following.  According 
> to 
> >> Julia semantics, "a in b" is equivalent to 
> >> 
> >>  for x in b 
> >> if x==a 
> >>return true 
> >> end 
> >>  end 
> >>  return false 
> >> 
> >> But in fact, as the Julia 0.4 recent masters show, there are at least 
> two 
> >> cases in which 'in' does not follow these semantics and returns an 
> error if 
> >> it thinks the programmer made a mistake.  (See the trace below-- both 
> are 
> >> cases where Julia 0.4 changed behavior from 0.3). 
> >> 
> >> It is important for Julia to be vigilant about catching obvious 
> programmer 
> >> errors.  This will help improve its chances for use in introductory 
> >> programming courses at universities, among other reasons. 
> >> 
> >> I propose the following: In Julia 0.5, Base should be broken up into 
> Base 
> >> and ExpansiveBase.  Functions like in(x::Any,itr::Any) from reduce.jl 
> or 
> >> start(x::Number) from number.jl that allow oddball user code to be 
> accepted 
> >> by the compiler would be put into ExpansiveBase.  The semantics for 
> >> 'in(a,b)' when only Base is loaded should be either 
> typeof(a)==eltype(b) or 
> >> that there exists a method convert(eltype(b),a). 
> >> 
> >> -- Steve Vavasis 
> >> 
> >> 
> >> julia> 0 in IntSet() 
> >> WARNING: stored zeros in IntSet is deprecated 
> >>  in depwarn at deprecated.jl:63 
> >>  in in at intset.jl:163 
> >> while loading no file, in expression starting on line 0 
> >> false 
> >> 
> >> julia> (1,2) in Dict{Any,Any}() 
> >> ERROR: Associative collections only contain Pairs; 
> >> Either look for e.g. A=>B instead, or use the `keys` or `values` 
> >> function if you are looking for a key or value respectively. 
> >>  in in at dict.jl:13 
> >> 
> > 
>

Re: [julia-users] Convert an Array{Any,2} to an AbstractVector in Julia

[Charles Novaes de Santana]

Many thanks, guys! Indeed reshape(a,length(a)) is much faster than doing in
the simplest way. However, it brings another question:

When I ran the command:

function myfunc1(corpus)
wc = wordcloud(x = corpus[:])
end

function myfunc2(corpus)
wc = wordcloud(x = reshape(corpus,length(corpus)))
end

I get the following performance:

@time myfunc1(corpus)

1st running:  398.202 milliseconds (452 k allocations: 17406 KB)
2nd running: 144.181 microseconds (374 allocations: 20832 bytes)
3rd running:  99.270 microseconds (374 allocations: 20832 bytes)
4th running:  93.860 microseconds (374 allocations: 20832 bytes)

@time myfunc2(corpus)

1st running:  4.102 milliseconds (2667 allocations: 136 KB)
2nd running: 110.182 microseconds (375 allocations: 20464 bytes)
3rd running:  130.949 microseconds (375 allocations: 20464 bytes)
4th running:  120.142 microseconds (375 allocations: 20464 bytes)

It is clear that it is much faster and occupies much less memory in the
first running. And actually I only need to run it once. However I am
curious to know why would myfunc2 be slower than the myfunc1 as the number
of running increase?

Thanks for everything!

Best,

Charles

On 10 September 2015 at 19:24, Steven G. Johnson 
wrote:

>
>
> On Thursday, September 10, 2015 at 10:39:58 AM UTC-4, Seth wrote:
>>
>> would vec() also work for you? It's supposed to be pretty fast.
>>
>>> 
>>>
>>
> vec(a) is equivalent to reshape(a, length(a)), and is fast because it
> doesn't make a copy of the data.
>



-- 
Um axé! :)

--
Charles Novaes de Santana, PhD
http://www.imedea.uib-csic.es/~charles

Re: [julia-users] Error in the Dict type declaration

[Jeff Bezanson]

There are two things going on. First, unfortunately you can't yet
declare types on global variables. Second, `Dict{String,
Array{Float64}}` and `Dict{String, Array{Float64,1}}` are disjoint
types, due to parametric invariance.

On Thu, Sep 10, 2015 at 9:27 AM, Alex M  wrote:
> Hello,
>
> I am trying to attach the type for a variable like that:
>
> julia> a::Dict{String, Array{Float64}} = { "y" => Float64[1.0, 2.0]}
> ERROR: type: typeassert: expected Dict{String,Array{Float64,N}}, got
> Array{Float64,1}
>
> julia> a::Dict{String, Array{Float64}} = { "y" => [1.0, 2.0]}
> ERROR: type: typeassert: expected Dict{String,Array{Float64,N}}, got
> Array{Float64,1}
>
> Why is it an error?
>
> Best regards,
> Alex

[julia-users] Error in the Dict type declaration

[Alex M]

Hello,

I am trying to attach the type for a variable like that:

julia> a::Dict{String, Array{Float64}} = { "y" => Float64[1.0, 2.0]}
ERROR: type: typeassert: expected Dict{String,Array{Float64,N}}, got 
Array{Float64,1}

julia> a::Dict{String, Array{Float64}} = { "y" => [1.0, 2.0]}
ERROR: type: typeassert: expected Dict{String,Array{Float64,N}}, got 
Array{Float64,1}

Why is it an error?

Best regards,
Alex

[julia-users] installation problem mageia 5

[Evan]

Hi, I am trying to install Julia on a Mageia 5 i7 system.  In Make.user I 
put this:

USE_SYSTEM_LLVM=1
USE_SYSTEM_BLAS=1
USE_SYSTEM_LAPACK=1
USE_SYSTEM_FFTW=1
USE_SYSTEM_MPFR=1
USE_SYSTEM_ARPACK=1
USE_SYSTEM_ZLIB=1
USE_SYSTEM_RMATH=1

and the tail of output from "make" is below:

In file included from codegen.cpp:766:0:
debuginfo.cpp: In function ‘void jl_getDylibFunctionInfo(const char**, 
size_t*, const char**, size_t, int*, int)’:
debuginfo.cpp:359:16: warning: unused variable ‘msize’ [-Wunused-variable]
 size_t msize = (size_t)(((uint64_t)-1)-fbase);
^
CC src/interpreter.o
CC src/alloc.o
CC src/dlload.o
CC src/sys.o
CC src/init.o
CC src/task.o
CC src/array.o
CC src/dump.o
CC src/toplevel.o
CC src/jl_uv.o
CC src/jlapi.o
CC src/profile.o
CC src/llvm-simdloop.o
CC src/gc.o
LINK usr/lib/libjulia.so
PERL base/pcre_h.jl
PERL base/errno_h.jl
PERL base/build_h.jl.phony
PERL base/fenv_constants.jl
PERL base/file_constants.jl
PERL base/uv_constants.jl
fatal: bad revision '^origin/release-0.3'
fatal: Not a valid object name origin/release-0.3
PERL base/version_git.jl.phony
CC ui/repl.o
LINK usr/bin/julia
exports.jl
base.jl
reflection.jl
build_h.jl
error during bootstrap: LoadError(at "sysimg.jl" line 28: LoadError(at 
"build_h.jl" line 2: ErrorException("syntax: invalid character "")))
Makefile:127: recipe for target '/opt/julia/julia/usr/lib/julia/sys0.o' 
failed
make[1]: *** [/opt/julia/julia/usr/lib/julia/sys0.o] Error 1
Makefile:37: recipe for target 'release' failed
make: *** [release] Error 2
[emason@marula julia (release-0.3)]$

See also the full output: 
https://gist.github.com/evanmason/89d73157f042680ee755


When I inspect line 2 of base/build_h.jl, I see indeed that line 2 seems to 
be corrupted:

# This file is automatically generated in base/Makefile
^[[01;31m^[[Kc^[[m^[[K^[[01;31m^[[Ko^[[m^[[K^[[01;31m^[[Kn^[[m^[[K^[[01;31m^[[Ks^[[m^[[K^[[01;31m^[[Kt^[[m^[[K^[[01;31m^[[K
 
^[[m^[[K^[[01;31m^[[KO^[[m^[[K^[[01;31m^[[KS^[[m^[[K^[[01;31m^[[K_^[[m^[[K^[[01;31m^[[KN^[[m^[[K^[[01;31m^[[KA^[[m^[[K^[[01;31m^[[KM^[[m^[[K^[[01;31m^[[KE^[[m^[[K^[[01;31m^[[K
 
^[[m^[[K^[[01;31m^[[K=^[[m^[[K^[[01;31m^[[K 
^[[m^[[K^[[01;31m^[[K:^[[m^[[K^[[01;31m^[[KL^[[m^[[K^[[01;31m^[[Ki^[[m^[[K^[[01;31m^[[Kn^[[m^[[K^[[01;31m^[[Ku^[[m^[[K^[[01;31m^[[Kx^[[m^[[K
const ARCH = :x86_64
const MACHINE = "x86_64-mageia-linux-gnu"
const libm_name = "libopenlibm"
const libblas_name = "libblas"
const liblapack_name = "liblapack"
const USE_BLAS64 = true
const libfftw_name = "libfftw3_threads"
const libfftwf_name = "libfftw3f_threads"
const libllvm_version = "3.5.2"
const VERSION_STRING = "0.3.12-pre"
const TAGGED_RELEASE_BANNER = ""
const SYSCONFDIR = "../etc"
const DATAROOTDIR = "../share"

I'd be grateful for any help with this.

Thanks, Evan

[julia-users] [ANN] Plots.jl, a plotting interface

[Tom Breloff]

This may be a slightly premature announcement, but I wanted to put it out 
there so that people that have strong opinions have a chance to give their 
thoughts.  Here's the link:

https://github.com/tbreloff/Plots.jl

Plots.jl is intended to be an API/interface that sits above other plotting 
packages (backends) and gives the user simple, consistent, and flexible 
plotting commands.  It's a problem when someone is used to a package which 
is great for interactive plots, but then has to re-learn and re-code new 
plots in another package when producing publication-quality plots (or vice 
versa).  The same goes for switching between desktop GUIs and javascript 
technologies... sometimes one package is better than another for a specific 
task, and it's a shame to be forced to choose.

I've implemented a bunch of functionality for both Gadfly.jl and Qwt.jl 
backends.  See the examples to get a sense of how they differ.  I think 
Vega.jl and UnicodePlots.jl might be next on my priority list, but please 
let me know if I should prioritize differently.  Note: This is still a work 
in progress, and I will probably change parts of the API, and not every 
plot type is implemented yet.

Please let me know comments, wish lists, etc.  Issues are great for 
actionable items, comments can go here.  This effort was partially inspired 
by various discussions here and on github, which prompted the forming 
of https://github.com/JuliaPlot, and an effort to improve the plotting 
landscape with tutorials and documentation.  If you're 
interested: https://github.com/JuliaPlot/juliaplot_docs/issues

Tom

[julia-users] Re: Type inheritance question

[Maurizio Tomasi]

Yes, thanks a lot, leaving it out of the definition of the type makes the code 
even more elegant.

Maurizio.

[julia-users] Re: PyPlot does not work with Julia Version 0.4.0-rc1+5

[ggggg]

I have a different failure with PyPlot, this is the first thing I tried 
after installing the 0.4.0-rc1 osx binary, Pkg.add("PyPlot");using PyPlot


*julia> **using PyPlot*

WARNING: could not import Base.help into PyCall

Could not find platform independent libraries 

Could not find platform dependent libraries 

Consider setting $PYTHONHOME to [:]

ImportError: No module named site


The problem appears to be 

*julia> **ENV["PYTHONHOME"]*

*ERROR: KeyError: PYTHONHOME not found*
despite the fact that if I launch julia 3.10 in the same terminal 
"PYTHONHOME" is defined and PyPlot works.



Julia Version 0.4.0-rc1

Commit e5c6964 (2015-09-09 16:07 UTC)

Platform Info:

  System: Darwin (x86_64-apple-darwin13.4.0)

  CPU: Intel(R) Core(TM) i5-2500S CPU @ 2.70GHz

  WORD_SIZE: 64

  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)

  LAPACK: libopenblas

  LIBM: libopenlibm

  LLVM: libLLVM-3.3

Re: [julia-users] Re: 'in' should carry out more typechecking

[Jeff Bezanson]

If anybody is interested and missed it the first time around, there is
some good discussion of this in
https://github.com/JuliaLang/julia/issues/7903.

On Thu, Sep 10, 2015 at 2:01 PM, Randy Zwitch
 wrote:
> How do you enumerate all of the cases that are "oddball"?
>
> julia> [1,2,3] in Any[[1],[2],[3],[1,2,3]]
>
> true
>
>
> julia> [1,2,3] in [[1],[2],[3],[1,2,3]]
>
> false
>
>
> In the first case, because I declare the array of type "Any", I have an
> Array of Arrays (Array{Any, 1}). In that case, the "in" statement is
> perfectly valid to test for and is true.
>
>
> In the second case, you get false. What's difficult here is that I think the
> compiler is confused due to the change in concentation syntax:
>
>
> julia> typeof([[1],[2],[3],[1,2,3]])
>
> WARNING: [a,b,...] concatenation is deprecated; use [a;b;...] instead
>
>  in depwarn at ./deprecated.jl:73
>
>  in oldstyle_vcat_warning at ./abstractarray.jl:29
>
>  in vect at abstractarray.jl:32
>
> while loading no file, in expression starting on line 0
>
> Array{Int64,1}
>
>
>
> I'm not proposing a solution, just highlighting that it would be pretty
> difficult to protect everyone from themselves. At some point, people need to
> be precise about what they mean.
>
>
>
>
> On Thursday, September 10, 2015 at 12:59:59 PM UTC-4, vav...@uwaterloo.ca
> wrote:
>>
>> About a year ago I proposed on this forum that 'in' should do more
>> type-checking.  For example, the expression
>>
>>[1,2,3] in [1,2,3,4]
>>
>> is almost certainly a programmer error.  But Julia accepts it without
>> complaint and returns 'false'.  I myself have had problems with the wrong
>> version of 'in' getting called and nonsensical results returned.
>>
>> The argument raised against this proposal was the following.  According to
>> Julia semantics, "a in b" is equivalent to
>>
>>  for x in b
>> if x==a
>>return true
>> end
>>  end
>>  return false
>>
>> But in fact, as the Julia 0.4 recent masters show, there are at least two
>> cases in which 'in' does not follow these semantics and returns an error if
>> it thinks the programmer made a mistake.  (See the trace below-- both are
>> cases where Julia 0.4 changed behavior from 0.3).
>>
>> It is important for Julia to be vigilant about catching obvious programmer
>> errors.  This will help improve its chances for use in introductory
>> programming courses at universities, among other reasons.
>>
>> I propose the following: In Julia 0.5, Base should be broken up into Base
>> and ExpansiveBase.  Functions like in(x::Any,itr::Any) from reduce.jl or
>> start(x::Number) from number.jl that allow oddball user code to be accepted
>> by the compiler would be put into ExpansiveBase.  The semantics for
>> 'in(a,b)' when only Base is loaded should be either typeof(a)==eltype(b) or
>> that there exists a method convert(eltype(b),a).
>>
>> -- Steve Vavasis
>>
>>
>> julia> 0 in IntSet()
>> WARNING: stored zeros in IntSet is deprecated
>>  in depwarn at deprecated.jl:63
>>  in in at intset.jl:163
>> while loading no file, in expression starting on line 0
>> false
>>
>> julia> (1,2) in Dict{Any,Any}()
>> ERROR: Associative collections only contain Pairs;
>> Either look for e.g. A=>B instead, or use the `keys` or `values`
>> function if you are looking for a key or value respectively.
>>  in in at dict.jl:13
>>
>

[julia-users] Re: PyPlot does not work with Julia Version 0.4.0-rc1+5

[Uwe Fechner]

This is not yet fixed.

I deleted .jula/v0.4/PyCall and .jula/v0.4/PyPlot.
Then I did:
Pkg.update()
Pkg.checkout("PyCall")
Pkg.checkout("PyPlot")
Pkg.build("PyCall")
using PyPlot

This works fine. But if I restart Julia
and do using PyPlot again, I get the error:

julia> tic(); using PyPlot; toc();
/home/ufechner/miniconda/envs/kitepower/lib/python2.7/site-packages/matplotlib/__init__.py:1155:
 
UserWarning:  This call to matplotlib.use() has no effect
because the backend has already been chosen;
matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
or matplotlib.backends is imported for the first time.

  warnings.warn(_use_error_msg)
ERROR: LoadError: InitError: PyError (:PyImport_ImportModule) 
ImportError('/home/ufechner/miniconda/envs/kitepower/lib/python2.7/site-packages/sip.so:
 
undefined symbol: PyProperty_Type',)
  File 
"/home/ufechner/miniconda/envs/kitepower/lib/python2.7/site-packages/matplotlib/pyplot.py",
 
line 98, in 
_backend_mod, new_figure_manager, draw_if_interactive, _show = 
pylab_setup()
  File 
"/home/ufechner/miniconda/envs/kitepower/lib/python2.7/site-packages/matplotlib/backends/__init__.py",
 
line 28, in pylab_setup
globals(),locals(),[backend_name],0)
  File 
"/home/ufechner/miniconda/envs/kitepower/lib/python2.7/site-packages/matplotlib/backends/backend_qt4agg.py",
 
line 13, in 
from backend_qt4 import QtCore, QtGui, FigureManagerQT, FigureCanvasQT,\
  File 
"/home/ufechner/miniconda/envs/kitepower/lib/python2.7/site-packages/matplotlib/backends/backend_qt4.py",
 
line 25, in 
from qt4_compat import QtCore, QtGui, _getSaveFileName, __version__
  File 
"/home/ufechner/miniconda/envs/kitepower/lib/python2.7/site-packages/matplotlib/backends/qt4_compat.py",
 
line 36, in 
import sip

 [inlined code] from /home/ufechner/.julia/v0.4/PyCall/src/exception.jl:82
 in pyimport at /home/ufechner/.julia/v0.4/PyCall/src/PyCall.jl:315
 in __init__ at /home/ufechner/.julia/v0.4/PyPlot/src/PyPlot.jl:245
 in include at ./boot.jl:260
 in include_from_node1 at ./loading.jl:271
 in require at ./loading.jl:210
during initialization of module PyPlot
while loading /home/ufechner/.julia/v0.4/PyPlot/src/PyPlot.jl, in 
expression starting on line 653

Any idea?

Uwe Fechner


Am Donnerstag, 10. September 2015 18:51:32 UTC+2 schrieb Steven G. Johnson:
>
> Just merged a fix, I think.
>
> I've fallen behind a bit on PyCall and PyPlot issues, but I'll be cleaning 
> things up over the next few days since I need these for my class soon.
>

Re: [julia-users] META: What are the chances of moving this forum?

[Jarrett Revels]

>
> -1 to re-purposing GitHub issues for any sort of free-form discussion. I 
> don't see that as solving any problems. At scale, the GitHub issue tracker 
> is limited even for the intended purpose.
>

The main reason I mentioned it was that it was a solid example of the kind 
of features I had always felt Google Groups lacked. But...

I do like Discourse because of the auto-suggestion, tiered moderation, 
> proper threading, categorization, and other features that would (hopefully) 
> *cut down* on the number of pings we see. Discourse also has at least 
> one-way GitHub cross-linking (mentioning a GitHub issue in discourse will 
> expand to a short summary, IIRC).
>

...that basically sums up everything I'd want in a new mailing list. I just 
gave their sandbox  a whirl, and it looks 
awesome, especially the onebox feature (that would be *really* great for 
seeing where commits/PRs lead without having to click on them). Discourse 
has my vote, if the idea of moving the mailing list ever takes flight.

On Thursday, September 10, 2015 at 1:37:01 PM UTC-4, Miguel Bazdresch wrote:
>
> Personally, I'd prefer to just have an old-fashioned, LISTERV-type mailing 
> list. Yes, I'm old.
>
> -- mb
>
> On Wed, Sep 9, 2015 at 7:34 AM, Nils Gudat  > wrote:
>
>> Was just thinking about this as first I had to try opening a thread here 
>> a couple of times before any posts were actually displayed, and then read 
>> through this 
>> 
>>  
>> thread on Mike's Juno Discuss forum, where a user had a question which was 
>> almost answered by the nice auto-suggestion feature that pops up when you 
>> ask a question.
>>
>> I feel that Google Groups has mostly downsides - the system is slow, with 
>> posts frequently not loading, double posts because of this, no proper code 
>> formatting or Markdown support etc.
>>
>> Is there a chance this could be moved to something like Discuss or is 
>> there too much inertia in having an "established" forum on Google Groups?
>>
>
>

[julia-users] Re: 'in' should carry out more typechecking

[Randy Zwitch]

How do you enumerate all of the cases that are "oddball"?

*julia> **[1,2,3] in Any[[1],[2],[3],[1,2,3]]*

*true*


*julia> **[1,2,3] in [[1],[2],[3],[1,2,3]]*

*false*


In the first case, because I declare the array of type "Any", I have an 
Array of Arrays (Array{Any, 1}). In that case, the "in" statement is 
perfectly valid to test for and is true.


In the second case, you get false. What's difficult here is that I think 
the compiler is confused due to the change in concentation syntax:


*julia> **typeof([[1],[2],[3],[1,2,3]])*

*WARNING: [a,b,...] concatenation is deprecated; use [a;b;...] instead*

 in depwarn at ./deprecated.jl:73

 in oldstyle_vcat_warning at ./abstractarray.jl:29

 in vect at abstractarray.jl:32

while loading no file, in expression starting on line 0

*Array{Int64,1}*



I'm not proposing a solution, just highlighting that it would be pretty 
difficult to protect everyone from themselves. At some point, people need 
to be precise about what they mean.




On Thursday, September 10, 2015 at 12:59:59 PM UTC-4, vav...@uwaterloo.ca 
wrote:
>
> About a year ago I proposed on this forum that 'in' should do more 
> type-checking.  For example, the expression
>
>[1,2,3] in [1,2,3,4]
>
> is almost certainly a programmer error.  But Julia accepts it without 
> complaint and returns 'false'.  I myself have had problems with the wrong 
> version of 'in' getting called and nonsensical results returned.
>
> The argument raised against this proposal was the following.  According to 
> Julia semantics, "a in b" is equivalent to
>
>  for x in b
> if x==a
>return true
> end
>  end
>  return false 
>
> But in fact, as the Julia 0.4 recent masters show, there are at least two 
> cases in which 'in' does not follow these semantics and returns an error if 
> it thinks the programmer made a mistake.  (See the trace below-- both are 
> cases where Julia 0.4 changed behavior from 0.3).
>
> It is important for Julia to be vigilant about catching obvious programmer 
> errors.  This will help improve its chances for use in introductory 
> programming courses at universities, among other reasons.
>
> I propose the following: In Julia 0.5, Base should be broken up into Base 
> and ExpansiveBase.  Functions like in(x::Any,itr::Any) from reduce.jl or 
> start(x::Number) from number.jl that allow oddball user code to be accepted 
> by the compiler would be put into ExpansiveBase.  The semantics for 
> 'in(a,b)' when only Base is loaded should be either typeof(a)==eltype(b) or 
> that there exists a method convert(eltype(b),a).
>
> -- Steve Vavasis
>
>
> julia> 0 in IntSet()
> WARNING: stored zeros in IntSet is deprecated
>  in depwarn at deprecated.jl:63
>  in in at intset.jl:163
> while loading no file, in expression starting on line 0
> false
>
> julia> (1,2) in Dict{Any,Any}()
> ERROR: Associative collections only contain Pairs;
> Either look for e.g. A=>B instead, or use the `keys` or `values`
> function if you are looking for a key or value respectively.
>  in in at dict.jl:13
>
>

[julia-users] Re: Julia v0.4.0-rc1 released

[catchall]

Congrats to all the Julia devs on this great milestone, and thanks for all 
your hard work on this amazing project.

On Thursday, September 10, 2015 at 10:21:52 AM UTC-7, Elliot Saba wrote:
>
> The first release candidate of the 0.4 series is available for download 
> from the usual place .  Please test 
> extensively, report issues to the issue tracker 
>  for base Julia problems, and 
> report issues with packages to their respective issue trackers.  The 0.4 
> series will undergo a period of stabilization in anticipation of a final 
> release as soon as feasible, while new breaking development will continue 
> to occur on the master branch which will target a 0.5 release further down 
> the line.
>
> Many thanks and congratulations to all the contributors that have come 
> together for this release; we have volunteers from all over the globe 
> working in concert to create the best environment for technical computing 
> available.  Onwards and upwards!
> -E
>

Re: [julia-users] META: What are the chances of moving this forum?

[Miguel Bazdresch]

Personally, I'd prefer to just have an old-fashioned, LISTERV-type mailing
list. Yes, I'm old.

-- mb

On Wed, Sep 9, 2015 at 7:34 AM, Nils Gudat  wrote:

> Was just thinking about this as first I had to try opening a thread here a
> couple of times before any posts were actually displayed, and then read
> through this
> 
> thread on Mike's Juno Discuss forum, where a user had a question which was
> almost answered by the nice auto-suggestion feature that pops up when you
> ask a question.
>
> I feel that Google Groups has mostly downsides - the system is slow, with
> posts frequently not loading, double posts because of this, no proper code
> formatting or Markdown support etc.
>
> Is there a chance this could be moved to something like Discuss or is
> there too much inertia in having an "established" forum on Google Groups?
>

[julia-users] Re: Julia v0.4.0-rc1 released

[Jeffrey Sarnoff]

On Thursday, September 10, 2015 at 1:21:54 PM UTC-4, Elliot Saba wrote:
>
> The first release candidate of the 0.4 series is available for download 
> from the usual place .  Please test 
> extensively, report issues to the issue tracker 
>  for base Julia problems, and 
> report issues with packages to their respective issue trackers.  The 0.4 
> series will undergo a period of stabilization in anticipation of a final 
> release as soon as feasible, while new breaking development will continue 
> to occur on the master branch which will target a 0.5 release further down 
> the line.
>
> Many thanks and congratulations to all the contributors that have come 
> together for this release; we have volunteers from all over the globe 
> working in concert to create the best environment for technical computing 
> available.  Onwards and upwards!
> -E
>

Re: [julia-users] Re: META: What are the chances of moving this forum?

[Waldir Pimenta]

On Thursday, September 10, 2015 at 3:23:16 PM UTC+1, Isaiah wrote:
>
> proper threading
>

Uh, I thought Discourse was adamantly on the flat side of the "flat vs. 
threaded discussion" debate, Or did you mean something different?

Re: [julia-users] Convert an Array{Any,2} to an AbstractVector in Julia

[Steven G. Johnson]

On Thursday, September 10, 2015 at 10:39:58 AM UTC-4, Seth wrote:
>
> would vec() also work for you? It's supposed to be pretty fast.
>
>> 
>>
>
vec(a) is equivalent to reshape(a, length(a)), and is fast because it 
doesn't make a copy of the data.

[julia-users] Julia v0.4.0-rc1 released

[Elliot Saba]

The first release candidate of the 0.4 series is available for download
from the usual place .  Please test
extensively, report issues to the issue tracker
 for base Julia problems, and
report issues with packages to their respective issue trackers.  The 0.4
series will undergo a period of stabilization in anticipation of a final
release as soon as feasible, while new breaking development will continue
to occur on the master branch which will target a 0.5 release further down
the line.

Many thanks and congratulations to all the contributors that have come
together for this release; we have volunteers from all over the globe
working in concert to create the best environment for technical computing
available.  Onwards and upwards!
-E

[julia-users] Re: Error when including file with umlaut

[Steven G. Johnson]

Julia requires source code to be in the UTF-8 encoding of Unicode.  It 
looks like you are using the non-Unicode iso-8859-1 (or Windows-1252) 
encoding.

[julia-users] Re: Type inheritance question

[Tim Wheeler]

Thanks Jeffrey - I did not know that one can leave the type out.

[julia-users] 'in' should carry out more typechecking

[vavasis]

About a year ago I proposed on this forum that 'in' should do more 
type-checking.  For example, the expression

   [1,2,3] in [1,2,3,4]

is almost certainly a programmer error.  But Julia accepts it without 
complaint and returns 'false'.  I myself have had problems with the wrong 
version of 'in' getting called and nonsensical results returned.

The argument raised against this proposal was the following.  According to 
Julia semantics, "a in b" is equivalent to

 for x in b
if x==a
   return true
end
 end
 return false 

But in fact, as the Julia 0.4 recent masters show, there are at least two 
cases in which 'in' does not follow these semantics and returns an error if 
it thinks the programmer made a mistake.  (See the trace below-- both are 
cases where Julia 0.4 changed behavior from 0.3).

It is important for Julia to be vigilant about catching obvious programmer 
errors.  This will help improve its chances for use in introductory 
programming courses at universities, among other reasons.

I propose the following: In Julia 0.5, Base should be broken up into Base 
and ExpansiveBase.  Functions like in(x::Any,itr::Any) from reduce.jl or 
start(x::Number) from number.jl that allow oddball user code to be accepted 
by the compiler would be put into ExpansiveBase.  The semantics for 
'in(a,b)' when only Base is loaded should be either typeof(a)==eltype(b) or 
that there exists a method convert(eltype(b),a).

-- Steve Vavasis


julia> 0 in IntSet()
WARNING: stored zeros in IntSet is deprecated
 in depwarn at deprecated.jl:63
 in in at intset.jl:163
while loading no file, in expression starting on line 0
false

julia> (1,2) in Dict{Any,Any}()
ERROR: Associative collections only contain Pairs;
Either look for e.g. A=>B instead, or use the `keys` or `values`
function if you are looking for a key or value respectively.
 in in at dict.jl:13

[julia-users] Re: Multi-dimensional Arrays

[Steven G. Johnson]

On Thursday, September 10, 2015 at 9:59:04 AM UTC-4, Scott Jones wrote:
>
> I'd also like to see real MD associative arrays
>

dict[a,b,c] works now.   (It is equivalent to dict[(a,b,c)], i.e. the keys 
are tuples.)

[julia-users] Re: PyPlot does not work with Julia Version 0.4.0-rc1+5

[Steven G. Johnson]

Just merged a fix, I think.

I've fallen behind a bit on PyCall and PyPlot issues, but I'll be cleaning 
things up over the next few days since I need these for my class soon.

[julia-users] Error when including file with umlaut

[bernhard]

All

When I include the attached file with 

include("c:\\temp\\test.jl")

I get an error about a missing comma or ).
Does anybody know why that is the case?

I am using 0.3.11 on Windows7.

The issue seems to be the umlaut in row2. If I replace it with a 
non-umlaut, things work as expected.

Bernhard



test.jl
Description: Binary data

Re: [julia-users] PyPlot does not work with Julia Version 0.4.0-rc1+5

[Uwe Fechner]

Yes, I can.

I fixed the first problem with:
sudo pip install matplotlib==1.4.3

With other words, PyPlot is using the system libraries, even though I use a 
virtual 
conda environment. This is just ignored.

Now everything works fine with Julia 0.3 and 0.4, as long as I do not use 
precompilation.

After I did:
Pkg.checkout("PyCall")
Pkg.checkout("PyPlot")
Pkg.build("PyCall")

both libraries get precompiled on 0.4, but now I get the following error:

julia> using PyPlot
/home/ufechner/miniconda/envs/kitepower/lib/python2.7/site-packages/matplotlib/__init__.py:1155:
 
UserWarning:  This call to matplotlib.use() has no effect
because the backend has already been chosen;
matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
or matplotlib.backends is imported for the first time.

  warnings.warn(_use_error_msg)
ERROR: InitError: PyError (:PyImport_ImportModule) 
ImportError('/home/ufechner/miniconda/envs/kitepower/lib/python2.7/site-packages/sip.so:
 
undefined symbol: PyProperty_Type',)
  File 
"/home/ufechner/miniconda/envs/kitepower/lib/python2.7/site-packages/matplotlib/pyplot.py",
 
line 98, in 
_backend_mod, new_figure_manager, draw_if_interactive, _show = 
pylab_setup()
  File 
"/home/ufechner/miniconda/envs/kitepower/lib/python2.7/site-packages/matplotlib/backends/__init__.py",
 
line 28, in pylab_setup
globals(),locals(),[backend_name],0)
  File 
"/home/ufechner/miniconda/envs/kitepower/lib/python2.7/site-packages/matplotlib/backends/backend_qt4agg.py",
 
line 13, in 
from backend_qt4 import QtCore, QtGui, FigureManagerQT, FigureCanvasQT,\
  File 
"/home/ufechner/miniconda/envs/kitepower/lib/python2.7/site-packages/matplotlib/backends/backend_qt4.py",
 
line 25, in 
from qt4_compat import QtCore, QtGui, _getSaveFileName, __version__
  File 
"/home/ufechner/miniconda/envs/kitepower/lib/python2.7/site-packages/matplotlib/backends/qt4_compat.py",
 
line 36, in 
import sip

 [inlined code] from /home/ufechner/.julia/v0.4/PyCall/src/exception.jl:82
 in pyimport at /home/ufechner/.julia/v0.4/PyCall/src/PyCall.jl:315
 in __init__ at /home/ufechner/.julia/v0.4/PyPlot/src/PyPlot.jl:245
 in _require_from_serialized at loading.jl:84
 in _require_from_serialized at ./loading.jl:109
 in require at ./loading.jl:186
during initialization of module PyPlot

Any idea?





Am Donnerstag, 10. September 2015 18:20:52 UTC+2 schrieb Mauro:
>
> Works for me.  The error suggests that matplotlib doesn't work.  Can you 
> import in python itself? 
>
> $ python 
>
> >>> import matplotlib 
>
> On Thu, 2015-09-10 at 18:06, Uwe Fechner  > wrote: 
> > Hello, 
> > 
> > I have a problem with PyPlot on Julia 0.4.0-rc1: 
> > 
> > julia> using PyPlot 
> > ERROR: InitError: Failed to pyimport("matplotlib"): PyPlot will not work 
> > until you have a functioning matplotlib module.  PyError 
> > (:PyImport_ImportModule)  
> > ImportError('cannot import name scimath',) 
> >   File 
> > 
> "/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/matplotlib/__init__.py",
>  
>
> > line 180, in  
> > from matplotlib.cbook import is_string_like 
> >   File 
> > 
> "/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/matplotlib/cbook.py",
>  
>
> > line 33, in  
> > import numpy as np 
> >   File 
> > 
> "/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/numpy/__init__.py",
>  
>
> > line 170, in  
> > from . import add_newdocs 
> >   File 
> > 
> "/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/numpy/add_newdocs.py",
>  
>
> > line 13, in  
> > from numpy.lib import add_newdoc 
> >   File 
> > 
> "/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/numpy/lib/__init__.py",
>  
>
> > line 17, in  
> > from . import scimath as emath 
> > 
> >  in __init__ at /home/ufechner/.julia/v0.4/PyPlot/src/PyPlot.jl:232 
> >  in _require_from_serialized at loading.jl:84 
> >  in _require_from_serialized at ./loading.jl:109 
> >  in require at ./loading.jl:186 
> > during initialization of module PyPlot 
> > 
> > julia> 
> > 
> > Any idea? 
> > 
> > Uwe Fechner 
>
>

Re: [julia-users] PyPlot does not work with Julia Version 0.4.0-rc1+5

[Mauro]

Works for me.  The error suggests that matplotlib doesn't work.  Can you
import in python itself?

$ python

>>> import matplotlib

On Thu, 2015-09-10 at 18:06, Uwe Fechner  wrote:
> Hello,
>
> I have a problem with PyPlot on Julia 0.4.0-rc1:
>
> julia> using PyPlot
> ERROR: InitError: Failed to pyimport("matplotlib"): PyPlot will not work 
> until you have a functioning matplotlib module.  PyError 
> (:PyImport_ImportModule) 
> ImportError('cannot import name scimath',)
>   File 
> "/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/matplotlib/__init__.py",
>  
> line 180, in 
> from matplotlib.cbook import is_string_like
>   File 
> "/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/matplotlib/cbook.py",
>  
> line 33, in 
> import numpy as np
>   File 
> "/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/numpy/__init__.py",
>  
> line 170, in 
> from . import add_newdocs
>   File 
> "/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/numpy/add_newdocs.py",
>  
> line 13, in 
> from numpy.lib import add_newdoc
>   File 
> "/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/numpy/lib/__init__.py",
>  
> line 17, in 
> from . import scimath as emath
>
>  in __init__ at /home/ufechner/.julia/v0.4/PyPlot/src/PyPlot.jl:232
>  in _require_from_serialized at loading.jl:84
>  in _require_from_serialized at ./loading.jl:109
>  in require at ./loading.jl:186
> during initialization of module PyPlot
>
> julia> 
>
> Any idea?
>
> Uwe Fechner

[julia-users] Re: PyPlot does not work with Julia Version 0.4.0-rc1+5

[Uwe Fechner]

I tried it also with Julia 0.3.11.
Same error.

If I use ipython, import matplotlib works fine.
In [2]: matplotlib.__version__
Out[2]: '1.4.3'

In [3]: 

I used conda on ubuntu 14.04, 64 bit to install matplotlib.

Am Donnerstag, 10. September 2015 18:06:30 UTC+2 schrieb Uwe Fechner:
>
> Hello,
>
> I have a problem with PyPlot on Julia 0.4.0-rc1:
>
> julia> using PyPlot
> ERROR: InitError: Failed to pyimport("matplotlib"): PyPlot will not work 
> until you have a functioning matplotlib module.  PyError 
> (:PyImport_ImportModule) 
> ImportError('cannot import name scimath',)
>   File 
> "/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/matplotlib/__init__.py",
>  
> line 180, in 
> from matplotlib.cbook import is_string_like
>   File 
> "/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/matplotlib/cbook.py",
>  
> line 33, in 
> import numpy as np
>   File 
> "/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/numpy/__init__.py",
>  
> line 170, in 
> from . import add_newdocs
>   File 
> "/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/numpy/add_newdocs.py",
>  
> line 13, in 
> from numpy.lib import add_newdoc
>   File 
> "/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/numpy/lib/__init__.py",
>  
> line 17, in 
> from . import scimath as emath
>
>  in __init__ at /home/ufechner/.julia/v0.4/PyPlot/src/PyPlot.jl:232
>  in _require_from_serialized at loading.jl:84
>  in _require_from_serialized at ./loading.jl:109
>  in require at ./loading.jl:186
> during initialization of module PyPlot
>
> julia> 
>
> Any idea?
>
> Uwe Fechner
>
>

[julia-users] PyPlot does not work with Julia Version 0.4.0-rc1+5

[Uwe Fechner]

Hello,

I have a problem with PyPlot on Julia 0.4.0-rc1:

julia> using PyPlot
ERROR: InitError: Failed to pyimport("matplotlib"): PyPlot will not work 
until you have a functioning matplotlib module.  PyError 
(:PyImport_ImportModule) 
ImportError('cannot import name scimath',)
  File 
"/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/matplotlib/__init__.py",
 
line 180, in 
from matplotlib.cbook import is_string_like
  File 
"/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/matplotlib/cbook.py",
 
line 33, in 
import numpy as np
  File 
"/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/numpy/__init__.py",
 
line 170, in 
from . import add_newdocs
  File 
"/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/numpy/add_newdocs.py",
 
line 13, in 
from numpy.lib import add_newdoc
  File 
"/home/ufechner/miniconda/envs/numba2/lib/python2.7/site-packages/numpy/lib/__init__.py",
 
line 17, in 
from . import scimath as emath

 in __init__ at /home/ufechner/.julia/v0.4/PyPlot/src/PyPlot.jl:232
 in _require_from_serialized at loading.jl:84
 in _require_from_serialized at ./loading.jl:109
 in require at ./loading.jl:186
during initialization of module PyPlot

julia> 

Any idea?

Uwe Fechner

[julia-users] Re: Type inheritance question

[Jeffrey Sarnoff]

And Julia is quite comfortable with using *type_parameter[s] *to guide or 
to fully direct multiple dispatch;
so in the second of the preceding approaches, you could eliminate the 
direction::D field from the type, keeping the D<:Direction parameter
and your functions (Base.plus etc) would do the right thing if you made a 
ForwardDirection and a BackwardDirection version for each needed.
Where that sort of apportionment greatly simplifies or clarifies 
implementation, it is available.
 


On Thursday, September 10, 2015 at 11:39:29 AM UTC-4, Tim Wheeler wrote:
>
> Julia only supports concrete leaves in the type tree - all non-leaves 
> (parents) must be abstract types.
>
> You should be able to do:
>
> abstract AbstractDataStream{T <: Number}
>
> type DirectedDataStream{T <: Number} <: AbstractDataStream{T}
> data::Vector{T}
> stuff
> end
>
> type ReversedDataStream{T <: Number} <: AbstractDataStream{T}
> data::Vector{T}
> stuff
> end
>
> Another thing you can do that still leverages multiple dispatch is define 
> the reversal as a separate type:
>
> abstract Direction
> type ForwardDirection <: Direction end
> type BackwardDirection <: Direction end
>
> type MyDataStream{T<:Number, D<:Direction}
> data::Vector{T}
> direction::D
> stuff
> end
>
> Base.plus{T<:Number, S<:Number, D<:ForwardDirection}(a::MyDataStream{T,D}, 
> b::MyDataStream{S,D}) ...
> Base.plus{T<:Number, S<:Number, D<:BackwardDirection}(a::MyDataStream{T,D
> }, b::MyDataStream{S,D}) ...
>
>
>

Re: [julia-users] Re: META: What are the chances of moving this forum?

[Mike Innes]

My experience with Discourse so far has been pretty good, but I haven't had
enough volume over there to really test the moderation tools, maintenance
requirements and so on. It's certainly functional but I couldn't say for
certain that the value-add is worth the disruption and effort of moving.

If a small pool of users here are interested, I don't mind people
piggy-backing on the Juno board for Julia discussion as something of a
trial run – if people find that it works really well then we can always
discuss next steps from there.

On Thu, 10 Sep 2015 at 16:41 Nils Gudat  wrote:

> The Rust example probably explains this:
> https://youtu.be/pYYmnBma9qk?list=PLP8iPy9hna6Sdx4soiGrSefrmOPdUWixM&t=337
> :)
>

[julia-users] Re: Type inheritance question

[Maurizio Tomasi]

Thanks a lot, Tim, your answer is extremely clear. I'll do some tests with 
both solutions to decide which one I like most.

Cheers,
  Maurizio.

On Thursday, September 10, 2015 at 5:39:29 PM UTC+2, Tim Wheeler wrote:
>
> Julia only supports concrete leaves in the type tree - all non-leaves 
> (parents) must be abstract types.
>
> You should be able to do:
>
> abstract AbstractDataStream{T <: Number}
>
> type DirectedDataStream{T <: Number} <: AbstractDataStream{T}
> data::Vector{T}
> stuff
> end
>
> type ReversedDataStream{T <: Number} <: AbstractDataStream{T}
> data::Vector{T}
> stuff
> end
>
> Another thing you can do that still leverages multiple dispatch is define 
> the reversal as a separate type:
>
> abstract Direction
> type ForwardDirection <: Direction end
> type BackwardDirection <: Direction end
>
> type MyDataStream{T<:Number, D<:Direction}
> data::Vector{T}
> direction::D
> stuff
> end
>
> Base.plus{T<:Number, S<:Number, D<:ForwardDirection}(a::MyDataStream{T,D}, 
> b::MyDataStream{S,D}) ...
> Base.plus{T<:Number, S<:Number, D<:BackwardDirection}(a::MyDataStream{T,D
> }, b::MyDataStream{S,D}) ...
>
>
>

[julia-users] Re: Type inheritance question

[Tim Wheeler]

Julia only supports concrete leaves in the type tree - all non-leaves 
(parents) must be abstract types.

You should be able to do:

abstract AbstractDataStream{T <: Number}

type DirectedDataStream{T <: Number} <: AbstractDataStream{T}
data::Vector{T}
stuff
end

type ReversedDataStream{T <: Number} <: AbstractDataStream{T}
data::Vector{T}
stuff
end

Another thing you can do that still leverages multiple dispatch is define 
the reversal as a separate type:

abstract Direction
type ForwardDirection <: Direction end
type BackwardDirection <: Direction end

type MyDataStream{T<:Number, D<:Direction}
data::Vector{T}
direction::D
stuff
end

Base.plus{T<:Number, S<:Number, D<:ForwardDirection}(a::MyDataStream{T,D}, b
::MyDataStream{S,D}) ...
Base.plus{T<:Number, S<:Number, D<:BackwardDirection}(a::MyDataStream{T,D}, 
b::MyDataStream{S,D}) ...

[julia-users] Re: Good, short set of slides introducing Julia

[andrew cooke]

oops, yes thanks.

On Thursday, 10 September 2015 08:42:01 UTC-3, Jeffrey Sarnoff wrote:
>
> if you want to get into it, 
>
> immutable Complex ... end
>
> does what type Complex ... end does with the added benefit of behaving 
> more as Float64 does with respect to memory and access at the price of not 
> being able to change its component values 
>
> and none of that is needed, though it does make a good example, because 
> Complex is already available:
>
> julia> c = Complex(1.5,0.5)
> 1.5 + 0.5im
>
> julia> typeof(c)
> Complex{Float64}
>
>
> On Thursday, September 10, 2015 at 7:29:50 AM UTC-4, Jeffrey Sarnoff wrote:
>>
>>   type Complex{ T<:AbstractFloat } <: Number
>>   x::T
>>   y::T
>>   end
>>
>>
>> On Thursday, September 10, 2015 at 7:18:13 AM UTC-4, andrew cooke wrote:
>>>
>>> thanks (how does someone working on embedded c++ get to work with 
>>> adaboost?!)
>>>
>>> what i am actually going with is a bunch of links to examples (i can 
>>> email this to everyone before the talk, which will be over google meetup):
>>>
>>> (if anyone has corrections to what follows in the next few hours i am 
>>> happy to hear them, although i think it's pretty uncontroversial)
>>>
>>>
>>> * Data analysis and plots something like R
>>>   http://dcjones.github.io/Gadfly.jl/
>>>
>>> * IJulia reminds me of Mathematica (based on IPython)
>>>   
>>> https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks#julia
>>>   
>>> http://nbviewer.ipython.org/url/beowulf.csail.mit.edu/18.337/fractals.ipynb
>>>   
>>> http://nbviewer.ipython.org/github/JuliaOpt/juliaopt-notebooks/blob/master/notebooks/Matrix%20Completion%20with%20Binary%20Data.ipynb
>>>
>>> * Like Matlab, it makes using arrays easy
>>>   http://quant-econ.net/jl/julia_arrays.html
>>>
>>> * The neat thing (to me) is that unlike Matlab, the arrays code is often
>>>   (not always - it calls out to BLAS etc) written in Julia itself.
>>>   http://julialang.org/benchmarks/
>>>
>>> * More generally, it has managed ("automatic") memory allocation.
>>>   It doesn't have objects/classes, but it has something similar:
>>>   it combines types (like C structs) with multiple dispatch.
>>>
>>>   For example, to define complex types:
>>>
>>>   type Complex64<:Number
>>>   Float64 x
>>>   Float64 y
>>>   end
>>>
>>>   and then define
>>>
>>>   +(a::Complex64, b::Complex64) = Complex64(a.x + b.x, a.y + b.y)
>>>   ... etc
>>>
>>>   Note that + is already defined for a pile of other types (start julia 
>>> and
>>>   type "methods(+)" to see them all).
>>>
>>>   Which is almost the same as defining a Complex64 class with a "+" 
>>> method.
>>>   Main differences are (1) all types used to choose method and (2) only 
>>> final
>>>   types have fields (so memory layout is known).
>>>
>>>   And it's fast because the compiler compiles functions at runtime 
>>> depending
>>>   on types when called.  So the code ends up being compiled for a very
>>>   specific type, even if in your code you just had "a+b" and it wasn't 
>>> clear
>>>   whether a and b were Complex64 or Float64 or Int32 or ...
>>>
>>>   Downside to that is that when you first run a program it is actually 
>>> slow,
>>>   as it compiles things.  But second and further calls to any routine are
>>>   fast.
>>>
>>>   I've written CRC32 (checksum) code of comparable speed to libz (pretty 
>>> much
>>>   the C benchmark).  It wasn't "simple", but it was no harder than C.  
>>> You
>>>   have profiling tools, you unroll loops, etc etc.
>>>
>>>   (In practice you would probably do:
>>>
>>>   type Complex(F<:Float}<:Number
>>>   F x
>>>   F y
>>>   end
>>>
>>>   because it hs parameterised types)
>>>
>>>
>>> On Thursday, 10 September 2015 05:21:42 UTC-3, Carlos Becker wrote:

 Hi Andrew, my slides are here, 
 https://sites.google.com/site/carlosbecker/a-few-notes , they are for 
 v0.3: 

 If you need the openoffice original let me know, I can send it to you.
 Cheers.

 El miércoles, 9 de septiembre de 2015, 14:07:36 (UTC+2), andrew cooke 
 escribió:
>
> ok, thanks everyone i'll have a look at all those.  andrew
>
> On Tuesday, 8 September 2015 17:58:33 UTC-3, andrew cooke wrote:
>>
>>
>> I need to give a presentation at work and was wondering is slides 
>> already exist that:
>>
>>   * show how fast it is in benchmarks
>>
>>   * show that it's similar to matlab (matrix stuff)
>>
>>   * show that you can write fast inner loops
>>
>>  For bonus points:
>>
>>   * show how you can add other numerical types at no "cost"
>>
>>   * show how mutiple dispatch can be useful
>>
>>   * show how someone used to OO in, say, python, won't feel too lost
>>
>> Preferably just one slide per point.  Very short.
>>
>> Thanks,
>> Andrew
>>
>>

[julia-users] Type inheritance question

[Maurizio Tomasi]

Hi to everybody,

  I'm trying to implement a set of types in Julia, but I fear my C++ 
background is leading me to a wrong path. I want to define a type, 
DataStream which is basically a vector of numbers with some metadata 
associated with it. The order of the elements in the vector is important, 
because the instrument that measures such data can order them in two ways: 
let's say that they can be saved either in direct or reverse order (things 
are more complicated, but this is the point). There are many operations 
that I want to do with DataStream:

   1. Combine two of them by means of mathematical operations (in this 
   case, mixing two DataStreams with different orderings should be forbidden);
   2. Transform the ordering of one datastream into another and vice versa;
   3. Finally, there is a class of operations which can be applied to any 
   DataStream, regardless of its ordering.

My question is: what is the best, "Julian" way to implement DataStream? I 
was thinking of defining three types:

type DataStream{T <: Number}
data :: Vector{T}
# Put other variables here
end

type DirectDataStream{T <: Number} <: DataStream{T}
end

type ReverseDataStream{T <: Number} <: DataStream{T}
end

and then implement each function using the proper typing. This would have 
the advantage that the compiler itself should check if the operations on 
DataStream objects are compatible with their ordering.

Unfortunately, this makes the compiler complain because, as far as I 
understand from Julia's source code 
(https://github.com/JuliaLang/julia/blob/master/src/toplevel.c#L639), the 
base type (DataStream{T}) is not abstract. A solution would be to add a 
@enum member to DataStream which specifies the ordering, but in this case I 
should manually check if the ordering is ok or not in the implementation of 
every function. Is there a way to implement DataStream which is able to 
maximally exploit Julia's type system?

Thanks a lot,
  Maurizio.

Re: [julia-users] Re: META: What are the chances of moving this forum?

[Nils Gudat]

The Rust example probably explains this: 
https://youtu.be/pYYmnBma9qk?list=PLP8iPy9hna6Sdx4soiGrSefrmOPdUWixM&t=337 
:)

Re: [julia-users] Convert an Array{Any,2} to an AbstractVector in Julia

[Seth]

would vec() also work for you? It's supposed to be pretty fast.

julia> a = rand(4,4)
4x4 Array{Float64,2}:
 0.794534   0.618345   0.941777  0.449794
 0.0615869  0.513610.141349  0.874955
 0.504186   0.0687788  0.64149   0.863215
 0.485404   0.193311   0.766789  0.0304138

julia> vec(a)
16-element Array{Float64,1}:
 0.794534
 0.0615869
 0.504186
 0.485404
 0.618345
 0.51361
 0.0687788
 0.193311
 0.941777
 0.141349
 0.64149
 0.766789
 0.449794
 0.874955
 0.863215
 0.0304138



On Thursday, September 10, 2015 at 5:38:35 AM UTC-7, Charles Santana wrote:
>
> Mauro, you are a genius! :) 
>
> Thanks a lot! It worked perfectly! 
>
> Best,
>
> Charles
>
> On 10 September 2015 at 14:30, Mauro > 
> wrote:
>
>> >>> wc = wordcloud(x = corpus)
>> > ERROR: TypeError: typeassert: expected AbstractArray{T,1}, got 
>> Array{Any,2}
>> >
>> > Do you have any suggestion about how to convert an Array{Any,2} to an
>> > AbstractVector? Or how to read a text file to an AbstractVector 
>> variable?
>>
>> Have you tried to just flatten the array:
>>
>> wc = wordcloud(x = corpus[:])
>>
>
>
>
> -- 
> Um axé! :)
>
> --
> Charles Novaes de Santana, PhD
> http://www.imedea.uib-csic.es/~charles
>

Re: [julia-users] Re: META: What are the chances of moving this forum?

[Isaiah Norton]

>
> More confusion: my post was about github-issues as a mailing list.  But
> of course this applies equally to discourse, which indeed Juno uses.
>
-1 to re-purposing GitHub issues for any sort of free-form discussion. I
don't see that as solving any problems. At scale, the GitHub issue tracker
is limited even for the intended purpose.

I do like Discourse because of the auto-suggestion, tiered moderation,
proper threading, categorization, and other features that would (hopefully)
*cut down* on the number of pings we see. Discourse also has at least
one-way GitHub cross-linking (mentioning a GitHub issue in discourse will
expand to a short summary, IIRC).

For another example of an active programming language-related Discourse
site, see:

http://users.rust-lang.org

On Thu, Sep 10, 2015 at 10:01 AM, Mauro  wrote:

> More confusion: my post was about github-issues as a mailing list.  But
> of course this applies equally to discourse, which indeed Juno uses.
>
> On Thu, 2015-09-10 at 15:51, Nils Gudat  wrote:
> > Juno is already on (I think) discourse: http://discuss.junolab.org/about
> > That's what already brought me to post this, as the forum over there is
> > infinitely better than Google Groups. Maybe Mike has some comments about
> > time & monetary effort involved in setting this up?
> >
> > On Thursday, September 10, 2015 at 2:15:53 PM UTC+1, Mauro wrote:
> >
> >> I think you may have misunderstood my comment: I suggested that one of
> >> the larger Julia projects, e.g. Julia-Stats, Juno, or Gadfly, would try
> >> this out and report back.
> >>
> >> But yes, the JuliaUsers would have to be part of JuliaLang.
>
>

Re: [julia-users] Re: META: What are the chances of moving this forum?

[Scott Jones]

I just checked out Mike's Juno discourse site, looks very good to me.

On Thursday, September 10, 2015 at 9:51:09 AM UTC-4, Nils Gudat wrote:
>
> Juno is already on (I think) discourse: http://discuss.junolab.org/about
> That's what already brought me to post this, as the forum over there is 
> infinitely better than Google Groups. Maybe Mike has some comments about 
> time & monetary effort involved in setting this up?
>
> On Thursday, September 10, 2015 at 2:15:53 PM UTC+1, Mauro wrote:
>
>> I think you may have misunderstood my comment: I suggested that one of 
>> the larger Julia projects, e.g. Julia-Stats, Juno, or Gadfly, would try 
>> this out and report back. 
>>
>> But yes, the JuliaUsers would have to be part of JuliaLang. 
>>
>>

Re: [julia-users] Re: META: What are the chances of moving this forum?

[Mauro]

More confusion: my post was about github-issues as a mailing list.  But
of course this applies equally to discourse, which indeed Juno uses.

On Thu, 2015-09-10 at 15:51, Nils Gudat  wrote:
> Juno is already on (I think) discourse: http://discuss.junolab.org/about
> That's what already brought me to post this, as the forum over there is 
> infinitely better than Google Groups. Maybe Mike has some comments about 
> time & monetary effort involved in setting this up?
>
> On Thursday, September 10, 2015 at 2:15:53 PM UTC+1, Mauro wrote:
>
>> I think you may have misunderstood my comment: I suggested that one of 
>> the larger Julia projects, e.g. Julia-Stats, Juno, or Gadfly, would try 
>> this out and report back. 
>>
>> But yes, the JuliaUsers would have to be part of JuliaLang. 

[julia-users] Re: Multi-dimensional Arrays

[Scott Jones]

Have you had experience with multi-dimensional arrays in other languages?
(I spent 3 decades implementing them, both "local" (process private) and 
"global" (shared, persistent, distributed) in
M/Mumps -> InterSystems' Caché, so I know how useful they can be)

I'd also like to see real MD associative arrays, both local and "global", 
available in Julia.

On Thursday, September 10, 2015 at 3:06:45 AM UTC-4, Leonardo wrote:
>
> Hi All,
> I need some clarifications about subclassing AbstractArray to create a 
> multi-dimensional array with unspecified number of dimensions.
>
> I've created an (useless) example defining a simple container (attached) 
> to clarify me necessary step and function to implement, and then my doubts:
>
>- for Julia 0.4.x a chapter *Interface* 
>states 
>that minimal function that I MUST create are size(), getindex(), 
>setindex!(), but in my case I MUST create another form of getindex(), 
>setindex!() listed between optional methods
>- for Julia 0.3.x previous chapter doesn't exists, then I don't have a 
>clear guideline to implement my type
>- running attached example (in Julia 0.3.11 64bit under Win7 64bit), 
>other function are required to show objects in REPL (some also 
> undocumented 
>like print_matrix() ), otherwise creation of an object (e.g. with 
>command a = MyArr(3)) fails
>
> Than, what's correct way to subclass AbstractArray for my needs 
> (multidimensional array)? 
>
>
> Many thanks in advance for anyone can indicate me right direction
>
>
> Leonardo
>
>
>

[julia-users] Re: Micro-benchmark on julialang.org needs updating

[Scott Jones]

If at all possible, if someone with Python expertise could get things set 
up for you, would be good to compare also to Numba, Python 3.5 (should be 
released shortly), and PyPy3.

If anything shows that other languages are much better than Julia in some 
area, all the more incentive for us to step up our game.   (No matter what, 
I still think Julia wins hands-down on expressiveness, LOC needed to write 
performant code).

Another thing it might be useful to show in a graph on the JuliaLang page, 
is the LOC for each microbenchmark, as that's an important metric as well, 
that I've seen elsewhere graphed showing big advantage for Julia.

On Wednesday, September 9, 2015 at 10:00:48 PM UTC-4, Tony Kelman wrote:
>
> We'll probably update to more recent versions of everything and re-run the 
> benchmarks once 0.4.0 final is released and someone gets some time to get 
> all the relevant software set up on the same machine.
>
>
> On Saturday, September 5, 2015 at 12:03:32 PM UTC-7, Stefan Stoll wrote:
>>
>> Hi all,
>>
>> I am a veteran Matlab user and have recently started playing around with 
>> Julia. What a great language!
>>
>> Today I noticed that the micro-benchmark published on julialang.org is 
>> quite out of date, esp. what Matlab is concerned. The benchmark uses Matlab 
>> R2014a, but the most recent R2015b has a new execution engine that is 
>> significantly faster.
>>
>> For a fair comparison, I suggest rerunning the benchmark with the latest 
>> Matlab (and Julia) versions and updating the numbers on the website.
>>
>> Here's what I get when running the micro-benchmark function perf() on 
>> Matlab R2014b on my old laptop:
>> matlab,fib,95.66057408
>> matlab,parse_int,151.79947331
>> matlab,mandel,12.45005290
>> matlab,quicksort,24.00013615
>> matlab,pi_sum,47.18823305
>> matlab,rand_mat_stat,62.70896132
>> matlab,rand_mat_mul,221.44602147
>>
>> And here are the results with Matlab R2015b on the same laptop:
>> matlab,fib,1.04503455
>> matlab,parse_int,95.14879485
>> matlab,mandel,3.11889527
>> matlab,quicksort,2.05846277
>> matlab,pi_sum,36.74599177
>> matlab,rand_mat_stat,100.73379335
>> matlab,rand_mat_mul,224.68040137
>>
>> The biggest speedups are in the Fibonacci and quicksort tests.
>>
>>
>>

Re: [julia-users] Re: META: What are the chances of moving this forum?

[Nils Gudat]

Juno is already on (I think) discourse: http://discuss.junolab.org/about
That's what already brought me to post this, as the forum over there is 
infinitely better than Google Groups. Maybe Mike has some comments about 
time & monetary effort involved in setting this up?

On Thursday, September 10, 2015 at 2:15:53 PM UTC+1, Mauro wrote:

> I think you may have misunderstood my comment: I suggested that one of 
> the larger Julia projects, e.g. Julia-Stats, Juno, or Gadfly, would try 
> this out and report back. 
>
> But yes, the JuliaUsers would have to be part of JuliaLang. 
>
>

Re: [julia-users] Re: META: What are the chances of moving this forum?

[Jarrett Revels]

>
> I think you may have misunderstood my comment: I suggested that one of 
> the larger Julia projects, e.g. Julia-Stats, Juno, or Gadfly, would try 
> this out and report back.
>

Oh yeah, sorry, that makes more sense haha.

On Thursday, September 10, 2015 at 9:15:53 AM UTC-4, Mauro wrote:
>
> >> Maybe it would be best if this was 
> >> tried out with a large Julia project to see the ins and outs? 
> >> Volunteers? 
> > 
> > I imagine that the only way that a tentative switch to a "JuliaUsers" 
> repo 
> > on Github would gain any significant traction is if the repo was under 
> the 
> > JuliaLang org. 
>
> I think you may have misunderstood my comment: I suggested that one of 
> the larger Julia projects, e.g. Julia-Stats, Juno, or Gadfly, would try 
> this out and report back. 
>
> But yes, the JuliaUsers would have to be part of JuliaLang. 
>
> > On Thursday, September 10, 2015 at 5:15:12 AM UTC-4, Mauro wrote: 
> >> 
> >> >> Do any of these other suggestions have a mailing list interface? 
> >> > 
> >> > GitHub's issue tracking interface does. 
> >> 
> >> In my email client the threading doesn't seem to work well with github 
> >> issue-emails, so I end up using the web interface most of the time. 
> >> Otherwise it might work well.  I had a quick look around on the 
> >> internet, not many projects seem to use issues as mailing list.  I only 
> >> found these: 
> >> https://lists.w3.org/Archives/Public/public-houdini/2015Sep/0004.html 
> >> https://github.com/hapijs/discuss/issues 
> >> 
> >> @-notifications could be quite nice.  Maybe it would be best if this 
> was 
> >> tried out with a large Julia project to see the ins and outs? 
> >> Volunteers? 
> >> 
> >> > On Wednesday, September 9, 2015 at 3:59:51 PM UTC-4, Robert DJ wrote: 
> >> >> 
> >> >> I'm not a fan of Google, so I think it would great to find another 
> >> forum. 
> >> >> Besides, I fully agree with the technical issues mentioned. 
> >> >> 
> >> >> Regarding the need for user accounts on e.g. GitHub, I don't see how 
> >> that 
> >> >> is different from requiring a Google account for participating 
> here... 
> >> >> 
> >> >> On Wednesday, September 9, 2015 at 5:33:33 PM UTC+2, Jarrett Revels 
> >> wrote: 
> >> >>> 
> >> >>> I often find myself wishing that this forum was just a GitHub repo, 
> >> with 
> >> >>> posts as issues. It would be great for supporting @-style mentions, 
> >> >>> markdown, issue-linking, etc. The main downside would be forcing 
> >> everybody 
> >> >>> to have GitHub account (not bad IMO, but I can see others having an 
> >> issue 
> >> >>> for it). 
> >> >>> 
> >> >>> It would probably be a bad idea to upheave the forums, anyway, 
> >> especially 
> >> >>> at such a critical moment in Julia's development (v0.4 getting 
> >> released 
> >> >>> soon). I doubt this is going to happen. 
> >> >>> 
> >> >>> On Wednesday, September 9, 2015 at 7:34:58 AM UTC-4, Nils Gudat 
> wrote: 
> >>  
> >>  Was just thinking about this as first I had to try opening a 
> thread 
> >> here 
> >>  a couple of times before any posts were actually displayed, and 
> then 
> >> read 
> >>  through this 
> >>  < 
> >> 
> http://discuss.junolab.org/t/how-to-let-julia-be-the-boss-of-juno-windows-windows-issue/320>
>  
>
> >> 
> >>  thread on Mike's Juno Discuss forum, where a user had a question 
> >> which was 
> >>  almost answered by the nice auto-suggestion feature that pops up 
> when 
> >> you 
> >>  ask a question. 
> >>  
> >>  I feel that Google Groups has mostly downsides - the system is 
> slow, 
> >>  with posts frequently not loading, double posts because of this, 
> no 
> >> proper 
> >>  code formatting or Markdown support etc. 
> >>  
> >>  Is there a chance this could be moved to something like Discuss or 
> is 
> >>  there too much inertia in having an "established" forum on Google 
> >> Groups? 
> >>  
> >> >>> 
> >> 
> >> 
>
>

[julia-users] Re: Multi-dimensional Arrays

[Matt Bauman]

The reason you're needing to define more methods than the interface chapter 
suggests is because you haven't specified the AbstractArray's parameters; 
this is just as important as the required methods.  That is, you need to 
define your type as

type MyArr{T,N} <: AbstractArray{T,N}

in order for the interface to be properly defined.  This could be better 
emphasized in the interfaces chapter.

I'm not entirely sure what your needs are — could you clarify your use 
case?  Your wording makes it sound like you want the ability to dynamically 
change the dimensionality of the array at runtime.  Unfortunately, *many* 
of the builtin methods for AbstractArrays depend upon the dimensionality 
being defined as a type parameter… and therefore constant for each object. 
 Without that, you'll hit tons of missing methods that you'll need to 
implement on your own (as you've experienced).

Matt

On Thursday, September 10, 2015 at 3:06:45 AM UTC-4, Leonardo wrote:
>
> Hi All,
> I need some clarifications about subclassing AbstractArray to create a 
> multi-dimensional array with unspecified number of dimensions.
>
> I've created an (useless) example defining a simple container (attached) 
> to clarify me necessary step and function to implement, and then my doubts:
>
>- for Julia 0.4.x a chapter *Interface* 
>states 
>that minimal function that I MUST create are size(), getindex(), 
>setindex!(), but in my case I MUST create another form of getindex(), 
>setindex!() listed between optional methods
>- for Julia 0.3.x previous chapter doesn't exists, then I don't have a 
>clear guideline to implement my type
>- running attached example (in Julia 0.3.11 64bit under Win7 64bit), 
>other function are required to show objects in REPL (some also 
> undocumented 
>like print_matrix() ), otherwise creation of an object (e.g. with 
>command a = MyArr(3)) fails
>
> Than, what's correct way to subclass AbstractArray for my needs 
> (multidimensional array)? 
>
>
> Many thanks in advance for anyone can indicate me right direction
>
>
> Leonardo
>
>
>

Re: [julia-users] Re: META: What are the chances of moving this forum?

[Mauro]

>> Maybe it would be best if this was
>> tried out with a large Julia project to see the ins and outs?
>> Volunteers?
>
> I imagine that the only way that a tentative switch to a "JuliaUsers" repo 
> on Github would gain any significant traction is if the repo was under the 
> JuliaLang org.

I think you may have misunderstood my comment: I suggested that one of
the larger Julia projects, e.g. Julia-Stats, Juno, or Gadfly, would try
this out and report back.

But yes, the JuliaUsers would have to be part of JuliaLang.

> On Thursday, September 10, 2015 at 5:15:12 AM UTC-4, Mauro wrote:
>>
>> >> Do any of these other suggestions have a mailing list interface? 
>> > 
>> > GitHub's issue tracking interface does. 
>>
>> In my email client the threading doesn't seem to work well with github 
>> issue-emails, so I end up using the web interface most of the time. 
>> Otherwise it might work well.  I had a quick look around on the 
>> internet, not many projects seem to use issues as mailing list.  I only 
>> found these: 
>> https://lists.w3.org/Archives/Public/public-houdini/2015Sep/0004.html 
>> https://github.com/hapijs/discuss/issues 
>>
>> @-notifications could be quite nice.  Maybe it would be best if this was 
>> tried out with a large Julia project to see the ins and outs? 
>> Volunteers? 
>>
>> > On Wednesday, September 9, 2015 at 3:59:51 PM UTC-4, Robert DJ wrote: 
>> >> 
>> >> I'm not a fan of Google, so I think it would great to find another 
>> forum. 
>> >> Besides, I fully agree with the technical issues mentioned. 
>> >> 
>> >> Regarding the need for user accounts on e.g. GitHub, I don't see how 
>> that 
>> >> is different from requiring a Google account for participating here... 
>> >> 
>> >> On Wednesday, September 9, 2015 at 5:33:33 PM UTC+2, Jarrett Revels 
>> wrote: 
>> >>> 
>> >>> I often find myself wishing that this forum was just a GitHub repo, 
>> with 
>> >>> posts as issues. It would be great for supporting @-style mentions, 
>> >>> markdown, issue-linking, etc. The main downside would be forcing 
>> everybody 
>> >>> to have GitHub account (not bad IMO, but I can see others having an 
>> issue 
>> >>> for it). 
>> >>> 
>> >>> It would probably be a bad idea to upheave the forums, anyway, 
>> especially 
>> >>> at such a critical moment in Julia's development (v0.4 getting 
>> released 
>> >>> soon). I doubt this is going to happen. 
>> >>> 
>> >>> On Wednesday, September 9, 2015 at 7:34:58 AM UTC-4, Nils Gudat wrote: 
>>  
>>  Was just thinking about this as first I had to try opening a thread 
>> here 
>>  a couple of times before any posts were actually displayed, and then 
>> read 
>>  through this 
>>  <
>> http://discuss.junolab.org/t/how-to-let-julia-be-the-boss-of-juno-windows-windows-issue/320>
>>  
>>
>>  thread on Mike's Juno Discuss forum, where a user had a question 
>> which was 
>>  almost answered by the nice auto-suggestion feature that pops up when 
>> you 
>>  ask a question. 
>>  
>>  I feel that Google Groups has mostly downsides - the system is slow, 
>>  with posts frequently not loading, double posts because of this, no 
>> proper 
>>  code formatting or Markdown support etc. 
>>  
>>  Is there a chance this could be moved to something like Discuss or is 
>>  there too much inertia in having an "established" forum on Google 
>> Groups? 
>>  
>> >>> 
>>
>>

Re: [julia-users] Re: META: What are the chances of moving this forum?

[Jarrett Revels]

>
> Maybe it would be best if this was
> tried out with a large Julia project to see the ins and outs?
> Volunteers?


I imagine that the only way that a tentative switch to a "JuliaUsers" repo 
on Github would gain any significant traction is if the repo was under the 
JuliaLang org.

On Thursday, September 10, 2015 at 5:15:12 AM UTC-4, Mauro wrote:
>
> >> Do any of these other suggestions have a mailing list interface? 
> > 
> > GitHub's issue tracking interface does. 
>
> In my email client the threading doesn't seem to work well with github 
> issue-emails, so I end up using the web interface most of the time. 
> Otherwise it might work well.  I had a quick look around on the 
> internet, not many projects seem to use issues as mailing list.  I only 
> found these: 
> https://lists.w3.org/Archives/Public/public-houdini/2015Sep/0004.html 
> https://github.com/hapijs/discuss/issues 
>
> @-notifications could be quite nice.  Maybe it would be best if this was 
> tried out with a large Julia project to see the ins and outs? 
> Volunteers? 
>
> > On Wednesday, September 9, 2015 at 3:59:51 PM UTC-4, Robert DJ wrote: 
> >> 
> >> I'm not a fan of Google, so I think it would great to find another 
> forum. 
> >> Besides, I fully agree with the technical issues mentioned. 
> >> 
> >> Regarding the need for user accounts on e.g. GitHub, I don't see how 
> that 
> >> is different from requiring a Google account for participating here... 
> >> 
> >> On Wednesday, September 9, 2015 at 5:33:33 PM UTC+2, Jarrett Revels 
> wrote: 
> >>> 
> >>> I often find myself wishing that this forum was just a GitHub repo, 
> with 
> >>> posts as issues. It would be great for supporting @-style mentions, 
> >>> markdown, issue-linking, etc. The main downside would be forcing 
> everybody 
> >>> to have GitHub account (not bad IMO, but I can see others having an 
> issue 
> >>> for it). 
> >>> 
> >>> It would probably be a bad idea to upheave the forums, anyway, 
> especially 
> >>> at such a critical moment in Julia's development (v0.4 getting 
> released 
> >>> soon). I doubt this is going to happen. 
> >>> 
> >>> On Wednesday, September 9, 2015 at 7:34:58 AM UTC-4, Nils Gudat wrote: 
>  
>  Was just thinking about this as first I had to try opening a thread 
> here 
>  a couple of times before any posts were actually displayed, and then 
> read 
>  through this 
>  <
> http://discuss.junolab.org/t/how-to-let-julia-be-the-boss-of-juno-windows-windows-issue/320>
>  
>
>  thread on Mike's Juno Discuss forum, where a user had a question 
> which was 
>  almost answered by the nice auto-suggestion feature that pops up when 
> you 
>  ask a question. 
>  
>  I feel that Google Groups has mostly downsides - the system is slow, 
>  with posts frequently not loading, double posts because of this, no 
> proper 
>  code formatting or Markdown support etc. 
>  
>  Is there a chance this could be moved to something like Discuss or is 
>  there too much inertia in having an "established" forum on Google 
> Groups? 
>  
> >>> 
>
>

[julia-users] Re: META: What are the chances of moving this forum?

[Jonathan Malmaud]

Some of us were thinking seriously about moving to Discourse. Mostly it 
would be a matter of handling the financing and administration of a 
Discourse server. Being able to import the archive of threads from the 
google group into Discourse would also be a help. 

On Wednesday, September 9, 2015 at 7:34:58 AM UTC-4, Nils Gudat wrote:
>
> Was just thinking about this as first I had to try opening a thread here a 
> couple of times before any posts were actually displayed, and then read 
> through this 
> 
>  
> thread on Mike's Juno Discuss forum, where a user had a question which was 
> almost answered by the nice auto-suggestion feature that pops up when you 
> ask a question.
>
> I feel that Google Groups has mostly downsides - the system is slow, with 
> posts frequently not loading, double posts because of this, no proper code 
> formatting or Markdown support etc.
>
> Is there a chance this could be moved to something like Discuss or is 
> there too much inertia in having an "established" forum on Google Groups?
>

Re: [julia-users] Re: Finding the index of a type member

[J Luis]

Thanks too. I have to start studying the c api as well.

quinta-feira, 10 de Setembro de 2015 às 03:06:03 UTC+1, Yichao Yu escreveu:
>
> On Wed, Sep 9, 2015 at 9:27 PM, Luke Stagner  > wrote: 
> > Firstly, instead of using ```symbol("is_continuous")``` you can use the 
> > colon notation ```:is_continuous```. Secondly, you can do element wise 
> > comparison by using ```.==``` operator. This will return a BitArray. You 
> can 
> > then find where the BitArray is true by using the ```find``` function 
> which 
> > returns an array of indices. 
> > 
> > So for your case all you would need to do is 
> > ``` 
> > index = find(fn .== :is_continuous) 
> > ``` 
> > 
>
> findfirst(fn, :is_continuous) 
>
> There's also the c api jl_field_index that can be called with 
> `ccall(:jl_field_index, Cint, (Any, Any, Cint), GMT_PALETTE, 
> :is_continuous, 1) + 1` 
>
> > 
> > On Wednesday, September 9, 2015 at 6:01:47 PM UTC-7, J Luis wrote: 
> >> 
> >> So I need to find position of a certain type member in a type. Easy, I 
> >> though 
> >> 
> >> julia> fn = fieldnames(GMT_PALETTE) 
> >> 9-element Array{Symbol,1}: 
> >>  :n_headers 
> >>  :n_colors 
> >>  :alloc_level 
> >>  :auto_scale 
> >>  :model 
> >>  :is_gray 
> >>  :is_bw 
> >>  :is_continuous 
> >>  :z_unit_to_meter 
> >> 
> >> julia> search(fn,"is_continuous") 
> >> ERROR: MethodError: `search` has no method matching 
> >> search(::Array{Symbol,1}, ::ASCIIString) 
> >> Closest candidates are: 
> >>   search(::AbstractString, ::AbstractString) 
> >>   search(::AbstractString, ::AbstractString, ::Integer) 
> >> 
> >> Went to the docs and found the "symbol" function and though, ok now it 
> >> will work 
> >> 
> >> julia> search(fn,symbol("is_continuous")) 
> >> ERROR: MethodError: `search` has no method matching 
> >> search(::Array{Symbol,1}, ::Symbol) 
> >> 
> >> Ok, I can do a loop over the number of elements and ask 
> >> 
> >> fn[k] == symbol("is_continuous") 
> >> 
> >> but isn't there a more compact way of do this ? 
> >> 
> >> (I confess this parts of Julia are annoying) 
> >> 
> >> Thanks 
>

Re: [julia-users] Convert an Array{Any,2} to an AbstractVector in Julia

[Charles Novaes de Santana]

Mauro, you are a genius! :)

Thanks a lot! It worked perfectly!

Best,

Charles

On 10 September 2015 at 14:30, Mauro  wrote:

> >>> wc = wordcloud(x = corpus)
> > ERROR: TypeError: typeassert: expected AbstractArray{T,1}, got
> Array{Any,2}
> >
> > Do you have any suggestion about how to convert an Array{Any,2} to an
> > AbstractVector? Or how to read a text file to an AbstractVector variable?
>
> Have you tried to just flatten the array:
>
> wc = wordcloud(x = corpus[:])
>



-- 
Um axé! :)

--
Charles Novaes de Santana, PhD
http://www.imedea.uib-csic.es/~charles

Re: [julia-users] Convert an Array{Any,2} to an AbstractVector in Julia

[Mauro]

>>> wc = wordcloud(x = corpus)
> ERROR: TypeError: typeassert: expected AbstractArray{T,1}, got Array{Any,2}
>
> Do you have any suggestion about how to convert an Array{Any,2} to an
> AbstractVector? Or how to read a text file to an AbstractVector variable?

Have you tried to just flatten the array:

wc = wordcloud(x = corpus[:])

[julia-users] Convert an Array{Any,2} to an AbstractVector in Julia

[Charles Novaes de Santana]

Dear all,

I just started to play with Vega, a great Julia package for visualization,
developed by John Myles ( http://johnmyleswhite.github.io/Vega.jl ). One of
the features I like more is the wordcloud (
http://johnmyleswhite.github.io/Vega.jl/wordcloud.html).

I could easily reproduce the example he put in the webpage, in which the
text to be processed is defined as a the following:

>> corpus = [ "Julia is a high-level, high-performance dynamic programming
language for technical computing,...", "Julia programs are organized around
multiple dispatch; by defining functions and overloading them ..." ]

>> wc = wordcloud(x = corpus)

Now I would like to read a text from an ascii file. My first try was to
read an ascii file using the command readdlm. As follows:

>> corpus = readdlm("./textfile.txt",'\n');

(you can find the file textfile.txt here:
https://github.com/cndesantana/filestoshare/blob/master/textfile.txt)

The function used to build the wordcloud (wordcloud) asks as input an
AbstractVector. However, when I read the text using readdlm the variable
corpus is an Array{Any,2}. So, when I call the function wordcloud I have
the following (expected) error message:

>> wc = wordcloud(x = corpus)
ERROR: TypeError: typeassert: expected AbstractArray{T,1}, got Array{Any,2}

Do you have any suggestion about how to convert an Array{Any,2} to an
AbstractVector? Or how to read a text file to an AbstractVector variable?

Thanks for your attention and for any tip!

Best,

Charles
-- 
Um axé! :)

--
Charles Novaes de Santana, PhD
http://www.imedea.uib-csic.es/~charles

[julia-users] Re: DataFrame filling NA values

[Cedric St-Jean]

Thanks! I wasn't looking for inplace, so each_replacena is half of what I 
was looking for. How would you write it? I was surprised that DataFrame's 
constructor didn't accept a dict of Symbol=>DataArray, so I wound up 
writing `out_df = DataFrame()`, then modifying it, but that's ugly.

On Thursday, September 10, 2015 at 12:08:14 AM UTC-4, Alex Ames wrote:
>
> There's also the each_replacena(dataframe[:col], replacement) function, 
> but that only operates on columns and doesn't appear to replace in-place. A 
> straightforward in-place replacement would look something like: 
>
> function replacena!(dframe::DataFrame, replacement::Any)
>   nrows, ncols = size(dframe)
>   for j = 1:ncols; for i = 1:nrows
> if isna(dframe[i,j]); dframe[i,j] = replacement; end
> end
>   end
> end
>
> On Wednesday, September 9, 2015 at 1:42:37 PM UTC-5, Cedric St-Jean wrote:
>>
>> Just found the DataFrames.isna() function, so that's solved, only the 
>> iteration question remains.
>>
>> On Wednesday, September 9, 2015 at 2:26:23 PM UTC-4, Cedric St-Jean wrote:
>>>
>>> In 0.3, what's the best way of replacing all NA with a given value (eg. 
>>> 0)? Pandas has df.fillna. I've noticed that
>>>
>>> isnan(DataFrames.NA)
>>>
>>> is undefined and 
>>>
>>> DataFrames.NA == DataFrames.NA
>>>
>>> is NA. The docs say it's a singleton, so I assume that I should use === 
>>> to check if it's NA? Likewise, how should I iterate over all elements? I 
>>> was disappointed that `map(fun, df)` is not defined (is that an omission? 
>>> it's defined for matrices). Should I just go over all columns one by one?
>>>
>>> Cédric
>>>
>>

[julia-users] Re: Good, short set of slides introducing Julia

[Jeffrey Sarnoff]

if you want to get into it, 

immutable Complex ... end

does what type Complex ... end does with the added benefit of behaving more 
as Float64 does with respect to memory and access at the price of not being 
able to change its component values 

and none of that is needed, though it does make a good example, because 
Complex is already available:

julia> c = Complex(1.5,0.5)
1.5 + 0.5im

julia> typeof(c)
Complex{Float64}


On Thursday, September 10, 2015 at 7:29:50 AM UTC-4, Jeffrey Sarnoff wrote:
>
>   type Complex{ T<:AbstractFloat } <: Number
>   x::T
>   y::T
>   end
>
>
> On Thursday, September 10, 2015 at 7:18:13 AM UTC-4, andrew cooke wrote:
>>
>> thanks (how does someone working on embedded c++ get to work with 
>> adaboost?!)
>>
>> what i am actually going with is a bunch of links to examples (i can 
>> email this to everyone before the talk, which will be over google meetup):
>>
>> (if anyone has corrections to what follows in the next few hours i am 
>> happy to hear them, although i think it's pretty uncontroversial)
>>
>>
>> * Data analysis and plots something like R
>>   http://dcjones.github.io/Gadfly.jl/
>>
>> * IJulia reminds me of Mathematica (based on IPython)
>>   
>> https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks#julia
>>   
>> http://nbviewer.ipython.org/url/beowulf.csail.mit.edu/18.337/fractals.ipynb
>>   
>> http://nbviewer.ipython.org/github/JuliaOpt/juliaopt-notebooks/blob/master/notebooks/Matrix%20Completion%20with%20Binary%20Data.ipynb
>>
>> * Like Matlab, it makes using arrays easy
>>   http://quant-econ.net/jl/julia_arrays.html
>>
>> * The neat thing (to me) is that unlike Matlab, the arrays code is often
>>   (not always - it calls out to BLAS etc) written in Julia itself.
>>   http://julialang.org/benchmarks/
>>
>> * More generally, it has managed ("automatic") memory allocation.
>>   It doesn't have objects/classes, but it has something similar:
>>   it combines types (like C structs) with multiple dispatch.
>>
>>   For example, to define complex types:
>>
>>   type Complex64<:Number
>>   Float64 x
>>   Float64 y
>>   end
>>
>>   and then define
>>
>>   +(a::Complex64, b::Complex64) = Complex64(a.x + b.x, a.y + b.y)
>>   ... etc
>>
>>   Note that + is already defined for a pile of other types (start julia 
>> and
>>   type "methods(+)" to see them all).
>>
>>   Which is almost the same as defining a Complex64 class with a "+" 
>> method.
>>   Main differences are (1) all types used to choose method and (2) only 
>> final
>>   types have fields (so memory layout is known).
>>
>>   And it's fast because the compiler compiles functions at runtime 
>> depending
>>   on types when called.  So the code ends up being compiled for a very
>>   specific type, even if in your code you just had "a+b" and it wasn't 
>> clear
>>   whether a and b were Complex64 or Float64 or Int32 or ...
>>
>>   Downside to that is that when you first run a program it is actually 
>> slow,
>>   as it compiles things.  But second and further calls to any routine are
>>   fast.
>>
>>   I've written CRC32 (checksum) code of comparable speed to libz (pretty 
>> much
>>   the C benchmark).  It wasn't "simple", but it was no harder than C.  You
>>   have profiling tools, you unroll loops, etc etc.
>>
>>   (In practice you would probably do:
>>
>>   type Complex(F<:Float}<:Number
>>   F x
>>   F y
>>   end
>>
>>   because it hs parameterised types)
>>
>>
>> On Thursday, 10 September 2015 05:21:42 UTC-3, Carlos Becker wrote:
>>>
>>> Hi Andrew, my slides are here, 
>>> https://sites.google.com/site/carlosbecker/a-few-notes , they are for 
>>> v0.3: 
>>>
>>> If you need the openoffice original let me know, I can send it to you.
>>> Cheers.
>>>
>>> El miércoles, 9 de septiembre de 2015, 14:07:36 (UTC+2), andrew cooke 
>>> escribió:

 ok, thanks everyone i'll have a look at all those.  andrew

 On Tuesday, 8 September 2015 17:58:33 UTC-3, andrew cooke wrote:
>
>
> I need to give a presentation at work and was wondering is slides 
> already exist that:
>
>   * show how fast it is in benchmarks
>
>   * show that it's similar to matlab (matrix stuff)
>
>   * show that you can write fast inner loops
>
>  For bonus points:
>
>   * show how you can add other numerical types at no "cost"
>
>   * show how mutiple dispatch can be useful
>
>   * show how someone used to OO in, say, python, won't feel too lost
>
> Preferably just one slide per point.  Very short.
>
> Thanks,
> Andrew
>
>

[julia-users] Re: Good, short set of slides introducing Julia

[Jeffrey Sarnoff]

  type Complex{ T<:AbstractFloat } <: Number
  x::T
  y::T
  end


On Thursday, September 10, 2015 at 7:18:13 AM UTC-4, andrew cooke wrote:
>
> thanks (how does someone working on embedded c++ get to work with 
> adaboost?!)
>
> what i am actually going with is a bunch of links to examples (i can email 
> this to everyone before the talk, which will be over google meetup):
>
> (if anyone has corrections to what follows in the next few hours i am 
> happy to hear them, although i think it's pretty uncontroversial)
>
>
> * Data analysis and plots something like R
>   http://dcjones.github.io/Gadfly.jl/
>
> * IJulia reminds me of Mathematica (based on IPython)
>   
> https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks#julia
>   
> http://nbviewer.ipython.org/url/beowulf.csail.mit.edu/18.337/fractals.ipynb
>   
> http://nbviewer.ipython.org/github/JuliaOpt/juliaopt-notebooks/blob/master/notebooks/Matrix%20Completion%20with%20Binary%20Data.ipynb
>
> * Like Matlab, it makes using arrays easy
>   http://quant-econ.net/jl/julia_arrays.html
>
> * The neat thing (to me) is that unlike Matlab, the arrays code is often
>   (not always - it calls out to BLAS etc) written in Julia itself.
>   http://julialang.org/benchmarks/
>
> * More generally, it has managed ("automatic") memory allocation.
>   It doesn't have objects/classes, but it has something similar:
>   it combines types (like C structs) with multiple dispatch.
>
>   For example, to define complex types:
>
>   type Complex64<:Number
>   Float64 x
>   Float64 y
>   end
>
>   and then define
>
>   +(a::Complex64, b::Complex64) = Complex64(a.x + b.x, a.y + b.y)
>   ... etc
>
>   Note that + is already defined for a pile of other types (start julia and
>   type "methods(+)" to see them all).
>
>   Which is almost the same as defining a Complex64 class with a "+" method.
>   Main differences are (1) all types used to choose method and (2) only 
> final
>   types have fields (so memory layout is known).
>
>   And it's fast because the compiler compiles functions at runtime 
> depending
>   on types when called.  So the code ends up being compiled for a very
>   specific type, even if in your code you just had "a+b" and it wasn't 
> clear
>   whether a and b were Complex64 or Float64 or Int32 or ...
>
>   Downside to that is that when you first run a program it is actually 
> slow,
>   as it compiles things.  But second and further calls to any routine are
>   fast.
>
>   I've written CRC32 (checksum) code of comparable speed to libz (pretty 
> much
>   the C benchmark).  It wasn't "simple", but it was no harder than C.  You
>   have profiling tools, you unroll loops, etc etc.
>
>   (In practice you would probably do:
>
>   type Complex(F<:Float}<:Number
>   F x
>   F y
>   end
>
>   because it hs parameterised types)
>
>
> On Thursday, 10 September 2015 05:21:42 UTC-3, Carlos Becker wrote:
>>
>> Hi Andrew, my slides are here, 
>> https://sites.google.com/site/carlosbecker/a-few-notes , they are for 
>> v0.3: 
>>
>> If you need the openoffice original let me know, I can send it to you.
>> Cheers.
>>
>> El miércoles, 9 de septiembre de 2015, 14:07:36 (UTC+2), andrew cooke 
>> escribió:
>>>
>>> ok, thanks everyone i'll have a look at all those.  andrew
>>>
>>> On Tuesday, 8 September 2015 17:58:33 UTC-3, andrew cooke wrote:


 I need to give a presentation at work and was wondering is slides 
 already exist that:

   * show how fast it is in benchmarks

   * show that it's similar to matlab (matrix stuff)

   * show that you can write fast inner loops

  For bonus points:

   * show how you can add other numerical types at no "cost"

   * show how mutiple dispatch can be useful

   * show how someone used to OO in, say, python, won't feel too lost

 Preferably just one slide per point.  Very short.

 Thanks,
 Andrew

[julia-users] Re: Good, short set of slides introducing Julia

[andrew cooke]

thanks (how does someone working on embedded c++ get to work with 
adaboost?!)

what i am actually going with is a bunch of links to examples (i can email 
this to everyone before the talk, which will be over google meetup):

(if anyone has corrections to what follows in the next few hours i am happy 
to hear them, although i think it's pretty uncontroversial)


* Data analysis and plots something like R
  http://dcjones.github.io/Gadfly.jl/

* IJulia reminds me of Mathematica (based on IPython)
  
https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks#julia
  
http://nbviewer.ipython.org/url/beowulf.csail.mit.edu/18.337/fractals.ipynb
  
http://nbviewer.ipython.org/github/JuliaOpt/juliaopt-notebooks/blob/master/notebooks/Matrix%20Completion%20with%20Binary%20Data.ipynb

* Like Matlab, it makes using arrays easy
  http://quant-econ.net/jl/julia_arrays.html

* The neat thing (to me) is that unlike Matlab, the arrays code is often
  (not always - it calls out to BLAS etc) written in Julia itself.
  http://julialang.org/benchmarks/

* More generally, it has managed ("automatic") memory allocation.
  It doesn't have objects/classes, but it has something similar:
  it combines types (like C structs) with multiple dispatch.

  For example, to define complex types:

  type Complex64<:Number
  Float64 x
  Float64 y
  end

  and then define

  +(a::Complex64, b::Complex64) = Complex64(a.x + b.x, a.y + b.y)
  ... etc

  Note that + is already defined for a pile of other types (start julia and
  type "methods(+)" to see them all).

  Which is almost the same as defining a Complex64 class with a "+" method.
  Main differences are (1) all types used to choose method and (2) only 
final
  types have fields (so memory layout is known).

  And it's fast because the compiler compiles functions at runtime depending
  on types when called.  So the code ends up being compiled for a very
  specific type, even if in your code you just had "a+b" and it wasn't clear
  whether a and b were Complex64 or Float64 or Int32 or ...

  Downside to that is that when you first run a program it is actually slow,
  as it compiles things.  But second and further calls to any routine are
  fast.

  I've written CRC32 (checksum) code of comparable speed to libz (pretty 
much
  the C benchmark).  It wasn't "simple", but it was no harder than C.  You
  have profiling tools, you unroll loops, etc etc.

  (In practice you would probably do:

  type Complex(F<:Float}<:Number
  F x
  F y
  end

  because it hs parameterised types)


On Thursday, 10 September 2015 05:21:42 UTC-3, Carlos Becker wrote:
>
> Hi Andrew, my slides are here, 
> https://sites.google.com/site/carlosbecker/a-few-notes , they are for 
> v0.3: 
>
> If you need the openoffice original let me know, I can send it to you.
> Cheers.
>
> El miércoles, 9 de septiembre de 2015, 14:07:36 (UTC+2), andrew cooke 
> escribió:
>>
>> ok, thanks everyone i'll have a look at all those.  andrew
>>
>> On Tuesday, 8 September 2015 17:58:33 UTC-3, andrew cooke wrote:
>>>
>>>
>>> I need to give a presentation at work and was wondering is slides 
>>> already exist that:
>>>
>>>   * show how fast it is in benchmarks
>>>
>>>   * show that it's similar to matlab (matrix stuff)
>>>
>>>   * show that you can write fast inner loops
>>>
>>>  For bonus points:
>>>
>>>   * show how you can add other numerical types at no "cost"
>>>
>>>   * show how mutiple dispatch can be useful
>>>
>>>   * show how someone used to OO in, say, python, won't feel too lost
>>>
>>> Preferably just one slide per point.  Very short.
>>>
>>> Thanks,
>>> Andrew
>>>
>>>

Re: [julia-users] Multi-dimensional Arrays

[Mauro]

My understanding is that it is much easier to subtype AbstractArray in
0.4.  As 0.4 should be out pretty soon (a release candidate is out and
should be announced on this list once binaries are made), it would
probably be best to do this in 0.4.

On Thu, 2015-09-10 at 09:06, Leonardo  wrote:
> Hi All,
> I need some clarifications about subclassing AbstractArray to create a 
> multi-dimensional array with unspecified number of dimensions.
>
> I've created an (useless) example defining a simple container (attached) to 
> clarify me necessary step and function to implement, and then my doubts:
>
>- for Julia 0.4.x a chapter *Interface* 
>states that 
>minimal function that I MUST create are size(), getindex(), setindex!(), 
>but in my case I MUST create another form of getindex(), setindex!() 
>listed between optional methods
>- for Julia 0.3.x previous chapter doesn't exists, then I don't have a 
>clear guideline to implement my type
>- running attached example (in Julia 0.3.11 64bit under Win7 64bit), 
>other function are required to show objects in REPL (some also 
> undocumented 
>like print_matrix() ), otherwise creation of an object (e.g. with 
>command a = MyArr(3)) fails
>
> Than, what's correct way to subclass AbstractArray for my needs 
> (multidimensional array)? 
>
>
> Many thanks in advance for anyone can indicate me right direction
>
>
> Leonardo

Re: [julia-users] Re: META: What are the chances of moving this forum?

[Mauro]

>> Do any of these other suggestions have a mailing list interface?
>
> GitHub's issue tracking interface does.

In my email client the threading doesn't seem to work well with github
issue-emails, so I end up using the web interface most of the time.
Otherwise it might work well.  I had a quick look around on the
internet, not many projects seem to use issues as mailing list.  I only
found these:
https://lists.w3.org/Archives/Public/public-houdini/2015Sep/0004.html
https://github.com/hapijs/discuss/issues

@-notifications could be quite nice.  Maybe it would be best if this was
tried out with a large Julia project to see the ins and outs?
Volunteers?

> On Wednesday, September 9, 2015 at 3:59:51 PM UTC-4, Robert DJ wrote:
>>
>> I'm not a fan of Google, so I think it would great to find another forum. 
>> Besides, I fully agree with the technical issues mentioned.
>>
>> Regarding the need for user accounts on e.g. GitHub, I don't see how that 
>> is different from requiring a Google account for participating here...
>>
>> On Wednesday, September 9, 2015 at 5:33:33 PM UTC+2, Jarrett Revels wrote:
>>>
>>> I often find myself wishing that this forum was just a GitHub repo, with 
>>> posts as issues. It would be great for supporting @-style mentions, 
>>> markdown, issue-linking, etc. The main downside would be forcing everybody 
>>> to have GitHub account (not bad IMO, but I can see others having an issue 
>>> for it).
>>>
>>> It would probably be a bad idea to upheave the forums, anyway, especially 
>>> at such a critical moment in Julia's development (v0.4 getting released 
>>> soon). I doubt this is going to happen.
>>>
>>> On Wednesday, September 9, 2015 at 7:34:58 AM UTC-4, Nils Gudat wrote:

 Was just thinking about this as first I had to try opening a thread here 
 a couple of times before any posts were actually displayed, and then read 
 through this 
 
  
 thread on Mike's Juno Discuss forum, where a user had a question which was 
 almost answered by the nice auto-suggestion feature that pops up when you 
 ask a question.

 I feel that Google Groups has mostly downsides - the system is slow, 
 with posts frequently not loading, double posts because of this, no proper 
 code formatting or Markdown support etc.

 Is there a chance this could be moved to something like Discuss or is 
 there too much inertia in having an "established" forum on Google Groups?

>>>

Re: [julia-users] Cannot load NFFT on Mac

[Robert DJ]

I figured out what the problem is: In the directory where I tried to load 
NFFT I also had a file called 'nfft.jl' (non-capital letters). 
Apparently 'using NFFT' was trying to load the local file.


On Thursday, September 10, 2015 at 8:24:22 AM UTC+2, Robert DJ wrote:
>
> Very strange. I'll try to upgrade and see if that makes a difference.
>
> Thanks for letting me know.
>
> On Wednesday, September 9, 2015 at 10:10:52 PM UTC+2, John Nelson wrote:
>>
>> I just tried to replicate on Yosemite and Julia 0.4.0-pre+7113. 
>>
>> I was able to `Pkg.update()/add()`; then, `using NFFT` without problems. 
>>
>> On Wed, Sep 9, 2015 at 3:37 PM, Robert DJ  wrote:
>>
>>> Hi,
>>>
>>> I am having a strange problem on Mac (Yosemite): I cannot load the NFFT 
>>>  package.
>>>
>>> Unfortunately, it is difficult to diagnose as I do not get any errors, 
>>> Julia just hangs after
>>> using NFFT
>>> Uninstalling and reinstalling NFFT does not help, neither does a 
>>> complete re-compilation of Julia from scratch.
>>>
>>> I have tried installing and loading NFFT on two different computers 
>>> running Linux and here it works.
>>> I am running Julia 0.4.something on all computers.
>>>
>>> Has anyone else had similar problems?
>>>
>>> Thanks,
>>>
>>> Robert
>>>
>>
>>

[julia-users] Re: Good, short set of slides introducing Julia

[Carlos Becker]

Hi Andrew, my slides are here, 
https://sites.google.com/site/carlosbecker/a-few-notes , they are for v0.3: 

If you need the openoffice original let me know, I can send it to you.
Cheers.

El miércoles, 9 de septiembre de 2015, 14:07:36 (UTC+2), andrew cooke 
escribió:
>
> ok, thanks everyone i'll have a look at all those.  andrew
>
> On Tuesday, 8 September 2015 17:58:33 UTC-3, andrew cooke wrote:
>>
>>
>> I need to give a presentation at work and was wondering is slides already 
>> exist that:
>>
>>   * show how fast it is in benchmarks
>>
>>   * show that it's similar to matlab (matrix stuff)
>>
>>   * show that you can write fast inner loops
>>
>>  For bonus points:
>>
>>   * show how you can add other numerical types at no "cost"
>>
>>   * show how mutiple dispatch can be useful
>>
>>   * show how someone used to OO in, say, python, won't feel too lost
>>
>> Preferably just one slide per point.  Very short.
>>
>> Thanks,
>> Andrew
>>
>>

[julia-users] Re: product of vectors and matrix elements

[Nils Gudat]

You've (almost) already written out a list comprehension syntax to do this. 
Generally I think you wouldn't want to have a couple of vectors and a 
couple of matrices, but the vectors stored as (e.g.) rows of a matrix, and 
the matrices stored as slices of a three-dimensional array. E.g.:

vectors = [1 2; 3 4]
matrices = zeros(Int64, (2,2,2))
matrices[:,:,1] = vectors*2
matrices[:,:,2] = vectors*3

[[vectors[:,i]'*matrices[:,:,j] for i = 1:2] for j = 1:2]

I would personally argue that a loop is easier to read/understand, but your 
mileage may vary...

[julia-users] product of vectors and matrix elements

[Ferran Mazzanti]

Hi folks,

this is probably very easy to do, but  probably there are optimal ways to 
do it that escape me. What I would like to do is the following kind
of operation: suppose I have a set of 3-element vectors labelled r1, 
r2,...,rN, and a set of matrices M1, M2,...,MN. FOr the sake of simplicity 
assume these are 2x2 matrices of the form Mk= [[ ak, bk] [ck,dk]]. Then I 
want to evaluate 

r1*M1 + r2*M2 + ... + rN*MN

producing an array of vectors such that the result is of the form

[[ a1*r1 + a2*r2 + ... +aN*rN, b1*r1 + b2*r2 + ... + bN*rN] 
[c1*r1+c2*r2+...+cN*rN , d1*r1 + d2*r2 + ... + dN*rN ]]

Is there a simple way to do that, other than using simple loops? 

Thanks a lot,

Ferran.

[julia-users] Multi-dimensional Arrays

[Leonardo]

Hi All,
I need some clarifications about subclassing AbstractArray to create a 
multi-dimensional array with unspecified number of dimensions.

I've created an (useless) example defining a simple container (attached) to 
clarify me necessary step and function to implement, and then my doubts:

   - for Julia 0.4.x a chapter *Interface* 
   states that 
   minimal function that I MUST create are size(), getindex(), setindex!(), 
   but in my case I MUST create another form of getindex(), setindex!() 
   listed between optional methods
   - for Julia 0.3.x previous chapter doesn't exists, then I don't have a 
   clear guideline to implement my type
   - running attached example (in Julia 0.3.11 64bit under Win7 64bit), 
   other function are required to show objects in REPL (some also undocumented 
   like print_matrix() ), otherwise creation of an object (e.g. with 
   command a = MyArr(3)) fails
   
Than, what's correct way to subclass AbstractArray for my needs 
(multidimensional array)? 


Many thanks in advance for anyone can indicate me right direction


Leonardo




test.jl
Description: Binary data