Re: [julia-users] How to vonvet Char to Float64, what wrong ?

[Stefan Karpinski]

It was set correctly but for some reason didn't work even though the same
change worked correctly on julia-dev. The Google Groups admin tools are a
train wreck of brokenness and confusion – one of the many reasons we're
moving away. I had to go through and manually set everyone's posting
permissions, so hopefully now people can't post. Admins and managers will
still occasionally use this list for announcements since we probably won't
get most people to join Discourse immediately.

On Fri, Nov 25, 2016 at 11:47 AM, Waldir Pimenta 
wrote:

> On Friday, November 25, 2016 at 4:47:07 PM UTC, Waldir Pimenta wrote:
> > On Friday, November 25, 2016 at 3:13:51 PM UTC, Yichao Yu wrote:
> > >
> > > Also, please stop posting on this list and move to
> > > https://discourse.julialang.org/
> > >
> >
> > Wasn't this list locked for new posts? Maybe there's something wrong
> with the configuration.
>
> Sorry, I meant new threads.

Re: [julia-users] Passing Dictionary from Julia to C function using ccall

[Stefan Karpinski]

I'm not sure what's up with that – the group settings look correct (only
manager, owners can start new threads), but Google Groups has confusing
settings, doesn't always do what it's configured to do and is otherwise
generally unreliable, so who knows? These are among the reasons we're
switching away. Please use discourse.julialang.org – thanks!

On Tue, Nov 22, 2016 at 8:08 AM, Yichao Yu  wrote:

> Hmmm, I thought you can't start a new thread on julia-users anymore
>
> On Tue, Nov 22, 2016 at 2:18 AM, Alexander Lyapin
>  wrote:
> > Is there way to pass Dictionary from Julia to C function using ccall???
> >
> > I have to divide all dictionaries for subarrays and then send them to
> C...
> > this is really long and leads to huge syntax. Is there way to pass whole
> > dictionary at once?
>
> You can just pass a pointer to the dict to C with `Any` as argument
> type. This works for any types.
>
> Note that there's no standard representation of dict in C though so
> accessing it in C is not trivial
> (https://groups.google.com/forum/?fromgroups=#!msg/julia-use
> rs/E4FNM7m_Alw/3s6ePRzTAgAJ;context-place=searchin/julia-
> users/Julia$20embedding%7Csort:relevance)
> I also can't understand what exactly you want to do ...
>
> >
> > Thank you
>

Re: [julia-users] Sharing experience on packages

[Stefan Karpinski]

Pkg3, the next generation package manager I'm working on will likely
include optional telemetry collection. You'll be asked to opt in or out
when you first use it.

On Tue, Nov 15, 2016 at 5:02 AM, Jérôme Collet 
wrote:

> Hi all,
>
>
> I am new to Julia, I used to use R. And using R packages, the main
> difficulty for me is the choice of a package for a given task. Most of the
> time, there are many packages solving the same problem, so we have to
> choose.
>
>- A first possibility could be the TaskViews, but it is easy to see
>that around a third of all packages is listed in a TaskView, so being
>listed does not say anything about quality.
>- Thanks to Rstudio, it is possible to know how many times a given
>package was downloaded. It is an indication about package quality. But this
>indication is difficult to obtain, and not very reliable.
>- I heard that in Matlab, it is easy to know the experience about a
>package, or even a function of a package, compared to other similar
>functions in another packages.
>
> So, are there any plans to collect, store and share the experience on
> packages?
>

Re: [julia-users] Base.Threads user feedback: it's great. please keep it. anyone tried hybrid (addprocs + Threads)?

[Stefan Karpinski]

There's no risk of threading being removed. It's only experimental, as per
Yichao, in the sense that it's currently not ready for production use.

On Tue, Nov 15, 2016 at 9:07 AM, Yichao Yu  wrote:

> On Tue, Nov 15, 2016 at 8:42 AM, Florian Oswald
>  wrote:
> > ok, thanks for that. do you think this is going to change already in
> v0.6 or
> > will that have to wait until a future release?
>
> There will be improvements but it's very likely still going to be
> experimental in 0.6.
>
> >
> >
> > On 14 November 2016 at 23:59, Yichao Yu  wrote:
> >>
> >> On Mon, Nov 14, 2016 at 5:08 PM, Florian Oswald
> >>  wrote:
> >> > I'm not sure how many people are using Base.Threads out there, I came
> >> > across
> >> > it by accident and think it works great. It's under the heading
> >> > "experimental" in the manual, so I just wanted to encourage the
> >> > developers
> >> > that this is a great feature, please don't drop it. I just wrote
> >> > @threads in
> >> > front of a loop in my code and time was cut by pretty much exactly
> >> > JULIA_NUM_THREADS.
> >>
> >> It's experimental in that apart from some really simple cases, code
> >> that uses thread can easily crash.
> >> It is not recommended to use threading at this stage.
> >>
> >> >
> >> > Along those lines, has anyone tried to run a hybrid job, i.e.
> connecting
> >> > several machines via `addprocs` and running several threads on each of
> >> > those
> >> > machines? Is something like that even possible and/or do you recommend
> >> > something like that? There is not too much in the manual, so I would
> >> > just
> >> > like to get some more info.
> >>
> >> Doing so is certainly possible but is not recommended since threading
> >> itself isn't.
> >>
> >> >
> >> > thanks.
> >> >
> >> >
> >
> >
>

Re: [julia-users] Optional Arguments for Do-Block Syntax for Functions

[Stefan Karpinski]

You can use a name like _ but otherwise, no, there's no way to do this.

On Fri, Nov 11, 2016 at 11:46 AM, Adrian Salceanu  wrote:

> I love the block syntax for functions as it provides great readability and
> I'm using it heavily as a design pattern to enclose code behind
> authorization or caching.
>
> For example:
>
> function article_edit(params::Dict{Symbol,Any}; a::Article = Article())
>   with_authorization(:edit, unauthorized_access, params) do auth_scopes
> article = SearchLight.is_persisted(a) ? a : SearchLight.find_one!!(
> Article, params[:article_id])
> ejl(:admin, :article, layout = :admin, article = article, params =
> params) |> respond
>   end
> end
>
> I was wondering if there's any way to make the auth_scopes param optional
> for the cases when the users are not interested in this passed value.
> Similarly to how in the ruby blocks you're not required to capture the
> values that are passed into, if you don't want them. It will help to
> greatly reduce the noise, especially when multiple params are expected.
>

Re: [julia-users] Rewriting this function from python to julia

[Stefan Karpinski]

Yeah, that version is considerably more concise as well. My version is the
"how you would fix the thing you were trying to do" version :)

On Mon, Nov 7, 2016 at 3:27 PM, Steven G. Johnson 
wrote:

> On Monday, November 7, 2016 at 3:17:54 PM UTC-5, Jacob Yates wrote:
>>
>> I know ^ is an exponent. The whole function is meant to xor strings the
>> strings end up being the variables s and t
>>
>
> By "xor the strings", I think you mean "xor the bytes"?   Note that chr
> and ord in Python only work for ASCII characters, so I guess you are only
> interested in ASCII data?   In that case, I would do:
>
> xorstrings(s::String, t::String) = String(s.data $ t.data)
>
> (requires Julia 0.5).   You will have to think carefully about whether you
> want to handle non-ASCII Unicode strings and what you want to do in that
> case.  (The above code will hande non-ASCII data by xor-ing their UTF-8
> representations.  It's not clear whether this is what you want.)
>

Re: [julia-users] Rewriting this function from python to julia

[Stefan Karpinski]

You also need parens around (a,b):

julia> xorStrings(s,t) = join(Char(Int(a) $ Int(b)) for (a,b) in zip(s,t))
xorStrings (generic function with 1 method)

julia> xorStrings("foo","bar")
"\x04\x0e\x1d"

julia> xorStrings("foo",ans)
"bar"


On Mon, Nov 7, 2016 at 3:17 PM, blm22 <blmv...@gmail.com> wrote:

> I know ^ is an exponent. The whole function is meant to xor strings the
> strings end up being the variables s and t
>
> On Nov 7, 2016 15:12, "Stefan Karpinski" <ste...@karpinski.org> wrote:
>
>> ^ isn't xor in Julia, it's exponentiation. You can use infix $ instead.
>>
>> On Mon, Nov 7, 2016 at 3:02 PM, Jacob Yates <blmv...@gmail.com> wrote:
>>
>>> return "".join(chr(ord(a)^ord(b)) for a,b in zip(s,t))
>>>
>>>
>>>
>>> Now I know that chr = Char, ord = Int, and zip = tuple in julia. But
>>> while using this in that context I get a load error saying the I'm missing
>>> a ", or )"
>>>
>>>
>>> function xorStrings(s,t)
>>> global xorStr = join(Char(Int(a)^Int(b)) for a,b in tuple(s,t)
>>> exit
>>>
>>
>>

Re: [julia-users] Rewriting this function from python to julia

[Stefan Karpinski]

^ isn't xor in Julia, it's exponentiation. You can use infix $ instead.

On Mon, Nov 7, 2016 at 3:02 PM, Jacob Yates  wrote:

> return "".join(chr(ord(a)^ord(b)) for a,b in zip(s,t))
>
>
>
> Now I know that chr = Char, ord = Int, and zip = tuple in julia. But while
> using this in that context I get a load error saying the I'm missing a ",
> or )"
>
>
> function xorStrings(s,t)
> global xorStr = join(Char(Int(a)^Int(b)) for a,b in tuple(s,t)
> exit
>

Re: [julia-users] Re: [Announcement] Moving to Discourse (Statement of Intent)

[Stefan Karpinski]

- Selectively subscribe to certain topics/categories of discussion and not
others.
- Selectively see threads that reach certain quality/interest thresholds.
- Take links directly from where one reads messages
(I really dislike the Google groups interface, so I use Gmail for
reading messages, but then getting a link to a post is a real pain; the
Discourse interface is much better).
- Real tools for moderation, management and administration.
- Active, open development
Google Groups is not only proprietary, but it's also effectively
abandonware.

On Sun, Nov 6, 2016 at 8:33 AM, Simon Byrne  wrote:

> Personally, I find the following an improvement over google groups:
> - code blocks (copying and pasting code into the google groups interface
> always tends to look bad)
> - the ability to edit posts
> - the ability to move threads to different categories (i.e. posts to
> julia-dev which should have gone to julia-users, etc)
>
>
> On Sunday, 6 November 2016 10:33:20 UTC, Milan Bouchet-Valat wrote:
>>
>> Le dimanche 06 novembre 2016 à 01:49 -0800, Andreas Lobinger a écrit :
>> > Hello colleague,
>> >
>> > > The Julia community has been growing rapidly over the last few
>> > > years and discussions are happening at many different places: there
>> > > are several Google Groups (julia-users, julia-dev, ...), IRC,
>> > > Gitter, and a few other places. Sometimes packages or organisations
>> > > also have their own forums and chat rooms.
>> > >
>> > > In the past, Discourse has been brought up as an alternative
>> > > platform that we could use instead of Google Groups and that would
>> > > allow us to invite the entire Julia community into one space.
>> > >
>> >
>> > What problem with the julia-users mailing-list and the google groups
>> > web interface is solved by using discourse?
>> You can have a look at the previous thread about this:
>> https://groups.google.com/d/msg/julia-users/4oDqW-QxyVA/lw71uqNGBQAJ
>>
>> I also encourage you to give a try to Discourse (this can be done
>> without even creating an account on their test instance).
>>
>> > Why do you think (can you prove?) more centralisation will happen
>> > with discourse?
>> Centralization will be made possible by allowing for sub-forums
>> dedicated to each topic (stats, optimization, data...) inside Discourse
>> itself, instead of creating totally separate mailing lists as is
>> currently done. Of course people will still be free to use something
>> else, but that's quite unlikely.
>>
>> > > We would like to solicit feedback from the broader Julia community
>> > > about moving julia-users to Discourse as well, and potentially
>> > > other mailing lists like julia-stats.
>> > >
>> >
>> > Please define 'We'.
>> "We" meant "Julia core developers".
>>
>> > > If you have feedback or comments, please post them
>> > > at http://discourse.julialang.org/t/migration-of-google-groups-to-
>> > > discourse or in this thread.
>> > >
>> >
>> > In some parts of the world, asking for feedback on a topic via a
>> > different medium is seen as unfriendly act ... but still there is
>> > this thread.
>> The idea was that we would like to see how well it works by having
>> people use Discourse for this discussion. But as you noted there's this
>> thread for people who don't want to to that.
>>
>>
>> Regards
>>
>> > Wishing a happy day,
>> >  Andreas
>>
>
> On Sunday, 6 November 2016 10:33:20 UTC, Milan Bouchet-Valat wrote:
>>
>> Le dimanche 06 novembre 2016 à 01:49 -0800, Andreas Lobinger a écrit :
>> > Hello colleague,
>> >
>> > > The Julia community has been growing rapidly over the last few
>> > > years and discussions are happening at many different places: there
>> > > are several Google Groups (julia-users, julia-dev, ...), IRC,
>> > > Gitter, and a few other places. Sometimes packages or organisations
>> > > also have their own forums and chat rooms.
>> > >
>> > > In the past, Discourse has been brought up as an alternative
>> > > platform that we could use instead of Google Groups and that would
>> > > allow us to invite the entire Julia community into one space.
>> > >
>> >
>> > What problem with the julia-users mailing-list and the google groups
>> > web interface is solved by using discourse?
>> You can have a look at the previous thread about this:
>> https://groups.google.com/d/msg/julia-users/4oDqW-QxyVA/lw71uqNGBQAJ
>>
>> I also encourage you to give a try to Discourse (this can be done
>> without even creating an account on their test instance).
>>
>> > Why do you think (can you prove?) more centralisation will happen
>> > with discourse?
>> Centralization will be made possible by allowing for sub-forums
>> dedicated to each topic (stats, optimization, data...) inside Discourse
>> itself, instead of creating totally separate mailing lists as is
>> currently done. Of course people will still be free to use something
>> else, but that's quite unlikely.
>>
>> > > We would like to solicit feedback from the broader Julia 

Re: [julia-users] using or import a specific package version

[Stefan Karpinski]

In Pkg3, if your script uses a particular environment, which can be
project-local (i.e. local to the repository the script is in) then as long
as you don't change the version of anything in that environment, it won't
change. I wasn't planning on having a way of indicating a particular
version in the source code at the point of loading something, however.

On Fri, Nov 4, 2016 at 6:30 PM, Tom Breloff  wrote:

> Not that I know of. Hopefully the next generation package manager (Pkg3)
> will enable this sort of conditional pinning. It should at least enable
> dual environments.
>
>
> On Friday, November 4, 2016, Tom Lee  wrote:
>
>> Hi all,
>>
>> Is there any way to specify that "using" or "import" should load a
>> specific package version without pinning the package to a particular
>> version globally? I would like to prevent my older scripts breaking when
>> packages are updated while still using the latest version by default.
>>
>> Thanks,
>>
>> Tom
>>
>

Re: [julia-users] create command with spaces without quoting

[Stefan Karpinski]

Interpolating commands into commands is a useful pattern as well:

cmd = `convert`
if haskey(opts, :density)
cmd = `$cmd -density $(opts[:density])`
end
if haskey(opts, :depth)
cmd = `$cmd -depth $(opts[:depth])`
end
run(cmd)




On Thu, Nov 3, 2016 at 12:21 PM, Yichao Yu  wrote:

> On Thu, Nov 3, 2016 at 12:17 PM, Andre Bieler 
> wrote:
> > I want to generate a command for imagemagick and use options loaded from
> a
> > file.
> > So the number of utilized options is not known beforehand.
> >
> > An example might look like:
> >
> > convert -density 300 somefile.pdf -depth 10 somefile.jpeg
> >
> > It is easy to generate the string above, but when interpolating it
> > into a command it gets quoted because of the spaces.
> >
> > So
> >
> > s = "convert -density 300 somefile.pdf -depth 10 somefile.jpeg"
> > run(`$s`)
> >
> > does not work. Is there an easy way to omit quoting?
> > Or how to generate the command when having vectors of keyword : value
> pairs
> > such as
> >
> > kw = ["-density", "-depth"]
> > vals = [300, 8]
> >
> > (assuming for now that all these options simply follow each other in one
> > place of
> > the command)
> >
> > Thanks for the help.
>
> Interpolate in the command and not the string
>
> you can do `command $option` where option is a string or an array of
> string.
>
> >
> > Andre
>

Re: [julia-users] Re: avoid dollar $ interpolation in shell commands

[Stefan Karpinski]

You can make a command with quoted `$` like this: `echo \$x` or `echo '$x'`.

On Wed, Nov 2, 2016 at 8:00 AM, Christian Theil Have <
christiantheilh...@gmail.com> wrote:

> Thank you for the responses and my apologies for not being entirely clear:
> Actually, the $PATH variable was just to provide an example. I really did
> want to construct a Cmd with an unquoted dollar in it.
> The reason why I want do such a silly thing is that I have a toying with a
> package (https://github.com/cth/QsubCmds.jl) which generates shell
> scripts from Cmd's that are run through sun grid engine, so
> since the commands are not executed by Julia anymore, but a shell, it
> makes sense to allow interaction with shell variables. I do not know
> whether there could be any other use case for this (probably not).
>
> I get if this is not possible for the reason that there is no shell to
> expand variables when running Cmds from Julia, but I just wondered if there
> are some escaping mechanism that makes it possible to construct such
> commands.
>
> Best,
> Christian
>
>
>
> Den onsdag den 2. november 2016 kl. 12.23.00 UTC+1 skrev Stefan Karpinski:
>>
>> I think that needs some additional parens: `echo $(ENV["PATH"])`. This is
>> in fact, exactly what you need – Julia commands in backticks are not run by
>> a shell so there is no shell to expand any environment variables, only
>> Julia can expand them.
>>
>> On Wed, Nov 2, 2016 at 7:02 AM, Simon Byrne <simon...@gmail.com> wrote:
>>
>>> Perhaps not quite what you had in mind, but
>>>
>>> `echo $ENV["PATH"]`
>>>
>>> should work
>>>
>>> On Wednesday, 2 November 2016 10:43:47 UTC, Christian Theil Have wrote:
>>>>
>>>> Hi,
>>>>
>>>> I've been trying to create a shell command that refers to an
>>>> environment variable, e.g.,
>>>>
>>>> echo $PATH
>>>>
>>>> Julia will interpolate $ in shell commands in backticks to Julia
>>>> variables, i.e., `echo $PATH`, will look for a Julia variable PATH.
>>>> What can I do if I really want to insist having a shell command that
>>>> includes a (non-quoted) dollar-sign? Currently,
>>>> my workaround is `sh -c "echo \$PATH"`, but this is not really
>>>> satisfactory.
>>>>
>>>> Best,
>>>> Christian
>>>>
>>>
>>

Re: [julia-users] Re: avoid dollar $ interpolation in shell commands

[Stefan Karpinski]

I think that needs some additional parens: `echo $(ENV["PATH"])`. This is
in fact, exactly what you need – Julia commands in backticks are not run by
a shell so there is no shell to expand any environment variables, only
Julia can expand them.

On Wed, Nov 2, 2016 at 7:02 AM, Simon Byrne  wrote:

> Perhaps not quite what you had in mind, but
>
> `echo $ENV["PATH"]`
>
> should work
>
> On Wednesday, 2 November 2016 10:43:47 UTC, Christian Theil Have wrote:
>>
>> Hi,
>>
>> I've been trying to create a shell command that refers to an environment
>> variable, e.g.,
>>
>> echo $PATH
>>
>> Julia will interpolate $ in shell commands in backticks to Julia
>> variables, i.e., `echo $PATH`, will look for a Julia variable PATH.
>> What can I do if I really want to insist having a shell command that
>> includes a (non-quoted) dollar-sign? Currently,
>> my workaround is `sh -c "echo \$PATH"`, but this is not really
>> satisfactory.
>>
>> Best,
>> Christian
>>
>

Re: [julia-users] avoid dollar $ interpolation in shell commands

[Stefan Karpinski]

Are you trying to get the shell to expand $PATH but not Julia?

On Wed, Nov 2, 2016 at 5:40 AM, Christian Theil Have <
christiantheilh...@gmail.com> wrote:

> Hi,
>
> I've been trying to create a shell command that refers to an environment
> variable, e.g.,
>
> echo $PATH
>
> Julia will interpolate $ in shell commands in backticks to Julia
> variables, i.e., `echo $PATH`, will look for a Julia variable PATH.
> What can I do if I really want to insist having a shell command that
> includes a (non-quoted) dollar-sign? Currently,
> my workaround is `sh -c "echo \$PATH"`, but this is not really
> satisfactory.
>
> Best,
> Christian
>

Re: [julia-users] Re: 0.5 new generators syntax question

[Stefan Karpinski]

When in doubt, use @benchmark!

On Tue, Nov 1, 2016 at 5:49 AM, Johan Sigfrids 
wrote:

> Given that allocating an array for 50 Ints, filling it up, and then
> summing it all together probably takes less than a microsecond, any
> difference between allocating and not allocating will disappears in the
> noise. As Yichao Yu mentions, what you end up measuring is the time it
> takes to setup the computation. This is a case where using the
> BenchmarkTools can be really helpful.
>
> julia> using BenchmarkTools
>
> julia> @benchmark sum([2*t for t in 1:2:100])
> BenchmarkTools.Trial:
>   samples:  1
>   evals/sample: 907
>   time tolerance:   5.00%
>   memory tolerance: 1.00%
>   memory estimate:  560.00 bytes
>   allocs estimate:  2
>   minimum time: 121.00 ns (0.00% GC)
>   median time:  131.00 ns (0.00% GC)
>   mean time:162.82 ns (10.91% GC)
>   maximum time: 2.45 μs (0.00% GC)
>
> julia> @benchmark sum(2*t for t in 1:2:100)
> BenchmarkTools.Trial:
>   samples:  1
>   evals/sample: 962
>   time tolerance:   5.00%
>   memory tolerance: 1.00%
>   memory estimate:  80.00 bytes
>   allocs estimate:  3
>   minimum time: 86.00 ns (0.00% GC)
>   median time:  90.00 ns (0.00% GC)
>   mean time:107.20 ns (6.99% GC)
>   maximum time: 3.64 μs (95.05% GC)
>
>
> On Monday, October 31, 2016 at 9:42:14 PM UTC+2, Jesse Jaanila wrote:
>>
>> Hi,
>>
>> I was experimenting with the new 0.5 features and they are great! But to
>> my surprise,
>> the generator syntax doesn't work as I'm expecting. Let's say I want to
>> calculate
>> some summation. With the old syntax I could do
>>
>> @time sum([2*t for t in 1:2:100])
>>   0.015104 seconds (13.80 k allocations: 660.366 KB)
>>
>> that allocates the array within the summation. Now I thought this would a
>> prime example
>> where the memory overhead could be decreased by using the new notation
>> i.e.
>>
>> @time sum(2*t for t in 1:2:100)
>>   0.019215 seconds (18.98 k allocations: 785.777 KB)
>>
>> ,but generator syntax performs slightly worse. Also if we want find the
>> maximum we would do
>>
>> julia> @time maximum([2*t for t in 1:2:100])
>>   0.015182 seconds (12.90 k allocations: 606.166 KB)
>> 198
>>
>> julia> @time maximum(2*t for t in 1:2:100)
>>   0.019935 seconds (18.74 k allocations: 772.180 KB)
>> 198
>>
>> Have I understood the new generator syntax incorrectly or should the new
>> syntax perform
>> better in these code snippet examples?
>>
>>
>>
>>
>>
>>
>>

Re: [julia-users] Preventing Bool<->Number conversion/promotion

[Stefan Karpinski]

See #18367 <https://github.com/JuliaLang/julia/issues/18367> and #19168
<https://github.com/JuliaLang/julia/issues/19168>.

On Mon, Oct 31, 2016 at 3:06 PM, Stefan Karpinski <ste...@karpinski.org>
wrote:

> At the moment no, although there's been discussion of making Bool not a
> subtype of Number.
>
> On Mon, Oct 31, 2016 at 2:29 PM, Penn Taylor <rpe...@gmail.com> wrote:
>
>> Is there a way to prevent automatic conversion/promotion between Bool and
>> Number types?
>>
>> Motivating examples:
>>
>> type Bools
>>   a::Bool
>>   b::Bool
>> end
>>
>> Bools(1, 0) #=> Bools(true,false)
>>
>> type Ints
>>   a::Int64
>>   b::Int64
>> end
>>
>> Ints(true, false) #=> Ints(1,0)
>>
>> In both of the above cases, I want the construction to fail.
>>
>> I'm aware that I could write constructors for these types to explicitly
>> reject Bool<->Number mismatch, but that gets tedious when there are more
>> than a few Number or Bool fields in a type. Wondering if there's an easier
>> way.
>>
>
>

Re: [julia-users] Preventing Bool<->Number conversion/promotion

[Stefan Karpinski]

At the moment no, although there's been discussion of making Bool not a
subtype of Number.

On Mon, Oct 31, 2016 at 2:29 PM, Penn Taylor  wrote:

> Is there a way to prevent automatic conversion/promotion between Bool and
> Number types?
>
> Motivating examples:
>
> type Bools
>   a::Bool
>   b::Bool
> end
>
> Bools(1, 0) #=> Bools(true,false)
>
> type Ints
>   a::Int64
>   b::Int64
> end
>
> Ints(true, false) #=> Ints(1,0)
>
> In both of the above cases, I want the construction to fail.
>
> I'm aware that I could write constructors for these types to explicitly
> reject Bool<->Number mismatch, but that gets tedious when there are more
> than a few Number or Bool fields in a type. Wondering if there's an easier
> way.
>

Re: [julia-users] [ANN] QuickTypes.jl: Concise type definitions with default arguments

[Stefan Karpinski]

The issue in question in case anyone is curious:
https://github.com/JuliaLang/julia/issues/19157.

On Sunday, October 30, 2016, Stefan Karpinski <ste...@karpinski.org> wrote:

> That wasn't a PR, it was a "crazy idea" issue. Please stop spreading bogus
> news of change before anything has been decided, let alone happened.
>
> On Sunday, October 30, 2016, Scott Jones <scott.paul.jo...@gmail.com
> <javascript:_e(%7B%7D,'cvml','scott.paul.jo...@gmail.com');>> wrote:
>
>> Maybe `@mutable` instead of `@qtype` or `@type`, to reflect Jeff's PR to
>> change the `type` keyword to `mutable`, making the naming consistent
>>
>> On Tuesday, October 25, 2016 at 11:00:13 AM UTC-4, Cedric St-Jean wrote:
>>>
>>> Types are central to Julia programming, but the built-in `type` and
>>> `immutable` definitions can be cumbersome to write. QuickTypes.jl
>>> <https://github.com/cstjean/QuickTypes.jl> provides two alternative
>>> macros, *@qtype* and *@qimmutable, *with a more convenient syntax:
>>>
>>> Pkg.add("QuickTypes")   # to install
>>> using QuickTypes
>>>
>>> @qtype Wall(width, height)
>>>
>>> # Optional and keyword-arguments
>>> @qtype Cat(name, age::Int, nlegs=4; species="Siamese")
>>>
>>> # Parametric type
>>> @qtype Pack{T}(animals::Vector{T})
>>>
>>> # Inheritance
>>> abstract Tree
>>> @qtype Maple(qty_syrup::Float64) <: Tree
>>>
>>> # Immutables work the same way
>>> @qimmutable SquaredNumber(x2::Number)
>>>
>>>

Re: [julia-users] [ANN] QuickTypes.jl: Concise type definitions with default arguments

[Stefan Karpinski]

That wasn't a PR, it was a "crazy idea" issue. Please stop spreading bogus
news of change before anything has been decided, let alone happened.

On Sunday, October 30, 2016, Scott Jones  wrote:

> Maybe `@mutable` instead of `@qtype` or `@type`, to reflect Jeff's PR to
> change the `type` keyword to `mutable`, making the naming consistent
>
> On Tuesday, October 25, 2016 at 11:00:13 AM UTC-4, Cedric St-Jean wrote:
>>
>> Types are central to Julia programming, but the built-in `type` and
>> `immutable` definitions can be cumbersome to write. QuickTypes.jl
>>  provides two alternative
>> macros, *@qtype* and *@qimmutable, *with a more convenient syntax:
>>
>> Pkg.add("QuickTypes")   # to install
>> using QuickTypes
>>
>> @qtype Wall(width, height)
>>
>> # Optional and keyword-arguments
>> @qtype Cat(name, age::Int, nlegs=4; species="Siamese")
>>
>> # Parametric type
>> @qtype Pack{T}(animals::Vector{T})
>>
>> # Inheritance
>> abstract Tree
>> @qtype Maple(qty_syrup::Float64) <: Tree
>>
>> # Immutables work the same way
>> @qimmutable SquaredNumber(x2::Number)
>>
>>

Re: [julia-users] anonymous function

[Stefan Karpinski]

You can write

function (x)
# body
# goes
# here
end


On Fri, Oct 28, 2016 at 3:00 PM, Yichao Yu  wrote:

> On Fri, Oct 28, 2016 at 2:59 PM, digxx  wrote:
> > I didnt see it
>
>
>
> > f = function ()
> > end
> >
> > defines an anonymous function and assigns it to a variable f.
>

Re: [julia-users] Re: Binary read

[Stefan Karpinski]

Then you're going to have to inspect the file for things that look like
likely floating-point values since there are no specific values that you
can search for in the file. You could try posting a small initial portion
of the data here – 256 bytes or so.

On Wed, Oct 26, 2016 at 5:24 PM, Aleksandr Mikheev <al.mikhee...@gmail.com>
wrote:

> Unfortunately, I do not. However, I am most definitely sure that
> everything is okay with file since it is a training file.
>
> среда, 26 октября 2016 г., 23:17:00 UTC+3 пользователь Stefan Karpinski
> написал:
>>
>> Do you have an example where you have the file and you know what the data
>> should be? You may want to look at the data in a hex editor and try to
>> figure out what's going on.
>>
>> On Wed, Oct 26, 2016 at 4:06 PM, Aleksandr Mikheev <al.mik...@gmail.com>
>> wrote:
>>
>>> So, to avoid the opening a new thread I will write here again. It seems
>>> I still have a problem which I cannot solve. I use
>>>
>>> a_million_floats = read(f, Float64, 1_000_000)
>>>
>>>
>>> as it was suggested, however the numbers I get are obviously wrong
>>> (there are numbers like 8.68e+272, -5.39e-142, and even NaN). I am pretty
>>> that these are not the right numbers. Also, I am pretty sure that the type
>>> is correct (it should be 'double' in C/C++). Furthermore, I have i5 CPU, so
>>> it should be little endian as it is supposed in .dat file. What could be
>>> wrong?
>>>
>>> Thanks in advance!
>>>
>>
>>

Re: [julia-users] One more effort

[Stefan Karpinski]

[Please don't edit the subject on replies since this breaks the threading
and removes all context.]

On Wed, Oct 26, 2016 at 5:13 PM, Jeffrey Sarnoff 
wrote:

> I can compare my dirs and dll names with yours and we can replay the cold
> startup -- tomorrow.  I am away.
>
> Jeffrey Sarnoff
>
>

Re: [julia-users] Re: Binary read

[Stefan Karpinski]

Do you have an example where you have the file and you know what the data
should be? You may want to look at the data in a hex editor and try to
figure out what's going on.

On Wed, Oct 26, 2016 at 4:06 PM, Aleksandr Mikheev 
wrote:

> So, to avoid the opening a new thread I will write here again. It seems I
> still have a problem which I cannot solve. I use
>
> a_million_floats = read(f, Float64, 1_000_000)
>
>
> as it was suggested, however the numbers I get are obviously wrong (there
> are numbers like 8.68e+272, -5.39e-142, and even NaN). I am pretty that
> these are not the right numbers. Also, I am pretty sure that the type is
> correct (it should be 'double' in C/C++). Furthermore, I have i5 CPU, so it
> should be little endian as it is supposed in .dat file. What could be wrong?
>
> Thanks in advance!
>

Re: [julia-users] llvm call error

[Stefan Karpinski]

Julia can already generate static code:

   - http://juliacomputing.com/blog/2016/02/09/static-julia.html
   - http://juliacomputing.com/blog/2016/03/10/j2c-announcement.html

However, Julia's @code_llvm output is not meant to be compilable. What are
you trying to do?


On Tue, Oct 25, 2016 at 1:11 PM,  wrote:

> Thanks, is it possible for julia to avoid generating jl_value_t
>
> When I use a scalar Int64 julia generates code with i64 as input and no
>  jl_value_t appears. is it possible to do the same with arrays?
> Array{Float32,2} genrates a  jl_value_t? Is there an array type that can do
> this? For example fixed arrays?
>
> Finally, is this features planned to be supported if julia statically
> compiles?
>
> Thanks
>
> On Tuesday, October 25, 2016 at 9:23:02 AM UTC-7, Yichao Yu wrote:
>
>> On Mon, Oct 24, 2016 at 8:15 PM,   wrote:
>> > Hi All,
>> >
>> > I am trying to call llvm ir generated from julia.
>> >
>> > Here is my function:
>> >
>> > function incr(a::Array{Int64})  a+1; end
>> >
>> >
>> > thus:
>> >
>> > @code_llvm(incr([1 2 5 6 7]))
>> >
>> > returns:
>> >
>> > define %jl_value_t* @julia_incr_62127(%jl_value_t*) #0 {
>> > top:
>> >   %1 = call %jl_value_t* @"julia_.+_62128"(%jl_value_t* %0, i64 1) #0
>> >   ret %jl_value_t* %1
>> > }
>> >
>> >
>> >
>> > Thus to call it using llvm I try :
>> >
>> > Base.llvmcall(("""declare %jl_value_t* @julia_incr_62127(%jl_value_t*)""",
>>
>> > """top:
>> >  %1 = call %jl_value_t* @"julia_.+_62128"(%jl_value_t* %0, i64
>> 1) #0
>> >  ret %jl_value_t* %1
>> >"""),Vector{Int64},Tuple{Array{Int64}},[1 2 5 6 7])
>> >
>> >
>> >
>> >
>> > and I get the error:
>> >
>> > ERROR: error compiling anonymous: Failed to parse LLVM Assembly:
>> > julia: llvmcall:2:9: error: use of undefined type named 'jl_value_t'
>> > declare %jl_value_t* @julia_incr_62127(%jl_value_t*)
>> >
>> >
>> > I m not sure how to define jl_value_t.
>>
>> This is not supported.
>> You also shouldn't call julia generated functions with `llvmcall`.
>>
>> >
>> >
>> > any help?
>> >
>> > Thanks
>>
>

Re: [julia-users] stricter parsing of integers

[Stefan Karpinski]

You could check that there's no whitespace first. Otherwise, this isn't
terribly hard to write a parser for, especially if you don't want any fancy
features.

On Mon, Oct 24, 2016 at 9:29 AM, Tamas Papp  wrote:

> Is there a way to make
>
> parse(Int, " - 42 ")
>
> throw an error, or substitute with a different function that does this?
>
> Note that I am not advocating that this should be invalid syntax, just
> want to have a "strict" version for reading a dataset that throws an
> error unless the integer is not of the "optional sign followed by
> digits", without reimplementing Base.parse if possible.
>

Re: [julia-users] Re: BLAS.set_num_threads() and peakflops scaling

[Stefan Karpinski]

I think Ralph is suggesting that you disable the CPU's hyperthreading if
you run this kind of code often. We've done that on our benchmarking
machines, for example.

On Wed, Oct 19, 2016 at 11:47 PM, Thomas Covert 
wrote:

> So are you suggesting that real numerical workloads under
> BLAS.set_num_threads(4) will indeed be faster than
> under BLAS.set_num_threads(2)?  That hasn't been my experience and I
> figured the peakflops() example would constitute an MWE.  Is there another
> workload you would suggest I try to figure out if this is just a peak
> flops() aberration or a real issue?
>
>
> On Wednesday, October 19, 2016 at 8:28:16 PM UTC-5, Ralph Smith wrote:
>>
>> At least 2 things contribute to erratic results from peakflops(). With
>> hyperthreading, the threads are not always put on separate cores. Secondly,
>> the measured time includes
>> the allocation of the result matrix, so garbage collection affects some
>> of the results.  Most available advice says to disable hyperthreading on
>> dedicated number crunchers
>> (most full loads work slightly more efficiently without the extra context
>> switching).  The GC issue seems to be a mistake, if "peak" is to be taken
>> seriously.
>>
>> On Wednesday, October 19, 2016 at 12:04:00 PM UTC-4, Thomas Covert wrote:
>>>
>>> I have a recent iMac with 4 logical cores (and 8 hyper threads).  I
>>> would have thought that peakflops(N) for a large enough N should be
>>> increasing in the number of threads I allow BLAS to use.  I do find that
>>> peakflops(N) with 1 thread is about half as high as peakflops(N) with 2
>>> threads, but there is no gain to 4 threads.  Are my expectations wrong
>>> here, or is it possible that BLAS is somehow configured incorrectly on my
>>> machine?  In the example below, N = 6755, a number relevant for my work,
>>> but the results are similar with 5000 or 1.
>>>
>>> here is my versioninfo()
>>> julia> versioninfo()
>>> Julia Version 0.5.0
>>> Commit 3c9d753* (2016-09-19 18:14 UTC)
>>> Platform Info:
>>>   System: Darwin (x86_64-apple-darwin15.6.0)
>>>   CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
>>>   WORD_SIZE: 64
>>>   BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Haswell)
>>>   LAPACK: libopenblas
>>>   LIBM: libopenlibm
>>>   LLVM: libLLVM-3.7.1 (ORCJIT, haswell)
>>>
>>> here is an example peakflops() exercise:
>>> julia> BLAS.set_num_threads(1)
>>>
>>> julia> mean(peakflops(6755) for i=1:10)
>>> 5.225580459387056e10
>>>
>>> julia> BLAS.set_num_threads(2)
>>>
>>> julia> mean(peakflops(6755) for i=1:10)
>>> 1.004317640281997e11
>>>
>>> julia> BLAS.set_num_threads(4)
>>>
>>> julia> mean(peakflops(6755) for i=1:10)
>>> 9.838116463900085e10
>>>
>>>
>>>
>>>
>>>
>>>

Re: [julia-users] Embedding Julia in C++ - Determining returned array types

[Stefan Karpinski]

You can pull the significant bits and the exponent values out of a Float16
and then use those to compute the value as a Float32:
https://en.wikipedia.org/wiki/Half-precision_floating-point_format

On Wed, Oct 19, 2016 at 1:00 PM, Yichao Yu  wrote:

>
>
> On Wed, Oct 19, 2016 at 12:54 PM, Kyle Kotowick  wrote:
>
>> Aha, that fixed it!
>>
>> I'm running into one issue though. What do I do with the data when it's a
>> "Float16" type? C++ has no way to represent a 16-bit float, so I'm having
>> difficulty converting it to a regular 32-bit float.
>>
>
> Find a compiler / library that supports it? ;-p
>
> I'm only half joking. You can always just keep a pointer to the value or
> store it in a int16_t as long as you don't need to do any operation on it.
> If you want to operate on them in C++ natively you would have to find a
> C/C++ compiler/library (or write the necessary operations yourself) that
> supports __fp16.
>
>
>>
>> jl_value_t *ret = jl_eval_string(code_string);
>> jl_array_t *ret_array = (jl_array_t*)ret;
>>
>> if (jl_array_eltype(ret) == jl_float16_type) {
>>
>>  /* now I need to convert the 'ret_array' to a C++ array of floats, but
>> how do I do that when they're given in Float16? */
>>
>> }
>>
>>
>> On Tuesday, 18 October 2016 20:57:10 UTC-4, Isaiah wrote:
>>>
>>> The issue here is that `jl_array_eltype` is already returning a type.
>>>
>>> `jl_typeis(v, t)` becomes `jl_typeof(v) == t`, so your checks become:
>>>
>>> jl_typeof(array_type) == jl_int64_type
>>>
>>> But
>>>
>>> jl_typeof(array_type) -> DataType
>>>
>>> Instead, either do the equality check directly:
>>>
>>>   array_type == jl_int64_type
>>>
>>> Or use the exported API only (jlapi.c):
>>>
>>>   strcmp(jl_typename_str(array_type), jl_typename_str(jl_int64_type))
>>>
>>> On Tue, Oct 18, 2016 at 7:52 PM, Kyle Kotowick 
>>> wrote:
>>>
 I apologize for the formatting, that should be:

 jl_value_t *ret = jl_eval_string(code_string);
 void* array_type = jl_array_eltype(ret);
 jl_array_t *ret_array = (jl_array_t*)ret;

 if (jl_typeis(array_type, jl_int64_type)) {
   long *data = (long*) jl_array_data(ret_array);
 }
 else if (jl_typeis(array_type, jl_float64_type)) {
   double *data = (double*) jl_array_data(ret_array);
 }


 And the issue is that even if it is an Int64 or Float64, neither of
 those IF statements will return true.



 On Sunday, 16 October 2016 21:36:03 UTC-4, Kyle Kotowick wrote:
>
> Awesome, thanks. Could you show how to use it in a minimal code
> example? Here's what I'm currently trying, but it does not appear to be
> working:
>
> jl_value_t *ret = jl_eval_string(code_string);
> void* array_type = jl_array_eltype(ret);
> jl_array_t *ret_array = (jl_array_t*)ret;
>
>
>
> if (jl_typeis(array_type, jl_int64_type)) {
>  long *data = (long*) jl_array_data(ret_array);
> }
> else if (jl_typeis(array_type, jl_float64_type)) { double *data = (
> double*) jl_array_data(ret_array);
> }
>
>
> On Friday, 14 October 2016 20:45:18 UTC-4, Isaiah wrote:
>>
>> On Fri, Oct 14, 2016 at 2:28 PM, Kyle Kotowick 
>> wrote:
>>>
>>>
>>> After determining that an array was returned, how would you
>>> determine what the inner type of the array is (i.e. the type of the 
>>> objects
>>> it contains)?
>>>
>>
>> `jl_array_eltype`
>>
>>
>>>
>>> And furthermore, if it returns an array of type "Any", would there
>>> be any way to tell what the type is of any arbitrary element in that 
>>> array?
>>>
>>
>> `jl_typeof`, after retrieving the element (which will be boxed)
>>
>>
>>>
>>> Thanks!
>>>
>>
>>
>>>
>

Re: [julia-users] UTF8, how to procesed text data

[Stefan Karpinski]

http://docs.julialang.org/en/release-0.5/manual/strings/

On Wed, Oct 19, 2016 at 7:46 AM,  wrote:

> Data file is coding UTF8 but i cant procedsed this datain Julia ? What
> wrong ?
>
> o=open("data.txt")
>
> julia> temp=readline(io)
> "3699778,13,2,gdbiehz jablej gupując szybgi Injehnej dg 26
> paździehniga,1\n"
>
> julia> temp[61:65]
> "aźdz"
>
> julia> findin(temp[61:65],"d")
> ERROR: invalid UTF-8 character index
>  in next at utf8.jl:64
>  in findin at array.jl:1179
>
> Paul
>

Re: [julia-users] thread safe locks and Julia 0.4

[Stefan Karpinski]

The task stuff and threading stuff will converge but for now they're
separate. Part of the "experimental" label.

On Tue, Oct 18, 2016 at 3:57 PM, Yichao Yu  wrote:

>
>
> On Tue, Oct 18, 2016 at 3:53 PM, Ryan Gardner  wrote:
>
>> The documentation for Julia 0.5.0 says that the lock returned by
>> ReentrantLock() "is NOT threadsafe" ( http://docs.julialang.org/en/r
>> elease-0.5/stdlib/parallel/ see ReentrantLock()) .  What does that
>> mean?  I interpret it to mean that I cannot safely call lock or unlock
>> simultaneously with different threads, but then what good would the lock be
>> at all?
>>
>
> Don't use that lock for threads. It's for tasks.
>
>
>>
>> In any case, I need a reliable mutex-style lock, but am using Julia 0.4.3
>> where there is no Mutex, as far as I can tell.  Can I use ReentrantLock and
>> lock and unlock?  Thanks.
>>
>
> There's no threading support on 0.4
>
>
>

Re: [julia-users] matrix multiplications

[Stefan Karpinski]

Since it uses the in-place assignment operator .= it could be made to work
as desired, but there's some designing to do.

On Tue, Oct 18, 2016 at 2:55 PM, Cameron McBride <cameron.mcbr...@gmail.com>
wrote:

> You mean like the following?
>
> julia> A=[1.0 2.0; 3.0 4.0]; B=[1.0 1.0; 1.0 1.0]; Y = similar(B); Y.= A *
> B
>
> This doesn’t work as you might hope. I believe it just creates a temporary
> result of A*B and then stuffs it into the preexisting Y.
>
> On Tue, Oct 18, 2016 at 2:41 PM, Jérémy Béjanin <jeremy.beja...@gmail.com>
> wrote:
>
>> I know, I was asking about that being the default behaviour of *
>>
>> On Tuesday, October 18, 2016 at 2:10:14 PM UTC-4, Stefan Karpinski wrote:
>>>
>>> That's what A_mul_B! does.
>>>
>>> On Tue, Oct 18, 2016 at 1:45 PM, Jérémy Béjanin <jeremy@gmail.com>
>>> wrote:
>>>
>>>> I think this is something I might have read about in the past, but are
>>>> there plans to make y = a*b use an already allocated y?
>>>>
>>>> On Tuesday, October 18, 2016 at 12:38:00 PM UTC-4, Stefan Karpinski
>>>> wrote:
>>>>>
>>>>>   A_mul_B!(Y, A, B) -> Y
>>>>>
>>>>>   Calculates the matrix-matrix or matrix-vector product A⋅B and stores
>>>>> the result in Y, overwriting the
>>>>>   existing value of Y. Note that Y must not be aliased with either A
>>>>> or B.
>>>>>
>>>>>   julia> A=[1.0 2.0; 3.0 4.0]; B=[1.0 1.0; 1.0 1.0]; Y = similar(B);
>>>>> A_mul_B!(Y, A, B);
>>>>>
>>>>>   julia> Y
>>>>>   2×2 Array{Float64,2}:
>>>>>3.0  3.0
>>>>>7.0  7.0
>>>>>
>>>>> On Tue, Oct 18, 2016 at 10:27 AM, <zamani.m...@gmail.com> wrote:
>>>>>
>>>>>> hi guys
>>>>>> is there a way to reduce allocated memory in matrix multiplications?
>>>>>>
>>>>>> for example this code blew in my machine gives :
>>>>>>
>>>>>> function test4(n)
>>>>>>   a = rand(n,n)
>>>>>>   for i = 1:100
>>>>>>  a*a
>>>>>>end
>>>>>>  end
>>>>>>
>>>>>>
>>>>>> -- answer  --
>>>>>> test4(1)
>>>>>> # force compiling
>>>>>>
>>>>>> @time test4(1000)
>>>>>> 16.589743 seconds (433 allocations: 770.587 MB, 0.68% gc time)
>>>>>>
>>>>>
>>>>>
>>>
>

Re: [julia-users] matrix multiplications

[Stefan Karpinski]

That's what A_mul_B! does.

On Tue, Oct 18, 2016 at 1:45 PM, Jérémy Béjanin <jeremy.beja...@gmail.com>
wrote:

> I think this is something I might have read about in the past, but are
> there plans to make y = a*b use an already allocated y?
>
> On Tuesday, October 18, 2016 at 12:38:00 PM UTC-4, Stefan Karpinski wrote:
>>
>>   A_mul_B!(Y, A, B) -> Y
>>
>>   Calculates the matrix-matrix or matrix-vector product A⋅B and stores
>> the result in Y, overwriting the
>>   existing value of Y. Note that Y must not be aliased with either A or B.
>>
>>   julia> A=[1.0 2.0; 3.0 4.0]; B=[1.0 1.0; 1.0 1.0]; Y = similar(B);
>> A_mul_B!(Y, A, B);
>>
>>   julia> Y
>>   2×2 Array{Float64,2}:
>>3.0  3.0
>>7.0  7.0
>>
>> On Tue, Oct 18, 2016 at 10:27 AM, <zamani.m...@gmail.com> wrote:
>>
>>> hi guys
>>> is there a way to reduce allocated memory in matrix multiplications?
>>>
>>> for example this code blew in my machine gives :
>>>
>>> function test4(n)
>>>   a = rand(n,n)
>>>   for i = 1:100
>>>  a*a
>>>end
>>>  end
>>>
>>>
>>> -- answer  --
>>> test4(1)
>>> # force compiling
>>>
>>> @time test4(1000)
>>> 16.589743 seconds (433 allocations: 770.587 MB, 0.68% gc time)
>>>
>>
>>

Re: [julia-users] matrix multiplications

[Stefan Karpinski]

  A_mul_B!(Y, A, B) -> Y

  Calculates the matrix-matrix or matrix-vector product A⋅B and stores the
result in Y, overwriting the
  existing value of Y. Note that Y must not be aliased with either A or B.

  julia> A=[1.0 2.0; 3.0 4.0]; B=[1.0 1.0; 1.0 1.0]; Y = similar(B);
A_mul_B!(Y, A, B);

  julia> Y
  2×2 Array{Float64,2}:
   3.0  3.0
   7.0  7.0

On Tue, Oct 18, 2016 at 10:27 AM,  wrote:

> hi guys
> is there a way to reduce allocated memory in matrix multiplications?
>
> for example this code blew in my machine gives :
>
> function test4(n)
>   a = rand(n,n)
>   for i = 1:100
>  a*a
>end
>  end
>
>
> -- answer  --
> test4(1)
> # force compiling
>
> @time test4(1000)
> 16.589743 seconds (433 allocations: 770.587 MB, 0.68% gc time)
>

Re: [julia-users] Re: Julia 0.5 Highlights

[Stefan Karpinski]

Yes, that's essentially it – except that since we haven't converged on a
particular design, it's hard to say exactly what interfaces are at this
point. But yes, it's something that provides a first class representation
of some protocol/interface.

On Mon, Oct 17, 2016 at 11:33 AM, Brian Rogoff <brog...@gmail.com> wrote:

> On Thursday, October 13, 2016 at 1:00:21 PM UTC-7, Stefan Karpinski wrote:
>>
>> No, Function doesn't have signatures, arity or return type as part of its
>> type. The signature of a function is the union of its method signatures,
>> which is potentially very complicated. Type parameters are not
>> contravariant, so they can't be described without massively complicated
>> Julia's (already complicated) type system. Worse still, adding any form of
>> contravariance would almost certainly make important predicates like
>> subtype and type intersection undecidable. There are still things that
>> could be done to get some of the features that you probably want from
>> function types, but dispatching on the return type is unlikely to ever be
>> allowed. Two things that may happen are:
>>
>
> Got it, thanks! I want method signatures for documentation, debugging, and
> as constraints or hints for the compiler, which are exactly what your two
> things provide.
>
> Are these are what you call 'interfaces' in your JuliaCon 2016 keynote,
> discussed here https://github.com/JuliaLang/julia/issues/6975?
>
>
>> 1. Constraining the type signature of a generic function, raising an
>> error if any method returns something that doesn't match:
>>
>> convert{T} :: (T, Any)-->T
>>
>>
>> or whatever syntax makes sense. This would implicitly mean that any call
>> to convert(T,x) would be translated to convert(T,x)::T so that we know
>> convert always returns the type one would expect for it. This is what I was
>> alluding to above.
>>
>> 2. Intersecting a function signature on an argument with a generic
>> function to extract a "sub-function" that will either behave the way we
>> expect it to or raise an error:
>>
>> function mysort!{T}(lt::(T,T)-->Bool, Vector{T})
>> ...
>>
>> end
>>
>>
>> This would mean that any use like lt(a, b) in the function body would
>> implicitly be wrapped as lt(a::T, b::T)::Bool or something like that. This
>> extra type information could potentially allow the compiler to reason
>> better about the function's behavior even in cases where it otherwise can't
>> figure out that much. Of course, in the case that's already fast, we don't
>> need that information since the type of function calls can already be
>> completely inferred.
>>
>> Note that neither of these allow you to dispatch on the type of lt.
>>
>

Re: [julia-users] linspace question; bug?

[Stefan Karpinski]

On Fri, Oct 14, 2016 at 8:17 PM, Páll Haraldsson 
wrote:

>
> Nobody makes a one element linspace intentionally, but would it be bad to
> allow it?
>

Yes, it's better to raise an error when asked to do something that makes no
sense than to do some arbitrary wrong thing.

I wouldn't have posted if not for seeing "Real" that is the real question
> (bug?).
>

There's a discussion about this somewhere. The linspace type is likely to
change in 0.6 anyway.

Re: [julia-users] Does julia -L work with plots?

[Stefan Rigger]

Works great, thanks!

On Sat, Oct 15, 2016 at 2:56 AM, Isaiah Norton <isaiah.nor...@gmail.com>
wrote:

> Call `show()` at the end of the script. See explanation here:
>
> https://github.com/JuliaPy/PyPlot.jl#non-interactive-plotting
>
> On Fri, Oct 14, 2016 at 1:17 PM, Stefan Rigger <schtiv...@gmail.com>
> wrote:
>
>>
>>
>> Hello everyone,
>>
>> I'm using julia to numerically solve partial differential equations and
>> use PyPlot to plot the solutions. I'd like to be able to calculate a
>> solution and plot entering something like
>> julia -L file.jl
>>
>> in Terminal but unfortunately, this doesn't seem to work (there is no
>> window opening where one can view the solution). I've attached a small .jl
>> file if you want to test it yourself. Is there any way one can get this to
>> work? Thank you for your time,
>>
>> Best Regards,
>> Stefan Rigger
>>
>
>

Re: [julia-users] linspace question; bug?

[Stefan Karpinski]

I'll answer your question with a riddle: How can you have a length-one
collection whose first and last value are different?

On Fri, Oct 14, 2016 at 6:25 PM, Páll Haraldsson 
wrote:

>
> I mistook third param for step, and got confusing error:
>
>
> julia> linspace(1, 2, 1)
> ERROR: linspace(1.0, 2.0, 1.0): endpoints differ
>  in linspace(::Float64, ::Float64, ::Float64) at ./range.jl:212
>  in linspace(::Float64, ::Float64, ::Int64) at ./range.jl:251
>  in linspace(::Int64, ::Int64, ::Int64) at ./range.jl:253
>
> julia> linspace(1.0, 2.0, 1)
> ERROR: linspace(1.0, 2.0, 1.0): endpoints differ
>  in linspace(::Float64, ::Float64, ::Float64) at ./range.jl:212
>  in linspace(::Float64, ::Float64, ::Int64) at ./range.jl:251
>
>
> It may not matter too much to get this to work (or give helpful error); I
> went to debug and found (should num/len be Integer? see inline comments):
>
>
> immutable LinSpace{T<:AbstractFloat} <: Range{T}
> start::T
> stop::T
> len::T # len::Integer, only countable..
> divisor::T
> end
>
> function linspace{T<:AbstractFloat}(start::T, stop::T, len::T)
>
> #long function omitted
>
> function linspace{T<:AbstractFloat}(start::T, stop::T, len::Real) #
> change to len::Integer, is this for type stability reasons, or to handle
> Rationals somehow?
> T_len = convert(T, len)
> T_len == len || throw(InexactError())
> linspace(start, stop, T_len)
> end
> linspace(start::Real, stop::Real, len::Real=50) =  # change to
> len::Integer=50
> linspace(promote(AbstractFloat(start), AbstractFloat(stop))..., len)
>
>

[julia-users] Does julia -L work with plots?

[Stefan Rigger]

Hello everyone, 

I'm using julia to numerically solve partial differential equations and use 
PyPlot to plot the solutions. I'd like to be able to calculate a solution 
and plot entering something like 
julia -L file.jl

in Terminal but unfortunately, this doesn't seem to work (there is no 
window opening where one can view the solution). I've attached a small .jl 
file if you want to test it yourself. Is there any way one can get this to 
work? Thank you for your time,

Best Regards,
Stefan Rigger


test.jl
Description: Binary data

Re: [julia-users] Re: Julia 0.5 Highlights

[Stefan Karpinski]

On Thu, Oct 13, 2016 at 12:26 PM, Brian Rogoff  wrote:

> Great summary, thanks so much!
>
> Being a fan of typeful functional programming, I really like the return
> type annotations and FP performance improvements. Is there a way to
> describe a precise return type for a higher order function? The examples of
> Function I've seen have neither the arguments type/arity or return types.
>

No, Function doesn't have signatures, arity or return type as part of its
type. The signature of a function is the union of its method signatures,
which is potentially very complicated. Type parameters are not
contravariant, so they can't be described without massively complicated
Julia's (already complicated) type system. Worse still, adding any form of
contravariance would almost certainly make important predicates like
subtype and type intersection undecidable. There are still things that
could be done to get some of the features that you probably want from
function types, but dispatching on the return type is unlikely to ever be
allowed. Two things that may happen are:

1. Constraining the type signature of a generic function, raising an error
if any method returns something that doesn't match:

convert{T} :: (T, Any)-->T


or whatever syntax makes sense. This would implicitly mean that any call to
convert(T,x) would be translated to convert(T,x)::T so that we know convert
always returns the type one would expect for it. This is what I was
alluding to above.

2. Intersecting a function signature on an argument with a generic function
to extract a "sub-function" that will either behave the way we expect it to
or raise an error:

function mysort!{T}(lt::(T,T)-->Bool, Vector{T})
...

end


This would mean that any use like lt(a, b) in the function body would
implicitly be wrapped as lt(a::T, b::T)::Bool or something like that. This
extra type information could potentially allow the compiler to reason
better about the function's behavior even in cases where it otherwise can't
figure out that much. Of course, in the case that's already fast, we don't
need that information since the type of function calls can already be
completely inferred.

Note that neither of these allow you to dispatch on the type of lt.

Re: [julia-users] Are SubArrays intended to work with BLAS functions?

[Stefan Karpinski]

Seems like a bug to me. Can you file an issue?

On Thu, Oct 13, 2016 at 10:13 AM, Josh Day  wrote:

> After much confusion, I discovered That BLAS.syr! gives incorrect results
> when using a view.  Is this a bug, or is it not recommended to use views
> with BLAS functions?
>
>
> julia> a1 = zeros(2,2); a2 = zeros(2, 2); x = randn(5, 2);
>
> julia> BLAS.syr!('U', 1.0, view(x, 1, :), a1)
> 2×2 Array{Float64,2}:
>  0.483364  0.440104
>  0.0   0.400716
>
> julia> BLAS.syr!('U', 1.0, x[1, :], a2)
> 2×2 Array{Float64,2}:
>  0.483364  0.458034
>  0.0   0.434032
>
> However, BLAS.syrk! appears to work:
>
> julia> a1 = zeros(2,2); a2 = zeros(2, 2); x = randn(5, 2);
>
> julia> BLAS.syrk!('U', 'T', 1.0, x, 0.0, a1)
> 2×2 Array{Float64,2}:
>  4.16346  -0.618009
>  0.0   4.75777
>
> julia> BLAS.syrk!('U', 'T', 1.0, view(x, :, :), 0.0, a2)
> 2×2 Array{Float64,2}:
>  4.16346  -0.618009
>  0.0   4.75777
>

Re: [julia-users] Re: Performance of release 0.5.0 v 0.4.6.0

[Stefan Karpinski]

Increasing coverage of Julia's own code base was a major effort during 0.5
– it's not a user-facing change but it's very important. If you want to run
performance tests, they can be found under test/perf. There are also a
significant number of benchmarks that can be found in the BaseBenchmarks
 repository.

On Thu, Oct 13, 2016 at 9:58 AM, Steven G. Johnson 
wrote:

> runtests() runs correctness tests, not performance tests.  0.5 added many
> more tests, hence they are slower.
>

Re: [julia-users] Re: I have two data collection for mapreduce() vs. generator, which is correct/better implementation? (Julia 0.5)

[Stefan Karpinski]

540 ulps does seem kind of big.

On Thu, Oct 13, 2016 at 4:21 AM, DNF  wrote:

> That seems right:
>
> julia> f(a, p)
> 781.4987197415827
>
> julia> f(reverse(a), reverse(p))
> 781.4987197415213
>
>
> But I'm pretty surprised the effect is that big.
>
> On Thursday, October 13, 2016 at 9:49:00 AM UTC+2, Kristoffer Carlsson
> wrote:
>>
>> I think you will not add the numbers in the same order when SIMD is used.
>> Floating point addition is not commutative so you get slightly different
>> answers.
>>
>> On Thursday, October 13, 2016 at 9:14:31 AM UTC+2, DNF wrote:
>>>
>>> This is about twice as fast with, with @simd:
>>>
>>> function f2(a, p)
>>> @assert length(a) == length(p)
>>> s = 0.0
>>> @simd for i in eachindex(a)
>>> @inbounds s += abs((a[i] - p[i])/a[i])
>>> end
>>> return 100s/length(a)
>>> end
>>>
>>> julia> @benchmark f(a, p)
>>> BenchmarkTools.Trial:
>>>   samples:  115
>>>   evals/sample: 1
>>>   time tolerance:   5.00%
>>>   memory tolerance: 1.00%
>>>   memory estimate:  144.00 bytes
>>>   allocs estimate:  7
>>>   minimum time: 41.96 ms (0.00% GC)
>>>   median time:  42.53 ms (0.00% GC)
>>>   mean time:43.49 ms (0.00% GC)
>>>   maximum time: 52.82 ms (0.00% GC)
>>>
>>> julia> @benchmark f2(a, p)
>>> BenchmarkTools.Trial:
>>>   samples:  224
>>>   evals/sample: 1
>>>   time tolerance:   5.00%
>>>   memory tolerance: 1.00%
>>>   memory estimate:  0.00 bytes
>>>   allocs estimate:  0
>>>   minimum time: 21.08 ms (0.00% GC)
>>>   median time:  21.86 ms (0.00% GC)
>>>   mean time:22.38 ms (0.00% GC)
>>>   maximum time: 27.30 ms (0.00% GC)
>>>
>>>
>>> Weirdly, they give slightly different answers:
>>>
>>> julia> f(a, p)
>>> 781.4987197415827
>>>
>>> julia> f2(a, p)
>>> 781.498719741497
>>>
>>>
>>> I would like to know why that happens.
>>>
>>> On Friday, October 7, 2016 at 10:29:20 AM UTC+2, Martin Florek wrote:

 Thanks Andrew for answer.
 I also have experience that eachindex() is slightly faster.
 In Performance tips I found macros e.g. @simd. Do you have any
 experience with them?

>>>
>>>
>>>
>>

Re: [julia-users] Re: Julia 0.5 Highlights

[Stefan Karpinski]

That's a fair point. It seems like it could/should be handled by the same
(not-yet-implemented) mechanism that ensures that `convert(T,x)::T` is
true. Of course, we could choose to enforce this fact via lowering in this
case, independent of enforcing it for convert.

On Wed, Oct 12, 2016 at 7:40 PM, Cedric St-Jean 
wrote:

> Very nice summary!
>
> I assume that there's a mile-long issue discussing this somewhere, but why
> doesn't the return type also assert that convert returns a value of the
> correct type?
>
> type A end
> Base.convert(::Type{Int}, ::A) = "hey"
> foo()::Int = A()
> foo()  # returns "hey"
>
>
> On Wednesday, October 12, 2016 at 4:29:09 PM UTC-4, Jared Crean wrote:
>>
>>   Perfect, thanks.
>>
>>   Jared Crean
>>
>> On Wednesday, October 12, 2016 at 2:40:03 PM UTC-4, harven wrote:
>>>
>>>
>>>
>>> Le mercredi 12 octobre 2016 01:45:25 UTC+2, Jared Crean a écrit :

 Very nice summary, thanks for posting.  One question I had was what
 should the signature of a function be to receive a generator?  For example,
 if the only method of extrema is extrema(A::AbstractArray), is that too
 restrictive?

   Jared Crean


>>> Any functions working with iterables will work with generators.
>>>
>>> julia> methods(extrema)
>>> # 4 methods for generic function "extrema":
>>> extrema(r::Range) at reduce.jl:345
>>> extrema(x::Real) at reduce.jl:346
>>> extrema(A::AbstractArray, dims) at reduce.jl:388
>>> extrema(itr) at reduce.jl:362
>>>
>>>
>>> The last line tells you that extrema will work. An object is iterable if
>>> it implements the methods start, next and done. There are in fact a few
>>> other objects that also work on generators.
>>>
>>>  julia> methodswith(Base.Generator)
>>> 8-element Array{Method,1}:
>>>  collect(itr::Base.Generator) at array.jl:298
>>>  done(g::Base.Generator, s) at generator.jl:22
>>>  indices(g::Base.Generator) at generator.jl:91
>>>  length(g::Base.Generator) at generator.jl:89
>>>  ndims(g::Base.Generator) at generator.jl:92
>>>  next(g::Base.Generator, s) at generator.jl:24
>>>  size(g::Base.Generator) at generator.jl:90
>>>  start(g::Base.Generator) at generator.jl:21
>>>
>>> There are a few functions that work on arrays but not on iterables. You
>>> should not expect these to work on generators.
>>>
>>> julia> show(reverse([1:10;]))
>>> [10,9,8,7,6,5,4,3,2,1]
>>> julia> show(reverse(i for i = 1:10))
>>> ERROR: MethodError: no method matching reverse(::Base.Generator{UnitR
>>> ange{Int64},##9#10})
>>> Closest candidates are:
>>>   reverse(!Matched::String) at strings/string.jl:209
>>>   reverse(!Matched::BitArray{1}) at bitarray.jl:1416
>>>   reverse(!Matched::Tuple) at tuple.jl:199
>>>   ...
>>>
>>

[julia-users] Julia 0.5 Highlights

[Stefan Karpinski]

Since the 0.5 release affects everyone here, I wrote a longish blog post
about what the major changes are:
http://julialang.org/blog/2016/10/julia-0.5-highlights.

One other change that I left out of the post because it was getting pretty
long and it seems a bit esoteric is that array comprehensions are now
type-inference-independent. That means that the type of the resulting array
only depends on the actual types of values produced, not what the compiler
can prove about the expression in advance. In particular, this means that
comprehensions behave the same way in global scope as in local scope now,
which is a fairly major relief to anyone who's struggled with that.

Re: [julia-users] Re: Julia on Research Computing Podcast RCE

[Stefan Karpinski]

. Looking forward to hearing the episode! Thanks, Brock.

On Wed, Oct 5, 2016 at 6:45 PM, Brock Palen <bro...@mlds-networks.com>
wrote:

> Thank you everyone for the support of the podcast.  If you have other
> topics please let me know off list.
>
> The Julia episode is up at: http://www.rce-cast.com/
> Podcast/rce-107-julia.html
>
> Thanks again to:
> Viral Shah
> Stefan Karpinski
> Jeff Bezanson
> Alan Edelman
>
> Brock Palen
>
>
> On Saturday, September 10, 2016 at 11:33:41 PM UTC-4, Brock Palen wrote:
>>
>> I am one half of the HPC/Research Computing podcast
>> http://www.rce-cast.com/
>>
>> We would like to feature Julia on the show.  This takes a developer or
>> two and is a friendly interview, takes about an hour over the phone or
>> skype and aims to educate our community.
>>
>> Feel free to contact me off list.
>>
>> Thank you !
>>
>> Brock Palen
>>
>>

Re: [julia-users] Re: Julia and the Tower of Babel

[Stefan Karpinski]

Good generic API design is one of the hardest problems around. For many
problem areas, we just haven't found the right design yet. JuMP is one of
the prime examples of brilliant work in this area. Mathematica is the best
example of consistent APIs in a language and it's ecosystem because Stephen
Wolfram literally reviews and approves every single function that's added.
We can't do that since this is an open source community and we don't have
dictators, and honestly no one has the time or breadth of expertise to do
this for all the amazing areas people are using Julia in. There are some
things that are helpful, however.

*GitHub orgs.* Having related packages under a single org is weirdly
effective – way more than it seems like it should be. I think this is about
awareness and communication. Not a panacea, but more helpful than you would
imagine.

*Communication.* Long hard conversations like this one
. Get people talking about
what the common API should look like. Once people agree on a good one,
implementation is often easier than one might think.

*Generic functions.* Julia's multiple dispatch is good at this, especially
because it allows you to disentangle nouns and verbs, and different people
can work on different parts of the vocabulary. Have a good set of nouns
like Distributions ? Anyone
can add their own verbs. Have some good consistent verbs? Making them apply
to your own nouns is no problem either. See the esoteric-seeming expression
problem [1 ,2

,3 ] –
which doesn't even occur to Julia programmers as being a problem because
the solution is so natural.

*Persistence.* The more speculative and active a research area is, the less
likely we are to have a consensus on what the generic interfaces and APIs
should look like. Optimization APIs were all over the place until things
like JuMP and Convex came along. Now you can swap out different solvers
easily and keep the expression of your problem the same. Changing deep
learning backends should be just as easy, but it's certainly not – because
people are still trying to figure out how what the interface between how
you program and how you implement these systems is.

*Summary:* keep trying, communicate, create organizations, and use multiple
dispatch effectively.


On Sat, Oct 8, 2016 at 10:12 AM, Tsur Herman  wrote:

> I noticed this also .. and this is why I chose to "rip" some packages for
> some of its functionality.
>
> From what I observed the problem is the "coolness" of the language and the
> highly creative level of the package writers. Just as the first post here
> states the seemingly two advantages , cool language and super-creative
> package writers .. can some time have a "babel tower" effect.
>
> I encountered this with respect to image processing geometry primitive
> manipulation etc .. the problem is: too many types!!
>
> if something can be represented as an array with some convention for
> example MxN array where M is the Descriptor size and N is the number of
> Descriptors  .. then it is better to use and support that
> than to declare more specialized types.
>
> At least for fast paced research and idea validation it is better.
> Probably for implementation and performance specialized types optimized for
> speed will be required..
>
>
>

Re: [julia-users] How does one read and write a sizeable amount of data (megabytes) from a process?

[Stefan Karpinski]

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

On Fri, Oct 7, 2016 at 6:26 PM, Eric Davies  wrote:

> Thanks, I will try both of those. I had tried making smaller pieces before
> but I'll try with `Base.process_events(false)`.
>

Re: [julia-users] Re: multiple dispatch for operators

[Stefan Karpinski]

I think you're asking on the wrong list :P

On Fri, Oct 7, 2016 at 1:56 PM, Gabriel Gellner 
wrote:

> Any reason to not just use a function? (like np.dot etc)
>
> My understanding is that in python '*' means elementwise multiplication,
> so even if you could monkeypatch numpys __mul__ method to do the right
> thing wouldn't you be changing the semantics?
>
> Gabriel
>
> On Friday, October 7, 2016 at 3:51:11 AM UTC-6, Sisyphuss wrote:
>
>> In Julia, we can do multiple dispatch for operators, that is the
>> interpreter can identify:
>> float + integer
>> integer + integer
>> integer + float
>> float + float
>> as well as *user-defined* data structure.
>>
>> Recently, I am working on Python (I have no choice because Spark hasn't
>> yet a Julia binding). I intended to do the same thing -- multiplication --
>> between a Numpy matrix and self-defined Low-rank matrix. Of course, I
>> defined the `__rmul__ ` method for Low-rank matrix. However, it seems to me
>> that the Numpy matrix intercepts the `*` operator as its `__mul__` method,
>> which expects the argument on the right side of `*` to be a scalar.
>>
>> I would like to know if there is anyway around?
>>
>>

Re: [julia-users] Simple test functions generates different codegen

[Stefan Karpinski]

Julia has to do a delicate balancing act between compilation speed and
runtime speed. In the future, we may introduce multiple compilation tiers
as many other JITs have, but so far we've managed to avoid it, which is
really actually quite nice for both keeping implementation complexity down
and for performance being predictable. Ideally we can figure out other ways
to make compilation faster without compiler tiers.

On Tue, Oct 4, 2016 at 1:15 PM, mmh  wrote:

> Ah right, I forgot @code_lowered even existed , thanks for that. Yeah
> gcc/clang all have the same native code from this snippet, which is why I
> was surprised that the same julia code was produced different  code native.
>
>
> On Tuesday, October 4, 2016 at 9:13:17 AM UTC-4, Isaiah wrote:
>>
>> These expressions are lowered differently because `test2` gets a
>> temporary due to the conditional reassignment of `u`, whereas `test1` is
>> just a straight line switch and jump (look at `code_lowered` and
>> `code_typed`).
>>
>> For the same C code, the lowered IR from Clang looks similar, but it
>> appears to constant fold and reduce down to identical assembly at `-O1` and
>> above. The fact that Julia doesn't is probably due to difference in LLVM
>> optimization passes or order.
>>
>> As far as style, personally I think the first one is cleaner.
>>
>> On Fri, Sep 30, 2016 at 1:48 PM, mmh  wrote:
>>
>>> I would have that thought that these two function would produce the same
>>> code, but they do not.
>>>
>>> Could someone care to explain the difference and which is preferred and
>>> why
>>>
>>>
>>> http://pastebin.com/GJ8YPfV3
>>>
>>> function test1(x)
>>> y = 2.0
>>> u = 2.320
>>> x < 0 && (u = 32.0)
>>> x > 1 && (u = 1.0)
>>> return u + y
>>> end
>>>
>>>
>>> function test2(x)
>>> y = 2.0
>>> u = 2.320
>>> u = x < 0 ? 32.0 : u
>>> u = x > 1 ? 1.0 : u
>>> return u + y
>>> end
>>>
>>>
>>> @code_llvm test1(2.2)
>>>
>>> @code_llvm test2(2.2)
>>>
>>>
>>

Re: [julia-users] Re: Julia-i18n logo proposal

[Stefan Karpinski]

On Wed, Oct 5, 2016 at 9:29 AM, Waldir Pimenta 
wrote:

> Oops, meant to link to julia-i18n-j.svg 
> in the previous message, rather than twice to the -ju variant.
>

I like this one  – it looks nicely
balanced. The letters from the three scripts is really nice.

Re: [julia-users] Re: Using generators

[Stefan Karpinski]

There's nothing you can do with comprehensions or generators that you can't
do with for loops or functional programming. But there are situations where
they are considerably more convenient syntactically. Consider a case where
you have several nested for clauses and a filter clause involving all of
those variables, such as:

julia> [(a,b,c,d) for a=1:n for b=a:n for c=b:n for d=c:n if a*d < b*c]
418-element Array{Tuple{Int64,Int64,Int64,Int64},1}:
 (1,2,2,2)
 (1,2,2,3)
 (1,2,3,3)
 (1,2,3,4)
 (1,2,3,5)
 ⋮
 (8,9,9,9)
 (8,9,9,10)
 (8,9,10,10)
 (8,10,10,10)
 (9,10,10,10)


That's really annoying to express with loops or functional constructs.
Lambdas force you to keep giving the variables names over and over, even
though you really just want to use the same names throughout the
construction. The flattened nested iteration can be expressed with higher
order constructs, but it's a serious pain to write and not pretty.

The same argument applies to generators, except that you'll want to use
them in cases where you'd like to iterate a complex set of values like that
without actually constructing an intermediate array of values. For example,
let's say you wanted to make an IntSet of the possible values of a*d +
b*c in the above cases:

julia> IntSet(a*d + b*c for a=1:n for b=a:n for c=b:n for d=c:n if a*d <
b*c)
IntSet([6, 7, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23,
24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42,
43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 62,
63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81,
82, 83, 84, 85, 86, 88, 89, 90, 91, 92, 93, 94, 96, 97, 99, 100, 101, 102,
103, 104, 106, 108, 109, 110, 111, 112, 113, 114, 117, 118, 120, 121, 122,
123, 124, 126, 127, 130, 131, 132, 135, 140, 141, 142, 144, 150, 151, 153,
160, 161, 170, 180, 190])


Instead of creating an intermediate set of all tuples and then passing that
to the IntSet, this iterates through the possible values, inserting them
into the IntSet as it goes. Since there are only 127 of these values, it's
more efficient.

On Sun, Oct 2, 2016 at 8:23 PM, Steven G. Johnson 
wrote:

>
>
> On Sunday, October 2, 2016 at 6:02:13 AM UTC-4, harven wrote:
>>
>> I see that julia v0.5 has now generators. That looks promising but the
>> example given in the docs is not really interesting,
>>
>>   sum(1/n^2 for n = 1:1000)
>>
>> since we have been able to write from start the shorter  and I think as
>> efficient
>>
>>   sum(n->1/n^2, 1:1000)
>>
>> My question is, where may/should I use generators?
>>
>
> Generator expressions produce an iterator, so they work with any function
> that accepts iterables.
>

Re: [julia-users] Re: Julia-i18n logo proposal

[Stefan Karpinski]

Lovely logo for i18n. 

On Fri, Sep 30, 2016 at 5:51 AM, Waldir Pimenta 
wrote:

> What a nice coincidence! That was totally unintended :)
>
> By the way, here's a reference for the most used writing systems:
> https://en.wikipedia.org/wiki/List_of_writing_systems#List_
> of_writing_scripts_by_adoption
>
>
> On Friday, September 30, 2016 at 9:16:05 AM UTC+1, Kenta Sato wrote:
>>
>> "朱" means a kind of red colors in Japanese (https://ja.wikipedia.org/wiki
>> /%E6%9C%B1%E8%89%B2). You placed it at the best circle of the logo.
>>
>> On Friday, September 30, 2016 at 9:47:04 AM UTC+9, Waldir Pimenta wrote:
>>>
>>> Hi all. I made a proposal for the logo for the Julia-i18n organization:
>>> http://imgh.us/julia-i18n_1.svg
>>>
>>> It uses the three most used scripts worldwide, and the characters are
>>> actually the start of the word “Julia” as written in each of those scripts.
>>>
>>> Looking forward to know what you guys think.
>>>
>>> --Waldir
>>>
>>

[julia-users] Seg fault when using Logging.jl

[Stefan Kruger]

Not sure if this is the right place for this..

I encountered a seg fault in v.0.5 (also in v.0.4) when I introduced 
Logging.jl - my set of tests runs fine without Logging, but crashes 
immediately when I try to log something:

signal (11): Segmentation fault: 11

while loading /Users/stefan/.julia/v0.5/Couchzilla/test/crud_tests.jl, in 
expression starting on line 1

uv_write2 at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/deps/srccache/libuv-8d5131b6c1595920dd30644cd1435b4f344b46c8/src/unix/stream.c:1389

uv_write at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/deps/srccache/libuv-8d5131b6c1595920dd30644cd1435b4f344b46c8/src/unix/stream.c:1475

jl_uv_write at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/jl_uv.c:424

uv_write at ./stream.jl:809

unsafe_write at ./stream.jl:830

write at ./io.jl:175

print at ./strings/io.jl:70 [inlined]

with_output_color at ./util.jl:302

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_apply_generic at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942

jl_apply at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia.h:1392 
[inlined]

jl_f__apply at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/builtins.c:547

print_with_color at ./util.jl:306

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_apply_generic at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942

err at /Users/stefan/.julia/v0.5/Logging/src/Logging.jl:53

#relax#2 at /Users/stefan/.julia/v0.5/Couchzilla/src/utils.jl:97

unknown function (ip: 0x318f98bb6)

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_apply_generic at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942

#relax at ./:0

#readdoc#6 at /Users/stefan/.julia/v0.5/Couchzilla/src/database.jl:177

readdoc at /Users/stefan/.julia/v0.5/Couchzilla/src/database.jl:126

unknown function (ip: 0x318f94f66)

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_apply_generic at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942

macro expansion; at 
/Users/stefan/.julia/v0.5/Couchzilla/test/crud_tests.jl:4 [inlined]

macro expansion; at ./test.jl:672 [inlined]

anonymous at ./ (unknown line)

unknown function (ip: 0x318f9484f)

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_toplevel_eval_flex at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.c:569

jl_parse_eval_all at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/ast.c:717

jl_load at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.c:596 
[inlined]

jl_load_ at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.c:605

include_from_node1 at ./loading.jl:488

jlcall_include_from_node1_20125 at 
/Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib 
(unknown line)

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_apply_generic at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942

do_call at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/interpreter.c:66

eval at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/interpreter.c:190

eval_body at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/interpreter.c:534

eval_body at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/interpreter.c:515

jl_interpret_call at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/interpreter.c:573

jl_toplevel_eval_flex at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.c:572

jl_parse_eval_all at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/ast.c:717

jl_load at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.c:596 
[inlined]

jl_load_ at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.c:605

include_from_node1 at ./loading.jl:488

jlcall_include_from_node1_20125 at 
/Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib 
(unknown line)

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_apply_generic at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942

process_options at ./client.jl:262

_start at ./client.jl:318

jlcall__start_21452 at 
/Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib 
(unknown line)

jl_call_method_internal at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 
[inlined]

jl_apply_generic at 
/Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942

true_main at /usr/local/bin/julia (unknown line

Re: [julia-users] Re: "both DataArrays and StatsBase export "rle"; uses of it in module DataFrames must be qualified"

[Stefan Karpinski]

It's not an issue with either package: when there are two things with the
same name, you need to be explicit about which one you want to use, either
by qualify how you refer to is or by explicitly importing one of the two
things with that name.

On Wed, Sep 28, 2016 at 7:44 AM, K leo  wrote:

> Thanks for the reply.  Then this is an issue in DataFrames.
>
>
> On Wednesday, September 28, 2016 at 5:47:03 PM UTC+8, Patrick Kofod
> Mogensen wrote:
>>
>> As the error says, they both export a function called rle, so it is not
>> possible to know which one you're trying to call, if you don't qualify
>> them. Qualifying means writing "package name dot" and then the function, as
>> seen below
>>
>> module A
>> export f
>> f(x::Int64) = x
>> end
>>
>> module B
>> export f
>> f(x::Int64) = x+1
>> end
>>
>> using A, B
>>
>> f(3) # error
>> A.f(3) # returns x = 3
>> B.f(3) # returns x + 1 = 3 + 1
>>
>>
>>
>> On Sunday, September 25, 2016 at 3:15:57 PM UTC+2, K leo wrote:
>>>
>>> I get a few warning messages like this often.  Does it mean that
>>> DataFrames package need to be updated, or that I need to do something in my
>>> user code?
>>>
>>

Re: [julia-users] Re: eval in current scope

[Stefan Karpinski]

If you need to generate code where the outer function has access to some
part of a local scope, you can generate the entire function and then call
it:

julia> ex = :(x + 1)
:(x + 1)

julia> @eval function f(x)
   y = $ex
   return y^2
   end
f (generic function with 1 method)

julia> f(2)
9


But note that if you want some piece of f to be "pasted" from the user and
have access to certain parts of the local state of f, it's probably a much
better design to let the user pass in a function which f calls, passing the
function the state that it should have access to:

julia> f(2)
9

julia> function g(h, x)
   y = h(x)
   return y^2
   end
g (generic function with 1 method)

julia> g(x->x+1, 2)
9


It's three more characters to type, but the way you call g isn't coupled to
the local variable names that g happens to use (x), and you can pass named
functions like `abs` to g more easily. It also prevents someone from
passing in a bit of code that completely breaks the caller in unexpected
ways.

On Tue, Sep 27, 2016 at 9:00 AM, Fábio Cardeal  wrote:

> The lambda example works, but couldn't you do:
> function f(x)
>   eval(:($x + 1))
> end
> ?
>
> You can still do that in a macro:
> macro m()
>   quote
> ex = :($x + 1)
> eval(ex)
>   end
> end
>
> function f(x)
>   @m
> end
>
> f(1) == 2
>
>
> What would be a situation where this wouldn't work?
>
>
> Em terça-feira, 27 de setembro de 2016 09:36:48 UTC-3, Jussi Piitulainen
> escreveu:
>>
>> You might be able to wrap your expression so as to create a function
>> instead, and call the function with the values of the variables that the
>> actual expression depends on. In Python, because I haven't learned to
>> construct expressions in Julia yet and don't have the time to learn it now:
>>
>> def f(x): return eval("lambda x: x + 1")(x)
>>
>>
>>
>> tiistai 27. syyskuuta 2016 12.28.40 UTC+3 Marius Millea kirjoitti:
>>>
>>> Hi, is there a way to "eval" something in the current scope? My problem
>>> is the following, I've written a macro that, inside the returned
>>> expression, builds an expression which I need to eval. It looks like this,
>>>
>>> macro foo()
>>> quote
>>> ex = ...
>>> eval_in_current_scope(ex)
>>> end
>>> end
>>>
>>> Now, you might say I'm using macros wrong and I should just be doing,
>>>
>>> macro foo()
>>> ex = ...
>>> end
>>>
>>>
>>> but in this case when I build "ex", it needs to occur at runtime since
>>> it depends on some things only available then. So is there any way to go
>>> about this? Thanks.
>>>
>>>

Re: [julia-users] Generators vs Comprehensions, Type-stability?

[Stefan Karpinski]

I see the same, yet:

julia> r = rand(10^5);

julia> @time test1(r)
  0.000246 seconds (7 allocations: 208 bytes)
33375.54531253989

julia> @time test2(r)
  0.001029 seconds (7 allocations: 781.500 KB)
33375.54531253966


So test1 is efficient, despite the codewarn output. Not sure what's up.

On Thu, Sep 22, 2016 at 2:21 PM, Christoph Ortner <
christophortn...@gmail.com> wrote:

> I hope that there is something I am missing, or making a mistake in the
> following example:
>
> r = rand(10)
> test1(r) = sum( t^2 for t in r )
> test2(r)= sum( [t^2 for t in r] )
> @code_warntype test1(r)   # return type Any is inferred
> @code_warntype test2(r)   # return type Float64 is inferred
>
>
> This caused a problem for me, beyond execution speed: I used a generator
> to create the elements for a comprehension, since the type was not inferred
> the zero-element could not be created.
>
> Is this a known issue?
>

Re: [julia-users] Re: ANN: A potential new Discourse-based Julia forum

[Stefan Karpinski]

Yikes... recycled static IP address :|

On Thu, Sep 22, 2016 at 1:02 PM, mmh <mumo...@gmail.com> wrote:

> http://julia.malmaud.com
> <http://www.google.com/url?q=http%3A%2F%2Fjulia.malmaud.com=D=1=AFQjCNFCXzcz9SUqslP2iBzUCOJuzZZNmw>
>
> Now links to some random dudes website :P
>
> On Monday, September 19, 2016 at 3:39:34 PM UTC-4, Jonathan Malmaud wrote:
>>
>> Discourse lives!
>> On Mon, Sep 19, 2016 at 3:01 PM Stefan Karpinski <ste...@karpinski.org>
>> wrote:
>>
>>> I got the go ahead from Jeff and Viral to give this a try, then it
>>> didn't end up panning out. It would still be worth a try, imo.
>>>
>>> On Sat, Sep 17, 2016 at 11:55 AM, mmh <mum...@gmail.com> wrote:
>>>
>>>> Hi Jonathan,
>>>>
>>>> Seems like this has kind of burnt out. Is there still an impetus on a
>>>> transition.
>>>>
>>>> On Saturday, September 19, 2015 at 8:16:36 PM UTC-4, Jonathan Malmaud
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>> There's been some chatter about maybe switching to a new, more modern
>>>>> forum platform for Julia that could potentially subsume julia-users,
>>>>> julia-dev, julia-stats, julia-gpu, and julia-jobs.   I created
>>>>> http://julia.malmaud.com for us to try one out and see if we like it.
>>>>> Please check it out and leave feedback. All the old posts from julia-users
>>>>> have already been imported to it.
>>>>>
>>>>> It is using Discourse <http://www.discourse.org/faq/>, the same forum
>>>>> software used for the forums of Rust <https://users.rust-lang.org>,
>>>>> BoingBoing, and some other big sites. Benefits over Google Groups include
>>>>> better support for topic tagging, community moderation features,  Markdown
>>>>> (and hence syntax highlighting) in messages, inline previews of linked-to
>>>>> Github issues, better mobile support, and more options for controlling 
>>>>> when
>>>>> and what you get emailed. The Discourse website
>>>>> <http://www.discourse.org/faq/> does a better job of summarizing the
>>>>> advantages than I could.
>>>>>
>>>>> To get things started, MIke Innes suggested having a topic on what we
>>>>> plan on working on this coming wee
>>>>> <http://julia.malmaud.com/t/whats-everyone-working-on-this-week-9-19-2015-9-26/3155>k.
>>>>> I think that's a great idea.
>>>>>
>>>>> Just to be clear, this isn't "official" in any sense - it's just to
>>>>> kickstart the discussion.
>>>>>
>>>>> -Jon
>>>>>
>>>>>
>>>>>
>>>

Re: [julia-users] Re: Adding publications easier

[Stefan Karpinski]

I didn't realize that there was a README that actually tells you to do all
of that. I've opened an issue
<https://github.com/JuliaLang/julialang.github.com/issues/421> since
there's no reason someone should have to install Jekyll in order to submit
a publication that uses Julia – that's way over the top.

On Thu, Sep 22, 2016 at 11:48 AM, Stefan Karpinski <ste...@karpinski.org>
wrote:

> You don't need Jekyll installed to edit markdown files. You can even edit
> files directly in the web and preview the rendering. Admittedly, installing
> Jekyll is a pain and seems to have gotten worse over time somehow, but you
> don't need to do any of that to submit a publication.
>
> On Thu, Sep 22, 2016 at 8:08 AM, Magnus Röding <magnus.rod...@gmail.com>
> wrote:
>
>> I have now made a new attempt, ending up having everything installed and
>> seemingly working on an Ubuntu 16.04 system. My workflow so far is:
>>
>> - git clone https:// to local repo (I have a github account)
>> - edit julia.bib and _EDIT_ME_index.md according to instructions
>> - run 'make' in publications directory
>> - run 'bundle exec jekyll build' in main repo directory
>> - adding the modified files by 'git add *'
>>
>> So, off-topic question as far as Julia goes, but what to do now? I
>> realize I'm supposed to commit, annotate, request-pull, and go nuts, but in
>> which order?
>>
>> Thanks in advance, not my cup of tea this, so if anyone can help tx :-)
>>
>> Den tisdag 20 september 2016 kl. 21:14:21 UTC+2 skrev Tony Kelman:
>>
>>> What do you propose? Github is about as simple as we can do, considering
>>> also the complexity of maintaining something from thr project side. There
>>> are plenty of people around the community who are happy to walk you through
>>> the process of making a pull request, and if it's not explained in enoug
>>> detail then we can add more instructions if it would help. What have you
>>> tried so far?
>>
>>
>

Re: [julia-users] Re: Adding publications easier

[Stefan Karpinski]

You don't need Jekyll installed to edit markdown files. You can even edit
files directly in the web and preview the rendering. Admittedly, installing
Jekyll is a pain and seems to have gotten worse over time somehow, but you
don't need to do any of that to submit a publication.

On Thu, Sep 22, 2016 at 8:08 AM, Magnus Röding 
wrote:

> I have now made a new attempt, ending up having everything installed and
> seemingly working on an Ubuntu 16.04 system. My workflow so far is:
>
> - git clone https:// to local repo (I have a github account)
> - edit julia.bib and _EDIT_ME_index.md according to instructions
> - run 'make' in publications directory
> - run 'bundle exec jekyll build' in main repo directory
> - adding the modified files by 'git add *'
>
> So, off-topic question as far as Julia goes, but what to do now? I realize
> I'm supposed to commit, annotate, request-pull, and go nuts, but in which
> order?
>
> Thanks in advance, not my cup of tea this, so if anyone can help tx :-)
>
> Den tisdag 20 september 2016 kl. 21:14:21 UTC+2 skrev Tony Kelman:
>
>> What do you propose? Github is about as simple as we can do, considering
>> also the complexity of maintaining something from thr project side. There
>> are plenty of people around the community who are happy to walk you through
>> the process of making a pull request, and if it's not explained in enoug
>> detail then we can add more instructions if it would help. What have you
>> tried so far?
>
>

Re: [julia-users] Re: ANN: A potential new Discourse-based Julia forum

[Stefan Karpinski]

I got the go ahead from Jeff and Viral to give this a try, then it didn't
end up panning out. It would still be worth a try, imo.

On Sat, Sep 17, 2016 at 11:55 AM, mmh  wrote:

> Hi Jonathan,
>
> Seems like this has kind of burnt out. Is there still an impetus on a
> transition.
>
> On Saturday, September 19, 2015 at 8:16:36 PM UTC-4, Jonathan Malmaud
> wrote:
>
>> Hi all,
>> There's been some chatter about maybe switching to a new, more modern
>> forum platform for Julia that could potentially subsume julia-users,
>> julia-dev, julia-stats, julia-gpu, and julia-jobs.   I created
>> http://julia.malmaud.com for us to try one out and see if we like it.
>> Please check it out and leave feedback. All the old posts from julia-users
>> have already been imported to it.
>>
>> It is using Discourse , the same forum
>> software used for the forums of Rust ,
>> BoingBoing, and some other big sites. Benefits over Google Groups include
>> better support for topic tagging, community moderation features,  Markdown
>> (and hence syntax highlighting) in messages, inline previews of linked-to
>> Github issues, better mobile support, and more options for controlling when
>> and what you get emailed. The Discourse website
>>  does a better job of summarizing the
>> advantages than I could.
>>
>> To get things started, MIke Innes suggested having a topic on what we
>> plan on working on this coming wee
>> k.
>> I think that's a great idea.
>>
>> Just to be clear, this isn't "official" in any sense - it's just to
>> kickstart the discussion.
>>
>> -Jon
>>
>>
>>

Re: [julia-users] Horn clauses

[Stefan Karpinski]

You might try LilKanren.jl .

On Mon, Sep 19, 2016 at 10:21 AM, Kevin Liu  wrote:

> Hello. What would be the long-term solution for using Horn clauses in
> Julia? Is the present solution to call Prolog from C and C from Julia?
> Thanks
>

Re: [julia-users] Re: tail active log

[Stefan Karpinski]

You'd want something more like this:

open(last_sim_log) do fh
while !eof(fh)
print(readline(fh))
end
end


This does a couple of things:

   1. Use the open(...) do fh ... end construct to ensure file closing.
   2. Check for stream end using eof(fh) instead of catching an error.


On Fri, Sep 16, 2016 at 5:06 AM, <adrian_le...@hushmail.com> wrote:

> Thanks for the replies,
>
> For some reason only one chunk of data is printed even though the log is
> still being written to
>
>   fh = open(last_sim_log)
>   try
> while true
>   print(readline(fh))
> end
>   finally
> close(fh)
>   end
>
> For readavailable(fh), I getting "no method matching
> readavailable(::IOStream)"
>
> Many Thanks
>
> Aidy
>
> On 9/15/2016 at 4:24 PM, "Stefan Karpinski" <ste...@karpinski.org> wrote:
> >
> >If you don't mind blocking when a complete line isn't available,
> >you can
> >just call readline(io) repeatedly.
> >
> >On Thu, Sep 15, 2016 at 7:57 AM, Steven G. Johnson
> ><stevenj@gmail.com>
> >wrote:
> >
> >>
> >>
> >> On Thursday, September 15, 2016 at 7:11:55 AM UTC-4, Adrian
> >Lewis wrote:
> >>>
> >>> I have an active log and I wondered how I could `tail -f` this
> >without
> >>> running the Unix command?
> >>
> >>
> >> Open the file and repeatedly call `readavailable`
> >>
>
>

Re: [julia-users] Advice on programs with large data types

[Stefan Karpinski]

You can also have const bindings to global mutable state without any
performance impact. Passing around a state object is probably better style
though.

On Thu, Sep 15, 2016 at 2:35 PM, Mauro  wrote:

> The first style is fine as objects are passed by reference, i.e. there
> are not copies made.
>
> On Thu, 2016-09-15 at 20:15, Nathan Smith wrote:
> > Hi
> >
> > I'm looking for some advice for some on writing methods on large
> (memory-wise)
> > data types. Is there an overhead difference in the following two methods?
> >
> > type State
> >  hugearray1::Array{Float64, 2}
> >  hugearray2::Array{Float64, 2}
> >  ... # Many more components
> > end
> >
> > function style1!(s::State)
> >   complicated_function(s.hugearray1)
> > end
> >
> > function style2!(arr::Array{Float64, 2})
> >   complicated_function(arr)
> > end
> >
> > # difference in calls:
> >
> > s = State(arr1, arr2, ...)
> > style1!(s)  # Pretty but is it slower?
> > style2!(s.hugearray1)# Ugly but is it faster?
> >
> >
> > Basically, is there an overhead in throwing the whole state datatype
> into a
> > function even if i only manipulate one or two of the potentially large
> amount
> > of components or should I be making functions in the second style where
> > arguments are exactly of the type of the components being manipulated.
> >
> > Thanks!
> > Nathan
> >
> > ps: sorry for the double post, I hit enter before I finished writing..
>

Re: [julia-users] Re: tail active log

[Stefan Karpinski]

If you don't mind blocking when a complete line isn't available, you can
just call readline(io) repeatedly.

On Thu, Sep 15, 2016 at 7:57 AM, Steven G. Johnson 
wrote:

>
>
> On Thursday, September 15, 2016 at 7:11:55 AM UTC-4, Adrian Lewis wrote:
>>
>> I have an active log and I wondered how I could `tail -f` this without
>> running the Unix command?
>
>
> Open the file and repeatedly call `readavailable`
>

Re: [julia-users] Re: Curious parsing behavior

[Stefan Karpinski]

It's a really appealing idea.

On Wed, Sep 14, 2016 at 1:01 PM, Erik Schnetter  wrote:

> There was a talk at JuliaCon suggesting that parsing ambiguities are often
> best resolved by throwing an error: "Fortress: Features and Lessons
> Learned".
>
> -erik
>
> On Wed, Sep 14, 2016 at 12:01 PM, David P. Sanders 
> wrote:
>
>>
>>
>> El miércoles, 14 de septiembre de 2016, 11:12:52 (UTC-4), David Gleich
>> escribió:
>>>
>>> Ahah! That explains it.
>>>
>>> Is there a better way to create floating point literals that avoid this?
>>>
>>
>> I think using 1782.0 instead of 1782. (without the 0) will solve this?
>> I seem to remember there was an issue to deprecate the style without the
>> 0.
>>
>>
>>>
>>> David
>>>
>>> On Wednesday, September 14, 2016 at 9:26:42 AM UTC-4, Steven G. Johnson
>>> wrote:



 On Wednesday, September 14, 2016 at 9:18:11 AM UTC-4, David Gleich
 wrote:
>
> Can anyone give me a quick explanation for why these statements seem
> to parse differently?
>
> julia> 1782.^12. + 1841.^12.
>

 .^ and .+ are (elementwise/broadcasting) operators in Julia, and there
 is a parsing ambiguity here because it is not clear whether the . goes with
 the operator or the number.

 See also the discussion at

  https://github.com/JuliaLang/julia/issues/15731
  https://github.com/JuliaLang/julia/pull/11529

 for possible ways that this might be made less surprising in the future.

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

Re: [julia-users] ls()?

[Stefan Karpinski]

There's already shell mode:

;cd projects
;ls


in the REPL.

On Wed, Sep 14, 2016 at 12:56 PM, <adrian_le...@hushmail.com> wrote:

> > There are POSIX standards for new programming language function names?
>
> No, but you've implemented functions with POSIX names
>
> > yes, ls() could be a better name
>
> In the REPL, I might
>
> julia> cd("projects")
>
> And want to
>
> julia> ls()
>
> to see what's there
>
> But, I probably wouldn't want to do that in Julia file
>
> rd = readdir(pwd())  # ls() doesn't make sense here
>
> So, maybe alias them?
>
> Aidy
>
> On 9/14/2016 at 5:41 PM, "Stefan Karpinski" <ste...@karpinski.org> wrote:
> >
> >There are POSIX standards for new programming language function
> >names? But
> >yes, ls() could be a better name.
> >
> >On Wed, Sep 14, 2016 at 12:04 PM, Adrian Lewis
> ><adrian_le...@hushmail.com>
> >wrote:
> >
> >> > You can find a thread/issue where this is discussed. Some
> >group decided
> >> to call it readdir() and like it more. I just got used to it. I
> >think it's
> >> silly, but it's just syntax.
> >>
> >> I thought it might be an idea to stick with POSIX standards.
> >>
> >> On Wednesday, September 14, 2016 at 4:40:03 PM UTC+1, Chris
> >Rackauckas
> >> wrote:
> >>>
> >>>
> >>>
> >>> On Wednesday, September 14, 2016 at 7:36:18 AM UTC-7, Jacob
> >Quinn wrote:
> >>>>
> >>>> readdir()
> >>>>
> >>>> On Wed, Sep 14, 2016 at 8:34 AM, Adrian Lewis
> ><adrian...@hushmail.com>
> >>>> wrote:
> >>>>
> >>>>> In the filesystem package, if we have pwd() and cd(), why do
> >we not
> >>>>> have ls()?
> >>>>>
> >>>>> Aidy
> >>>>>
> >>>>
> >>>>
>
>

Re: [julia-users] ls()?

[Stefan Karpinski]

There are POSIX standards for new programming language function names? But
yes, ls() could be a better name.

On Wed, Sep 14, 2016 at 12:04 PM, Adrian Lewis 
wrote:

> > You can find a thread/issue where this is discussed. Some group decided
> to call it readdir() and like it more. I just got used to it. I think it's
> silly, but it's just syntax.
>
> I thought it might be an idea to stick with POSIX standards.
>
> On Wednesday, September 14, 2016 at 4:40:03 PM UTC+1, Chris Rackauckas
> wrote:
>>
>>
>>
>> On Wednesday, September 14, 2016 at 7:36:18 AM UTC-7, Jacob Quinn wrote:
>>>
>>> readdir()
>>>
>>> On Wed, Sep 14, 2016 at 8:34 AM, Adrian Lewis 
>>> wrote:
>>>
 In the filesystem package, if we have pwd() and cd(), why do we not
 have ls()?

 Aidy

>>>
>>>

Re: [julia-users] Re: Julia Users and First Customers

[Stefan Karpinski]

 use right now as those other languages, 
> non-software-development-oriented
> users will quickly encounter these simple problems and it may leave a bad
> taste in their mouths.
>
> "I tried Julia but I couldn't get Juno to install"
> "Did you set the julia path either as an environment variable or inside
> the julia-client package?"
> "No, I don't know what the julia path is. Anyways, let me know when it
> actually has an 'auto-install' since I want to be able to use an IDE, but
> have it simple to setup"
>
> That's too common right now. People think a "developed" language means a
> 1-click installed IDE to a language where they can use the same script a
> year from now without any errors or warnings, and right now that's not
> offered. Don't get me wrong, I love Julia and use it for everything now
> because it is high quality, not buggy, and works well. But I would not say
> it's not alpha.
>
> I too would like to hear the core devs weigh in. I presented my side, but
> am willing to toe the party line if there is one.
>
> On Tuesday, September 13, 2016 at 9:39:09 AM UTC-7, David Anthoff wrote:
>>
>> I find this characterization of julia as “not released” and “alpha”
>> really not helpful. To the casual reader these terms signal low quality and
>> lots of bugs, and in my experience (after 2.5 years of heavy use) those are
>> the last two things that come to mind with respect to julia. On the
>> contrary, I think the quality of the julia builds at this point can easily
>> compete with things like Python or R (in terms of bugs).
>>
>>
>>
>> I think the correct characterization of the pre-1.0 builds is that julia
>> hasn’t reached a stable API, i.e. you need to be willing to live with
>> breaking changes coming your way. That is a VERY different thing than a
>> buggy alpha release!
>>
>>
>>
>> There is a large group of julia users out there that use julia for “real
>> world” work. It is really not helpful for us if julia gets an undeserved
>> reputation of being a pre-release, buggy thing that shouldn’t be used for
>> “real work”. Such a reputation would question the validity of our results,
>> whereas a reputation as “hasn’t reached a stable API” is completely
>> harmless.
>>
>>
>>
>> Also, keep in mind that there is julia computing out there, which is
>> feeding the core dev group. They have customers that pay them (I hope) for
>> supported versions of julia, so it seems highly misleading to characterize
>> julia as not released and not ready for production. Heck, you can buy a
>> support contract for the current released version, so in my mind that seems
>> very much released!
>>
>>
>>
>> I think it would be a good idea if the core julia group would actually
>> put a definitive statement out on the website for this topic. There are a
>> couple of devs that at least from the outside seem close to the core group
>> that have made statements like the one below, that to any sloppy reader
>> will just sound like “stay away from julia if you don’t want a bug riddled
>> system”, and I think that really doesn’t square with the message that e.g.
>> julia computing needs to put out there or with the state of the language. I
>> think a good official position would be: “Current julia releases are of
>> high quality and are ready to be used for ‘real world’ work. Pre-1.0
>> releases will introduce breaking API changes between 0.x versions, which
>> might require extra work on the users part when updating to new julia
>> versions.” Or something like that.
>>
>>
>>
>> Cheers,
>>
>> David
>>
>>
>>
>> --
>>
>> David Anthoff
>>
>> University of California, Berkeley
>>
>>
>>
>> http://www.david-anthoff.com
>>
>>
>>
>>
>>
>> *From:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On
>> Behalf Of *Chris Rackauckas
>> *Sent:* Tuesday, September 13, 2016 9:05 AM
>> *To:* julia-users <julia...@googlegroups.com>
>> *Subject:* [julia-users] Re: Julia Users and First Customers
>>
>>
>>
>> 1. Jeff Bezanson and Stefan Karpinski. I kid (though that's true). It's
>> the group of MIT students who made it. You can track the early issues
>> and kind of see who's involved.
>> <https://github.com/JuliaLang/julia/issues?page=348=is%3Aissue+is%3Aclosed>
>>  Very
>> early on that's probably a good indicator of who's joining in when, but
>> that only makes sense for very early Julia when using means also
>> c

Re: [julia-users] Julia Users and First Customers

[Stefan Karpinski]

On Tue, Sep 13, 2016 at 10:21 AM, Adeel Malik 
wrote:

> I would Like to ask few questions about Julia that I could not find it on
> the internet.
>
> 1) Who were the very first few users of Julia ?
>

Julia was developed by Jeff Bezanson, Viral Shah and myself, funded (in
part) by Alan Edelman; and Alan was the first user, unless you consider the
three initial developers to be users. He also had an MIT class use Julia
for numerical stuff before Julia 1.0, and they were probably the next round
of early users after Alan. Jameson Nash was one of those students, so at
least one of them liked it :)

2) Who were the industrial customers of Julia when it was first released?
> Who are those industrial customers now?
>

Intel, BlackRock, the FAA (ACAS X), Conning, Invenia, Voxel8 and a number
of other companies have publicly talked about using Julia and have
sponsored JuliaCons. There are many others too but some are not public and
its nearly impossible to track this. Julia just broke into the top 50
programming languages on the Tiobe Index
 – there
are a lot of users these days.

3) How Julia found more users?
>

Word of mouth, talks at conferences, and sites like Hacker News and Reddit,
and the occasional article in magazines like Wired.

4) How Julia survived against Python and R at first release?
>

The initial selling point is that it's much faster. But people come for the
speed and stay for the features and productivity (and speed). Or they don't
– some people get frustrated by the less mature ecosystem and go back to
using what they were before, but those people are far outnumbered by the
people who keep on using Julia, or the user base wouldn't be growing so
fast.

Re: [julia-users] hashing floating point zeroes

[Stefan Karpinski]

It has been discussed that hashing -0.0 and 0.0 the same, but this has an
unfortunate interaction with sorting. See #9381
 and #18485
, which I just opened.

On Tue, Sep 13, 2016 at 10:41 AM, Steven G. Johnson 
wrote:

>
>
> On Tuesday, September 13, 2016 at 10:07:49 AM UTC-4, Fengyang Wang wrote:
>>
>> This is an intuitive explanation, but the mathematics of IEEE floating
>> points seem to be designed so that 0.0 represents a "really small positive
>> number" and -0.0 represents "exact zero" or at least "an even smaller
>> really small negative number"; hence -0.0 + 0.0 = 0.0. I never understood
>> this either.
>>
>
> For one thing, the signed zero preserves 1/(1/x) == x, even when x is +Inf
> or -Inf, since 1/-Inf is -0.0 and 1/-0.0 is -Inf.   More generally, when
> there is underflow (numbers get so small they can no longer be
> represented), you lose the value but you don't lose the sign.   Also, the
> sign of zero is useful in evaluating complex-valued functions that have a
> branch cut along the real axis, so that you know which side of the branch
> you are on (see the classic paper Much Ado About Nothing's SIgn Bit
>  by Kahan).
>

Re: [julia-users] Re: Re: 1st try julia, 2/3 speed of python/c++

[Stefan Karpinski]

Great. It seems like there's some low hanging fruit to speed it up even
more :)

On Tue, Sep 13, 2016 at 2:35 PM, Neal Becker <ndbeck...@gmail.com> wrote:

> Stefan Karpinski wrote:
>
> > On Tue, Sep 13, 2016 at 1:23 PM, Neal Becker
> > <ndbeck...@gmail.com> wrote:
> >
> >>
> >> Thanks for the ideas.  Here, though, the generated values need to be
> >> Uniform([0...2^N]), where N could be any number.  For example [0...2^3].
> >> So the output array itself would be Array{Int64} for example, but the
> >> values
> >> in the array are [0 ... 7].  Do you know a better way to do this?
> >
> >
> > Is this the kind of thing you're looking for?
> >
> > julia> @time rand(0x0:0x7, 10^5);
> >   0.001795 seconds (10 allocations: 97.953 KB)
> >
> >
> > Produces a 10^5-element array of random UInt8 values between 0 and 7.
>
> Yes, that is the sort of thing I want!  I guess the type of the returned
> array is determined by the type of the argument passed.
>
> BTW, after the first fix to my PnGen, the time for the julia code is about
> equal to the python/c++ code.  Not bad I suppose for a 1st try, although
> this code is pretty trivial.
>
>
>

Re: [julia-users] Re: Julia Low Pass Filter much slower than identical code in Python ??

[Stefan Karpinski]

As an aside, most JIT runtimes actually don't compile code until after it
has been run a few thousand times and seems hot – before that they
interpret it. Julia is unusual in that it fully JIT compiles almost all
code (except for some top-level expressions which are interpreted) before
running it at all. That's technically what JIT originally meant, but not
what most systems do since they often *need* profile information from
execution in order to compile the code, whereas Julia can infer this
information in advance.

On Tue, Sep 13, 2016 at 3:09 AM, Matjaz Licer <matjaz.li...@gmail.com>
wrote:

> Makes sense, thanks :-)
>
> On 12 September 2016 at 17:17, Stefan Karpinski <ste...@karpinski.org>
> wrote:
>
>> JIT = Just In Time, i.e. the first time you use the code.
>>
>> On Mon, Sep 12, 2016 at 6:52 AM, MLicer <matjaz.li...@gmail.com> wrote:
>>
>>> Indeed it does! I thought JIT compilation takes place prior to execution
>>> of the script. Thanks so much, this makes sense now!
>>>
>>> Output:
>>> first call:   0.804573 seconds (1.18 M allocations: 53.183 MB, 1.43% gc
>>> time)
>>> repeated call:  0.000472 seconds (217 allocations: 402.938 KB)
>>>
>>> Thanks again,
>>>
>>> Cheers!
>>>
>>>
>>> On Monday, September 12, 2016 at 12:48:30 PM UTC+2, randm...@gmail.com
>>> wrote:
>>>>
>>>> The Julia code takes 0.000535 seconds for me on the second run --
>>>> during the first run, Julia has to compile the method you're timing. Have a
>>>> look at the performance tips
>>>> <http://docs.julialang.org/en/latest/manual/performance-tips/#measure-performance-with-time-and-pay-attention-to-memory-allocation>
>>>> for a more in depth explanation.
>>>>
>>>> Am Montag, 12. September 2016 11:53:01 UTC+2 schrieb MLicer:
>>>>>
>>>>> Dear all,
>>>>>
>>>>> i've written a low-pass filter in Julia and Python and the code in
>>>>> Julia seems to be much slower (*0.800 sec in Julia vs 0.000 sec in
>>>>> Python*). I *must* be coding ineffieciently, can anyone comment on
>>>>> the two codes below?
>>>>>
>>>>> *Julia:*
>>>>>
>>>>>
>>>>> <https://lh3.googleusercontent.com/-pEyZjPDcmP8/V9Z6hJdXKfI/KLc/iiefpFSzY88S333QndnbnnAnKUBQvzTkACLcB/s1600/filter_julia.png>
>>>>> using PyPlot, DSP
>>>>>
>>>>> # generate data:
>>>>> x = linspace(0,30,1e4)
>>>>> sin_noise(arr) = sin(arr) + rand(length(arr))
>>>>>
>>>>> # create filter:
>>>>> designmethod = Butterworth(5)
>>>>> ff = digitalfilter(Lowpass(0.02),designmethod)
>>>>> @time yl = filtfilt(ff, sin_noise(x))
>>>>>
>>>>> Python:
>>>>>
>>>>> from scipy import signal
>>>>> import numpy as np
>>>>> import cProfile, pstats
>>>>>
>>>>> def sin_noise(arr):
>>>>> return np.sin(arr) + np.random.rand(len(arr))
>>>>>
>>>>> def filterSignal(b,a,x):
>>>>> return signal.filtfilt(b, a, x, axis=-1)
>>>>>
>>>>> def main():
>>>>> # generate data:
>>>>> x = np.linspace(0,30,1e4)
>>>>> y = sin_noise(x)
>>>>> b, a = signal.butter(5, 0.02, "lowpass", analog=False)
>>>>> ff = filterSignal(b,a,y)
>>>>>
>>>>> cProfile.runctx('filterSignal(b,a,y)',globals(),{'b':b,'a':a,'y':y
>>>>> },filename='profileStatistics')
>>>>>
>>>>> p = pstats.Stats('profileStatistics')
>>>>> printFirstN = 5
>>>>> p.sort_stats('cumtime').print_stats(printFirstN)
>>>>>
>>>>> if __name__=="__main__":
>>>>> main()
>>>>>
>>>>>
>>>>> Thanks very much for any replies!
>>>>>
>>>>
>>
>

Re: [julia-users] Re: 1st try julia, 2/3 speed of python/c++

[Stefan Karpinski]

On Tue, Sep 13, 2016 at 1:23 PM, Neal Becker  wrote:

>
> Thanks for the ideas.  Here, though, the generated values need to be
> Uniform([0...2^N]), where N could be any number.  For example [0...2^3].
> So the output array itself would be Array{Int64} for example, but the
> values
> in the array are [0 ... 7].  Do you know a better way to do this?


Is this the kind of thing you're looking for?

julia> @time rand(0x0:0x7, 10^5);
  0.001795 seconds (10 allocations: 97.953 KB)


Produces a 10^5-element array of random UInt8 values between 0 and 7.

Re: [julia-users] code design question – best ideomatic way to define nested types?

[Stefan Karpinski]

The biggest practical issue is that if you can subtype a concrete type then
you can't store values inline in an array, even if the values are immutable
– since a subtype can be bigger than the supertype. This leads to having
things like "final" classes, etc. Fundamentally, this is really an issue of
failing to separate the concrete type – which is complete and can be
instantiated – from the abstract type, which is incomplete and can be
subtyped.

On Mon, Sep 12, 2016 at 3:17 PM, Chris Rackauckas <rackd...@gmail.com>
wrote:

> https://en.wikipedia.org/wiki/Composition_over_inheritance
>
> http://programmers.stackexchange.com/questions/134097/why-should-i-prefer-
> composition-over-inheritance
>
> https://www.thoughtworks.com/insights/blog/composition-vs-
> inheritance-how-choose
>
> That's just the start. Overtime, people realized inheritance can be quite
> fragile, so many style guidelines simply forbid you from doing it.
>
> On Monday, September 12, 2016 at 11:45:40 AM UTC-7, Bart Janssens wrote:
>>
>> Looking at this example, it seems mighty tempting to have the ability to
>> subtype a concrete type. Are the exact problems with that documented
>> somewhere? I am aware of the following section in the docs:
>>
>> "One particularly distinctive feature of Julia’s type system is that
>> concrete types may not subtype each other: all concrete types are final and
>> may only have abstract types as their supertypes. While this might at first
>> seem unduly restrictive, it has many beneficial consequences with
>> surprisingly few drawbacks. It turns out that being able to inherit
>> behavior is much more important than being able to inherit structure, and
>> inheriting both causes significant difficulties in traditional
>> object-oriented languages."
>>
>> I'm just wondering what the "significant difficulties" are, not
>> advocating changing this behaviour.
>>
>> On Mon, Sep 12, 2016 at 5:28 PM Stefan Karpinski <ste...@karpinski.org>
>> wrote:
>>
>>> I would probably go with approach #2 myself and only refer to the .bar
>>> and .baz fields in all of the generic AbstractFoo methods.
>>>
>>> On Mon, Sep 12, 2016 at 10:10 AM, Michael Borregaard <
>>> mkborr...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I am defining a set of types to hold scientific data, and trying to get
>>>> the best out of Julia's type system. The types in my example are 'nested'
>>>> in the sense that each type will hold progressively more information and
>>>> thus allow the user to do progressively more. Like this:
>>>>
>>>> type Foo
>>>>   bar
>>>>   baz
>>>> end
>>>>
>>>> type Foobar
>>>>   bar  # this
>>>>   baz  # and this are identical with Foo
>>>>   barbaz
>>>>   bazbaz
>>>> end
>>>>
>>>>
>>>

Re: [julia-users] code design question – best ideomatic way to define nested types?

[Stefan Karpinski]

I would probably go with approach #2 myself and only refer to the .bar and
.baz fields in all of the generic AbstractFoo methods.

On Mon, Sep 12, 2016 at 10:10 AM, Michael Borregaard  wrote:

> Hi,
>
> I am defining a set of types to hold scientific data, and trying to get
> the best out of Julia's type system. The types in my example are 'nested'
> in the sense that each type will hold progressively more information and
> thus allow the user to do progressively more. Like this:
>
> type Foo
>   bar
>   baz
> end
>
> type Foobar
>   bar  # this
>   baz  # and this are identical with Foo
>   barbaz
>   bazbaz
> end
>
>
> Thus, you can do anything with a Foobar object that you can with a Foo
> object, but not the other way around. The real example is much more
> complex, of course, with levels of nestedness and more fields of complex
> types.
> There are several ways I could design this:
>
>1. I could make all objects be of type Foobar, but make the barbaz and
>bazbaz fields Nullable. I don't think that is ideal, as I would like to use
>dispatch to do things with object Foobar that I cannot do with Foo, instead
>of constantly checking for isnull on specific fields.
>2. I could keep the above design, then define an abstract type
>AbstractFoo and make both Foo and Foobar inherit from this. Then
>AbstractFoo can be used to define functions for everything that can be done
>with the fields that are in Foo objects. The downside is that the types
>become really big and clunky, and especially that my constructors become
>big and tricky to write.
>3. I could use composition to let Foobar contain a Foo object. But
>then I will have to manually dispatch every method defined for Foo to the
>Foo field of Foobar objects.To make it clear what I mean, here are the
>three designs:
>
> # Example 1:
>
> type Foobar{T<:Any}
>   bar
>   baz
>   barbaz::Nullable{T}
>   bazbaz::Nullable{T}
> end
>
>
> # Example 2:
>
> abstract AbstractFoo
>
>
> type Foo <: AbstractFoo
>   bar
>   baz
> end
>
> type Foobar <: AbstractFoo
>   bar
>   baz
>   barbaz
>   bazbaz
> end
>
>
> # Example 3:
>
> type Foo
>   bar
>   baz
> end
>
> type Foobar
>   foo::Foo
>   barbaz
>   bazbaz
> end
>
> I do realize that the easy answer to this is "this depends on your use
> case, there are pros and cons for each method". However, I believe there
> must be a general ideomatic solution, as this issue arises from the design
> of the type system: because you cannot inherit from concrete types in
> Julia, and abstract types (which you can inherit from) cannot have fields.
> In C++, where you can inherit from concrete types, this would have an
> ideomatic solution as:
>
>
> class Foo{
>   protected:
> int bar, baz;
> };
>
> class Foobar: public Foo{
>   int barbaz, bazbaz;
> };
>
>
> I have been struggling for days with different redesigns of my code and I
> really cannot wrap my head around it. I appreciate the help!
>

Re: [julia-users] Julia for Data Science book recently released

[Stefan Karpinski]

Great! You'll probably want to make a PR to add this book here:
http://julialang.org/learning/ (repo here:
https://github.com/JuliaLang/julialang.github.com)

On Mon, Sep 12, 2016 at 7:57 AM, Steve Hoberman 
wrote:

> *Julia for Data Science* by Zacharias Voulgaris, PhD, will show you how
> to use the Julia language to solve business critical data science
> challenges. After covering the importance of Julia to the data science
> community and several essential data science principles, we start with the
> basics including how to install Julia and its powerful libraries. Many
> examples are provided as we illustrate how to leverage each Julia command,
> dataset, and function. Learn more about the book and where to obtain a copy
> here: https://technicspub.com/analytics/.
>

Re: [julia-users] Re: 1st try julia, 2/3 speed of python/c++

[Stefan Karpinski]

All of the globals setup in bench1 are non-const, which means the top-level
benchmarking code is pretty slow, but if N is small, this won't matter
much. If N is large, it's worth either wrapping the setup in a function
body or making all these variables const.

On Mon, Sep 12, 2016 at 8:37 AM, Neal Becker  wrote:

> Steven G. Johnson wrote:
>
> >
> >
> >
> > On Monday, September 12, 2016 at 7:59:33 AM UTC-4, DNF wrote:
> >>
> >> function(p::pnseq)(n,T=Int64)
> >>
> >>>
> > Note that the real problem with this function declaration is that the
> type
> > T is known only at runtime, not at compile-time. It would be better
> to
> > do
> >
> >  function (p::pnseq){T}(n, ::Type{T}=Int64)
>
> Thanks!  This change made a big difference. Now PnSeq is only using a small
> amount of time, as I expected it should.  I prefer this syntax to the
> alternative you suggest below as it seems more logical to me.
>
> >
> > since making the type a parameter like this exposes it as a compile-time
> > constant.  Although it would be even more natural to not have to pass the
> > type explicitly at all, but rather to get it from the type of n, e.g.
> >
> >
> >  function (p::pnseq){T<:Integer}(n::T)
> >
> > I have no idea whether this particular thing is performance-critical,
> > however.   I also see lots and lots of functions that allocate arrays, as
> > opposed to scalar functions that are composed and called on a single
> > array, which makes me think that you are thinking in terms of numpy-style
> > vectorized code, which doesn't take full advantage of Julia.
>
>
> >
> > It would be much easier to give pereformance tips if you could boil it
> > down to a single self-contained function that you want to make faster,
> > rather than requiring us to read through four or five different
> submodules
> > and
> > lots of little one-line functions and types.  (There's nothing wrong with
> > having lots of functions and types in Julia, it is just that this forces
> > us to comprehend a lot more code in order to make useful suggestions.)
>
> Nyquist and CoefFromFunc are normally only used at startup, so they are
> unimportant to optimize.
>
> The real work is PnSeq, Constellation, and the FIRFilters (which I didn't
> write - they are in DSP.jl).  I agree that the style is to operate on and
> return a large vector.
>
> I guess what you're suggesting is that PnSeq should return a single scalar,
> Constellation should map scalar->scalar.  But FIRFilter I think needs to be
> a vector->vector, so I will take advantage of simd?
>
>

Re: [julia-users] Re: Julia Low Pass Filter much slower than identical code in Python ??

[Stefan Karpinski]

JIT = Just In Time, i.e. the first time you use the code.

On Mon, Sep 12, 2016 at 6:52 AM, MLicer  wrote:

> Indeed it does! I thought JIT compilation takes place prior to execution
> of the script. Thanks so much, this makes sense now!
>
> Output:
> first call:   0.804573 seconds (1.18 M allocations: 53.183 MB, 1.43% gc
> time)
> repeated call:  0.000472 seconds (217 allocations: 402.938 KB)
>
> Thanks again,
>
> Cheers!
>
>
> On Monday, September 12, 2016 at 12:48:30 PM UTC+2, randm...@gmail.com
> wrote:
>>
>> The Julia code takes 0.000535 seconds for me on the second run -- during
>> the first run, Julia has to compile the method you're timing. Have a look
>> at the performance tips
>> 
>> for a more in depth explanation.
>>
>> Am Montag, 12. September 2016 11:53:01 UTC+2 schrieb MLicer:
>>>
>>> Dear all,
>>>
>>> i've written a low-pass filter in Julia and Python and the code in Julia
>>> seems to be much slower (*0.800 sec in Julia vs 0.000 sec in Python*).
>>> I *must* be coding ineffieciently, can anyone comment on the two codes
>>> below?
>>>
>>> *Julia:*
>>>
>>>
>>> 
>>> using PyPlot, DSP
>>>
>>> # generate data:
>>> x = linspace(0,30,1e4)
>>> sin_noise(arr) = sin(arr) + rand(length(arr))
>>>
>>> # create filter:
>>> designmethod = Butterworth(5)
>>> ff = digitalfilter(Lowpass(0.02),designmethod)
>>> @time yl = filtfilt(ff, sin_noise(x))
>>>
>>> Python:
>>>
>>> from scipy import signal
>>> import numpy as np
>>> import cProfile, pstats
>>>
>>> def sin_noise(arr):
>>> return np.sin(arr) + np.random.rand(len(arr))
>>>
>>> def filterSignal(b,a,x):
>>> return signal.filtfilt(b, a, x, axis=-1)
>>>
>>> def main():
>>> # generate data:
>>> x = np.linspace(0,30,1e4)
>>> y = sin_noise(x)
>>> b, a = signal.butter(5, 0.02, "lowpass", analog=False)
>>> ff = filterSignal(b,a,y)
>>>
>>> cProfile.runctx('filterSignal(b,a,y)',globals(),{'b':b,'a':a,'y':y},
>>> filename='profileStatistics')
>>>
>>> p = pstats.Stats('profileStatistics')
>>> printFirstN = 5
>>> p.sort_stats('cumtime').print_stats(printFirstN)
>>>
>>> if __name__=="__main__":
>>> main()
>>>
>>>
>>> Thanks very much for any replies!
>>>
>>

Re: [julia-users] Julia on Research Computing Podcast RCE

[Stefan Karpinski]

We've started a conversation with Brock to make sure that happens :)

On Mon, Sep 12, 2016 at 5:03 AM, Mauro  wrote:

> RCE is a excellent podcast, would be cool the hear some core-devs
> talking there.
>
> On Sun, 2016-09-11 at 02:29, Brock Palen  wrote:
> > I am one half of the HPC/Research Computing podcast
> http://www.rce-cast.com/
> >
> > We would like to feature Julia on the show.  This takes a developer or
> two
> > and is a friendly interview, takes about an hour over the phone or skype
> > and aims to educate our community.
> >
> > Feel free to contact me off list.
> >
> > Thank you !
> >
> > Brock Palen
>

Re: [julia-users] Re: Preferred MIME type for Julia

[Stefan Karpinski]

+1 for "text/julia" – let's start a rebellion :)

On Sat, Sep 10, 2016 at 9:02 PM, Steven G. Johnson 
wrote:

> Maybe.
>
> But the more I read about this the less consistent IANA seems to be on
> this issue, and the more inclined I am to say that one should just use
> text/julia
>

Re: [julia-users] How do I call run()?!

[Stefan Karpinski]

Use backticks:

run(`echo Hello`)

On Sat, Sep 10, 2016 at 12:42 PM, Dennis Eckmeier  wrote:

> Hi,
>
> I am trying to run an executable on Windows 10. I can run it from DOS
> command line and I double checked the current working path in Julia is the
> one that includes the bh_tsne.exe.
>
> *run('bh_tsne')* *> syntax: invalid character literal*
>
> All sources I find call run() with this syntax o.O
>
> Julia version 0.4.6
>
> D.
>
> *Why, yes, good Sir, I am, in fact, a noob.*
>

Re: [julia-users] odd stuff with`reverse` involving unsigned unit range

[Stefan Karpinski]

Could you open an issue if you haven't already?

On Sun, Aug 28, 2016 at 2:41 PM, Lutfullah Tomak 
wrote:

> julia> reverse(0:UInt(2))
>
> ERROR: InexactError()
>  in reverse at ./range.jl:674
>
>
> julia> reverse(0:1:UInt(2))
> 0x0002:0x:0x0001
>
>
> julia> length(reverse(0:1:UInt(2)))
> 0x
>
>
> julia> length(0:1:UInt(2))
> 0x0003
>
> I know it cannot be worked within unsigned numbers but at least it should
> return correct range with signed int.
> There are many functions that accept Integer as argument type then one may
> not work if a range reversed based on
> this argument.
>

Re: [julia-users] local "_" declared twice

[Stefan Karpinski]

If you could post clarification here:
https://github.com/JuliaLang/julia/issues/18251.

On Fri, Aug 26, 2016 at 4:35 PM, Christoph Ortner <
christophortn...@gmail.com> wrote:

> I am only confused because
>
> for (t, _, _) in zip(x, y, z)
>
> is fine while
>
> maximum( t for (t,_,_) in zip(x,y,z) )
>
> is not.
>

Re: [julia-users] local "_" declared twice

[Stefan Karpinski]

It's intentional, but maybe using `_` twice should be allowed?

On Thu, Aug 25, 2016 at 6:07 PM, Christoph Ortner <
christophortn...@gmail.com> wrote:

> Is this intended behaviour or a bug?
>
> julia> maximum( t for (t,_,_) in zip(x,y,z) )
> ERROR: syntax: local "_" declared twice
>
>
> julia> x = rand(3); y = rand(3); z = rand(3);
>
>
> julia> for (t, _, _) in zip(x, y, z)
>   println(t)
>   end
> 0.5059694701992228
> 0.6291609082858327
> 0.298657434448903
>
>
> julia> maximum( t for (t,_,_) in zip(x,y,z) )
> ERROR: syntax: local "_" declared twice
>
>
>
>
>

Re: [julia-users] Invalid history file (~/.julia_history) format

[Stefan Karpinski]

On Thu, Aug 25, 2016 at 10:20 AM, Kristoffer Carlsson  wrote:

> I already made a PR for it. Sorry for stealing it.


No worries. There's always more work to do :)

Re: [julia-users] Invalid history file (~/.julia_history) format

[Stefan Karpinski]

I opened an issue to include the path of the .julia_history file in this
error: https://github.com/JuliaLang/julia/issues/18223. If anyone is
looking for a pretty easy way to get started contributing to Julia (make a
PR, get feedback, etc.) this is a nice easy intro issue :)

On Thu, Aug 25, 2016 at 8:58 AM, Tony Kelman <t...@kelman.net> wrote:

> Looks like this is resolved now, but just for completeness, what are
> ENV["HOMEDRIVE"] and ENV["HOMEPATH"] on your system?
>
>
> On Thursday, August 25, 2016 at 4:17:59 AM UTC-7, Andy Dobson wrote:
>>
>> Ah - no - I've got it!  Now it works!  Thank you all very much,
>> especially Kristoffer!
>>
>>
>>
>> On Thursday, August 25, 2016 at 12:13:09 PM UTC+1, Andy Dobson wrote:
>>>
>>> It doesn't seem to. I've tried searching for %.julia_history% to get at
>>> hidden files - is there some other trick to find it?
>>>
>>>
>>>
>>> On Thursday, August 25, 2016 at 11:56:22 AM UTC+1, Kristoffer Carlsson
>>> wrote:
>>>>
>>>> Does that file exist? If so, removing it should fix your problems.
>>>>
>>>> On Thursday, August 25, 2016 at 12:54:31 PM UTC+2, Andy Dobson wrote:
>>>>>
>>>>> It says:
>>>>>
>>>>> "M:\\.julia_history"
>>>>>
>>>>> (This is not where the program files are written/held - they are on
>>>>> the C-drive, and all outputs are written to a separate networked drive).
>>>>>
>>>>> On Wednesday, August 24, 2016 at 6:05:27 PM UTC+1, Kristoffer Carlsson
>>>>> wrote:
>>>>>>
>>>>>> What does it say when you run
>>>>>>
>>>>>> Base.REPL.find_hist_file()
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wednesday, August 24, 2016 at 6:31:58 PM UTC+2, Andy Dobson wrote:
>>>>>>>
>>>>>>> I've uninstalled everything again, and I *think* I've deleted all
>>>>>>> julia-related files, but when I re-install Julia I still get the same 
>>>>>>> error
>>>>>>> message.
>>>>>>>
>>>>>>>
>>>>>>> On Wednesday, August 24, 2016 at 1:12:25 PM UTC+1, Kristoffer
>>>>>>> Carlsson wrote:
>>>>>>>>
>>>>>>>> It is likely "~/.juliarc" that is the file you are after.
>>>>>>>>
>>>>>>>> On Wednesday, August 24, 2016 at 11:47:16 AM UTC+2, Andy Dobson
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Kristoffer,
>>>>>>>>>
>>>>>>>>> I don't know if this is the right file
>>>>>>>>> (/julia-0.4.6/etc/julia/juliarc), but this is what it says:
>>>>>>>>>
>>>>>>>>> # This file should contain site-specific commands to be executed
>>>>>>>>> on Julia startup
>>>>>>>>> # Users should store their own personal commands in homedir(), in
>>>>>>>>> a file named .juliarc.jl
>>>>>>>>>
>>>>>>>>> # Set up environment for Julia Windows binary distribution
>>>>>>>>> ENV["PATH"] = JULIA_HOME*";"*joinpath(JULIA_
>>>>>>>>> HOME,"..","Git","bin")*";"*ENV["PATH"]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Should there be more here?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wednesday, August 24, 2016 at 10:36:10 AM UTC+1, Kristoffer
>>>>>>>>> Carlsson wrote:
>>>>>>>>>>
>>>>>>>>>> Maybe you can look into the .juliarc file at the line where it is
>>>>>>>>>> telling you the error is and see if anything looks strange.
>>>>>>>>>>
>>>>>>>>>> On Wednesday, August 24, 2016 at 11:11:54 AM UTC+2, Andy Dobson
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> No, it didn't create another one. I think you're right and I
>>>>>>>>>>> didn't delete what Julia was looking for. But it seems very

Re: [julia-users] Re: Tab completion for sub-modules names

[Stefan Karpinski]

That's right. This has nothing to do with Fruit being a submodule and
everything about it being a binding in Food that's not exported and
therefore not part of Food's externally facing interface.

On Thu, Aug 25, 2016 at 3:03 AM, Yichao Yu  wrote:

>
>
> On Thu, Aug 25, 2016 at 2:50 PM, Tony Kelman  wrote:
>
>> What version of Julia are you on? My memory might be hazy but there's a
>> chance this has been implemented recently on master? If not, then this does
>> sound like it would be useful to implement.
>>
>
> I believe imported and unexported symbols are intentionally not included
> in the auto completion.
>
>
>>
>>
>>
>> On Wednesday, August 24, 2016 at 4:49:50 PM UTC-7, Miguel Goncalves wrote:
>>>
>>> In the Julia REPL if I have a super-module Food which loads in a
>>> sub-module Fruit,
>>>
>>> module Food
>>>
>>> using Fruit
>>>
>>> include("nutrition.jl")
>>> export carbohydrate
>>> export fat
>>> export protein
>>>
>>> end
>>>
>>> then pressing tab after typing,
>>>
>>> Food.
>>>
>>> I get the list,
>>>
>>> carbohydratefatprotein
>>>
>>> But the sub-module Fruit does not show up for tab completion. However,
>>> after manually typing,
>>>
>>> Food.Fruit.
>>>
>>> I do have tab completion for everything which is exported by the Fruit
>>> sub-module.
>>>
>>> Could this behavior be changed to support tab completion for sub-modules
>>> names? This will facilitate working with nested modules.
>>>
>>
>

Re: [julia-users] Proposed solution for writing Enums

[Stefan Karpinski]

They're still fairly informal:

   - https://github.com/JuliaLang/julia/issues/12139
   - https://github.com/JuliaLang/julia/issues/14052
   - https://github.com/JuliaLang/julia/issues/16878
   - https://github.com/JuliaLang/julia/issues/17115

Basically an extended issue proposing a design to solve a particular
problem.

On Wed, Aug 24, 2016 at 9:06 AM, Brian Rogoff <brog...@gmail.com> wrote:

> What's an example of a good Julep? I did some searching and couldn't find
> much. Is there a document somewhere about
> writing and submitting Julia Enhancement Proposals?
>
> On Tuesday, August 23, 2016 at 11:09:25 AM UTC-7, Stefan Karpinski wrote:
>>
>> On Tue, Aug 23, 2016 at 12:39 PM, Brian Rogoff <bro...@gmail.com> wrote:
>>
>>> It's a bit surprising that Julia doesn't have built in enums and a
>>> case/switch form. I'm glad that there's open
>>> issue https://github.com/JuliaLang/julia/issues/5410
>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FJuliaLang%2Fjulia%2Fissues%2F5410=D=1=AFQjCNGQ278eIdJcTAsQPvyraltYcTf1bg>
>>> to address the lack of case/switch. Is there any hope that
>>> we may see these (or at least the built in case/switch) in 1.0?
>>>
>>
>> It's certainly possible. The best way to make it happen is to write a
>> good Julep for how case/switch should behave and once there's general
>> agreement on the plan, make a PR to implement it.
>>
>

Re: [julia-users] Proposed solution for writing Enums

[Stefan Karpinski]

On Tue, Aug 23, 2016 at 12:39 PM, Brian Rogoff  wrote:

> It's a bit surprising that Julia doesn't have built in enums and a
> case/switch form. I'm glad that there's open
> issue https://github.com/JuliaLang/julia/issues/5410 to address the lack
> of case/switch. Is there any hope that
> we may see these (or at least the built in case/switch) in 1.0?
>

It's certainly possible. The best way to make it happen is to write a good
Julep for how case/switch should behave and once there's general agreement
on the plan, make a PR to implement it.

Re: [julia-users] Proposed way of doing Enums

[Stefan Karpinski]

The current behavior was chosen because it allows you to put the enum in a
module or not. I agree that it's often nice to do so. One issue is that the
module name and the enum name "want" to be the same, which doesn't work
well, so you'd need to provide both an inner enum name and an outer module
name.

On Tue, Aug 23, 2016 at 8:50 AM, Paul Sorensen  wrote:

> The following code is my idea for doing enums in julia, I tried pasting
> the code but google groups breaks it:
> http://pastebin.com/Vxw0KdmC
> Let me know what you think. Is it a good idea?
>
>
> 
>
>

Re: [julia-users] Proposed solution for writing Enums

[Stefan Karpinski]

Oh, I see that you have:
https://groups.google.com/forum/#!topic/julia-users/fgzVlbGcw-o.

On Tue, Aug 23, 2016 at 8:55 AM, Stefan Karpinski <ste...@karpinski.org>
wrote:

> The formatting on that came out pretty garbled. Can you repost with line
> breaks and such?
>
> On Mon, Aug 22, 2016 at 5:03 PM, Paul Sorensen <aed...@gmail.com> wrote:
>
>> The following is my idea of writing enums that are better than the macro
>> because they give you a  typesafe way of passing them to a
>> functionbaremodule EnumNameimmutable enumnamex::UInt8end
>> const Value_A = enumname(0)const Value_B = enumname(1)end# usage
>> examplebaremodule Colorimmutable colorx::UInt8endconst
>> Red = color(1)const Green = color(2)const Blue = color(3)const
>> White = color(4)const Black = color(5)endfunction
>> testColor(c::Color.color)println("A color was
>> passed")endtestColor(Color.Red)
>>
>
>

Re: [julia-users] Proposed solution for writing Enums

[Stefan Karpinski]

The formatting on that came out pretty garbled. Can you repost with line
breaks and such?

On Mon, Aug 22, 2016 at 5:03 PM, Paul Sorensen  wrote:

> The following is my idea of writing enums that are better than the macro
> because they give you a  typesafe way of passing them to a
> functionbaremodule EnumNameimmutable enumnamex::UInt8end
> const Value_A = enumname(0)const Value_B = enumname(1)end# usage
> examplebaremodule Colorimmutable colorx::UInt8endconst
> Red = color(1)const Green = color(2)const Blue = color(3)const
> White = color(4)const Black = color(5)endfunction
> testColor(c::Color.color)println("A color was
> passed")endtestColor(Color.Red)
>

Re: [julia-users] Re: Unexpected slowdown

[Stefan Karpinski]

You might want to check if a*a > n instead since multiplication is much
cheaper than sqrt.

On Mon, Aug 22, 2016 at 5:22 PM, Taylor Pospisil  wrote:

> It's memory allocation.  If you don't make the whole array and just break
> out of the loop early you can get it about 50x faster on my machine.  Also
> I took the liberty of fixing a bug; you should check for <= sqrt(n).
>
> function a()
> pl = [2]
> n = 3
> ct = 1
> while ct < 10001
> isnprime = true
> for a in pl
> if n % a == 0
> isnprime = false
> break
> end
> if a > sqrt(n)
> break
> end
> end
> if isnprime
> push!(pl,n)
> ct += 1
> end
> n += 2
> end
> return pl
> end
>
>
>
> On Monday, August 22, 2016 at 4:58:30 PM UTC-4, Achu wrote:
>
>> I have a simple piece of code that finds me 10001 prime numbers.
>>
>> function a()
>> pl=[2]
>> n=3
>> ct=1
>> while(ct<10001)
>> isnprime=true
>> for a in pl
>> if n%a==0
>> isnprime=false
>> break
>> end
>> end
>> if isnprime
>> push!(pl,n)
>> ct+=1
>> end
>> n+=2
>> end
>> return pl
>> end
>>
>> When I tweaked the code to check only prime factors less than the sqrt of
>> the number, it slowed it down by a factor of 3.
>>
>> function a()
>> pl=[2]
>> n=3
>> ct=1
>> while(ct<10001)
>> isnprime=true
>> for a in pl[pl.> if n%a==0
>> isnprime=false
>> break
>> end
>> end
>> if isnprime
>> push!(pl,n)
>> ct+=1
>> end
>> n+=2
>> end
>> return pl
>> end
>>
>> Why is that?
>>
>>

Re: [julia-users] Invalid history file (~/.julia_history) format

[Stefan Karpinski]

The notion of what HOME is on Windows is a bit confusing and ambiguous.

On Tue, Aug 23, 2016 at 8:51 AM, Stefan Karpinski <ste...@karpinski.org>
wrote:

> That's strange. Did it create a ~/.julia_history file after you deleted
> the old one? If so, what's in it?
>
> I wonder if the ~/.julia_history file you deleted was not the one that
> Julia's looking at.
>
>
> On Tue, Aug 23, 2016 at 8:10 AM, Andy Dobson <a_d_m_dob...@hotmail.com>
> wrote:
>
>> Hi All,
>>
>> This morning when starting Julia 0.4.3 (which I've been using daily since
>> February) I received this error message :
>> -
>> ERROR: Invalid history file (~/.julia_history) format:
>> If you have a history file left over from an older version of Julia,
>> try renaming or deleting it.
>> Invalid character: '#' at line 465034
>>  in error at error.jl:22
>> -
>>
>> A thread on this site ("PSA: new ~/.julia_history format") suggested deleting
>> the julia_history file. I tried this, and it did not work. Next I
>> uninstalled Julia and re-installed the latest (0.4.6) version. The error
>> message is the same.
>>
>> Can anybody suggest a solution? I'm running on Windows 7 Enterprise.
>>
>> Thanks
>>
>> Andy
>>
>>
>

Re: [julia-users] Invalid history file (~/.julia_history) format

[Stefan Karpinski]

That's strange. Did it create a ~/.julia_history file after you deleted the
old one? If so, what's in it?

I wonder if the ~/.julia_history file you deleted was not the one that
Julia's looking at.

On Tue, Aug 23, 2016 at 8:10 AM, Andy Dobson 
wrote:

> Hi All,
>
> This morning when starting Julia 0.4.3 (which I've been using daily since
> February) I received this error message :
> -
> ERROR: Invalid history file (~/.julia_history) format:
> If you have a history file left over from an older version of Julia,
> try renaming or deleting it.
> Invalid character: '#' at line 465034
>  in error at error.jl:22
> -
>
> A thread on this site ("PSA: new ~/.julia_history format") suggested deleting
> the julia_history file. I tried this, and it did not work. Next I
> uninstalled Julia and re-installed the latest (0.4.6) version. The error
> message is the same.
>
> Can anybody suggest a solution? I'm running on Windows 7 Enterprise.
>
> Thanks
>
> Andy
>
>

Re: [julia-users] Re: Why aren't multiple const definitions allowed on a line?

[Stefan Karpinski]

These syntaxes should be more uniform:
https://github.com/JuliaLang/julia/issues/18197.

On Tue, Aug 23, 2016 at 12:59 AM, 'Greg Plowman' via julia-users <
julia-users@googlegroups.com> wrote:

> global const u = 7, v = 11, w = 13
> seems to work.
>
>

Re: [julia-users] Re: binary searched sets/maps & faster symbols

[Stefan Karpinski]

Also, please don't use phrases like "got your panties in a knot" – this is
a violation of the Julia community standards
<http://julialang.org/community/standards/>.

On Sun, Aug 21, 2016 at 3:55 PM, Stefan Karpinski <ste...@karpinski.org>
wrote:

> Steven is correct here: licenses are what allow people to use your code,
> not a mechanism for constraining what people can do – by default they have
> no rights to your code. If you want to let people do whatever they want
> with your code, use the MIT license <https://opensource.org/licenses/MIT>
> or the even more permissive ISC license
> <https://opensource.org/licenses/ISC>. You can also state that you
> release the code into the public domain, but that's actually less effective
> than granting a license like ISC since not all countries have processes for
> reliably donating works to the public domain (e.g. continental Europe), so
> people in those countries would not legally be allowed to use your code.
>
> TL;DR: just put the ISC license on it.
>
> On Sun, Aug 21, 2016 at 1:25 PM, Steven G. Johnson <stevenj@gmail.com>
> wrote:
>
>>
>>
>> On Sunday, August 21, 2016 at 12:11:26 PM UTC-4, fnc...@gmail.com wrote:
>>>
>>> I gave a statement, on why I don't offer licenses.
>>>
>>
>> Not offering a license means that no one can copy, modify, or
>> redistribute your code.
>>
>> Saying "Go bananas; use it, break it; embrace and extend it", while it
>> gives some permissions, is actually not sufficient to qualify as open
>> source <https://opensource.org/osd-annotated>.  For example, you don't
>> explicitly give permission for people to sell it as part of commercial
>> products, so as a result that usage is prohibited (by default).
>>
>> It took many years for people in scientific computing to realize that
>> licenses were important for example (and as a result the Netlib repository
>> ended up having huge headaches), and there are other prominent examples of
>> problems stemming from software without a license because the authors
>> didn't think they needed one (e.g. qmail).   Learn from the bitter
>> experiences of others!
>>
>>
>>
>

Re: [julia-users] Re: binary searched sets/maps & faster symbols

[Stefan Karpinski]

Steven is correct here: licenses are what allow people to use your code,
not a mechanism for constraining what people can do – by default they have
no rights to your code. If you want to let people do whatever they want
with your code, use the MIT license 
or the even more permissive ISC license
. You can also state that you release
the code into the public domain, but that's actually less effective than
granting a license like ISC since not all countries have processes for
reliably donating works to the public domain (e.g. continental Europe), so
people in those countries would not legally be allowed to use your code.

TL;DR: just put the ISC license on it.

On Sun, Aug 21, 2016 at 1:25 PM, Steven G. Johnson 
wrote:

>
>
> On Sunday, August 21, 2016 at 12:11:26 PM UTC-4, fnc...@gmail.com wrote:
>>
>> I gave a statement, on why I don't offer licenses.
>>
>
> Not offering a license means that no one can copy, modify, or redistribute
> your code.
>
> Saying "Go bananas; use it, break it; embrace and extend it", while it
> gives some permissions, is actually not sufficient to qualify as open
> source .  For example, you don't
> explicitly give permission for people to sell it as part of commercial
> products, so as a result that usage is prohibited (by default).
>
> It took many years for people in scientific computing to realize that
> licenses were important for example (and as a result the Netlib repository
> ended up having huge headaches), and there are other prominent examples of
> problems stemming from software without a license because the authors
> didn't think they needed one (e.g. qmail).   Learn from the bitter
> experiences of others!
>
>
>

Re: [julia-users] Re: Composition of setindex!

[Stefan Karpinski]

Or write `a[(1:3)[1:2]] = 1` instead.

I'm also very unclear on what's going on in R since R does not return a
view object. Moreover, we have this:

> a <- c(0,0,0,0,0)

> a[1:3][1:2] <- 1

> a
[1] 1 1 0 0 0


Yet we also have this:

> a <- c(0,0,0,0,0)

> b <- a[1:3]

> b[1:2] <- 1

> a
[1] 0 0 0 0 0


Huh? So apparently the `a[1:3]` part of `a[1:3][1:2]` cannot be considered
a proper subexpression. In other words, `a[1:3]` here does not do what
`a[1:3]` by itself does – it is inextricably connected to the following
`[1:2]` in some fashion. This interpretation seems to be supported by the
fact that attempting to parenthesize this part is an error:

> a <- c(0,0,0,0,0)

> (a[1:3])[1:2] <- 1
Error in (a[1:3])[1:2] <- 1 : could not find function "(<-"


Can any R expert explain this behavior?

On Sun, Aug 21, 2016 at 4:43 AM, 'Greg Plowman' via julia-users <
julia-users@googlegroups.com> wrote:

> But also note that a[1:3] = 1.0 will modify a (rather than a copy)
>
> On Sunday, August 21, 2016 at 6:34:28 PM UTC+10, Kristoffer Carlsson wrote:
>>
>> Range indexing produces copies yes. Either just write the loops or use
>> "view" or "sub" to refer to the original memory.
>
>

Re: [julia-users] ANN: Documenter.jl 0.3

[Stefan Karpinski]

On Fri, Aug 19, 2016 at 5:07 PM, Morten Piibeleht <
morten.piibel...@gmail.com> wrote:

> [*] Developed as part of Morten’s Google Summer of Code project
> 
> .
>
Since I think that page is private, here's the description of the project:


> *Documentation tools for Julia*



A big part of Julia is its package ecosystem and their documentation should
> be as thorough as possible and documenting packages should be made as easy
> as possible for package developers.
>


The primary goal of the project is to extend Documenter.jl so that it could
> also generate a detailed reference manual of functions, types, submodules
> etc. with full signatures and a search capability. The idea is to
> complement the docstring, since sometimes you need this detailed
> information and it should be easily accessible (reading the code or using
> introspection methods is cumbersome).
>


A secondary goal is to lay the groundwork for a comments/notes system,
> where the community could more easily contribute to the docs (of both Base
> and packages).


It's a great project and the progress you guys have made is lovely to see :)

Re: [julia-users] Re: lower triangular matrix in julia

[Stefan Karpinski]

x-ref:
http://stackoverflow.com/questions/39039553/lower-triangular-matrix-in-julia-julia

On Fri, Aug 19, 2016 at 10:29 AM, Michael Krabbe Borregaard <
mkborrega...@gmail.com> wrote:

> A symmetric matrix and a lower triangular matrix are different things.
> Look for what you want here: http://julia.readthedocs.io/
> en/latest/manual/linear-algebra/ and here: http://julia.readthedocs.io/
> en/latest/stdlib/linalg/
>
> On Fri, Aug 19, 2016 at 4:07 PM, Ahmed Mazari 
> wrote:
>
>> 4×4 Array{Int64,2}:
>>  0  1  2  3
>>  1  0  4  5
>>  2  4  0  6
>>  3  5  6  0
>>
>> a symetric matrix m[i,j] =m[j,i]  and m[i,i]= 0
>>
>> On Fri, Aug 19, 2016 at 3:59 PM, Jeffrey Sarnoff <
>> jeffrey.sarn...@gmail.com> wrote:
>>
>>> Is this what you want, or are you looking for a more general way to
>>> construct nxn matrices like this 4x4 matrix, or something else?
>>>
>>> julia> m = [ [0,1,2,3] [1,0,4,5] [2,3,0,6] [4,5,6,0] ]
>>> 4×4 Array{Int64,2}:
>>>  0  1  2  4
>>>  1  0  3  5
>>>  2  4  0  6
>>>  3  5  6  0
>>>
>>>
>>> On Friday, August 19, 2016 at 9:01:06 AM UTC-4, Ahmed Mazari wrote:

 Yes but it doesn't allow me to set the diagonal to 0 ??

 On Fri, Aug 19, 2016 at 2:55 PM, Michael Borregaard <
 mkborr...@gmail.com> wrote:

> You can build the matrix as normal, then specify that the upper
> triangle is undefined by
> mat = LowerTriangular(mat) # where mat is a Matrix of any eltype.
>


>>
>