breatheoften

Wouldn’t go so far as never. I’m going to go out on a limb and say Fusion power on a space ship will be viable one day if humanity survives long enough.

Not sure why you are down voted. Buffet’s reasoning here is incredibly weak and he deserves to be criticized for it.

It’s “difficult to assess” whether or not an investment will produce a financial return but he doesn’t apply that argument to criticize those who pursue investments with the goal of growing their personal wealth.

I think this is the worst quote I’ve ever read from warren buffet and it makes me very much dislike him.

I think it’s impossible to decide which of two criminal justice systems is “better” knowing only the conviction rate of both. Asking people to do this or placing them in a position where they are likely to is asking them to commit to finding flawed reasoning to support their own biases — and probably has an enhancing effect on those biases.

Does bazel use the word “provenance“ at all?

Provenance is a word I first saw advertised in a platform called dotscience.io — that I find fundamentally interesting. And it seems quite relevant to hermetic builds.

Provenance is about giving any state derived from an arbitrary computation an identity that is derived from the content hash of the inputs needed to re-compute that state ... in dotscience they achieve this by instrumenting io and creating zfs filesystem snapshots when computing new provenance artifacts.

I think this concept could be the ultimate building block for a build system — and it could become the job of oses/containers/runtimes/databases to Coordinate to allow this abstraction to be tracked with sufficient efficiency that programmers would feel allowed to freely use the concept of provenance when building ... it seems to me like provenance could provide all the information needed to support a distributed build cache? You wouldn’t actually need a build language at all — just an api in each language to ask for the saving of provenance artifacts. The artifact would hold all the info needed to be able to recompute the artifact with the same state — which is also all the info needed to decide when the artifact is out of date ...?

I tried to build something like this for jest tests in an app I worked on.

I wanted my jest tests to serve as both unit tests and service diagnostics - so I instrumented axios and setup a hidden cache layer within it when running inside the test suite. I was trying to figure out how to best organize the cache so I could run tests really quickly by having all results pulled from cache — or run it slow and as a service diagnostic mechanism by deleting the cache before execution ... I had to extend axios to accept a bit of additional logic from the application ...

it was hard for me to get it to work properly inside of jest though ...

I don’t know many people who would be unable to derive value from the use of text selection on their mobile device - that should be a low percentage of the market, because everyone should be succeeding at using the functionality ...?

I came here just to say the same thing — Apple really needs to track the statistics on success rate for text selection ...

“User Selected the text they wanted first try”

“User Selected the text they wanted within 30 seconds”

“User Selected the text they wanted within 1 minute”

“User Failed to select the text they wanted”

I hit that last case probably more than 30% of the time nowadays — and very often it’s not because the text representation on screen makes it impossible — but because it’s just fucking horrifically bad ui and I can’t select the text I’m interested it despite trying for frustratingly long amount of time. I hit categories 2 and 3 frequently when I really need to get the data selected — and that makes me want to throw my Apple iPhone into the sun ...

> The code must be written in a specific linear way to cater the format of notebooks.

This issue is super annoying. Notebook's _force_ you into that linear style -- which then packages up your code in a form that can't compose with anything ... Its not even a limitation of the notebook file format as if often thought -- its simply the case that notebook's work best when the majority of code in the notebook is in the same scope -- otherwise you can't interactively inspect intermediate variables ...

I was helping a friend of mine with some data science tasks and made a little library to restore some ability to compose a notebook written in that linear style into larger programs ...

https://github.com/breathe/NotebookScripter

Its relatively easy to take a notebook written normally, define a few parameters for it that can be configured externally, and turn that notebook into a callable function ...

I really think that the various notebook implementation's (jupyter, swift playgrounds) -- _need_ to add some sort of parameterization model to the notebook concept. Its not that hard to come up with a transformation that allows one to (1) work interactively in a notebook which has its parameters inferred from defaults (2) exposes a callable interface to that notebook that allows the caller to supply new values for parameters

A Notebook <-> function transformation is really all that is needed to create a real-programming model for Notebook's which would let one compose notebook's into larger programs while still writing the notebooks themselves in a way that's useful for data exploration ...

Going both ways Notebook <-> function and function <-> Notebook would be such a nice general purpose development feature... I'd love to take any function in a swift project and be able to interactively develop the function body in a 'playground like environment'. All that's required would be to supply values for the function's arguments -- and then there is no reason (aside from the limitations of the existing tools) why you couldn't compile the function into a form that supported a 'playground-like' experience for working on the function body.

Its not a small change ... binary compatibility has essentially meant “c compatible” for the last several decades ... will any of the new languages currently attempting to implement a binary comparability model succeed in shifting this in a meaningful way?

I’d love to see professional licenses switch to a “maximally fair to the user subscription model”.

If you use the thing in a given month, you autopay the monthly subscription fee — if you don’t use it at all in a given month — you pay nothing.

people who use the software regularly pay basically the current subscription pricing model — but if you only use it very occasionally — you pay much less.

I think this kind of pricing model could really help drive adoption of subscription pricing for professional tools ... I’d be willing to maintain a subscription to several expensive infrequently used by me tools with this kind of pricing model — and I might occasionally use those tools which would be better for the developer than me never using their tool at all ...

There are so many huge UI fails in Apple products nowadays ...

My most recent encounter is pretty much anything to do with Apple Pay (especially on the mac). I couldn't get any transactions to complete. Ended up being that my address didn't validate (apparently) because it was 'too long' -- good luck figuring that out via the (horrific) Apple Pay address form edit UI ...

Interesting - I definitely have only a surface understanding of the go community and had not respected that the community embraces the game’s “requirement to grind the combinations”.

I had always thought there was some element of recognizing its “impossible to ever even remotely approach a true grinding of the combinations” for go — and that somehow players _did something else_ effectively when they played at a high level. It’s that “doing something else effectively” that the defeat of humanity by go algorithms challenges ...

Would be super Interesting if there could ever be a reversal which might allow humanity to beat go algorithms once again ... is there any evidence from the strategies that the go community has learned by analyzing the new go algorithms that this could be possible? Or is there just more and more evidence over time than humans will never be able to compete effectively at go again?

I think alpha zero can self-train to mastery or super-human performance at any two player game with perfect information?

I’d be curious to know if that’s incorrect ...

This is interesting to me ... how exactly is this assessed ...?

Do people keep around versions of “alpha go year 2017” and play against it in order to measure human improvement over time?

If the basis for observing improvement has become “I can beat old versions of the ai more reliably than I used to be able to” or if I have learned to beat players who have not studied alpha zero I suppose that’s a form of usefully learning “about go” by analyzing the games played by alpha zero ...

I wonder if we might ever arrive at a point where human vs fixed-year x ai performance at go pretty much stops increasing over time ...?

I sympathize.

It used to be that you might be able to believe that there is some kind of art behind go, some sort of abstract beauty to it, and that the pursuit of this beauty is the path to being good at go ...

But the defeat of the tactics born from this mindset by MCTS at least for now lay bare the fact that the path to being good at go is actually to probabilistically sample the phase space of the game and perform impossibly mindless statistics on the game outcome an enormous number of times ...

To top it off — there is almost nothing “about go” to learn from watching alpha go play ... I imagine that attempting to analyze alpha go’s victories would produce an unending sequence of the feeling of never gaining any new insight “into go”.

The analysis of go is now about optimizing algorithms — which _is_ interesting — but I don’t think it’s interesting for the same reasons that someone might’ve been passionate about go in the past ...

Just saying -- transitioning a large project from one component system to another -- while also developing/evolving the new component system ...

I can just imagine it would be easy to build up a very large mess ...

Wow - that must be an incredibly messy UI codebase by now ...

I think the size of the networks they are training might already be good motivation for developing custom hardware for training.

I would expect their training hardware to be something specifically aimed at optimizing memory bandwidth to support distributing training of their “shared” hydra feature. It’s interesting that the shared hydra feature extractor is able to converge as they keep adding more and more output predictions under a training regime of interleaving asynchronous updates to the model from different predictor networks ...

Seems to me the formula they are pursuing with custom hardware might be to support a strategy of 1. keep adding more predictions based on same feature 2. Increase the span of time represented by batches used to train the recurrent networks

Both pursuits seem very data efficient in terms of the amount of training data they could conceivably collect per unit time of observation ...

Custom hardware with a problem specific memory architecture aimed at efficiently supporting training with very large rnn time slices could be developed that’s more about “make it possible to train this proposed model at all” rather than “make it faster/cheaper to train existing common model architectures”. When custom hardware is required to make it possible to train the model they want, the validity of the hardware development cost bet might end up being more about the effectiveness of the model they think they want than it is about maintaining general purpose performance parity vs any off the shelf hardware options ...

Those layers are why you need to measure the sound speed profile -- speed of sound as a function of depth. The variation in sound speed in the water column affects not only the travel time of acoustic energy -- but also the path -- (snell's law).

I used to operate multibeam sonar system on an oceanographic research ship. Getting good data from those kinds of systems is an interesting challenge.

The speed of sound in water is proportional to temperature and conductivity — which are approximately dynamic functions of water column depth and temperature (and time depending on the properties of the region you are in — the tenperature can change a lot over short time scales). You need to measure to measure these properties in order to obtain a sufficiently accurate sound speed profile to be able to trace the path taken by acoustic energy projected from the transceiver, off the sea floor and back to the transceiver. Inaccurate sound velocity quickly becomes one of the largest error terms in measurement accuracy. We computed sound speed profiles as often as we reasonably could — sometimes the science objective involved measuring these properties and we’d use data from those measurements but sometimes we were just transiting along and would draw from a supply of expendable bathy thermographs that we could use to make sound speed profiles periodically (but certainly not often enough to maintain accurate calibration all the time.)

The ship is moving and the orientation of the array needs to be accurately calibrated — shipboard MRUs are expensive and imperfect.

The water column is rising and falling and vertical position measurement accuracy is very low from systems like gps compared to horizontal measurement accuracy.

The ship is pitching and with many ship designs this can create bubbles which can be swept beneath the ship — a small amount of bubbles close to the transceiver head can absolutely overwhelm the noise budget of these systems.

I’d be curious to know how much data from ship mounted sonar systems are actually useable for large scale high resolution mapping. I believe the best teams that build high resolution global sea floor maps rely on satellite gravimetric measurements for baselines — and use very sophisticated algorithms to fuse shipboard datasets with the global gravimetry — which im guessing probably have to throw away huge amounts of information from the higher resolution shipboard systems ...

Will airlines go multi-supplier again or will they specialize in particular manufacturers? The cost to an airline to keep certified personnel on staff capable of supporting planes from different manufacturers is probably greater than the unit savings they could realize in a situation where price competition exists ...

How is it possible to make that determination after the crash ...?

You can’t live without prettier once your using it.

What exactly is the advantage of reaching a cash neutral position? If you are a company that can reliably do that does that mean you no longer have to grow — since your investors are primarily attracted to a reliably stable ability to generate dividends?

I used to have this tendency — initially I wasn’t aware of it — I was just passionate and talked about what I wanted to talk about. Eventually became aware of it and lived a period where I still talked about rock climbing all the time/overly much — but I was passionate and it was what I wanted to talk about.

At the time Rock climbing was also a pretty social experience for me. I derived joy from talking about it with others — and some people can talk about their passions in a way that helps others feel inspired. That’s a good thing I think.

Now I don’t do it anymore — but a part of me is sad that I don’t because it reflects a decrease in my motivation and “psyche” for rock climbing and decrease in my desire to share that “psyche” with others.

Why do the ground crew in picture have hazmat suits?

Linear Cross-Entropy Benchmark is the framework used to try and estimate the accuracy of the random-circuit sampling -- to try and determine how likely it is that the random circuits are being executed correctly on the quantum computer.

From Scott Aaron's blog post about this paper: https://www.scottaaronson.com/blog/?p=4372 -- he shares some thoughts on whether this benchmark is itself easy or hard to simulate on a classical computer.

> Ah, but at the end of the day, we only believe that Google’s Sycamore chip is solving a classically hard problem because of the statistical test that Google applies to its outputs: the so-called “Linear Cross-Entropy Benchmark,” which I described in Q3 of my FAQ. And even if we grant that calculating the output probabilities for a random quantum circuit is almost certainly classically hard, and sampling the output distribution of a random quantum circuit is almost certainly classically hard—still, couldn’t spoofing Google’s benchmark be classically easy?

He goes on to supply an argument that its a hard test to spoof classically.

I'm wondering though -- has anyone addresses how hard it would be to spoof this benchmark using a collection of smaller (potentially non-scalable) quantum computers ...? E.g -- if it were possible to spoof the benchmark with a smaller quantum computer -- would that undermine the argument in the paper that this benchmark is evidence of quantum computing scaleability ...?

This seems like a really good idea to me. Is it possible to do in a way that preserves privacy and doesn’t basically become a hidden “telemetry” system?

Off topic but — anybody know a good/recommendable vpn service that supports MacOS without requiring third party software and which allows inbound access to the external ip associated with the service ...?

I need to ssh back to my laptop frequently because of some annoying restrictions with a service provider I use (heroku). I _can_ do shenanigans with ssh tunneling on a publicly accessible server I control - but it’s actually pretty annoying to work that way in my scenarios.

I’ve tried a few vpn services that offer “static ips” but the services I’ve tried filter inbound connections to that ip ... does anyone know a good vpn service that can effectively gives me a public IP address so I can make inbound connections to my developer machine while I’m random shitty coffee shop WiFi ...?

> I think the killer language will be typescript with access to both the python and JavaScript ecosystems. We'll see what that looks like.

I think this is an extremely good idea. Python is horrible but forced on a huge number of developers because of its ecosystem ... I think a bridging layer from typescript to python could be built in a way similar to swift’s Python Interop — and I don’t think it would require any special language support ...

I think could actually make a better/easier to use/more robust design than Swift by requiring all interactions with the python interpreter from node be async.