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
> As for square roots, the reason why you can't use the underlying architecture is that it only works on the native i16 type.
My understanding of your code is that you've got `struct Number { int16 a,b,c,d; };` and the value of a number is equal to the floating point number 256.0a + b + c / 256.0 + d / 65536.0. (if the arch had floats, which it doesn't) If this assumption is wrong, my bad.
What I'm proposing is that you do `b = i16.sqrt(256a + b); a = 0;` then do 1-2 iterations of newton's method. For instance, if you have the value 1234.56789 then i16.sqrt(256*a+b) = i16.sqrt(1234) = 35. So your first approximation is x = 35.56789. Do x = (x + 1234.56789/x)/2, and with floats you get x = 35.139035. Do it again, you get x = 35.136418. The true value is also 35.136418, so there ya go.
> I'd be concerned about Newton's method (specifically the squaring of x_n) overflowing the fixed point.
I may have lost the plot. Are you calculating _inverse_ square root? x_n isn't squared for Newton's method of square root, but it is for inverse square root.
(Either way, the square of the square root of a number should be the same as the original number. So if you have overflow, you have other problems.)
Unrelated: What do you need pi and trig functions for? I wrote a ray tracer (actually a path tracer, same diff) about a year ago, and I only used trig/pi to set up the camera for the render. While the render was actually rendering, no trig was happening. It didn't matter for me, so I just used the standard library, but in your case it would probably be fine to use slow brutish methods.
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.
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).
I think the parent was stating that it'd be neat (if possible) if Penny detected your location and flagged you with an geolocated alert at that point. Like a giant "really?! Target again?! You just spent $20 here yesterday!" (If it already does that or if I'm misinterpreting, please forgive!)
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.
> The other aspect is that banks are really good at physical security, but not so great at data security [..snip...] but at least they're modern technology companies that probably hold themselves to higher data security standards than your bank.
Except this doesn't actually improve your banks' security at all, it's only adding another (attractive and high-value) attack surface in addition to any potential vulnerabilities that your financial providers may have.
Maybe the friction would be too much for most users, but I'd be way more likely to try something like this if there was an option to handle the data myself with an export/import process from my financial providers and not have any account credentials shared at all.
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.
I can see the chat interface being built out by itself as a stepping stone to adding integration to Google Assistant / Google Home which would be neat.
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.
Makes sense, thanks for responding. I'm personally partial to chat UI when appropriate, and it does seem like this approach helps reinforce the personalized coaching aspect. Good stuff!
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.
You'll probably find that Canada is in there for free. If you guys use the same Intuit link that Level uses, you'll probably find "Royal Bank of Canada" and "Royal Bank of Canada (US)" in the list of supported institutions. Level worked great in Canada if you went through the effort of downloading it from the US AppStore.
I just tried this and it seems to work ok. I was able to link my BMO and Capital One Costco accounts. TD didn't want to sign in.
Knowing that this is possible, I wish more of these services officially offered their products cross-border. I'm not a huge fan of Mint, and have always figured the cool new apps were US only. I guess French language support might be a roadblock.
