3 ms·

Another reason we must have `all([]) == True`, because `any([])` should obviously be `False`. `all(x) == not any([not v for v in x])` so `all([]) == not any([

Another reason we must have `all([]) == True`, because `any([])` should obviously be `False`. `all(x) == not any([not v for v in x])` so `all([]) == not any([])` -> `True`

eru 7y ago
That's a strong hint that those definitions would make our lives easier. But it's not forcing anything? Also, I don't see why `any([]) == False` would be any more obvious than `all([]) == True`? I've seen not-so-carefully designed APIs that violate your 'obvious' logic for 'any': We had a system that you could send a list of topics, and it would return you all the datasets associated with those topics. The designer of the system decided that an empty list of topics would return all datasets, instead of nothing. I suspect their reasoning was that giving people an option to get all datasets was useful, and that predictably returning nothing was useless. But what they should have done in this situation for a clean API was to take an optional list of topics.
- erik_seaberg 7y ago
  If you view any and all as reductions any([x, y]) == x or any([y]) == x or y or any([]) all([x, y]) == x and all([y]) == x and y and all([]) then any([]) must be false (otherwise x and y would never matter), and all([]) must be true. In the query API you're describing, does {topic1, topic2} find datasets on (topic1 OR topic2), or is it (topic1 AND topic2)? That's what determines whether more topics means more or fewer results, and whether {} should correctly find nothing or everything.
  - eru 7y ago
    > [...] then any([]) must be false (otherwise x and y would never matter), and all([]) must be true. Yes, I know. My problem is with: > Another reason we must have `all([]) == True`, because `any([])` should obviously be `False`. Argument is of the form 'A, because B'. But I don't see how B is any more obvious than A here. They seem about equally obvious.

Another reason we must have `all([]) == True`, because `any([])` should obviously be `False`. `all(x) == not any([not v for v in x])` so `all([]) == not any([])` -> `True`

eru 7y ago

That's a strong hint that those definitions would make our lives easier. But it's not forcing anything? Also, I don't see why `any([]) == False` would be any more obvious than `all([]) == True`? I've seen not-so-carefully designed APIs that violate your 'obvious' logic for 'any': We had a system that you could send a list of topics, and it would return you all the datasets associated with those topics. The designer of the system decided that an empty list of topics would return all datasets, instead of nothing. I suspect their reasoning was that giving people an option to get all datasets was useful, and that predictably returning nothing was useless. But what they should have done in this situation for a clean API was to take an optional list of topics.

erik_seaberg 7y ago
If you view any and all as reductions any([x, y]) == x or any([y]) == x or y or any([]) all([x, y]) == x and all([y]) == x and y and all([]) then any([]) must be false (otherwise x and y would never matter), and all([]) must be true. In the query API you're describing, does {topic1, topic2} find datasets on (topic1 OR topic2), or is it (topic1 AND topic2)? That's what determines whether more topics means more or fewer results, and whether {} should correctly find nothing or everything.
- eru 7y ago
  > [...] then any([]) must be false (otherwise x and y would never matter), and all([]) must be true. Yes, I know. My problem is with: > Another reason we must have `all([]) == True`, because `any([])` should obviously be `False`. Argument is of the form 'A, because B'. But I don't see how B is any more obvious than A here. They seem about equally obvious.