Skip to content

Conversation

ds26gte
Copy link
Contributor

@ds26gte ds26gte commented Oct 12, 2025

This is an update of @ess476's PR #1217 that added map and filter methods to sets.

The previous PR is 7 years old and needed to be updated to mesh with the current horizon.

This PR is a working placeholder that we should use a basis to design how we want to proceed with this.

ds26gte and others added 28 commits August 22, 2025 13:35
- Extra arg removed for BigInteger.prototype.{round,roundEven,tan,atan,cos,sin,expt,acos,asin}
- bnpExp() should take errbacks arg and use it if exponent too large
- bnModPowInt() should take errbacks arg and pass it along to bnpExp()
- bnPow() should take errbacks arg and pass it along to bnpExp()
…rownplt#1799.

In fact, it doesn't give up at all, because any argument that doesn't
blow memory necessarily has a tractable logarithm.
…cos,tan} brownplt#1799

- num-{acos,asin,atan} don't have opportunity to trigger errbacks in method, so incorrectness (since corrected) was benign
- num-{exp,expt} now show proper error (previous error was incorrect convergence, didn't even trigger errbacks)
- num-log now always converges for convergent input (errbacks correctly propagated now, but impossible to trigger)
- test-numbers: use Racket value for log of large number in check block
- improve fromString() to use itself recursively rather than makeBignum()
fromFixnum(): fix for when argument fixnum is less than about 1e-7, brownplt/code.pyret.org#556
js-numbers.js: log() for nonintegral rational arguments = log(numr) - log(denr)
@ds26gte ds26gte requested review from schanzer and shriram October 12, 2025 19:00
@ds26gte ds26gte requested review from blerner and jpolitz October 12, 2025 19:01
@blerner
Copy link
Member

blerner commented Oct 12, 2025

I don't understand this PR -- it sounds like @shriram asked for design changes on the previous one, so either we should work on that, or we should close it.

I don't understand the implementation here -- there's no mention of Pick yet. Moreover, the implementation of map is very suspicious: if I have a tree-set of numbers and I map each number to an object, as in my-tree-set.map(lam(n): { val: n } end), the resulting implementation cannot be a tree-set because the items aren't comparable to each other. Further, do we intend the result to be a set at all? What if the mapping function introduces duplicate results? (AFAICT, only filter is reliably a set-to-set method.)

@blerner blerner marked this pull request as draft October 12, 2025 21:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants