Re: [julia-users] Re: Mathematical Computing course in Julia
Thanks Tim. That is very good news indeed!
On Saturday, April 16, 2016 at 6:57:51 PM UTC+8, Tim Holy wrote:
>
> I agree line numbers have been a persistent problem in julia. In a
> language
> that inlines as aggressively as julia, and uses macros and metaprogramming
> to
> generate code, it's not a trivial problem---in some cases you might even
> wonder what "line number" really means.
>
> Fortunately, you'll be pleased to hear that, due to some fantastic work by
> multiple people, in the current development version of julia your example
> gives the following:
>
> julia> include("/tmp/linenumbers.jl")
> ERROR: LoadError: ArgumentError: invalid type for argument a in method
> definition for foo at /tmp/linenumbers.jl:5
> in include(::ASCIIString) at ./boot.jl:234
> in include_from_node1(::ASCIIString) at ./loading.jl:417
> in eval(::Module, ::Any) at ./boot.jl:237
> while loading /tmp/linenumbers.jl, in expression starting on line 4
>
> Not only is the error message much easier to interpret, but every one of
> those
> line numbers is correct. This appears to hold generally---in recent
> julia-0.5
> builds, I have yet to notice an incorrect line number anywhere. One could
> construct examples where code is built up by expressions that
> (deliberately or
> not) get this wrong, but for any "typical" usage this appears to be fixed.
>
> Best,
> --Tim
>
> On Friday, April 15, 2016 07:01:05 PM Peter Kovesi wrote:
> > Sheehan, That's a very nice looking course but I think you are very
> brave
> > to use Julia at this stage.
> > I love the language but (at this stage of the language's development)
> the
> > error reporting is highly problematic. For example this morning I made
> a
> > classic mistake
> >
> > function foo(a::real) # Should have been: function foo(a::Real)
> > ...
> > end
> >
> > The function was defined at line 998, the error was reported at line
> 433,
> > 565 lines away! The message was
> > "ERROR: LoadError: TypeError: Tuple: in parameter, expected Type{T}, got
> > Function"
> >
> > Good luck to your students!
> >
> > Working in Julia requires a practice of defensive incremental coding in
> the
> > extreme. Every few lines of code that are added need to be tested
> before
> > carrying on. That way you know that any errors are in the few lines of
> > code that were just added and not at whatever spurious location was
> being
> > suggested.
> >
> > Let me say again I love the language. However the error reporting is a
> > source of extreme frustration to me.
> >
> > A key pathway to getting Julia more widely adopted would be for it to be
> > used for teaching purposes. However, at the moment I fear that any
> attempt
> > to do so would surely end in tears.
> >
> > Peter Kovesi
> >
> > On Friday, April 15, 2016 at 10:17:40 AM UTC+8, Sheehan Olver wrote:
> > > I'm currently lecturing the course MATH3076/3976 Mathematical
> Computing at
> > > U. Sydney in Julia, and thought that others may be interested in the
> > > resources I've provided:
> > >
> > > http://www.maths.usyd.edu.au/u/olver/teaching/MATH3976/
> > >
> > > The lecture notes and labs are all Jupyter notebooks. I've also
> included
> > > a "cheat sheet" of Julia commands used in the course
> > >
> > >
> > >
> http://nbviewer.jupyter.org/url/www.maths.usyd.edu.au/u/olver/teaching/MAT
> > > H3976/cheatsheet.ipynb
> > >
> > > The course is ongoing (it's about half through) and will continue to
> take
> > > shape, but any feedback is of course welcome!
> > >
> > >
> > > Sheehan Olver
>
>
[julia-users] Re: Mathematical Computing course in Julia
Sheehan, That's a very nice looking course but I think you are very brave
to use Julia at this stage.
I love the language but (at this stage of the language's development) the
error reporting is highly problematic. For example this morning I made a
classic mistake
function foo(a::real) # Should have been: function foo(a::Real)
...
end
The function was defined at line 998, the error was reported at line 433,
565 lines away! The message was
"ERROR: LoadError: TypeError: Tuple: in parameter, expected Type{T}, got
Function"
Good luck to your students!
Working in Julia requires a practice of defensive incremental coding in the
extreme. Every few lines of code that are added need to be tested before
carrying on. That way you know that any errors are in the few lines of
code that were just added and not at whatever spurious location was being
suggested.
Let me say again I love the language. However the error reporting is a
source of extreme frustration to me.
A key pathway to getting Julia more widely adopted would be for it to be
used for teaching purposes. However, at the moment I fear that any attempt
to do so would surely end in tears.
Peter Kovesi
On Friday, April 15, 2016 at 10:17:40 AM UTC+8, Sheehan Olver wrote:
>
>
>
> I'm currently lecturing the course MATH3076/3976 Mathematical Computing at
> U. Sydney in Julia, and thought that others may be interested in the
> resources I've provided:
>
> http://www.maths.usyd.edu.au/u/olver/teaching/MATH3976/
>
> The lecture notes and labs are all Jupyter notebooks. I've also included
> a "cheat sheet" of Julia commands used in the course
>
>
> http://nbviewer.jupyter.org/url/www.maths.usyd.edu.au/u/olver/teaching/MATH3976/cheatsheet.ipynb
>
> The course is ongoing (it's about half through) and will continue to take
> shape, but any feedback is of course welcome!
>
>
> Sheehan Olver
>
[julia-users] Re: Diverging Colormap (like RdBu) with opacity going from 1 to 0 in the middle and back to 1
I have recently added a package for generating a variety of perceptually uniform colour maps which may be of interest to you https://github.com/peterkovesi/PerceptualColourMaps.jl However I do not consider transparency Cheers Peter On Friday, February 12, 2016 at 5:48:06 PM UTC+8, Patrick Kofod Mogensen wrote: > > Is it possible to create a colormap as described in the title using > Colors.jl? I couldn't seem to find anything on Colormaps and > transparency/opacity. > > Best, > Patrick >
[julia-users] Fatal interaction between Winston and PyPlot?
I am encountering a problem whereby it seems that if Winston is imported any subsequent calls to PyPlot produce a fatal Python error and the REPL crashes > using PyPlot > plot(rand(20)) # All is OK > import Winston # lots of deprecation messages > plot(rand(20)) # crash Fatal Python error: PyEval_RestoreThread: NULL tstate Current thread 0x7fff788b9300 (most recent call first): signal (6): Abort trap: 6 __pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line) I do not want to use both Winston and PyPlot but if I load a package that happens to import Winston then any use of PyPlot is impossible Do others encounter this problem, or is this the result of some quirk in my installation? OSX 10.10.5 Julia 0.4.1 PyCall 1.2.0+ PyPlot 2.1.1 Winston 0.11.13 Anaconda Python 3.5.0-1
[julia-users] Re: Fatal interaction between Winston and PyPlot?
Thanks Tom, yes it looks like a Tk problem My matplotlib uses macosx as the backend. Winston uses the Tk package. Importing Tk will result in subsequent calls to PyPlot crashing everything. I was trying to use ImageView and PyPlot but ImageView uses Tk. I guess I will have to unpackage the data in my images and just use PyPlot (sigh)
[julia-users] Re: indexing with non Integer Reals is deprecated
Thanks Eric. Yes I appreciate that the language is highly flexible and one can do lots of things. I don't want to get hung up on using indexing with integer valued floats in particular, my concern is more philosophical For much of what I do I am wanting to solve some technical problem within an environment that involves a minimal overhead in solving the coding problem. If, as I am developing my solution, I end up writing some code that happens to use indexing with integer valued floats, or would find a meshgid() function handy, then I do not want the language to 'get in my way'.(Hands up everyone who has their own implementation of meshgrid() !) Yes I know these things are not required and are not efficient but I may find them handy and I don't want to be distracted from solving my technical problem while I attend to any finicky language issues. I want to develop my initial solution with the minimal amount of code and the minimal number of special data types. Later, when I have things solved, I can return to the code and re-engineer it for efficiency It is extremely attractive that you can engineer your Julia code to be highly efficient but I am hoping the language can develop in a way that does not compromise simplicity and convenience. Cheers Peter
[julia-users] Re: indexing with non Integer Reals is deprecated
Can I add a plea for allowing indexing with integers that are represented by a floating point type Following the principle of 'minimum surprise': If I have an integer just that happens to be represented via a floating point type I would still like to be able to use it as an integer. After all we are happy with the idea of allowing mathematical operations between integer and float types via automatic promotion of the integer. That is, we are not required to cast the integer to a float in order to multiply the two. Indexing with integer values that are represented by floats would seem an appropriate place for automatic demotion. Please do not make me write a[round(Int, 1.0)] ! As a long time Matlab user who is attempting to reform himself I confess to having some mixed feelings about Julia. Much of the time I find Julia very elegant and I find coding flows nicely but there are also times when I find Julia to be excessively finicky and a generator of too much 'surprise'. Indeed, sometimes I feel as if I might as well be coding in C. I am hoping much of this will go as I learn the language better. Still, let me say Julia is an impressive language and I greatly appreciate the work of the developers. I am looking forward to its future development. Cheers Peter
