Thanks for the suggestion. I've considered this, but since it's a free app I didn't want to expand the maintenance burden beyond what I can keep up with.
There are some other things I want to improve first, but I'll definitely consider this if I see more demand/requests for it.
Nope, I haven't compared those. It roughly follows common core, so it should be somewhat similar, but I'm not sure how each of those based their curriculum.
Plus I added automaticity related topics from some Math Academy courses I want to take to help raise my learning ceiling.
Yeah, common core doesn't really give you the graph at the granularity I'm using. I mostly use it as a curriculum/placement authority.
The more granular decomposition is something I built separately. I take a standard/topic and break it down into coherent concepts, then into the smallest independently useful retrieval skills I want to track. For Mathy that's especially constrained because I only care about things that make sense for automaticity, not everything you'd need to teach the subject.
So for example a standard might imply multiplication/division fluency, but internally that gets decomposed into individual mathematical relationships and retrieval directions. `7 × 8`, `56 ÷ 7`, and `56 ÷ 8` are related, but they're not necessarily the same learning state.
Then for procedural material I define bounded problem families rather than copying individual questions. A family specifies the operand domain, mathematical rule, intended strategy, answer form, exclusions, hardest cases, etc, and the questions are generated deterministically from that.
So unfortunately I don't have a magical curriculum-generation hack :) It's been a combination of standards/course outlines for scope + a lot of decomposition + AI helping propose/check things + deterministic validation afterward. It was a lot of experimentation, and I still have room to improve.
I also intentionally don't copy questions from textbooks. The standards and public course outlines tell me what belongs where, but the actual problems/content are independently authored or generated. That makes it much easier to reason about correctness, coverage, etc.
For the domaine, yea, it's important. I built-in steaks and XP/levels since I could borrow the general approach from a previous habit tracking app I made (maincharacter.game). I also added medals for achievements. The website version has a leaderboard, which I may also add to the iOS app, but would take some add'l work since it's currently offline only ATM.
The goal of the product is to give practice and help build automaticity in topics you already know, which makes learning harder stuff (e.g. through Math Academy) easier later to raise your ceiling.
So, I'm not sure if maybe you're less familiar with the material (below the threshold) and you should take a course focused on teaching the material OR that the material in Mathy is too hard for the selected topic. Because if you're familiar, it should be helping you rather than frustrating you.
It's an offline app so I don't capture that kind of data. But you make a good point, and at a minimum for each topic I can have it start with easier problems then increasingly get harder as you do better.
I'll think more about that today and maybe get a fix out once I have some time.
You know, I hadn't actually considered iCould sync, thank you! I didn't like the idea of not syncing devices either, but couldn't justify just eating the storage costs since it's a free app.
But using iCloud would let users cover their own storage costs for syncing practice/progress/medal/challenge data.
I'll take a look at implementing this when I get some free time so I can have high confidence in the approach. Thanks again!
Thank you! ANd thanks for sharing, that was a good overview and I had a similar experience.
To answer your question, I'm a product guy, so it was easier for me to start with the user app/mobile UX I wanted + constraints rather than starting with the cards.
Then I created a problem view in the dev version of the app that let me see every type of problem to see how it rendered, how input worked, etc.
Then with that plus the system around it (details below) gave me higher confidence in generating the 40,000+ problems across all the topics. It still has room for improvement, but happy with how it came out so far.
So, for the problems, they were programmatically generated, but NOT LLM-generated/trusted, so the process would give me the confidence:
1. Define the problem families explicitly. Each has bounded inupts, known mathematical rule, answer type, constraints & presentation rules.
2. A deterministic compiler generated the problems. So, given the same source definitions/versions itd produces the same corpus. so there's no AI inventing random questions at runtime .
3. Correct answers are computed from the underlying math, not from the rendered text. Integer/rational problems use exact arithmetic. More complex symbolic cases use validation recipes, incl. offline SymPy if needed.
4. LaTeX is just presentation (tried other way, didn't work). Internally the problem is represented as structured math, then laTeX/MathJax derives from that structure, so it doesnt generate a LaTeX string and cross fingers its interpreted correctly.
5. Generation/verification are separate steps. Every generated record has to pass mathematical, domain, schema, answer format & presentation checks before it can enter the corpus. Symbolic cases can be independently verified, for example by differentiating a proposed antiderivative.
6. Whole families are tested, not just samples. Finite spaces can be exhaustively enumerated. Larger spaces get property, boundary, invariant, and regression tests. It also runs corpus-wide audits for malformed questions, duplicate IDs, invalid answers, broken rendering, unreachable answer forms, etc
7. The shipped artifact is tied back to what was verified. Versions/content digests bind source definitions, generated problem, validation result & runtime representation together. If something changes, it has to be revalidated rather than reusing old results.
So, starting out I assumed doing it programmatically would be liability. But rather confidence comes BECAUSE it's programmatic. For a large class of problems deterministic generators + exact/exhaustive validation was easier to audit than tens of thousands of hand written questions. So could leverage AI for all that, just had to define the rules/review the system.
I'm very happy with the outcome, but in terms of process it far exceeded my expectations in what I learned about approaching problems like this.
I'm a very heavy AI coding using (I burn hundreds of billions of tokens a year!) so this was a fun way to validate my approach and test some new ones to build high quality experiences, particularly on mobile which is more of a taste thing. The decade plus of product experience really came in handy in guiding the AI here, which took a lot of iteration on the experience and trying different things. It was a blast, and I was generally surprised at how fast it came together. Thank you again.
Thanks. Yeah, related but problem families are more separate from the knowledge graph.
To be clear, the knowledge graph here is different than the Math Academy sense. What they have is far more impressive since it's for learning and convers prerequisites, related topics, etc. Where mine is more specifically focused on automaticity, with the assumption you've already learned it and just want to maintain/improve recall.
A recall target is basically the smallest piece of knowledge that gets its own spaced repetition state. So, for example, `7 × 8` can be one target. `8 × 7` is just another presentation of that same target, while something like `56 ÷ 7` is a separate inverse retrieval target.
A "problem family" is more of an authoring/generation construct layered onto that. E.g. is defines a bounded class of problems w/exact operand ranges, mathematical rules, expected answer forms, exclusions, presentation rules, etc. It can then deterministically produce valid problems for the relevant targets. So its not a 1:1 mapping between graph nodes <> problem families.
For the curriculum I tried to keep mathematical identity separate from curriculum placement. The internal graph is organized around coherent mathematical concepts and independently meaningful retrieval skills. Then grade/course views are mappings over that graph. It should roughly follow common core, but with some gaps since I only wanted to cover stuff doable in your head. I also covered add'l memorization topics to supplement the Math Academy courses I plan to do since I'll need those myself. I didn't get them all, but I know the MA team plans to add automaticity stuff, so I assume by the time I get to those they may already cover it anyway.
To clarify SymPy does not ship in the iOS app. It;s only used offline during the content build/validation process for the classes of symbolic math where it's useful. The app only ships the validated content. Runtime grading is bounded + local. E.g. there's no Python, SymPy, runtime AI, or unrestricted CAS running in the app.
I had to iterate a lot to get it performant, working 100% offline and at a manageable size with so much content. There were some compromises but it works reasonably well so far.
Thank you! Yeah, Justin Skycak's writing really turned me on to the benefits of automaticity. Once you're aware of it you start to notice everywhere you lack it and how much it'd help in raising your ceiling.
There are some other things I want to improve first, but I'll definitely consider this if I see more demand/requests for it.