# Message3783

Author | schlatterbeck |
---|---|

Recipients | ajaksu2, ber, richard, schlatterbeck, tobias-herp |

Date | 2009-07-14.15:15:06 |

Message-id | <20090714095004.GA1281@runtux.com> |

In-reply-to | <1247561272.39.0.110686786613.issue1182919@psf.upfronthosting.co.za> |

On Tue, Jul 14, 2009 at 08:47:52AM +0000, Tobias wrote: > > Tobias <tobias.herp@gmx.de> added the comment: > > > I'm considering enumerations of numbers (1,2,3) > > to be enumerations of degenerate ranges (with a single point). > > IMO, the more natural way would be to consider them sets (for our topic > here, I consider sets and enumerations equivalent). > > We don't need to invent such a strange beast like a "degenerate range". Its already there. Try to specify a search for a single date into the search for of dates. You'll find all occurrences of that date. These *are* already such strange beasts. Fine with me. Just think about sets of ranges, not just sets of numbers and you understand what I mean. Then there is no conceptual difference between 1 or 2 or 3 and 1 or 2 or 3 or 4;5 (I'm using "or" not comma here to show that we can leave out the brackets in the general case if the syntax isn't ambiguous.) or degenerate ranges - a = x so we can translate the thing above to (a=1 or a=2 or a=3 or (a>=4 and a<=5)) or use the "between" operator or use "in" for separate ranges. Thats the *backend*. I'm arguing about the frontend. > Sets do exist. We don't have to invent them. They are known to Python > and to SQL. There is definitely no need to work around them. This > would be as useful as a Brainfuck > (http://en.wikipedia.org/wiki/Brainfuck) implementation of Roundup. I have no problem of using sets in python and/or sql to implement the mini-query language for numbers and dates. I just don't want to force that concept on the users of that mini-language. No. And I've already mentioned that we can simplify it in the general case if we can leave out the brackets. > > IDs are *strings* in roundup. > > Yes, but > - they *look* like integers > - they can only be strings which can be interpreted as integers > - they *should be* integers > - they are considered integers by users > - concerning search expressions, they should be considered integers > by Roundup. > > > That's why you can combine them with space! > > That's not logic. Strings can *contain* space. No. For the search engine we only search for words. These cannot contain spaces. Why? I'm more concerned with - providing backward compatibility - making it easy for users - treating integers and dates alike > > date expressions like '. -1d' can contain spaces. > > That rules out the space as a separator. > > Wrong. That rules out the space as a separator *for dates*. See above. I don't want to invent two different syntaxes for dates and numbers. > Roundup date expressions are very special beasts, and everyone will > understand the difference. I don't think so. And I don't want two different code-bases for dates and ints. No. I still can't understand why you want to support sets of numbers *and* sets of ranges. Is there a good technical argument for that -- syntax left aside for a moment? I think we can come up with a good syntax that covers all. Are there search terms that use your number-sets which can express queries you cannot express in terms of sets of ranges? Mathematically, leave aside the syntax for a moment. (and I think the answer to that question is 'no'). So I ask for keep-it-simple: We don't need to introduce sets of numbers if we already have sets of ranges. Just for the record: I'm holding a Phd in computer science, so don't try to teach me set theory. On the other hand I've found that the users of roundup I'm working with will have a hard time understanding set theory. Thats why I argue that we should not put this into our mini-query-language if it can be avoided. > "The union of {1, 2, 3} and {2, 3, 4} is the set {1, 2, 3, 4}." > > Thus, we simply would support the mathematical notation of sets. > It will be very easily understood. Nobody will expect a C block or > Python dictionary in a search expression ;-) Note that I still think that set-queries of numbers are a special case. You usually want ranges. Or sets of *ranges*. So lets make the number a special case of the range and come up with a convenient syntax. No we don't need to "anyway". And the more I'm thinkig about it I tend to abolish the comma too. That would give us a form where we can leave out the brackets/parentheses in the general case. I don't think we need that. If we use the 'or' syntax we can leave out the brackets and can rewrite that as 1 or 2 or 5 My syntax is more convenient: 3;7 or 9 or 10 or 11 See above. If we only allow 'or' (and not ',' or space) we can leave out the brackets. We already have sets of ranges. I'm arguing against a separate set-of-nubmers concept. Ralf |

History | |||
---|---|---|---|

Date | User | Action | Args |

2009-07-14 15:15:07 | schlatterbeck | set | recipients: + schlatterbeck, richard, ber, tobias-herp, ajaksu2 |

2009-07-14 15:15:07 | schlatterbeck | link | issue1182919 messages |

2009-07-14 15:15:06 | schlatterbeck | create |