Add a design topic page on lazy vs. eager implementations

data-apis / array-api

RFC document, tooling and other content related to the array API standard

https://data-apis.github.io/array-api/latest/

MIT License

205 stars 42 forks source link

Add a design topic page on lazy vs. eager implementations #708

Closed rgommers closed 7 months ago

rgommers commented 7 months ago

Follow-up to gh-652, which added notes to the specifications for __bool__ & co on this topic.

rgommers commented 7 months ago

@seberg had one comment that is addressed in the second comment: point out that there is no built-in control flow beyond where (e.g., no cond) to avoid the __bool__.

rgommers commented 7 months ago

Three approvals and comments are addressed, so I'll go ahead and merge this. Thanks all!

betatim commented 7 months ago

On a more philosophical note: what should an array consuming library do to deal with these two variants of behaviour? There are two options that come to mind straight away: (1) state in your docs that of all Array API compliant array producing libraries you only support X, Y and Z (because they don't raise) or (2) add try excepts around your if statements?

Not sure if this PR is the best place to discuss this, but I started typing just before Ralf merged it, so will post here. Maybe an issue (with a follow up PR) is a better place?

rgommers commented 7 months ago

I think it's in practice a non-issue:

Few classes of algorithms should actually need __bool__; it's basically only iterative algorithms (e.g. minimizers, fitting routines)
For those that do need such iteration, they invariably already don't support lazy/graph algorithms - so I'd suggest simply documenting that fact in the relevant docstrings.