Last modified: 2010-11-07 08:13:52 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T27418, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 25418 - Add comparators for "greater than" and "less than"
Add comparators for "greater than" and "less than"
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Markus Krötzsch
https://www.saruman.biz/wiki/index.ph...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-04 19:42 UTC by Jan Schoonderbeek
Modified: 2010-11-07 08:13 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jan Schoonderbeek 2010-10-04 19:42:53 UTC
Request: please add the following new comparators: “less than” and “greater than”

Proposal:
A] Redefine comparators < and > to fit their mathematical meaning: “less than” and “greater than”
B] Add a new notation for the original comparators “less than or equal” and “greater than or equal”. The notation itself could either be the actual characters (Unicode 2264/Extended ASCII 243  ≤  and Unicode 2265/Extended ASCII 242  ≥ ) or their two-characterASCII approximations (<= and >=) or something else. People with knowledge of code pages and MW parsers may say something intelligent about this
C] SMW might need a parameter for backward compatibility with the original < and > comparators: $smwComparatorOldBehaviour. Reason: if one already has a wiki and it uses < and >, the new style alters the behaviour of existing queries with < or >. Admins of these wikis could set $smwComparatorOldBehaviour=true. This would have the effect of disabling the new “greater than” and “less than” comparators, and the parser would treat both < and ≤ the same (“greater than or equal”), meaning the wiki could start using ≤ explicitly, eventually switching over  to the “new” behaviour once all existing queries are corrected. After setting $smwComparatorOldBehaviour=false, SMW would start parsing < as “less than” and ≤ as “less than or equal”. It can also be argued that the parameter should be named $smwComparatorNewBehaviour, or $smwUseGreaterThanAndLessThanComparators, etc. I propose the $smwComparatorOldBehaviour name, so that we can use it while we need, and in the future (e.g. in the year 2099) can declare the the parameter deprecated, when we believe that no wiki on earth runs in the counter-intuitive Comparator Old Behaviour mode.
D] The backward compatibility parameter should get a default value. It can be argued that the default setting for $smwComparatorOldBehaviour should be
false, so that from now on every new wiki is always in new behaviour while we still can accommodate admins of existing wikis (but there's an increased risk of incorrect queries when admins of existing wikis fail to set/correct the parameter);
true, so that correct querying for existing wikis is ensured (but there's a great risk of new wiki's not switching to the new behaviour)
true for now, and false in a later version of SMW, to have people get used to the idea while not forcing anything.
I personally vote for the first option, with a clear warning in the release notes.
 
Background: As described in the Semantic MediaWiki online documentation, the SMW comparators are:
> and <: greater than/less than or equal
!: unequal
~: «like» comparison for strings (disabled by default) 
Ths does not readily allow for disjunct selects. Example: suppose property “Foo” is of type number. Ideally, you would like to be able to select (with “mathematical” comparators instead of SMW comparators):
a)   [[Foo::< 10]] (less than 10)
b)  [[Foo::>=10]] (10 or greater)
However, since the first comparator does not exist, a strict disjunct selection under SMW looks like this
c)  [[Foo::< 10]][[Foo::!10]] (less than 10)
d)  [[Foo::>10]] (10 or greater)
Technically this works, but the notation is counter-intuitive.

Furthermore, the fact that > is “greater than or equal” and not simply “greater than” can lead to unpleasant situations. Consider a property “maturity” with allowed values 1, 2, 3, 4, 5, and 9. When selection all values in the range 1-5, you must use [[Maturity::<9]][[Maturity::!9]] for “everything below 9”, instead of something like [[Maturity::<8]], since 8 is (currently) not an allowed value; the notation inside a query would yield the famous yellow-exclamation-triangle.

Discussion in #semantic-mediawiki and/or on the wikipage above most welcome
Comment 1 Markus Krötzsch 2010-10-05 09:58:36 UTC
The original motivation for choosing the current meaning was that strict operators were much less common in practice, so that it was decided to not require extra symbols for writing them. Moreover, many applications do not really care about the difference (e.g. when comparing dates or population numbers, the difference between <= and < is only ever seen if there is an item that is exactly on the border, and even this may not matter in practice).

Another motive for the current syntax was that the older ":=" syntax already had a "=" so that adding "<" or ">" suggested the "or equal" versions in a more natural way than now. Of course this argument is void now.

As you say, in many cases strictly greater than 8 can be written as greater than or equal to 9. The problem you describe for allowed values is a separate bug that should be fixed (I think there is an open bug report for this).

My main concern here is that we are making the more common case harder to accomplish, while at the same time introducing additional syntax that makes it harder to read queries. Unless there are a significant number of uses for strict comparators, I think that it is better for most SMW users to keep the current solution, requiring those who need strict comparators to add the explicit inequality condition instead of requiring everybody else to change their wiki or set new configuration parameters. Simplicity might be more important than mathematical canonicity here.
Comment 2 Jan Schoonderbeek 2010-10-06 20:59:57 UTC
While I understand your original motivation and your call for simplicity, I disagree with the implications. Mentioning this use on the IRC channel gave me 3 out of 3 people (including active developers) who didn't know that < actually means ≤. Not a really statistically representative poll, but nevertheless...

If you strive for simplicity, then have < really mean "less than". As it stands queries are harder to read because anything seemingly noted as "less than X" actually includes X, or, in my case, "less than X" is actually the correct notation for "less than Y" (or alternatively "less than X""also, not X").

However, if there are no strong objections to using characters ≤ and ≥, then I believe we can agree that query reading is strongly improved while not making it hard to accomplish the common case (which you suggest can still be accomplished using < and > if applications really don't care about the difference).

When following your reasoning I do see that the default setting should remain "old behaviour", which makes a case for something like "$smwStrictComparator = true" to switch on the extra comparators AND switch "equal or less" to ≤.

To summarize:
Notwithstanding the forementioned, I still believe the current implementation where writing [[Maturity::<9]] is actually not "less than nine" is confusing and needs to be remedied. Please add comparators that are truly "less than" and "greater than", off by default, with an option to switch them on in LocalSettings.php using a suitable boolean variable.
Comment 3 Jan Schoonderbeek 2010-11-07 08:13:52 UTC
Feature added in v1.5.3

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links