OK, I got what you're saying now, thanks! I got my wires crossed; I thought Newton's method was something else, but I was actually already implementing that.
I think it's a clever idea to use the native square root to seed the guess. That hadn't occurred to me. In my solution, I do integer square roots, and the fixed just dispatches to that, so I could drastically improve my guess if I used the native square root there. Nice idea!
And I don't use trig. I mention it just for fun. In the original Rust raytracer tutorial, they use trig to set up the field of view, but I hardcoded it to 90 degrees to remove the trig.
That would've been fun too as a different challenge (I wrote the blog post). My main hesitation was that doing so might prevent me from using the built-in VM/hardware emulators they provide, so I wouldn't be able to easily run my solution.
Wow, that is indeed way cooler than what I knew! Thanks a lot for sharing (I wrote the blog post).
As for square roots, the reason why you can't use the underlying architecture is that it only works on the native i16 type. That's why I had to reimplement integer square root in the Int32 and then fixed point square root using that.
If you're saying that I could just ignore the Int32 part of the code and implement square roots just for the fixed point using the underlying architecture, that's definitely doable, but I'd be concerned about Newton's method (specifically the squaring of x_n) overflowing the fixed point. Maybe it'd work and I haven't thought it through enough. Thanks for the suggestion :D
We built everything by hand. Cordova is our glue to the native side, but React is what really makes the chat stuff tick.
As for the Ruby/JSON stuff, that was also built by hand (actually the very first thing we built before we even had the UI in place). Whenever a conversation is started, the client gets the entire syntax tree from the server and evaluates it to make the conversation happen. We actually thought that pushing the state to the client actually made things easier since the server no longer has to manage the status of many concurrent conversations. It also means faster responses in poor network conditions.
I think the main reason for chatbot platforms to push things to the server is out of necessity because they work across many clients (Messenger, etc) where they don't control the client, and because they may be doing some heavy lifting with NLP that can only be done on the server.
100% agreed. Yet another benefit of a single endpoint is that we rarely have to worry about backwards compatibility. It's a huge tax on engineering time to support those few users who're using a client that's six months old. We don't have that issue.
Yup, Penny tries to focus on your discretionary spending since that's where you have the most agency. She tells you both your non-bills spending (assuming bills are mandatory) and your total spending, so you can get a sense of your spending that isn't basic needs. We also have spending goals which are curated to be mostly discretionary spending (eating out, department stores, etc).
Yup, though our emphasis is more on making finances as relatable and friendly as possible. The chat interface isn't just a skin on top of existing data (which some other chat interfaces can feel like), but completely dictates the entire experience. This is super relevant for our goal of coaching people to better financial health—chat is a great medium for coaching, but a traditional UI would probably be more difficult.
Privacy and security are really big priorities for us, so we do our best to address those concerns whenever we can. As far as personal info is concerned, we store the minimum possible info (first name and email, no address, DOB, etc). And we use a popular service called Plaid to do the transaction retrieval, so we never store sensitive credentials. Plaid actually powers many, many other financial services, so they're quickly building a great reputation themselves.
The other aspect is that banks are really good at physical security, but not so great at data security. Consider the recent Chase breaches, where a ton of sensitive data was leaked—you're obviously placing a lot of trust on Intuit or Plaid whenever you use Mint or Penny, but at least they're modern technology companies that probably hold themselves to higher data security standards than your bank.
Hey, co-founder here: I'll be the first to say that the chat interface isn't for everyone. If you'd prefer to get the facts with minimal extra stuff, Penny might not be for you. What we've found from working on this from so long is that the chat interface goes a long way towards making finances relatable and easy to understand. For most people, the biggest barrier to personal finance literacy isn't education; it's motivation. So celebrating wins like paychecks coming in actually helps a lot—feedback says people love being told they got paid and celebrating.
Great point about two-way vs one-way. We find that it's still valuable for one-way communication because our main goal is to make finances relatable and easy to understand, and a chat interface literally forces us to be simple and clear in how we explain. Certain concepts might be easy to name but hard to explain (APR, rolling average, prorated spending), and a chat interface allows us to teach those concepts in great detail.
For example, here's a excerpt from explaining how credit card interest works:
Penny: Chase charges you interest based on your <em>APR</em> (annual percentage rate).
Penny: You probably saw this number when you signed up for your credit card :credit_card:
Penny: APRs are usually about 12-24%.
Penny: As far as I can tell, your Chase Freedom's APR is about <em>{{ numeral(0.15).format('0%') }}</em>, which is about normal.
You: OK
Penny: To compute how much interest you get charged every day, divide your APR by the number of days in a year, like this:
<rest of conversation>
We also do a fair amount of two-way communication when we're understanding a user's circumstances. When Penny coaches people about investing, we try to understand the user's financial situation based on how much risk they're willing to take, how much they have that's investable, their horizon for returns, etc, all of which fits pretty naturally into a chat interface.
By the way, this is US only. We only link to US banks, so it wouldn't be very useful to download the app in a different region. Our team is pretty small, so international expansion probably won't be in the radar for awhile.
Sorry about that! Since we only link to US banks, we're only available in the US. Hopefully international expansion will be a thing, but we're a little too small for that at this point.
Since we use Cordova, the entire app is a website. So when you open up the app, it launches a webview pointed to a website that we deploy to like any other website. That means we can change any client logic and it'll go out in minutes. We also have a conversation DSL that lets us make conversation flow tweaks in under a minute, and since the bulk of the app is conversations, that allows us to move super quickly.
Great question about the changelogs! Since we don't have a longer cadence between feature pushes since we're deploying all the time, we have to go back and look at historical pushes whenever we need to write a changelog. We typically roll up all the little features and announce them whenever we make a new version in the app store. On top of that, we usually announce new features inside Penny, where she'll give a little intro on the new functionality. That also doubles as onboarding to the new feature if needed.
Our biggest differentiators: more focus on automation and friendliness. The major pain point we discovered is that average people find finances intimidating and difficult to track. We wanted to take as much of it off of people's hands as possible as well as doing everything we can to make the experience as friendly and engaging as possible. That goes a long way to making something that people feel comfortable using. We think Mint is a powerful tool with a much steeper learning curve, and we wanted to build something that anybody can use.
I was just thinking about this yesterday! I went with https://app.simplenote.com instead. Your app probably won't be compelling until you add more specific features that beat a generic note-taking app.
I originally built this for personal use while bored at a previous company, but ended up reviving it for external use over the past couple days. Hope you like it!
Hmm, that's surprising to me, since all the cards are loaded into the DOM regardless of whether or not the extension is active. The only memory footprint should be from the extension itself, which should be minimal since the code is so simple.
In fact, you might even observe a speedup because fewer elements are being painted, but the difference as a whole should be marginal.
Are you experiencing actual slowness from using the extension? I'd be really curious to know.
You're totally right that people who have trouble managing money in general don't use these kind of apps. Before starting work on Penny, we asked a hundred or so people "how do you manage your money?" The prevailing answer was, "I don't." So when you give them the tools to do that, it really helps them understand their situation.
What we see as the real problem is comprehension and usability. Many people we talked to shy away from apps like Mint because they're complex and intimidating. From a more technical/analytical/affluent standpoint (where I come from), I don't have an issue using Mint and querying my own data, but it's important to remember that I'm different from most people. So, we think that giving people that awareness of their financial situation in a friendly, relatable, and understandable manner goes a long, long way.
Regarding continued use: everybody's finances are a representation of their life, and as life changes, your finances do too. So we think there's a lot Penny can do to help you on an ongoing basis, like tell you about how your new commute to your new work is affecting your gas spending and your savings rates; mention how Comcast just bumped your bill up by 10%; point out that your Starbucks spending has been trending up and might start being a significant money drain, etc. We might be wrong, but we think we and everybody else in this space have only scratched the surface of what insights can help people with their finances.
I think it's a clever idea to use the native square root to seed the guess. That hadn't occurred to me. In my solution, I do integer square roots, and the fixed just dispatches to that, so I could drastically improve my guess if I used the native square root there. Nice idea!
I use pi just for normalization of the light power: https://github.com/aquach/from-nand-to-raytracer/blob/main/r...
And I don't use trig. I mention it just for fun. In the original Rust raytracer tutorial, they use trig to set up the field of view, but I hardcoded it to 90 degrees to remove the trig.