indeed30

The radioactive decay example specifically? Fit A and k (e.g. by nonlinear least squares) and then use the Jacobian to obtain the approximate covariance matrix. The diagnonal elements of that matrix give you the standard error estimates.

I think we are just coming at this from different angles. I do understand and agree that we are estimating the parameters of the fit curves.

> That already makes strong modeling assumptions (usually including IID, Gaussian noise, etc.,) to get the parameter estimates in the first place

You lose me here - I don't agree with "usually". I guess you're thinking of examples where you are sampling from a population and estimating features of that population. There's nothing wrong with that, but that is a much smaller domain than curve fitting in general.

If you give me a set of x and y, I can fit a parametric curve that tries to minimises the average squared distance between fit and observed values of y without making any assumptions whatsoever. This is a purely mechanical, non-stochastic procedure.

For example, if you give me the points {(0,0), (1,1), (2,4), (3,9)} and the curve y = a x^b, then I'm going to fit a=1, b=2, and I certainly don't need to assume anything about the data generating process to do so. However there is no concept of a confidence interval in this example - the estimates are the estimates, the residual error is 0, and that is pretty much all that can be said.

If you go further and tell me that each of these pairs (x,y) is randomly sampled, or maybe the x is fixed and the y is sampled, then I can do more. But that is often not the case.

I don’t think you can do anything sensible here without making much stronger modelling assumptions. A vanilla non-parametric bootstrap is only valid under a very specific generative story: IID sampling from a population. Many (most?) curve-fitting problems won't satisfy that.

For example, suppose you measure the decay of a radioactive source at fixed times t = 0,1,2,... and fit y = A e^{-kt}. The only randomness is small measurement error with, say, SD = 0.5. The bootstrap sees the huge spread in the y-values that comes from the deterministic decay curve itself, not from noise. It interprets that structural variation as sampling variability and you end up with absurdly wide bootstrap confidence intervals that have nothing to do with the actual uncertainty in the experiment.

As long as UK taxes are flow-based and not stock-based, it seems a bit silly to base analysis on a stock-based denominator like the number of millionaires.

I wouldn’t call the embedding layer "separate" from the LLM. It’s learned jointly with the rest of the network, and its dimensionality is one of the most fundamental architectural choices. You’re right though that, in principle, you can pick an embedding size independent of other hyperparameters like number of layers or heads, so I see where you're coming from.

However the embedding dimension sets the rank of the token representation space. Each layer can transform or refine those vectors, but it can’t expand their intrinsic capacity. A tall but narrow network is bottlenecked by that width. Width-first scaling tends to outperform pure depth scaling, you want enough representational richness per token before you start stacking more layers of processing.

So yeah, embedding size doesn’t have to scale up in lockstep with model size, but in practice it usually does, because once models grow deeper and more capable, narrow embeddings quickly become the limiting factor.

I think it's actually (2020)

Ten years ago, I worked for a company that had billions of sensor readings from mobile phones. The idea was to use crowdsourced data to create truly detailed, real-world coverage maps, and then sell that data to marketing and network operations teams at telcos.

We used reverse geocoding extensively — but never down to street addresses, always to a higher level. We wanted to split measurements by country, region, city — any geographic unit. When you deal with country borders, you get a lot of weird measurements as phones roam onto foreign networks. We weren’t interested in reporting on the experience of users roaming while abroad, so we needed shapefiles good enough to filter all that out and to partition the rest of the data cleanly.

We built a 30-machine Spark cluster on AWS back when Spark was still super early — around v0.7, definitely before 1.0. At the time, you pretty much had to use Scala with Spark if you cared about performance. Most of the workload was point-in-polygon tests. Before that, we were using a brutally hacky pipeline involving PostGIS, EMR, and Pig, and it was hell.

It was incredibly fun, but looking back now, I can see so clearly all the mistakes I made.

I would be pretty confident that Disney has a pricing team whose entire job is to model those effects.

So, can somebody in the know speculate about how Deepseek (or OpenAI, or whoever really) is actually running their API?

If I wanted to run a production-grade service using the full Deepseek model, with good tokens/sec and the ability to serve concurrent requests, what sort of hardware are we looking at?

That's interesting - I believe this is exactly how Sequelize implements soft-deletion.

To discover where else you then subsequently forwarded it.

I'm not suggesting this is actually a problem, but that's how an argument could go.

I don't disagree with what you say, but one difference is that we generally hold these people accountable and often shift liability to them when they are wrong (though not always, admittedly), which is not something I have ever seen done with any AI system.

I'd also mention that Tom McCarthy's "Tintin and The Secret of Literature" completely changed the way in which I viewed the series - genuinely exciting stuff.

Hang on a minute. There is absolutely nothing in this research that measures the accuracy of this approach. A user saying "I was ghosted" is not, to my mind, proof of anything.

Job seekers almost never actually know if the job was real or not, so it's hard to see how Glassdoor reviews can ever provide the insight this work is looking for.

I do believe that "ghost" jobs exist, often for H1B purposes, but I don't think this work proves it.

Easiest way is going to be to downsample the images and then apply a pre-trained classifier that can ignore the fact these are sat images. You could probably turn them into 28x28 greyscale and then use a model trained on handwritten characters, like EMNIST.

Whatever approach you take, you'll probably be selecting the final set by hand, so it's just about building the candidate set in an efficient manner. Low absolute accuracy isn't really an issue as long as you end up with a managable set to review.

I'm not sure what the complaint is here. I don't mind saying outright that I believe ethnicity is deeply intertwined with culture and that the two concepts are inseperable. Ethnic groups are essentially defined by their shared heritage, experiences and culture. When we talk about cultural diversity, we inevitably also discuss the ethnic diversity of a population.

I really don't think that is a controversial position, but clearly you disagree.

I'm interested in what you're comparing against. Denmark is typically towards the bottom of any measure of cultural or ethnic diversity - e.g. https://en.wikipedia.org/wiki/List_of_countries_ranked_by_et...

I have been to Denmark many times and it strikes me as considerably more homogenous than the UK or the US.

That's not my perception of the industry right now. I think what you said was true two years ago, but not any more.

Couldn't it be possible for ear protrusion to be uncorrelated with the other variables but still have a genetic basis - presumably by depending on a set of genes with little overlap over the ones that govern size?

It makes enterprise sales easier, since it removes a common objection from security, privacy and compliance teams.

No it doesn't - note the axis marks are every two years.

> At that point, the curve levels off, and as the number of typical questions die off because they've already been asked and answered many times, the number of new questions has to trend downward

Yes, absolutely, and the article addresses precisely that point. But the questions graph shows a drop of about 40% at exactly the point in time when ChatGPT launches, which is much too extreme to explain away like that.

Semantic search is what the commenter suggested. That's the most commonn use case in my experience too.

You have to say that Pinecone got the timing absolutely right.

The early generation of SaaS employee engagement platforms (Glint, CA, Peakon) found their success in replacing legacy consulting providers (who had fantastic services but terrible tech) with faster, better integrated, better designed and more automated solutions. That market was huge and everyone did very well out of it.

Today it is a much more mature market, and as rightly pointed out, a survey platform is no longer enough. But there is still so much room for innovation. Actually improving employee engagement is far from solved or commoditised, and I believe that anyone that can bring an original idea that can be proven to lead to real-world change can still find a place in this industry. Personally I believe that any future success stories are likely to be focused less on customisation and configurability, and more on opinionated takes that suggest better ways to manage and measure employee engagement.

The idea of linking HR initiatives to measurable change is a good one! But it's fairly easy to see that you can extend it to 'events' more widely. Customers don't just care about what HR has been doing; they want to know what impact virtually any event has had on their employees, whether internal, external, global or local. You may have noticed that over the last few years the buzzword 'moments that matter' has become pervasive in our industry, and you can see the majority of providers have delivered some kind of feature to capitalise on this.

One final point is that I would say that the idea that HR is responsible for improving employee engagement is a little dated. I think it is uncontroversial to say that HR does not have the time or resources to actually do anything about employee engagement themselves. The modern role of HR is as enablers, measurers and instigators - undoubtedly a key stakeholder - but ultimately if you actually want to change something then the responsibility has to be more widely distributed.

Disclosure: I was an early hire at Peakon, an employee engagement company, and I ran the ML and DS functions for four years until our acquisition by Workday, where I still work on Peakon today.

Guess: The emails are sent slowly, in small batches. The email addresses are selected in alphabetical order, and this recipient appears towards the end of the list. Therefore as subscriber count increases, they get the email later and later each day.

I love R more than any other language I have ever used. Perhaps more than any piece of software I've ever used. All of these points are valid, and yes, it's messy, and if you try to write the same type of code that you would in Python, it will frustrate you.

And yet.. it somehow works. It makes data analysis and statistical modelling a pleasure. It somehow gives off a sense of lightness, and makes it easy to investigate and explore. I would guess I am genuinely 2x as productive in R as I would be in Python on similar tasks.

I know it's not a "proper" language, but I think that, maybe, not everything has to be exactly like "proper" software engineering?

No, I understand that. I guess my question is actually around your experience with "You can argue that is sufficiently obfuscated to not count as PII" and whether your customers are actually successful with this argument.

Does Pinecone have any position on the status of document embeddings and whether they would be considered PII? One of the challenges of using a fully managed service is the headache of adding yet another data subprocessor and all of the legal and compliance questions that raises.

As my career progresses I find myself increasingly leaning towards opinionated tools that sell a methodology more than flexibility, for exactly this reason.