[julia-users] Re: Google Summer of Code: Your Project Suggestions

[Robert Gates]

I second the need for PetSc :) I think GLPlot's pretty good at 3D plotting 
btw.

On Friday, January 23, 2015 at 8:21:27 AM UTC+1, anonymousnoobie wrote:
>
> ability to rotate and manipulate 3D plots would be nice
>
> On Tuesday, January 20, 2015 at 8:38:42 AM UTC-8, cormu...@mac.com wrote:
>>
>> JuliaGraphics ,  Geometry2D 
>> , etc. would be attractive to 
>> graphics-oriented programmers...
>>
>

[julia-users] Re: Google Summer of Code: Your Project Suggestions

[anonymousnoobie]

ability to rotate and manipulate 3D plots would be nice

On Tuesday, January 20, 2015 at 8:38:42 AM UTC-8, cormu...@mac.com wrote:
>
> JuliaGraphics ,  Geometry2D 
> , etc. would be attractive to 
> graphics-oriented programmers...
>

Re: [julia-users] Re: Google Summer of Code: Your Project Suggestions

[Viral Shah]

Thanks to Amit's recent work on MPI.jl and ClusterManager.jl, we now have 
the ability to run MPI libraries and Julia's parallel libraries in the same 
program. Until recently, one could only have one of them, but not both 
simultaneously. 

I think this is important for the development of parallel libraries in 
Julia, where we can use existing MPI libraries where they exist and write 
new ones as needed. PetSc is huge - but we can start chipping away at it 
now.

-viral

On Tuesday, January 20, 2015 at 5:18:29 AM UTC+5:30, Eka Palamadai wrote:
>
> Chris,
>
> Just wanted to check about the progress you made about integrating PetSc 
> in Julia.
> Could you pls let me know the status of this project?
>
> Thanks,
> Eka
>
>
>
> On Thursday, February 20, 2014 at 8:54:33 PM UTC-5, Christopher Fusting 
> wrote:
>>
>> Great.  I'm going to start poking around PETSc.  Any guidance you have is 
>> welcome :)
>>
>> _Chris
>>
>> On Wednesday, February 19, 2014 7:01:51 PM UTC-5, Jiahao Chen wrote:
>>>
>>> If no one else volunteers, it's quite likely that that responsibility 
>>> will devolve to me. There's certainly plenty of work to do to improve 
>>> the base numerical library, so any interest there is much welcomed. 
>>>
>>> Thanks, 
>>>
>>> Jiahao Chen, PhD 
>>> Staff Research Scientist 
>>> MIT Computer Science and Artificial Intelligence Laboratory 
>>>
>>>
>>> On Wed, Feb 19, 2014 at 4:48 PM, Christopher Fusting  
>>> wrote: 
>>> > I may be interested in filling the student role of a project under 
>>> > scalability of big data applications, specifically PETSc integration 
>>> and 
>>> > solvers for numerical linear alegbra.  Has anyone expressed interest 
>>> in 
>>> > mentoring these projects?  I've been developing software for years but 
>>> have 
>>> > recently returned to school to study mathematics.  Could be lots of 
>>> fun :) 
>>>
>>

[julia-users] Re: Google Summer of Code: Your Project Suggestions

[cormullion]

JuliaGraphics ,  Geometry2D 
, etc. would be attractive to 
graphics-oriented programmers...

[julia-users] Re: Google Summer of Code: Your Project Suggestions

[Gabriel Mitchell]

It would be wonderful to see someone tackle some of the outstanding issues 
in Gadfly that revolving around aesthetic (I use the term in the colloquial 
sense here) functionality. For example, things like implementing dashed and 
dotted lines, accessible extension to Geom.point to get different markers, 
figuring out colors for Geom.contours, finer control over ordering of 
layers, something for getting latex on the various backends. OK, so perhaps 
this is just a bunch of aesthetic related issues piled together, but I 
imagine that someone with a vision could find a way to sell such an effort 
as a package?

On Sunday, February 16, 2014 at 7:50:06 PM UTC+1, Mike Innes wrote:
>
> We've published a project ideas list for GSoC here:
>
> http://julialang.org/gsoc/2014/
>
> We'd like our ideas page to be as healthy and diverse as possible, so 
> please do make your suggestions. Projects can include things like new 
> packages, specific language/package features, or something more 
> experimental; really, there's scope for any kind of coding project here, 
> but those which fit roughly three months of work and have a clear, tangible 
> benefit are best.
>
> If you maintain or use a package which is missing key features, now would 
> be a great time to ask for them!
>
> You're welcome to add project descriptions via github, but if you want to 
> suggest something more informally you can do so here - I'll continue to 
> write up as many as I can.
>
> Thanks,
> Mike
>
>

Re: [julia-users] Re: Google Summer of Code: Your Project Suggestions

[Eka Palamadai]

Chris,

Just wanted to check about the progress you made about integrating PetSc in 
Julia.
Could you pls let me know the status of this project?

Thanks,
Eka



On Thursday, February 20, 2014 at 8:54:33 PM UTC-5, Christopher Fusting 
wrote:
>
> Great.  I'm going to start poking around PETSc.  Any guidance you have is 
> welcome :)
>
> _Chris
>
> On Wednesday, February 19, 2014 7:01:51 PM UTC-5, Jiahao Chen wrote:
>>
>> If no one else volunteers, it's quite likely that that responsibility 
>> will devolve to me. There's certainly plenty of work to do to improve 
>> the base numerical library, so any interest there is much welcomed. 
>>
>> Thanks, 
>>
>> Jiahao Chen, PhD 
>> Staff Research Scientist 
>> MIT Computer Science and Artificial Intelligence Laboratory 
>>
>>
>> On Wed, Feb 19, 2014 at 4:48 PM, Christopher Fusting  
>> wrote: 
>> > I may be interested in filling the student role of a project under 
>> > scalability of big data applications, specifically PETSc integration 
>> and 
>> > solvers for numerical linear alegbra.  Has anyone expressed interest in 
>> > mentoring these projects?  I've been developing software for years but 
>> have 
>> > recently returned to school to study mathematics.  Could be lots of fun 
>> :) 
>>
>

Re: [julia-users] Re: Google Summer of Code: Your Project Suggestions

[Douglas Bates]

I don't think it has come up in this discussion that Steve Johnson has a 
start on a PETSc interface for Julia at https://github.com/stevengj/PETSc.jl

On Thursday, February 20, 2014 7:54:33 PM UTC-6, Christopher Fusting wrote:
>
> Great.  I'm going to start poking around PETSc.  Any guidance you have is 
> welcome :)
>
> _Chris
>
> On Wednesday, February 19, 2014 7:01:51 PM UTC-5, Jiahao Chen wrote:
>>
>> If no one else volunteers, it's quite likely that that responsibility 
>> will devolve to me. There's certainly plenty of work to do to improve 
>> the base numerical library, so any interest there is much welcomed. 
>>
>> Thanks, 
>>
>> Jiahao Chen, PhD 
>> Staff Research Scientist 
>> MIT Computer Science and Artificial Intelligence Laboratory 
>>
>>
>> On Wed, Feb 19, 2014 at 4:48 PM, Christopher Fusting  
>> wrote: 
>> > I may be interested in filling the student role of a project under 
>> > scalability of big data applications, specifically PETSc integration 
>> and 
>> > solvers for numerical linear alegbra.  Has anyone expressed interest in 
>> > mentoring these projects?  I've been developing software for years but 
>> have 
>> > recently returned to school to study mathematics.  Could be lots of fun 
>> :) 
>>
>

Re: [julia-users] Re: Google Summer of Code: Your Project Suggestions

[Christopher Fusting]

Great.  I'm going to start poking around PETSc.  Any guidance you have is 
welcome :)

_Chris

On Wednesday, February 19, 2014 7:01:51 PM UTC-5, Jiahao Chen wrote:
>
> If no one else volunteers, it's quite likely that that responsibility 
> will devolve to me. There's certainly plenty of work to do to improve 
> the base numerical library, so any interest there is much welcomed. 
>
> Thanks, 
>
> Jiahao Chen, PhD 
> Staff Research Scientist 
> MIT Computer Science and Artificial Intelligence Laboratory 
>
>
> On Wed, Feb 19, 2014 at 4:48 PM, Christopher Fusting 
> > 
> wrote: 
> > I may be interested in filling the student role of a project under 
> > scalability of big data applications, specifically PETSc integration and 
> > solvers for numerical linear alegbra.  Has anyone expressed interest in 
> > mentoring these projects?  I've been developing software for years but 
> have 
> > recently returned to school to study mathematics.  Could be lots of fun 
> :) 
>

Re: [julia-users] Re: Google Summer of Code: Your Project Suggestions

[Jiahao Chen]

If no one else volunteers, it's quite likely that that responsibility
will devolve to me. There's certainly plenty of work to do to improve
the base numerical library, so any interest there is much welcomed.

Thanks,

Jiahao Chen, PhD
Staff Research Scientist
MIT Computer Science and Artificial Intelligence Laboratory


On Wed, Feb 19, 2014 at 4:48 PM, Christopher Fusting  wrote:
> I may be interested in filling the student role of a project under
> scalability of big data applications, specifically PETSc integration and
> solvers for numerical linear alegbra.  Has anyone expressed interest in
> mentoring these projects?  I've been developing software for years but have
> recently returned to school to study mathematics.  Could be lots of fun :)

[julia-users] Re: Google Summer of Code: Your Project Suggestions

[Christopher Fusting]

I may be interested in filling the student role of a project under 
scalability of big data applications, specifically PETSc integration and 
solvers for numerical linear alegbra.  Has anyone expressed interest in 
mentoring these projects?  I've been developing software for years but have 
recently returned to school to study mathematics.  Could be lots of fun :)

Cheers,

_Chris

On Sunday, February 16, 2014 1:50:06 PM UTC-5, Mike Innes wrote:
>
> We've published a project ideas list for GSoC here:
>
> http://julialang.org/gsoc/2014/
>
> We'd like our ideas page to be as healthy and diverse as possible, so 
> please do make your suggestions. Projects can include things like new 
> packages, specific language/package features, or something more 
> experimental; really, there's scope for any kind of coding project here, 
> but those which fit roughly three months of work and have a clear, tangible 
> benefit are best.
>
> If you maintain or use a package which is missing key features, now would 
> be a great time to ask for them!
>
> You're welcome to add project descriptions via github, but if you want to 
> suggest something more informally you can do so here - I'll continue to 
> write up as many as I can.
>
> Thanks,
> Mike
>
>

Re: [julia-users] Re: Google Summer of Code: Your Project Suggestions

[Jacob Quinn]

I've also been meaning to package up the Sublime-IJulia backend, which will
be a way to call Julia from Python using the IJulia kernel as the backend.

-Jacob


On Mon, Feb 17, 2014 at 3:57 PM, Stefan Karpinski <
stefan.karpin...@gmail.com> wrote:

> There is already an Rif package for R interop but I'm not sure how current
> it is. Likewise, you can already call Julia from Python but this really
> needs someone to take ownership of it and package it up as an official,
> maintained Python package.
>
> > On Feb 17, 2014, at 3:43 PM, Mike Innes  wrote:
> >
> > Ok, I've added an autoformat project to the list. Jake, thanks for your
> additions.
> >
> > Do we have any kind of support for R interop? I might have missed it,
> but if not I'll add it to the list.
> >
> > Also, I'm thinking that it would be great for gradual adoption if there
> was a good story for calling Julia from Python (and perhaps other
> languages). Might be a good project, although perhaps too difficult?
> >
>

Re: [julia-users] Re: Google Summer of Code: Your Project Suggestions

[Stefan Karpinski]

There is already an Rif package for R interop but I'm not sure how current it 
is. Likewise, you can already call Julia from Python but this really needs 
someone to take ownership of it and package it up as an official, maintained 
Python package.

> On Feb 17, 2014, at 3:43 PM, Mike Innes  wrote:
> 
> Ok, I've added an autoformat project to the list. Jake, thanks for your 
> additions.
> 
> Do we have any kind of support for R interop? I might have missed it, but if 
> not I'll add it to the list.
> 
> Also, I'm thinking that it would be great for gradual adoption if there was a 
> good story for calling Julia from Python (and perhaps other languages). Might 
> be a good project, although perhaps too difficult?
> 

Re: [julia-users] Re: Google Summer of Code: Your Project Suggestions

[Mike Innes]

Ok, I've added an autoformat project to the list. Jake, thanks for your 
additions.

Do we have any kind of support for R interop? I might have missed it, but 
if not I'll add it to the list.

Also, I'm thinking that it would be great for gradual adoption if there was 
a good story for calling Julia from Python (and perhaps other languages). 
Might be a good project, although perhaps too difficult?

Re: [julia-users] Re: Google Summer of Code: Your Project Suggestions

[Jake Bolewski]

I'm sure is such a formatting tool existed and it worked well, the 
community would get behind it.  That said, a standard formatting guide 
enforcable through community pressure would be a good first step.  I feel 
creating something like this is great use case for benevolent dictatorial 
powers. 

Jake

On Monday, February 17, 2014 11:56:39 AM UTC-5, Stefan Karpinski wrote:
>
> On Mon, Feb 17, 2014 at 11:09 AM, Job van der Zwan 
> 
> > wrote:
>
>> Developing an autoformatting tool? Like I said earlier in another 
>> discussion, I really miss gofmt when not programming in Go these days. But 
>> there's more to it than simple convenience.
>>
>> To quote Andrew Gerrand's 
>> argumentsin favour of having one 
>> standard tool for this (he was discussing gofmt):
>>
>>>
>>>- easier to *write*: never worry about minor formatting concerns 
>>>while hacking away,
>>>- easier to *read*: when all code looks the same you need not 
>>>mentally convert others' formatting style into something you can 
>>> understand. 
>>>- easier to *maintain*: mechanical changes to the source don't cause 
>>>unrelated changes to the file's formatting; diffs show only the real 
>>>changes.
>>>- *uncontroversial*: never have a debate about spacing or brace 
>>>position ever again! 
>>>
>>> Regarding that last point: when I brought up autoformatting tools last 
>> time, one argument against making one now was that there is no consensus 
>> yet on a best stye for writing Julia. However, I think this thinking is the 
>> wrong way round.
>>
>
>> Some formatting decisions are inherently arbitrary. It is more important 
>> that *a* choice is made. That's either a majority-vote or top-down 
>> decision. Making an autoformatting tool will drive these decisions, rather 
>> than wait for them to happen on their own (some time after the heat death 
>> of the universe, if other languages are any indication).
>>
>
> I'm actually quite sympathetic to this idea. I suspect that Jeff thinks 
> it's a bit of a waste of time but might be fine with using one as long as 
> he didn't have to put effort into creating it. My guess is that Viral 
> doesn't really care, and Alan is actively waging a war against spaces, so 
> he might be miffed to have them automatically inserted everywhere ;-)
>
> Also highly relevant to a language still in its infancy is that a tool 
>> like this makes certain breaking changes to the language or standard 
>> library less painful. See the GoFix tool used in the Go language before it 
>> stabilised into version 1.0:
>>
>> Gofix  is a new tool that reduces the 
>>> amount of effort it takes to update existing code. It reads a program from 
>>> a source file, looks for uses of old APIs, rewrites them to use the current 
>>> API, and writes the program back to the file. Not all API changes preserve 
>>> all the functionality of an old API, so gofix cannot always do a perfect 
>>> job. When gofix cannot rewrite a use of an old API, it prints a warning 
>>> giving the file name and line number of the use, so that a developer can 
>>> examine and rewrite the code. Gofix takes care of the easy, repetitive, 
>>> tedious changes, so that a developer can focus on the ones that truly merit 
>>> attention. Each time we make a significant API change we’ll add code to 
>>> gofix to take care of the conversion, as much as mechanically possible. 
>>> When you update to a new Go release and your code no longer builds, just 
>>> run gofix on your source directory. 
>>>
>> http://blog.golang.org/introducing-gofix
>>
>> Having a tool like that would surely help with the adoption of Julia, as 
>> it would reduce fears of code breaking all the time. Also, it would let the 
>> developers of the language make more drastic changes for a longer time, as 
>> they would not have to worry as much about breaking existing code out there.
>>
>
> This is actually less relevant to Julia than you might think. Julia's 
> syntax is pretty simple and quite stable. We've made almost no breaking 
> syntax changes since version 0.1 – I literally can't think of a single one. 
> The backwards incompatible changes have been API changes rather than syntax 
> changes. Thanks to multiple dispatch, API changes can be easily handled via 
> deprecation. On the other hand, since dynamic languages like Julia are 
> inherently hard to statically analyze, we can't handle really API changes 
> at the level of AST transformations like Go can – because you can't in 
> general statically resolve what function a call actually invokes.
>  

Re: [julia-users] Re: Google Summer of Code: Your Project Suggestions

[Job van der Zwan]

On Monday, 17 February 2014 17:56:39 UTC+1, Stefan Karpinski wrote:
>
> I'm actually quite sympathetic to this idea. I suspect that Jeff thinks 
> it's a bit of a waste of time but might be fine with using one as long as 
> he didn't have to put effort into creating it. My guess is that Viral 
> doesn't really care, and Alan is actively waging a war against spaces, so 
> he might be miffed to have them automatically inserted everywhere ;-)
>

OTOH it will automatically trim off those forgotten half-a-dozen 
spaces/tabs at the end of a line after major code refactoring, so it might 
be worth the trade-off ;-).
 

> This is actually less relevant to Julia than you might think. [reasons why]
>

Now that you mention it, what I enjoyed when reading the Julia manual was 
indeed how minimalist yet "complete" the core language felt. 

Thanks to multiple dispatch, API changes can be easily handled via 
> deprecation. 
>

Still, automated help with refactoring can't be a bad thing for any 
language, right?

On the other hand, since dynamic languages like Julia are inherently hard 
> to statically analyze, we can't handle really API changes at the level of 
> AST transformations like Go can – because you can't in general statically 
> resolve what function a call actually invokes.


Oh, right... darn it.

Off-topic, it's kind of interesting to compare Go and Julia; I like both 
languages, but they couldn't be more different in many of their design 
decisions. Yet those decisions make sense when you look at different the 
problems they are trying to solve.

Re: [julia-users] Re: Google Summer of Code: Your Project Suggestions

[Stefan Karpinski]

On Mon, Feb 17, 2014 at 11:09 AM, Job van der Zwan  wrote:

> Developing an autoformatting tool? Like I said earlier in another
> discussion, I really miss gofmt when not programming in Go these days. But
> there's more to it than simple convenience.
>
> To quote Andrew Gerrand's 
> argumentsin favour of having one 
> standard tool for this (he was discussing gofmt):
>
>>
>>- easier to *write*: never worry about minor formatting concerns
>>while hacking away,
>>- easier to *read*: when all code looks the same you need not
>>mentally convert others' formatting style into something you can 
>> understand.
>>- easier to *maintain*: mechanical changes to the source don't cause
>>unrelated changes to the file's formatting; diffs show only the real
>>changes.
>>- *uncontroversial*: never have a debate about spacing or brace
>>position ever again!
>>
>> Regarding that last point: when I brought up autoformatting tools last
> time, one argument against making one now was that there is no consensus
> yet on a best stye for writing Julia. However, I think this thinking is the
> wrong way round.
>

> Some formatting decisions are inherently arbitrary. It is more important
> that *a* choice is made. That's either a majority-vote or top-down
> decision. Making an autoformatting tool will drive these decisions, rather
> than wait for them to happen on their own (some time after the heat death
> of the universe, if other languages are any indication).
>

I'm actually quite sympathetic to this idea. I suspect that Jeff thinks
it's a bit of a waste of time but might be fine with using one as long as
he didn't have to put effort into creating it. My guess is that Viral
doesn't really care, and Alan is actively waging a war against spaces, so
he might be miffed to have them automatically inserted everywhere ;-)

Also highly relevant to a language still in its infancy is that a tool like
> this makes certain breaking changes to the language or standard library
> less painful. See the GoFix tool used in the Go language before it
> stabilised into version 1.0:
>
> Gofix  is a new tool that reduces the
>> amount of effort it takes to update existing code. It reads a program from
>> a source file, looks for uses of old APIs, rewrites them to use the current
>> API, and writes the program back to the file. Not all API changes preserve
>> all the functionality of an old API, so gofix cannot always do a perfect
>> job. When gofix cannot rewrite a use of an old API, it prints a warning
>> giving the file name and line number of the use, so that a developer can
>> examine and rewrite the code. Gofix takes care of the easy, repetitive,
>> tedious changes, so that a developer can focus on the ones that truly merit
>> attention. Each time we make a significant API change we’ll add code to
>> gofix to take care of the conversion, as much as mechanically possible.
>> When you update to a new Go release and your code no longer builds, just
>> run gofix on your source directory.
>>
> http://blog.golang.org/introducing-gofix
>
> Having a tool like that would surely help with the adoption of Julia, as
> it would reduce fears of code breaking all the time. Also, it would let the
> developers of the language make more drastic changes for a longer time, as
> they would not have to worry as much about breaking existing code out there.
>

This is actually less relevant to Julia than you might think. Julia's
syntax is pretty simple and quite stable. We've made almost no breaking
syntax changes since version 0.1 – I literally can't think of a single one.
The backwards incompatible changes have been API changes rather than syntax
changes. Thanks to multiple dispatch, API changes can be easily handled via
deprecation. On the other hand, since dynamic languages like Julia are
inherently hard to statically analyze, we can't handle really API changes
at the level of AST transformations like Go can – because you can't in
general statically resolve what function a call actually invokes.

[julia-users] Re: Google Summer of Code: Your Project Suggestions

[Job van der Zwan]

Developing an autoformatting tool? Like I said earlier in another 
discussion, I really miss gofmt when not programming in Go these days. But 
there's more to it than simple convenience.

To quote Andrew Gerrand's argumentsin 
favour of having one standard tool for this (he was discussing gofmt):

>
>- easier to *write*: never worry about minor formatting concerns while 
>hacking away,
>- easier to *read*: when all code looks the same you need not mentally 
>convert others' formatting style into something you can understand.
>- easier to *maintain*: mechanical changes to the source don't cause 
>unrelated changes to the file's formatting; diffs show only the real 
>changes.
>- *uncontroversial*: never have a debate about spacing or brace 
>position ever again!
>
> Regarding that last point: when I brought up autoformatting tools last 
time, one argument against making one now was that there is no consensus 
yet on a best stye for writing Julia. However, I think this thinking is the 
wrong way round.

Some formatting decisions are inherently arbitrary. It is more important 
that *a* choice is made. That's either a majority-vote or top-down 
decision. Making an autoformatting tool will drive these decisions, rather 
than wait for them to happen on their own (some time after the heat death 
of the universe, if other languages are any indication).

Also highly relevant to a language still in its infancy is that a tool like 
this makes certain breaking changes to the language or standard library 
less painful. See the GoFix tool used in the Go language before it 
stabilised into version 1.0:

Gofix  is a new tool that reduces the amount 
> of effort it takes to update existing code. It reads a program from a 
> source file, looks for uses of old APIs, rewrites them to use the current 
> API, and writes the program back to the file. Not all API changes preserve 
> all the functionality of an old API, so gofix cannot always do a perfect 
> job. When gofix cannot rewrite a use of an old API, it prints a warning 
> giving the file name and line number of the use, so that a developer can 
> examine and rewrite the code. Gofix takes care of the easy, repetitive, 
> tedious changes, so that a developer can focus on the ones that truly merit 
> attention. Each time we make a significant API change we’ll add code to 
> gofix to take care of the conversion, as much as mechanically possible. 
> When you update to a new Go release and your code no longer builds, just 
> run gofix on your source directory. 
>
http://blog.golang.org/introducing-gofix

Having a tool like that would surely help with the adoption of Julia, as it 
would reduce fears of code breaking all the time. Also, it would let the 
developers of the language make more drastic changes for a longer time, as 
they would not have to worry as much about breaking existing code out there.

On Sunday, 16 February 2014 19:50:06 UTC+1, Mike Innes wrote:
>
> We've published a project ideas list for GSoC here:
>
> http://julialang.org/gsoc/2014/
>
> We'd like our ideas page to be as healthy and diverse as possible, so 
> please do make your suggestions. Projects can include things like new 
> packages, specific language/package features, or something more 
> experimental; really, there's scope for any kind of coding project here, 
> but those which fit roughly three months of work and have a clear, tangible 
> benefit are best.
>
> If you maintain or use a package which is missing key features, now would 
> be a great time to ask for them!
>
> You're welcome to add project descriptions via github, but if you want to 
> suggest something more informally you can do so here - I'll continue to 
> write up as many as I can.
>
> Thanks,
> Mike
>
>

[julia-users] Re: Google Summer of Code: Your Project Suggestions

[Mike Innes]

Any time, Stefan - and I wholeheartedly agree about keeping this up 
permanently. Speaking from experience, the issue tracker can be a little 
intimidating for people who want to get involved.

I didn't mean to suggest any preference for CUDA over OpenCL, so I'll add a 
note about the latter (this isn't my most knowledgeable area). Jake, that 
does sound like an interesting project - if you get a chance, it would be 
great if you could add it to the page. I don't mind looking into it myself, 
but you'll no doubt understand it better than I do.

[julia-users] Re: Google Summer of Code: Your Project Suggestions

[Jake Bolewski]

The libraries are not as mature but OpenCL now has an open source BLAS / 
FFT library from Amd and a recently updated OpenCL version of Magma so the 
gap is closing.  All major OpenCL compilers are built on LLVM and can take 
advantage of this though SPIR compilation.  I think a great project would 
be to wrap and provide a nice interface over clMagma, or to work on a 
common GPU array interface similar to python's 
compytelibrary.

-Jake 

there's an opencl package at https://github.com/jakebolewski/OpenCL.jlg i 
am very much looking forwards to, i don't know of any reason to favour cuda 
at this point.

there's an opencl package at https://github.com/jakebolewski/OpenCL.jlbrary, 
lik

On Sunday, February 16, 2014 3:22:14 PM UTC-5, Dahua Lin wrote:I think what 
would be nice is a commI think what would be nice is a common array 
interface library, like
on arI think what would be nice is a common array interface library, like
ray interface library, like

> OpenCL is definitely more open (without vendor lock-in).
>
> However, in practice, there are several aspects that make CUDA more 
> appealing for scientific computing:
>
>- A number of mature libraries for various computation purpose: 
>cuBLAS, cuFFT, cuRand, CULA, Magma, etc. 
>- CUDA LLVM 
>
> - Dahua
>
>
> On Sunday, February 16, 2014 2:13:22 PM UTC-6, andrew cooke wrote:
>>
>>
>> is the emphasis on cuda over opencl just an oversight?  while julia + gpu 
>> is something i am very much looking forwards to, i don't know of any reason 
>> to favour cuda at this point.
>>
>> there's an opencl package at https://github.com/jakebolewski/OpenCL.jl
>>
>> andrew
>>
>>
>> On Sunday, 16 February 2014 15:50:06 UTC-3, Mike Innes wrote:
>>>
>>> We've published a project ideas list for GSoC here:
>>>
>>> http://julialang.org/gsoc/2014/
>>>
>>> We'd like our ideas page to be as healthy and diverse as possible, so 
>>> please do make your suggestions. Projects can include things like new 
>>> packages, specific language/package features, or something more 
>>> experimental; really, there's scope for any kind of coding project here, 
>>> but those which fit roughly three months of work and have a clear, tangible 
>>> benefit are best.
>>>
>>> If you maintain or use a package which is missing key features, now 
>>> would be a great time to ask for them!
>>>
>>> You're welcome to add project descriptions via github, but if you want 
>>> to suggest something more informally you can do so here - I'll continue to 
>>> write up as many as I can.
>>>
>>> Thanks,
>>> Mike
>>>
>>>

[julia-users] Re: Google Summer of Code: Your Project Suggestions

[Dahua Lin]

OpenCL is definitely more open (without vendor lock-in).

However, in practice, there are several aspects that make CUDA more 
appealing for scientific computing:

   - A number of mature libraries for various computation purpose: cuBLAS, 
   cuFFT, cuRand, CULA, Magma, etc. 
   - CUDA LLVM 

- Dahua


On Sunday, February 16, 2014 2:13:22 PM UTC-6, andrew cooke wrote:
>
>
> is the emphasis on cuda over opencl just an oversight?  while julia + gpu 
> is something i am very much looking forwards to, i don't know of any reason 
> to favour cuda at this point.
>
> there's an opencl package at https://github.com/jakebolewski/OpenCL.jl
>
> andrew
>
>
> On Sunday, 16 February 2014 15:50:06 UTC-3, Mike Innes wrote:
>>
>> We've published a project ideas list for GSoC here:
>>
>> http://julialang.org/gsoc/2014/
>>
>> We'd like our ideas page to be as healthy and diverse as possible, so 
>> please do make your suggestions. Projects can include things like new 
>> packages, specific language/package features, or something more 
>> experimental; really, there's scope for any kind of coding project here, 
>> but those which fit roughly three months of work and have a clear, tangible 
>> benefit are best.
>>
>> If you maintain or use a package which is missing key features, now would 
>> be a great time to ask for them!
>>
>> You're welcome to add project descriptions via github, but if you want to 
>> suggest something more informally you can do so here - I'll continue to 
>> write up as many as I can.
>>
>> Thanks,
>> Mike
>>
>>

[julia-users] Re: Google Summer of Code: Your Project Suggestions

[andrew cooke]

is the emphasis on cuda over opencl just an oversight?  while julia + gpu 
is something i am very much looking forwards to, i don't know of any reason 
to favour cuda at this point.

there's an opencl package at https://github.com/jakebolewski/OpenCL.jl

andrew


On Sunday, 16 February 2014 15:50:06 UTC-3, Mike Innes wrote:
>
> We've published a project ideas list for GSoC here:
>
> http://julialang.org/gsoc/2014/
>
> We'd like our ideas page to be as healthy and diverse as possible, so 
> please do make your suggestions. Projects can include things like new 
> packages, specific language/package features, or something more 
> experimental; really, there's scope for any kind of coding project here, 
> but those which fit roughly three months of work and have a clear, tangible 
> benefit are best.
>
> If you maintain or use a package which is missing key features, now would 
> be a great time to ask for them!
>
> You're welcome to add project descriptions via github, but if you want to 
> suggest something more informally you can do so here - I'll continue to 
> write up as many as I can.
>
> Thanks,
> Mike
>
>