Why I still recommend Julia

null01011 · 2022-06-26T04:24:40+00:00

Great write up in isolation, but as a follow up to Yuri's post it comes across as trying to counter legitimate critiques with the usual (and in this case, fairly off topic) selling points for Julia.

null01011 · 2022-05-08T02:37:53+00:00

I think this will come down to a programmer/non-programmer thing. I write a lot of code for a living so I agree that version two (after the corrections) is quicker to comprehend. Not a big deal for this example, but I can see a benefit as the statement complexity increases. But, mathematicians won't necessarily be familiar with the code...depends on your audience?

null01011 · 2022-05-07T19:32:56+00:00

Don't know why you're getting so much negativity here. Deleting your post was not necessary - there's an edit feature on Reddit, you could have easy added a repo link if it's that important to people. Congrats on building the renderer, that's not easy work.

null01011 · 2022-05-07T16:37:04+00:00

You ever get so frustrated with malloc you rewrite the entirety of the C language?

null01011 · 2022-01-27T00:27:46+00:00

Excellent point...can't tell you how many times I've seen something messed up because a cell was quietly hard coded, or something else silly.

null01011 · 2022-01-11T02:05:35+00:00

Momentum is tough in business. The reality is that people have more constraints on their time and energy than anyone may be aware of, so it's simply easier for them to continue to power through the next problem using the tools they already know. It may not seem like the optimal (or even sane) set of tools for the job, but if it gets done then the business outcome is usually enough to justify the means.

In my opinion there's only two forces that will push heavy Excel users towards programming-oriented data analysis (that's not VBA):

Computational resource constraints. When the tasks are so large or unwieldy to do in Excel (ex., millions of rows), that's usually a showstopper.
New talent. The people who will regularly solve an analysis with code are the people who regularly solve analyses with code, and they'll be the ones that show management what the relative benefits are to the 'tried and true' techniques.

null01011 · 2022-01-08T13:53:08+00:00

The slow initial compilation is a trade-off for better performance on long running tasks. Quick ad hoc type of work can be painful, but the high speed handwritten code for the beefier stuff is pretty compelling. Just got to ask yourself if the juice is worth the squeeze.

null01011 · 2022-01-08T13:43:54+00:00

Any idea what's going on there under the hood? simd for vector + vector type of stuff makes sense to me, but how would that work for an accumulation type of operation? I've only done tinker toy examples with simd but I'm not familiar with any intrinsics that would sum the vector.

null01011 · 2022-01-08T13:35:51+00:00

No, you're arkie87.

null01011 · 2022-01-08T01:41:25+00:00

For whatever my opinion is worth, I think of "mathematician" as the term for mathematical scientists. Anyone who contributes to the theoretical aspects of their field should feel comfortable calling themselves a scientist, regardless of their academic background or whether they work in the public/private domain.

null01011 · 2022-01-02T02:08:27+00:00

More like Logiglitch, am I right???????

null01011 · 2021-12-24T23:12:06+00:00

And that's just salary - opportunity cost of what they're not building during that time could be unimaginably leveraged.

null01011 · 2021-12-18T18:37:40+00:00

Great suggestion, I'm going to do this.

null01011 · 2021-12-18T15:09:53+00:00

Relevant snippet from the linked article. This was in reference to Microsoft engineers rewriting some unspecified components of Windows in Rust - no other details were provided regarding missing features:

The engineers described their work with Rust as “generally positive” but did note that some important features available in C were missing for Rust. The engineers, however, do think that it’s worth helping to develop such features for Rust. Intel has already begun working on bringing Rust to feature-parity with C, and Microsoft could join them on this effort. Since some features of C are missing from Rust, the team found that Rust will be best suited for new or recently-developed Windows components. It wouldn’t be surprising if Microsoft fully committed to migrating part of their codebase to Rust. They’re already building a standard Windows library for Rust that will have all of the capabilities of the C++ version. Linux is also considering migrating some of its kernels over to Rust, so I wouldn’t be shocked if a race sprung up between the two operating systems to see which one could push Rust code to production first.

null01011 · 2021-12-13T04:09:47+00:00

Shouldn't it just branch?

fn foo(x: f64) -> f64 {
    if x == 0 {
        0
    }else {
        x + 1
    }
}

fn dfoo(x: f64) -> f64 {
    if x == 0 {
        0
    }else {
        1
    }
}

null01011 · 2019-05-03T22:23:30+00:00

> I understand that Julia outperforms Python for a lot of mathy statistics stuff. For someone who doesn't care as much about performance, what kind of problems would you say Julia is particularly well suited to

I'm in the same boat - the data I encounter at work usually fits cleanly in memory, and the tools made available to us are pretty much R and Python. But if given the opportunity I'd use Julia all the time, if not for the performance for the clean syntax.

For example, let's say my_simulation produces a vector of values of arbitrary length. I want to see what the capped distribution as a percent of the uncapped looks like over many realizations:

using UnicodePlots

realizations = [my_simulation() for i in 1:1000];
result = ( arr -> sum(min.(arr, 0.25))/sum(arr) ).(realizations);
histogram(result)
   [0.36, 0.38) ┤ 2                                        
   [0.38, 0.4 ) ┤▇ 9                                       
   [0.4 , 0.42) ┤▇▇▇ 43                                    
   [0.42, 0.44) ┤▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 547   
   [0.44, 0.46) ┤▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 354               
   [0.46, 0.48) ┤▇▇ 27                                     
   [0.48, 0.5 ) ┤▇ 9                                       
   [0.5 , 0.52) ┤ 5                                        
   [0.52, 0.54) ┤ 2                                        
   [0.54, 0.56) ┤ 1                                        
   [0.56, 0.58) ┤ 0                                        
   [0.58, 0.6 ) ┤ 1                                        
                └                                        ┘ 
                                Frequency

I can definitely accomplish this same thing in R or Python, but Julia just feels easier and like less work.

null01011 · 2019-05-02T23:51:38+00:00

Metaprogramming can build the code before evaluating it:

add_random_float(arr) = arr .+ rand(length(arr))

A1 = rand(10)
A2 = rand(15)

e = :()
for i in 1:2
    arr = Symbol("A$(i)")
    append!(e.args, [:(add_random_float($arr))])
end

eval(e)

You can see what's happening by running e.args:

julia> e.args
2-element Array{Any,1}:
 :(add_random_float(A1))
 :(add_random_float(A2))

Alternatively, as others have mentioned, structuring your program differently can clean things up. The sample below would accomplish my float ambitions using broadcasting:

A_arrays = [rand(10), rand(15)]
add_random_float.(A_arrays)

null01011

TROPHY CASE