oxinabox

Generally I am copy-pasting code out of a WIP package to test out an idea as I go. So the code is already being written in a file. Or I am using Juno/VS-Code/Vim-Slime to simplify the copy-paste.

Other times I have the package I am editing loaded with Revise.jl active and I am calling in and trying out the methods I am concurrently writing in my text editor.

It's more like TDD than anything else. It's got that same quick back and for of run, write, run write. But a but more interactive. (Note I am not saying that is TDD -- it isn't -- tests are not nesc written or saved. Though I do often use this while doing TDD to run a test I have written)

I am guessing it is the thing where if you look at `@code_typed` you will see sometimes annotated not just with types but with `Const(42)` which shows where constant folding is occuring

> Structs most definitely will be faster.

I am not 100% sure this is true.

Structs will definately look cleaner in the code. Not sure they will be faster though.

fixed, to be more limitted in the claim

I think they mean no GUI for that. To manually (rather than programatically) do this.

> You don't need to compile the plotting library every time.

You don't need to but Julia does. Its definately a issue, and I know it is being worked on.

Julia doesn't store compiled binary code between sessions. Unless you compile it into a sysimage.

There are apparently reasons why caching compiled binary like this is complicated in Julia. But once that is solved, wow things are going to be nice.

> (2) Is there something like python's `requests` lib?

For HTTP (etc) requests?

There is HTTP.jl which I have never had problems with; tons of packages use it. I have used it to wrap a ton of different REST APIs etc.

And in 1.6, as mentioned, there is the new Downloads standard library, based on libcurl. Despide the name, I believe it can be used more generally than simply downloading things. Can also be used as a normal library in Julia 1.3+ https://github.com/JuliaLang/Downloads.jl

And there are several other projects

> (1) How is its database connectivity?

Databases are not really my thing but: From what I hear: It is ok. Not amazing. But decent.

LibPQ.jl is very mature (we run it in production). MySQL.jl exists, I hear about SQLite.jl being used pretty often.

I know people use ODBC.jl, and JDBC.jl, though only because they complaint about things. I suspect there are a fair few people using them without complain that i never hear from. Though I haven't heard any mention really of JDBC in a while.

While there is nothing like SQLAlchemy, a nice thing about DataBases in julia is they all conform to Tables.jl tables. So very easy to take your DataFrame library of choice (or CSV reader, or Arrow.jl or a dozen other formats), and use that is the input or output from a database query.

The main equation may not really be anywhere near so simple as that. E.g. for the kind of stuff I do for work the main equation is something like output a vector which is the instructions for every powerplant in Texas of how much power to produce, such that every person and business that needs power has power, subject to constraints about the capacity of each powerline Differentiate total emissions of this process with respect to demand. It's is an equation yes. But it's actually a multi-hundred line program that includes thousands more lines of constants and a step of running ab internal linear optimization solver inside the problem.

Symbolic Differentiation, like Mathematica tends to start to slow down and generate massively amounts of code once functions get complicated. I am also not sure that it can handle dynamic length loops.

Source to Source AD, like Zygote (Julia), Tapenade (Fortran), Jax (Python), Enzyme (LLVM) have a lot of what you might want though.

> That is, I can see how the derivative can help optimise a simulation, but I'm not clear on how using an auto derivative really helps.

Finding a derivative by hand gets tiring fast, and is error prone. Used to be a neural net paper doing anything novel spent like 1-2 pages deriving the derivative of its cool new thing. Not it's derivative isn't even mentioned.

Correct. sin and cos was merely an example.

Every real AD system has a primative for sin and cos. but they do not have every single operation you might ever implement (else what would be the point), and it is unlikely they will have every operation that involves any approximation. (Though there is a good chance the might have every named scalar operation involving an approximation that you do, depends how fancy you are.)

I mean I maintain a library of hundreds of custom primatives. (one of the uses of this post was so i can point to it in response to people saying "why do you need all those primatives if AD can just decompose everything into + and *)

anyone one know why of the 7 AD's tried (8 including the one implemented at the start) there are the different answers? 0.4999999963909431 vs 0.4999999963909432 vs 0.4999999963909433

I assume if is some kind of IEEE math thing. given that IEEE allow `(a+b)+c != a + (b + c)` but where is it occuring exactly?

> Automatic Differentiation doesn't incur more truncation error than symbolically differentiating the function and then calculating the symbolic derivative's value.

Yes. The article even says that.

_"The AD system is (as you might have surmised) not incurring truncation errors. It is giving us exactly what we asked for, which is the derivative of my_sin. my_sin is a polynomial. The derivative of the polynomial is: [article lists the hand-derived derivative]"_

The reason symbolic might help is symbolic AD is often used in languages that don't represent things with numbers, but with lazy expressions. I will clarify that. (edit, I have updates that bit and I think it is clearer. Thanks)

> The article seems to calculate sin(x) in a lossy fashion and then attribute to the error to AD. That's not how it works.

The important bit is that the accurasy lost from a accurate derviative of a lossy approximation is greater than accurasy lost from a lossy approximation to an accurate derivative. Is there a bit I should clarify more about that? I tried to emphisize that at the end before the bit mentioning symbolic.

> https://github.com/JuliaDiff/ChainRules.jl is used by (almost all) automatic differentiation engines and provides an extensive list of such rules.

ChainRules is going to be used by everything. Right now it is used by 3 AD and a PR is open for a 4th, plus one thing that hasn't been released yet.

For context of anyone who doesn't know, I am the lead maintainer of ChainRules.jl, (and the auther of this blog post)

Note that this applies backwards also. Of the 7 ADs demoed, only 1 was forward. The other 6 were reverse mode. All gave same result

Occationally, there are a few places where you want arbitary high derivatives. But in general there are specialized solutions for those (though very few things implement them. E.g. Jax's JETs and TaylorSeries.jl in julia implement taylor-mode AD. But those also need custom primatives)

More of a problem is first derivatives, but that you need very high accuracy. Which doesn't occur in ML but does occur sometimes in scientific computing. (Doesn't occur in ML cos we just basically shake the thing about a bit anyway)

Correct, which is mentioned at the end of the post. I am not sure how well it generalizes, e.g. to multivariate functions that are defines as solutions of some thing like a differential equation.

Maybe it does? I don't know.

> The author's proposed solution is for sites to use DPI instead, but this would thwart the preferences of users who use scaling because they want the whole site to look bigger.

The author's problem is not things becoming bigger. Larger was the goal after all of settings that scaling. The author's problem is things optimize for mobile interaction. Like making thing touch controlled, Or making buttons disproportionately large to make easy to click with thumb.

Interstate idea. The title overstated too late though. Following the premise that an expanding civilization is expanding near the speed of light and it's radio will reach us first. We can expect hundreds of years between radio and anything physical.

1) We started producing a lot of radio around 100 years ago. And we are still a long way from expanding at near speed of light. Even with expodential growth in capacity.

2) expanding near speed of light is much less than speed of light. Say 99% of the speed of light. And expanding civilization is probably going to be coming from far far away, just because there is a lot more far far away than pretty close. So say they are comiy from 10,000 light-years away (still close by galactic standards, and incredibly Close by Universal standards). Then the radio they start transmitting when their grown begins has gained on their expansion ba lead of 100years by the time it reaches us

Sure on the million and billion year time-scales mostly talking about that 100+ years is very little but it is still generations.

One of the TeX stack exchange questions I keep coming back to is how to get tabular digits to show in duplex. Very useful. https://tex.stackexchange.com/questions/88958/make-numbers-i...

ESH

Most languages designed to be used by people are not good targets for people creating new languages. Very different set of concerns.

The main ones I am aware of are:

JavaScript: you basically got to if you want to run in a browser.

And C Because it's available on every piece of hardware, it was there before llvm and it doesn't change across hardware (unlike assembly), and most people writing languages know C.

JVM, the .Net CLR etc are not languages. They are intermidate representations like LLVM is. (Approximately). They were designed to be compilation targets. Julia wasn't.

Most of Julia's intersting compiler features are unusual because they need to solve problems Julia has in general other languages wouldn't,or that would not transfer across language boundaries.

The macro stuff is awesome for DSLs. Messing with compiler passed is cool for adding capacities. But I think much more in the sense of implementing a micro language that is closely related to Julia, rather than a full on language that has its own goals and identity (I want to write one for codegolf called Jules that is just Julia except on an error it tries some other lexically nearby code)

We have spend decades understanding the seperation of presentation /view from model

A consistant alignment-free indenting only style is perfectly readably. More reably than a lot of inconsitently applied and subjective alignment styles I often see.

Though I have also seen consistently applied non-subjective alignment based styles, that are also perfectly reably. But no more reasable than a consistently applied indenting only style. Alignment styles are in general more complex to describe and thus more inconsistently applied.

And sure some subjective alignment based styles are pretty are maybe even marginally more readable. But does it scale? Can the intern who is only here for summer weeks be expected to learn what makes it look nice in the teams opinion while also learning everything else? How about that one coworker who just doesn't agree and refuses to conform to these subjective rules that can't even be written down. Sure, you can have art if you want for your solo project. But programming is a team sport.

This is the real answer. I personally like tabs. But I will absolutely not stand for anyone using tabs on our code-base. Because we use spaces, and we have better things to do that debate or, or reformat the whole code base. (even though we actually do use a style without alignment and so it would be not at all a visual problem)

Semantically: tabs are simply correct. They encode actual meaning. Rather than merely presentation. They also win on accessibility, because someoen with visual difficulties can adjust their editor to display them as larger or smaller.

The counter to this is people using spaces for alignment, Like if one wants to list arguements below the openning backet of a function call, and line up the closing bracket.

The counter counter is: stop that. Adopt a style guide that doesn't do alignment and sticks to a simple rule like "Always indent once while within a multiline expression" Alignment is for art. We don't have time for your subjective view of what makes code pretty.

It was update in May to fix that the CDN changed. The actual content hasn't been updated in 7 years.

It really should be updated to have basically the content of this thread https://discourse.julialang.org/t/state-of-automatic-differe...

I don't think that is the case. Sure Perl may have been in decline for ages, but people were not comparing Perl to Python for that long. Simply because python hasn't existed that long.

Python 2.0 was released in 2000. Python 1.0 was 1994, and Python 0.9 (first public release?) was 1991.

Check the google trends. https://trends.google.com/trends/explore?date=all&geo=US&q=p... Its unclear when perl peaked since it has been in decline since before 2004 But it wasn't til late 2007 that Python overtook Perl in google searches

Even while it was in decline people were still making that argument.

Trying to think of others.

Kotlin was 2011, and is JetBrains. JetBrain's is 1500 people. So big, but not giant.

Rust is 2013 Mozilla is only 750 people

So perhaps Major Tech Giant is over-stating it. But definately most other things in the last decade have a major established tech firm backing it.

Julia has basically nothing. Starting out as a MIT project, and then Julia Computing is a tiny startup; with like what 50 people now?

Urg that website is so incredibly out of date. Julia has amazing things for autodiff. But like not the things listed on that website.

Also python is still doing great with Jax and PyTorch.