Welcome to the forum!
Nice work! (writing a library shows the ambition to deliver high quality)
Some improvement suggestions (ideas)
Complementing: check what's already in the "official" SciSnap! library - e.g. they have sets, and integrals, too. Perhaps you can focus on adding to that, by creating complementary functions and advanced versions (e.g. Simpson's rule as an alternative to the trapezoidal rule).
Documentation: write a comment on what a block does, requirements on the inputs, etc., and connect it to the block's header - thus it will pop up when a user right-clicks the block and selects "help".
Correct errors: e.g. is clearly incorrect. So is .
Optimization: there are opportunities to reduce code by using higher-order functions (such as MAP) and reusing some of your own blocks (e.g. logarithmical regression may build on linear regression, which I guess may in turn build on the detailed statistics block). Although some of this was used in your current version, it could be more widely used.
Further expansion: many areas in math have not yet (or hardly) been covered by your library, e.g. graph theory (I recently built a shortest-route finder according to Dijkstra's algorithm), topology, combinatorics, equation solving, and many more.
Oh, Ordinals! I want to experiment with ordinals, and also make a fast growing hierarchy function in it. I will still try to make my own Ordinal Library even if you do. Make it's own category for it, or put it in the sets category.
the original predicates can already return numbers instead of true and false
also, i made a simpler (round (x) to (y) digits) reporter (altought this one won't add zeros if the number of digits i want to round the number to is greater than the actual amount of digits)
I removed it because I found a better way to calculate it, but then forgot to implement it.
I can try to fix this
I could implement it, but that might take a while because that's not something I'm learning in school. No guarantees though since that's an entirely different rabbit hole to get into
I'm definitely doing this since some blocks are pretty old and come from the beginning of my Snap learning. After all, it was a fork of U2L4-Math Library.
Definitely thinking about expanding the library and adding more functions, just need to think about what to add first since most of the things in the library right now is things I currently know and understand.
I can try to understand SciSnap and implement some of it
I did think about adding this, but I wanted to try and build my own.
That's interesting, something I didn't know
Will try to fix things later today.
What other improvements should I make to the other categories? I also need ideas for my AP CS project.
I meant complementing SciSnap!, that is: building stuff they don't have yet, and that will nicely fit on what they do have.
But perhaps that's what you intended in the first place.
This one is really hard to implement correctly. Not for well-behaved* functions perhaps (calculate f(x) for some large values of x, and test if the differences become ever smaller for higher values of x; if necessary: try again from 2x, and so forth). But for tricky functions like , it won't work, at least if you choose integer values of x only: f(x) appears to move towards 0, but is actually periodical. And how about: , or even a discontinuous function that will behave differently when x is crossing some very high number? Alternatively you can ignore all that when coding, and document your block's limitations.
(*) ... whatever that may be
A more advanced approach to this loophole: don't analyze values of f(x), but analyze f itself. That would involve deconstructing the code, which is interesting enough if you're into abstract mathematics, but also quite complicated in itself. I can see that you already tried your hand at it (what if f = ?).
Was pretty much the only test that I did for this block
The block definitely does not work for trig functions when checking for x-> ∞ or -∞. My Nspire throws a undef since it checks for it, but mine doesn’t.
I guess we’ll just have to make the number it checks for bigger
Okay. Well, then, my advice is to make the minimal project that will let you answer their questions exactly the way they want. For instance, they want an iteration. Their own official rules say that MAP counts as an iteration, but that doesn't mean all the readers know what MAP is.
I talk about the AP with teachers much more than with students, but I tell the teachers to tell their students that you have to assume that the person reading your exam is hung over, has a headache, knows nothing about computer science, and hates kids. Not because all the readers are like that; most are dedicated and knowledgeable and right on top of things. But you have to assume that you're going to get the one terrible reader, and so you write your code and your text defensively. And then for fun you do a really cool project that you don't show the College Board.
is clearly incorrect. So is 
.
, it won't work, at least if you choose integer values of x only: f(x) appears to move towards 0, but is actually periodical. And how about: 
, or even a discontinuous function that will behave differently when x is crossing some very high number? Alternatively you can ignore all that when coding, and document your block's limitations.
?).