On 2 Oct 2015 17:33, "Abe Schneider"
>
> 3. Inheriting from non-abstract classes is an important item for me (you
can see multiple posts on the github page). In terms of building larger
systems than just prototypes, this can be vital for creating some type of
organization within your code.
I am
On 2 October 2015 at 11:18, SVAKSHA wrote:
> On Fri, Oct 2, 2015 at 7:05 AM, Daniel Carrera wrote:
> > nothing but a long list of `include` instructions for every file I work
> on.
> > So I am constantly running `include("lib.jl")` in the REPL.
>
> Isnt it
On Fri, Oct 2, 2015 at 7:05 AM, Daniel Carrera wrote:
> nothing but a long list of `include` instructions for every file I work on.
> So I am constantly running `include("lib.jl")` in the REPL.
Isnt it possible to achieve the same result with a .juliarc file for
each repo -
I didn't know about Autoreload.jl; thanks for the tip. I currently do
something similar using `include()`. I have a file called `lib.jl` that is
nothing but a long list of `include` instructions for every file I work on.
So I am constantly running `include("lib.jl")` in the REPL.
Do you have any
On Fri, Oct 2, 2015 at 1:29 PM, Daniel Carrera wrote:
> No, you didn't understand me. I don't have a bunch of repos with individual
> libraries. I have my own program that is a big stack of functions that I use
> to analyze the results of my simulations. I am constantly adding
I completely agree with those who suggested use of "x = A\b" instead of
x=inv(A)*b.
Do any of you have comments on things that can be done to make Julia more
'hackable' and even easier to use? Am I alone in wishing for functionality
such as that in Autoreload.jl [1] that is transparently built
On 30 September 2015 at 16:23, Christian Peel wrote:
> One could also ask what the reason for the success of Matlab and R; I
> don't know R, but I can speak a bit about Matlab.
>
> 1) Matlab has great high-level vectorized notation. If you're a student
> or engineer, it's
On 30 September 2015 at 16:57, Michele Zaffalon
wrote:
> There is some literature supporting the opposite:
> http://arxiv.org/pdf/1201.6035.pdf
>
>
I know from experience that "x = inv(A)*b" gets answers wrong in places
where "x = A \ b" gets them right. I show an
I myself do not care much about Julia or python speed since I can write
fast code in Cython (C/C++ speed with Python syntax sugar). There are
several features in Julia I like much (and I think they can be good selling
points).
* CFFI: great that we can call C function easily.
* Parallel: I very
You don’t think Julia does that? […] But not-so-well written Julia code
should be at least as fast as Python. Don’t you think so?
Yes, I do think so (but there are still lots of examples of new users who
manage to write Julia code that’s slower by orders of magnitude compared to
Hello colleagues,
On Tuesday, September 29, 2015 at 11:30:19 AM UTC+2, Sisyphuss wrote:
>
> While waiting Julia 0.4 stabilizing, let's do some brainstorming.
>
btw: it's not "waiting for Julia 0.4 stabilizing", the correct thing is:
While we test release candidates of Julia 0.4 to help it
On Wed, Sep 30 2015, Tomas Lycken wrote:
> You can get Python-like performance without getting computer-sciency.
>
> Again, the problem is not reaching Python-like performance, but rather *not
> beating Python by enough*.
Raw speed is a red herring. For many applications
Coming back to the original question about success of Python, I'd stress
these points:
* it's *simple*. for both - programmers and non-programmers
* it's a *system language* for most Unix-like operations systems
* it has very strong *scientific stack* (read as: has a lot of mature
One big pull for python is the ecosystem. Almost any task has a python
package available.
However, there are gaps. For all the strength of scipy + numpy, there are
serious gaps. For instance in methods for sparse matrices, and CUDA
bindings. It's those gaps that brought me here.
Also, pip is
One could also ask what the reason for the success of Matlab and R; I
don't know R, but I can speak a bit about Matlab.
1) Matlab has great high-level vectorized notation. If you're a student or
engineer, it's dramatically easier to solve a linear system in Matlab
(x=inv(A)*b) than it is in
On Wed, Sep 30 2015, Christian Peel wrote:
> 1) Matlab has great high-level vectorized notation. If you're a student or
> engineer, it's dramatically easier to solve a linear system in Matlab
> (x=inv(A)*b) than it is in many other languages. Julia has at least this
You
On Wed, Sep 30, 2015 at 4:32 PM, Tamas Papp wrote:
> On Wed, Sep 30 2015, Christian Peel wrote:
>
> > 1) Matlab has great high-level vectorized notation. If you're a student
> or
> > engineer, it's dramatically easier to solve a linear system in Matlab
>
> (x=inv(A)*b) than it is in many other languages. Julia has at least this
>
> You shouldn't ever do this (in either Julia or Matlab, or any language),
> it is ill-conditioned for general matrices. I think the Matlab function
> is linsolve.
>
> Perhaps more precise to say "A\b is always
On Wed, Sep 30 2015, Michele Zaffalon wrote:
> On Wed, Sep 30, 2015 at 4:32 PM, Tamas Papp wrote:
>
>> On Wed, Sep 30 2015, Christian Peel wrote:
>>
>> > 1) Matlab has great high-level vectorized notation. If you're a student
When you have matrices with special structures and symmetries, Julia can encode
that information in the type of the matrix, and in those cases the backslash
operator should actually be more efficient than in Matlab because there is no
need to “guess” what the best algorithm might be. My
Yes, one of the things that won me over was that I could write many fewer
lines of code that I'd have to do in C/C++/Java (and that was when I was
still a total novice - which I still am in many ways, but getting better).
Python has been successful IMO because it's easy to quickly get stuff up
One of the recent "why is my code slow" posts from a new user had a
statement that was something along the lines of "sure it's still 4-5 times
faster than python, but I expected it to be much faster". I think this
sums it up... new users hear of Julia's blazing speed and expect it to be
as fast
Leave it to Scott to make things more complicated... :)
On Tue, Sep 29, 2015 at 9:47 AM, Scott Jones
wrote:
> Yes, one of the things that won me over was that I could write many fewer
> lines of code that I'd have to do in C/C++/Java (and that was when I was
> still
On Tuesday, September 29, 2015 at 10:20:18 AM UTC, Tomas Lycken wrote:
>
> One thing Python does well, which Julia doesn't (yet) succeed in, is make
> it easy to start coding from zero experience and get something that
> executes "well enough"
>
I think, this may be a little unfair to Julia.
I think, this may be a little unfair to Julia.
I agree that it’s unfair - but new users are seldom fair. What I meant to
get at was not that Julia code by an inexperienced programmer is worse than
anything else, but just that since Julia *can* be so fast, I think there’s
a big risk that the
On Tuesday, September 29, 2015 at 10:14:48 AM UTC-4, Tom Breloff wrote:
>
> Leave it to Scott to make things more complicated... :)
>
Of course! :)
I just wanted it to reflect better which language might do better for a
company, where the programmer's time may be worth a lot more than the
First of all I want to say that you are doing an excellent job.
I program in Fortran and python but I'm keeping an eye on Julia, I haven't
decided to switch yet. I'm not afraid to learn a new language, so I may do
it in the future.
Python is slow, but most of the time I use vectorized
On Tuesday, 29 September 2015 12:20:18 UTC+2, Tomas Lycken wrote:
>
> One thing Python does well, which Julia doesn't (yet) succeed in, is make
> it easy to start coding from zero experience and get something that
> executes "well enough" (although, as always with first-time coders, code
>
On Tuesday, 29 September 2015 14:50:14 UTC+2, Páll Haraldsson wrote:
>
> Even if Julia were as slow as Python, it seems to be a better language -
> more maintainable
>
Exactly! I never liked Python. I use Julia because I like the language
itself. The fact that it is fast is actually secondary,
I prefer Julia to Python for many reasons, not only performance, but purely
regarding performance I often wondered:
How much is the poor Python performance just a current state. In fact NUMBA
can often take care if it in a very low-effort way.
(a) What is numba lacking now, compared to
Well, I do think there is a lot special about Julia's design that could not
be added on to Python - the macro programming, multiple dispatch
capabilities and the powerful type system (hopefully with traits built into
the language in the future!) are what most set it apart
from other languages,
On Tuesday, September 29, 2015 at 12:42:04 PM UTC-4, Edmondo Giovannozzi
wrote:
>
> First of all I want to say that you are doing an excellent job.
> I program in Fortran and python but I'm keeping an eye on Julia, I haven't
> decided to switch yet. I'm not afraid to learn a new language, so I
32 matches
Mail list logo