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

My Journey from R to Julia

drtomasaragon.github.io

Post reply on HN
Print view View original

81–90 of 120 posts

Re: My Journey from R to Julia

#81

Post by Hasnep »

rlh2 wrote: post #21
karencarits wrote: post #2

> For example, in R, we try to avoid loops because they are very inefficient This was true before, but the performance of for loops has been improved a lot later years, and while vectorization is still faster, for loops are no longer a no-no See https://www.r-bloggers.com/2022/02/avoid-loops-in-r-really/

The obsession with cpu speed almost always confuses me in these topics. Time it takes to program is way more important, and that’s where a terse language like R shines. The base/most common functions are almost always executing C anyway. It’s kind of like lisp in that it’s easy to write slow code, but who cares if it’s “fast enough”? Also, it’s almost always easy to speed up if necessary at the R level and R’s C API…

One of the key points of Julia is that the language you use for performance critical parts is also Julia. That applies to both the libraries like DataFrames.jl and for situations where you'd drop to a lower level language when optimising. I think being productive in Fortran or C++ is unrealistic for most scientific programmers.

Re: My Journey from R to Julia

#82

Post by adgjlsfhk1 »

jpfr wrote: post #79
adenozine wrote: post #6

I’ve made most of my career turning scientific and mathematical code into maintainable and aesthetic code, and the red flag for me in this article is that he evidently couldn’t keep up with the Python learning curve and chose instead a language with no traits, no interfaces, and no classes. So, the amount of organization in his code is effectively zero. I understand that Julia 2.0 is slated to have some sort of concr…

I'm surpised. At JuliaCon ~6 months ago the message was that no 2.0 is in the works [1]. I.e. no backwards-incompatible changes to the language. I checked the usual places and did not find any information on 2.0 and an interface mechanism. Do you have a pointer? [1] https://youtu.be/N4h46_TCmGc?t=1656

No, he's just making stuff up.

Re: My Journey from R to Julia

#83

Post by BrandonS113 »

celrod wrote: post #74
ChrisRackauckas wrote: post #43

Earlier quoted context omitted.

Ahh then it's all based on the speed of the objective function and the gradient calculation code. Do you have an example to look at for that? Or did you try modelingtoolkitizing and running an auto-simplified form?

I've noticed that R often defaults to much higher tolerances than Julia, even when it's wrappers to the same C library, like cubature. R cubature[0]: 1e-5 Cubature.jl [1]: 1e-8 The difference for NLopt in R vs Julia is smaller. `NLopt.DEFAULT_OPTIONS`[2] in Julia shows `1e-7` for `ftol_rel`, `xtol_rel`, and `constrtol_abs`, while in R `xtol_rel` is `1e-6` and the others are `0.0`[3]. So, the options at least aren't t…

We take of that by setting all the NLOPT options to be the same across calling languages. We get pretty much the same number of calls in julia, r and c.

Re: My Journey from R to Julia

#84

Post by mxkopy »

EdwardDiego wrote: post #52
mxkopy wrote: post #26

Earlier quoted context omitted.

> no traits, no interfaces, and no classes. So, the amount of organization in his code is effectively zero. This is an utterly deranged take. Do you mean to say that adherence to OOP and code organization are the same thing ?

Deranged? You could've said that you disagree and leave it at that.

I view the statement with fascination rather than derision

Re: My Journey from R to Julia

#85

Post by pjmlp »

adgjlsfhk1 wrote: post #70
pjmlp wrote: post #66

Earlier quoted context omitted.

Python is only slow because so far there has been a huge disregard for JIT implementations, versus how other dynamic languages have decided to deal with perfomance issues.

PyPy definitely shows that python could be 5x faster than it is, however this would still be ~10x slower than Julia/C/C++ (and R is roughly 5-10x slower than python now)

Yes, but it will never part of the development workflow of most Python developers, and the ongoing CPython JIT work sponsored by Microsoft will hardly win any JIT performance prices, given its design goals.

In any case, there is a reason why Python has a profiler in the box, as what one thinks and what actually is, isn't the same. Which was my starting point.

Re: My Journey from R to Julia

#86

Post by RosanaAnaDana »

BrandonS113 wrote: post #75
dunefox wrote: post #60

Earlier quoted context omitted.

It's not an issue at all with RCall and PyCall.

Of course it is, sometimes one needs to pass data represented as R objects (like zoo) to R functions, and receiving something that is an R object and to be worked on by R calls before being passed on. That is very clumsy to manage with RCall.

A perfect example of this is image processing.

Is is delightful in working with spatial raster data. It's an 'it just works' space, especially with raster and stars. There have been several attempts to disrupt the raster package but none have really stuck.

Granted, it's not fast. However trying to do the same kinds of things in python with rasterio is just cludgy. And half the time you end up making system calls to gdal anyways. Guess what? I can make the system calls from R too.

Re: My Journey from R to Julia

#87

Post by kgwgk »

mxkopy wrote: post #35

From my understanding Julia is closer to metal than R. This means the semantics are much more specific than R, and the syntax is more consistent/rigid. For example, plotting in R always baffled me. plot(x, y, col=..., col.name=...) In this case, col.name is literally just a symbol. But in another context col.name is the data with index 'name' stored in col. Or something, it's been a while. R seems to have a lot of th…

    > plot(x, y, col=..., col.name=...)
    > In this case, col.name is literally just a symbol.
In this case, col.name is literally… made up?

Re: My Journey from R to Julia

#88

Post by [deleted] »

kgwgk wrote: post #87
mxkopy wrote: post #35

From my understanding Julia is closer to metal than R. This means the semantics are much more specific than R, and the syntax is more consistent/rigid. For example, plotting in R always baffled me. plot(x, y, col=..., col.name=...) In this case, col.name is literally just a symbol. But in another context col.name is the data with index 'name' stored in col. Or something, it's been a while. R seems to have a lot of th…

> plot(x, y, col=..., col.name=...) > In this case, col.name is literally just a symbol. In this case, col.name is literally… made up?

[deleted]

Re: My Journey from R to Julia

#89

Post by mxkopy »

kgwgk wrote: post #87
mxkopy wrote: post #35

From my understanding Julia is closer to metal than R. This means the semantics are much more specific than R, and the syntax is more consistent/rigid. For example, plotting in R always baffled me. plot(x, y, col=..., col.name=...) In this case, col.name is literally just a symbol. But in another context col.name is the data with index 'name' stored in col. Or something, it's been a while. R seems to have a lot of th…

> plot(x, y, col=..., col.name=...) > In this case, col.name is literally just a symbol. In this case, col.name is literally… made up?

This is bad faith pedantry

Re: My Journey from R to Julia

#90

Post by BrandonS113 »

derbOac wrote: post #78
kkoncevicius wrote: post #27

Earlier quoted context omitted.

It depends. Take for example any omic dataset where you might need to run a GLM model on ~500,000 rows. Codes I've seen for this operation can range in time from taking 30 minutes to 2 days. My take away here is that, sure, for one operation the speed is not that critical, but there is always the case where that one operation will be used close to a million times in one analysis and then it all adds up. On top of tha…

Yes, I use R, Julia, and Python from time to time depending on the case and my mood and they all have their advantages and disadvantages. R is more than fast enough for straightforward prototypical analyses where a lot of the code is calling C or something lower level and you're not introducing something "new" to the interpreter system. But if you want to do some unusual optimization there's going to be something tha…

I have been thinking the same and had similar timing experiences. As Julia is lower level than R/Python, there is a lot of annoying things to take care of that are not needed in R/Python. And then why not use, say Rust? Or just Rcpp in R. We just did a small test program in Rust that is called very often on the command line and takes a couple of seconds to run. Very happy with the experience. Same run speed as Julia, 10 times faster than R/python, and no 60 second load time like julia.
Post reply on HN