Roundup Tracker - Issues


Author schlatterbeck
Recipients ajaksu2, ber, richard, schlatterbeck, tobias-herp
Date 2009-07-15.10:37:03
Message-id <>
In-reply-to <>
We don't agree on these yet.
I think we should use
1 or 2 or 5 *explicitly* not use the space *and* the comma for denoting

I don't agree, since one of the requirements was that the comma should
be used as a decimal separator. That excludes it as a 'set separator'.
> As far as possible, all types of data should be handled likewise
> in search expressions.

Leave out IDs. They are strings. Changing that would be major surgery.

No, see above.

> Ranges can be specified as "open" and "closed" intervals, following the
> "set builder notation"
> <>
>   [date1;date2)   --> date1 <= x < date2
> (this is what date ranges currently work like)
>   [a; b]          --> a <= x <= b
>   (a; b)          --> a <  x <  b
>   (a; b]          --> a <  x <= b
> It should be possible to combine range expressions:
>   [;v1] or [v2;]
>   [;v1], [v2;]
> This would allow to seek values x with
>   (x <= v1) or (x >= v2)
> which can't be achieved with [v1; v2] if v1 > v2.
> Ralf calls this a set of ranges.
> I call it or-connected ranges.
> Furthermore, it should be possible to specify in one expression
> /both/ a number of known values /and/ ranges; how this is should look
> like, is subject to our discussion.
> Ralf calls this number of values "degenerated ranges" (which contain a
> single element each only).
> I call this enumeration of values a set.
> Finally, before I make a point here to give Ralf the oppurtunity to
> countersign the text so far:
> We agree that it should be possible to specify float values with decimal
> commas.  Many Roundup users like in countries live in countries which
> use decimal commas, where the decimal point is known to computer geeks
> only (Germany, for one).
> Of course, this seems to conflict with the comma as an enumeration
> indicator. This might can be solved when using a special tokeniser for
> float searches (which is a small and perfectly testable piece of code),
> which could require the comma /separator/ not to be followed by a digit.  

I don't think we should introduce this ambiguity into the parser.

> But the problem could be a non-issue anyway, since float arithmetics is
> unprecise, and it might make sense to disallow both enumerations and
> closed intervals ("[a;b]" --> a <= x <= b) for floats, since comparison
> for equality is unrelyable for them.

You don't want to do special cases for special numbers here:
"Special cases aren't special enough to break the rules"

Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  Fax:   +43/2243/26465-23
Reichergasse 131                        www:
A-3411 Weidling                         email:
osAlliance member                       email:
Date User Action Args
2009-07-15 10:37:04schlatterbecksetrecipients: + schlatterbeck, richard, ber, tobias-herp, ajaksu2
2009-07-15 10:37:04schlatterbecklinkissue1182919 messages
2009-07-15 10:37:03schlatterbeckcreate