Forgot your password?
typodupeerror

Comment: Re:Yet another language (Score 1) 204

by Baron von Leezard (#39727877) Attached to: Julia Language Seeks To Be the C For Numerical Computing

Yeah, I think that was mentioned in Luke Hoban's talk on ECMAScript at Lang.NEXT (if not, I saw it elsewhere that I can't recall). That would certainly help and even make calling LAPACK possible in JavaScript, but I still think it wouldn't be much fun. It would be pretty cool though :-)

Comment: Re:Not fast at all (Score 3, Insightful) 204

by Baron von Leezard (#39726677) Attached to: Julia Language Seeks To Be the C For Numerical Computing

Dynamic typing doesn't add any overhead when you can determine which specific method you need when generating code — which, in a dynamic language with a JIT, is very late, meaning that you can most of the time. Julia uses tons of small method definitions that call other small methods and so on, even for basic things like adding two integers, but the compiler is smart enough to compile addition into a single machine instruction. The notion that dynamic languages are slow because of their dynamism is very outdated in light of modern compiler techniques.

Comment: Re:I "C" what they did there... (Score 1) 204

by Baron von Leezard (#39726439) Attached to: Julia Language Seeks To Be the C For Numerical Computing

The C/C++ benchmarks are intentionally written in C; the only reason that's it's a C++ files instead of C is so that we can use C++'s complex template in the Mandelbrot benchmark. Otherwise the whole thing would just be done in C. The clock_now function is only used to time other code, so its performance is irrelevant.

Stefan Karpinski

Comment: Re:Existing Codebase (Score 1) 204

by Baron von Leezard (#39726325) Attached to: Julia Language Seeks To Be the C For Numerical Computing

You can't do this just yet, but we're working on it. Should be possible in the near future. At some point further into the future, you'll be able to compile Julia code into a .so file, load it from C code and just call it as though it were written in C —except that the person writing the code gets the benefits of a high-level numerical language.

Stefan Karpinski

Comment: Re:Yet another language (Score 1) 204

by Baron von Leezard (#39726285) Attached to: Julia Language Seeks To Be the C For Numerical Computing

That's a fair question, and one I asked myself after writing the benchmark code for JavaScript and seeing just how incredibly fast the V8 engine is. Should we be doing numerical computing in JavaScript? The biggest problem that I can see is that JavaScript doesn't have a good story for calling external C/Fortran libraries. Some sort of FFI could be implemented, but there are deeper issues —especially the paucity if numerical types in JavaScript. JavaScript doesn't even have integers —every number is a double. So how can you distinguish between an array of integers versus an array of doubles that happen to have integer values? Can the compiler be smart enough to know that it can store those numerical arrays inline in a format that can be passed to LAPACK? To do numerical computing, you really need more control over memory layout, at the very least for the sake of calling external libraries.

Stefan Karpinski

Comment: Re:Why? (Score 1) 204

by Baron von Leezard (#39726183) Attached to: Julia Language Seeks To Be the C For Numerical Computing

As I mentioned in the interview, we're working on a compiler, at which point you would even be able to use compiled Julia code in embedded systems. So you get a nice productive, interactive development environment, then you invoke the static compiler and presto! you have a compiled .so files that you can just call from C. That eliminates the need to prototype in one language and then re-write everything in another language when you want to actually deploy it. I've done that before and it's deeply annoying, time-consuming, and hard to get right (it's generally harder to write correct C code than correct Matlab code). I've also deployed Matlab using their compiler. That's workable if you want to avoid re-writing your prototype, but it's also pretty annoying.

Stefan Karpinski

Comment: Re:Tangentially (Score 1) 204

by Baron von Leezard (#39726123) Attached to: Julia Language Seeks To Be the C For Numerical Computing

There's a few points:

1. Julia is entirely dynamic, so there's no need to think about compile time versus run time, simplifying the mental model (but the performance is like that of compiled languages). It's as easy as Python or Matlab in that respect, but much faster.
2. There are just a few powerful language features (e.g. ubiquitous, fast multiple dispatch, supported with an expressive type system), rather than a lot of features that interact in complicated ways.
3. Good for general programming stuff: working with strings, calling external programs and other things that are generally pretty awkward in R and Matlab (one of the reasons why NumPy is gaining popularity).

In general, the motivation (expressed in a previous Julia blog post) is to have something that's easy to use and learn, but fast and powerful (you *can* go deep if you want to), and designed expressly for numerical work —which means, among other things, that it has to be able to store large arrays of numeric values in-line and call libraries like LAPACK on them.

Stefan Karpinski

Comment: *despite* the data (Score 1) 472

by Baron von Leezard (#38372192) Attached to: New Study Concludes Math Gender Gap Is Cultural, Not Biological

It's difficult to fathom how the authors interpret the data on page 14 as *not* supporting the hypothesis that there is a male/female variance ratio of about 1.1. Figure 1A is a bell-like curve which is clearly centered around 1.1. In Figure 1B, almost all of the points are below the 1:1 line, whereas if you plot a 1.1:1 line, its a perfect fit for the data. In Figure 1C, the x value where the regression line intersects a zero gender gap (i.e. no evidence of cultural bias), is at a variance ratio of about 1.1. All of the evidence the authors present points to an underlying variance ratio near 1.1, yet somehow they conclude the opposite.

Comment: Re:Why is this a problem? (Score 1) 376

by Baron von Leezard (#35123412) Attached to: Wikipedia Works To Close Gender Gap

For a fairly mature project like wikipedia (everybody knows about them, they have more pagerank than god, ignorance is unlikely to be the reason behind most non-contributors), focusing on anomalies in your contributor statistics is a good way of identifying potential issues that might be standing in the way of your growth.

I'm pretty sure that god is not the gold standard when it comes to PageRank. Yup: god — top hit, wikipedia.

Technology

+ - Car Tech: Building The Zero-Fatality Car->

Submitted by CWmike
CWmike (1292728) writes "In the future, new cars might include an appealing sticker: This car is rated for zero fatalities. John Brandon reports that Volvo, for instance, has launched a program called Vision 2020, which states, 'By 2020, nobody shall be seriously injured or killed in a new Volvo.' It includes not just new protective measures in the car, but technology for communicating dangers to and from the car. Other car companies have similar, less formalized programs. As ambitious as it seems, Ed Kim, an analyst at automotive research firm AutoPacific, says the zero-fatality goal is achievable. In the next 10 years, there will be a confluence of safety technologies — such as road-sign recognition, pedestrian detection and autonomous car controls — that lead to safer cars, says Kim. Will your next car look something like this?"
Link to Original Source

"More software projects have gone awry for lack of calendar time than for all other causes combined." -- Fred Brooks, Jr., _The Mythical Man Month_

Working...