I was curious about this since it kind of makes sense, but I offer a few reasons why I think this isn't the case:
- In the 10% noise case at least, the second descent eventually finds a minima that's better than the original local minima which suggests to me the model really is finding a better fit rather than just reducing itself to a similar smaller model
- If it were the case, I think we might also expect the error for larger models to converge to the performance of smaller models? But instead they converge lower and better
- I checked the logged gradient histograms I had for a the runs. While I'm still learning how to interpret the results, I didn't see signs of vanishing gradients where dead neurons later in the model prevented earlier layers from learning. Gradients do get smaller over time but that seems expected and we don't have big waves of neurons dying which is what I'd expect to have the larger network converge on the size of the smaller one.
Thanks for the analysis. I'm a seasoned ML researcher but I wasn't aware of the phenomenon. Not sure yet how to make sens of it but the blog post was great
I built a personal finance app (https://tender.run) in the style of mailbox (swiping, keyboard shortcut, inbox-based workflow for reviewing transactions).
It's built on the automerge CRDT and sqlite running in the browser, which has been really fun to work with. I'd like to keep going, though honestly I've struggled with the marketing side (growth has been slow) and it's a pretty competitive space.
Sort of relatedly, I’ve been fighting Safari bug for years that feels like it has to be related to dates in js.
Safari’s saved credit card support works pretty well, but when I switch between US and Asia timezones the expiration date will shift by a month in one direction. My best guess is that they store the expiration as midnight local time on the 1st of the month in a js Date which can shift when you travel outside of that timezone.
I’ve been building a personal finance app that runs fully in the browser (using the automerge crdt and sqlite) for over a year now at https://tender.run.
Recently I’ve been taking more of being able to flexibly run sql against this data, and this past week I’ve been working with d3 to make fancy sankey graphs to show income/expense flows. Quick preview here: https://demo.tender.run/reports/sankey
That looks quite nice and the local first approach was a good idea.
I wonder how it will compare to ActualBudget and its pre/post rules and the GoCardless account data importer.
Side note: The first col of all text overlaps with some other text on mobile devices (both landscape and portrait mode) and thus is unreadable.
Also the inbox didn't work an I can't look at the inbox as the filters stay open.
Edit just noticed that this is a SaaS. If it would be a single payment for a license or sponsored FOSS, I believe it could work. The current way, I would assume that it will meet the fate of all the other apps in this non-market. Good luck though!
Pretty interesting take on a finance app! I like the inbox and filters on transactions. I'm not sure I understand the benefit of storing it all in the browser though. Does the data just live in the browser? Does anything store on a server?
Originally this was a privacy angle - the data is primarily stored on your device, with backend storage that’s treated like backup and sync only. I had plans for e2ee that built on this but it didn’t turn out to be a big differentiating factor.
Working in local-first turns out to be really nice for making the app feel super snappy. The responsiveness you see in the demo is the performance you can expect in day to day usage.
It's sad to hear that the new app encrypts everything.
A long time ago I worked on hacking airplay support for sonos speakers and it wouldn't have been possible without inspecting a lot of plaintext wireshark traffic.
As much as I've have cited, loved, and recommended sourcegraph (even going so far as to help run the open source version at a previous co), I never paid a cent for the product.
I'm curious about the line of thinking in leaving open source behind, but it seems somewhat unsurprising in that lens.
Thanks! We appreciate you. It was really a focus thing. It added a lot of overhead, lost focus, and risk to have stuff be open source. Most customers weren't telling us it was valuable to them, and frankly we heard very little from people who were using our open-source build. (How could we have gotten your input earlier?)
We still have a lot of open-source code, but ultimately we need to focus on building a great product and making money on it. Which we are doing. :-) As Sourcegraph CEO, I obviously wish we could do all the things, but we gotta stay focused on building a great code search/intelligence product.
why would consumers who can afford to use credit cards with rewards switch to fednow payments? are there equivalents for chargebacks, fraud protection, and rewards percentage?
Merchants are starting to surcharge credit card transactions to push the fees onto customers (rightfully so). If you want credit card benefits, you can still get them, you just have to pay for them.
This bifurcates the payment choice, so people who don't want these conveniences can avoid the cost (instead of all of us having to pay for it through internalized interchange costs) but those who do can continue to receive those benefits at their own cost.
Walmart notably filed public comments in support of FedNow [1], and they are working internally to support these rails to avoid credit card network costs.
I just tried to do this with chase, capital one, and citi. The first two only let you pay up to 10% more than your balance (balance, not credit limit) and citi only 7.5% - nowhere near 10x your credit limit.
I was curious about this since it kind of makes sense, but I offer a few reasons why I think this isn't the case:
- In the 10% noise case at least, the second descent eventually finds a minima that's better than the original local minima which suggests to me the model really is finding a better fit rather than just reducing itself to a similar smaller model
- If it were the case, I think we might also expect the error for larger models to converge to the performance of smaller models? But instead they converge lower and better
- I checked the logged gradient histograms I had for a the runs. While I'm still learning how to interpret the results, I didn't see signs of vanishing gradients where dead neurons later in the model prevented earlier layers from learning. Gradients do get smaller over time but that seems expected and we don't have big waves of neurons dying which is what I'd expect to have the larger network converge on the size of the smaller one.