Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Static, Ahead of Time Compiled Julia

juliacomputing.com

Post reply on HN
Print view View original

51–60 of 87 posts

Re: Static, Ahead of Time Compiled Julia

#51

Post by ViralBShah »

StefanKarpinski wrote: post #37
jakub_h wrote: post #30

Earlier quoted context omitted.

I thought that type stability was actually a crucial notion in real-world dynamic language implementations? Witness inline caches and polymorphic inline caches, for example.

The concept is certainly not new, but googling "type stability" seems to only turn up Julia-related pages or other, unrelated uses of the term, so it seems like this usage may have been coined in the Julia community. If you find prior uses with this meaning, please do let me know.

Yeah seems so. Perhaps worth having a wikipedia page for it now!

Re: Static, Ahead of Time Compiled Julia

#52

Post by StefanKarpinski »

jacobolus wrote: post #48
StefanKarpinski wrote: post #36

Earlier quoted context omitted.

The main valid complaints in Dan's post were: 1. Insufficient testing & coverage. Code coverage is now at 84% of base Julia, from somewhere around 50% at the time he wrote this post. While you can always have more tests (and that is happening), I certainly don't think that this is a major complaint at this point. 2. Package issues. Julia now has package precompilation so package loading is pretty fast. The package ma…

> The main valid complaints [...] the legitimate issues raised [...] This is a really passive-aggressive weaselly phrasing. I’d recommend reconsidering this type of tone in public discussion responses. Instead of suggesting that the other complaints were invalid or illegitimate, you could just not mention them at all, or at least use nicer language in brushing them aside. E.g. “... the main actionable complaints...”…

Sorry if it came off as smug or dismissive, that was not the intention. I was trying to be precise – we haven't fixed everything that Dan complained about, but some of those complaints were very subjective or things that I didn't think were fair and therefore wouldn't claim to have fixed.

Re: Static, Ahead of Time Compiled Julia

#53

Post by jasode »

cohomologo wrote: post #44
jasode wrote: post #23

Earlier quoted context omitted.

>I really, really wish they had dropped the 1-based indexing >, my opinion on this topic is distorted because I spent a lot of time programming in C++ Mathematics-related programming[1] in MATLAB, R Language, Mathematica, SAS, etc all use 1-based indexing. Given that the originators of Julia are MATLAB users, it makes sense that they made a deliberate choice to keep 1-based indexing. In other words, it was more impor…

Mathematica is actually 0-based - but with the zero index spot reserved. A list {1, 2, 3}=List[1, 2, 3] could be read as (List 1 2 3) in Lisp style; one can check if you have Mathematica that {1, 2, 3}[[0]] = List. But I think that's neither here nor there. Whenever the index has more use than as a label, mathematics starts at zero. Modular arithmetic, polynomials, discrete fourier transformations - for that matter,…

In this subthread, the phrase "0-based / 1-based" is for the word "base" accessing the first element which is semantically equivalent to x[0] in C/C++/Python/etc or x[1] in R Language. Yes in Mathematica, putting "0" between "[" "]" will get you the reserved "head" but that's not how people are talking about "0-based" here.

Re: Static, Ahead of Time Compiled Julia

#54

Post by wbhart »

jacobolus wrote: post #48
StefanKarpinski wrote: post #36

Earlier quoted context omitted.

The main valid complaints in Dan's post were: 1. Insufficient testing & coverage. Code coverage is now at 84% of base Julia, from somewhere around 50% at the time he wrote this post. While you can always have more tests (and that is happening), I certainly don't think that this is a major complaint at this point. 2. Package issues. Julia now has package precompilation so package loading is pretty fast. The package ma…

> The main valid complaints [...] the legitimate issues raised [...] This is a really passive-aggressive weaselly phrasing. I’d recommend reconsidering this type of tone in public discussion responses. Instead of suggesting that the other complaints were invalid or illegitimate, you could just not mention them at all, or at least use nicer language in brushing them aside. E.g. “... the main actionable complaints...”…

I read the final line completely differently to you. I read it as saying that the aforementioned issues were definitely legitimate and have therefore been addressed.

However, like you, I noted that some of the complaints had not been accepted.

Re: Static, Ahead of Time Compiled Julia

#55

Post by [deleted] »

jacobolus wrote: post #48
StefanKarpinski wrote: post #36

Earlier quoted context omitted.

The main valid complaints in Dan's post were: 1. Insufficient testing & coverage. Code coverage is now at 84% of base Julia, from somewhere around 50% at the time he wrote this post. While you can always have more tests (and that is happening), I certainly don't think that this is a major complaint at this point. 2. Package issues. Julia now has package precompilation so package loading is pretty fast. The package ma…

> The main valid complaints [...] the legitimate issues raised [...] This is a really passive-aggressive weaselly phrasing. I’d recommend reconsidering this type of tone in public discussion responses. Instead of suggesting that the other complaints were invalid or illegitimate, you could just not mention them at all, or at least use nicer language in brushing them aside. E.g. “... the main actionable complaints...”…

[deleted]

Re: Static, Ahead of Time Compiled Julia

#56

Post by acidflask »

lmm wrote: post #45
conjectures wrote: post #42

Earlier quoted context omitted.

It's an MCMC algorithm for a fancy kind of matrix factorisation. I had a look at Spark, but its linear algebra packages seemed too limited (I guess abstraction comes at a cost). I can see that Spark would be nice if it does what you need out of the box. Heard good things about Scala, is it straightforward to get a process on a remote machine to execute code?

> I had a look at Spark, but its linear algebra packages seemed too limited (I guess abstraction comes at a cost). I can see that Spark would be nice if it does what you need out of the box. Did you look at MLlib and/or just using Breeze directly? There's a bit of awkwardness in the initial set up of the cluster (mainly just having LAPACK installed on all nodes, see https://spark.apache.org/docs/1.1.0/mllib-guide.htm…

Most people don't need more than a handful of linear algebra operations (or think they don't), so Breeze and most wrappers of LAPACK or similar libraries don't implement or wrap them. But most people who work seriously on numerical routines will quickly run into performance problems if all they do is call LAPACK routines for general matrices instead of taking advantage of matrix structure.

I have yet to come across any other linear algebra library for any other high level language that provides the depth of integration available in the Julia base library. Want all eigenvalues of a symmetric tridiagonal 10x10 matrix between 1.0 and 12.0? Simply call T=SymTridiagonal(randn(10), randn(9)); eigvals(T, 1.0, 12.0). Or if you want to work closer to LAPACK, simply call LAPACK.stein!. I don't see a wrapper in Breeze or SciPy for this function. Want an LU factorization on a matrix of high precision floats? lufact(big(randn(5,4))). And so on.

Julia may not have everything users want, but its base library really tries to make matrix computations easy and accessible.

Re: Static, Ahead of Time Compiled Julia

#57

Post by openasocket »

StefanKarpinski wrote: post #50
openasocket wrote: post #47

Earlier quoted context omitted.

The closest concept I can think of is the concept of "strong typing," that a value does not change type based on its context, which is a fairly widely used term. It seems like Julia has some form of weak typing, at least between the different numeric primitives, and "type stability" refers to avoiding any usage of weak typing. I don't know a lot about Julia, though, so I could be way off here.

"Strong typing" and "weak typing" don't really mean anything: http://blogs.perl.org/users/ovid/2010/08/what-to-know-before... You probably mean "static typing" versus "dynamic typing" which I wrote a bit about in the context of Julia here: http://stackoverflow.com/questions/28078089/is-julia-dynamic... Basically, I think "type stability" hasn't really been a thing in the past because in dynamic languages, people have…

I disagree: strong and weak typing are fairly well defined terms. I'm going off the definition given in "Programming Language Pragmatics," which states "a language is strongly typed if it never allows an operation to be applied to an object that does not support it; a language is said to be statically typed if it enforces strong typing at compile time."

Re: Static, Ahead of Time Compiled Julia

#59

Post by jahewson »

openasocket wrote: post #57
StefanKarpinski wrote: post #50

Earlier quoted context omitted.

"Strong typing" and "weak typing" don't really mean anything: http://blogs.perl.org/users/ovid/2010/08/what-to-know-before... You probably mean "static typing" versus "dynamic typing" which I wrote a bit about in the context of Julia here: http://stackoverflow.com/questions/28078089/is-julia-dynamic... Basically, I think "type stability" hasn't really been a thing in the past because in dynamic languages, people have…

I disagree: strong and weak typing are fairly well defined terms. I'm going off the definition given in "Programming Language Pragmatics," which states "a language is strongly typed if it never allows an operation to be applied to an object that does not support it; a language is said to be statically typed if it enforces strong typing at compile time."

No, the parent comment is correct: formally they're meaningless. Those definitions might be fine for casual discussions, but from an academic programming language standpoint they don't correlate to anything meaningful.

Re: Static, Ahead of Time Compiled Julia

#60

Post by g0wda »

PeCaN wrote: post #49
Xcelerate wrote: post #38

Earlier quoted context omitted.

> I'd like an infix function composition operator. Do you mean like the pipe symbol? rand() |> println Or are you referring to something else?

No, x |> f is equivalent to f(x) while (f ∘ g)(x) is equivalent to g(f(x)). Specifically, x |> f results in a value (of the type of the return value of f) while f ∘ g results always results in a function.

Why not make one for yourself? ;)

julia> (∘)(f, g) = x -> f(g(x))

∘ (generic function with 1 method)

julia> (sum ∘ rand)(10)

3.397728240035534

Tip: type \circ to get ∘

Post reply on HN