Request or suggestion for comparison filter operators

[Mark S.]

Hello,

As far as I can tell, there is no filter operator that will allow one to make comparisons, either numeric or alphabetic. The use cases for this functionality would include limiting calendars to either past or future events, showing todo items with qualifying priorities, breaking up long lists of names into alphabetic chunks, etc.

For example, an operator that worked like this:

[ngt:dayofmonth[25]]

would return only those items with a numeric field "dayofmonth" greater than 25.

Or, for alpha, an operator like

[tags[contacts]gt:title[L]]

would return only those contacts from the last half of the alphabet. There would need to be "less than" operators (lt and nlt) as well, of course.

If there is already some way to accomplish this filtering, I would be interested to know!

Thanks!
Mark

[Jed Carty]

Nothing exactly like that exists yet, but you could use regular expressions to accomplish similar things. It would probably be a bit unwieldy though.

I don't think that writing a filter that does what you want would be too difficult to make. I may get around to working on my calendar stuff some more and make a plugin for it.
I don't know if this is something that would end up in the core, but it would be just as easy to use as a plugin.

[Jed Carty]

You could also do this using the first and last operators and lists, but once again it would be bulky and annoying. Have a field called numbers that contains '1 2 3 4 5... Up to 31 then use nested filters like this

<$list filter='[list[numbers]first[10]]'>
<$list filter=' tag[sometag]date<currentTiddler>]'>

</$list>
</$list>

this would list everything tagged with sometag that has a date field that contains a number less than or equal to 10.

You could do a similar thing with letters. It isn't a very good solution but if you want something now it should work.

[Jed Carty]

I have started making these filters. The numeric versions are easy at least, I haven't started on the others yet. The numeric versions are shown off here. I am going to use the convention that greater/less than is by default a numeric operator so instead of specifying numeric I am going to put a prefix on the alphanumeric version. Probably angreaterthan/anlessthan. This will be easy enough to change if someone has a better suggestion.

Also, is this something that would be useful enough to go into the core? If not I think that it would be useful enough to be added to the official plugin library.

[Jed Carty]

Ok, I have run into a problem. I am not sure what the expected behaviour for the alphanumeric greater than/less than is. If you go by the straight forward naive implementation than all capital letters are less than (come before) all lowercase letters, so 'Z' is less than 'a'. I could see this making sense, or I could make it case-insensitive so 'A' and 'a' are identical, or I could make it case sensitive but with A > a > B > b and so on.

I am leaning toward case insensitive because that is probably the closest to what most people would expect from the operator. Any suggestions?

[Mark S.]

Hi Jed,

In the long run, you would want case-sensitive versions of gt and lt. So I guess you would end up with 4 filter operators: ltc, lti, gtc, gti.

If you had to choose, case-insensitive would be more generally useful.

I assume that under the hood once you have one version it would be straight-forward to clone and adapt another. Er, hopefully?

Thanks!
Mark

[HansWobbe]

Another option would be to use a "list" field to explicitly set the ordering that is to be used.  This is particularly useful when dealing with Unicode characters since SORT sequences of various Unicode alphabets are often not the same as the positions of the characters =in their alphabets.

One of the benefits of dealing with Unicode characters is that there are about 100,000 defined Codepoits, the majority of which can be used as Tags and in Tiddler names (as sigils), which really improves information "density".

Regards,
Hans

On Saturday, July 25, 2015 at 2:08:33 PM UTC-4, Jed Carty wrote:

...

[Jed Carty]

Mark,

As long as you were ok with using the ordering defined by the encoding (which, as Hans says may not be consistent across encodings) than case sensitive tests are easy. Otherwise you have to define the ordering in the code somehow. This isn't particularly hard, you would just make an array that contains the ordering you wish to use. The problem comes in when you have different alphabets and accent marks and the like.

Hans,

I think you are correct as far as making something that is flexible. I think that I could add an input to the operator that allows you to specify a field that contains the desired ordering for the sort so you could include which ever symbols you wished. You could do something like this with plain wikitext and existing operators, but it would take enough effort that I think a filter operator is worth making.


I will try add the option to give a list field and unless someone has a good suggestion for a better solution I will leave it at that.

[Mark S.]

That sounds great to me Jed. I'm sure whole careers are made trying to resolve localization problems. I presume the problem already exists with the existing "sort" filter? Does it sort differently on different platforms and/or different encoding sets?

I suppose there could be yet another set of  lt/gt filters that indicate that the comparison is done with UTF (e.g. ltu,gtu).

Thanks!
Mark

[Kythzu Freeman]

I know I'm late to his party...
but for those like me stumbling through these forum posts in the search for answers:

I think comparison can be done by first sorting and then truncating (chopping a bit off) the sorted list.
I've got two different methods:

1. Sort then Truncate using first
Here's what I used for a "Recent Activity" list.

<$list filter="
[!prefix[Draft of]tag{!!title}!nsort[modified]]
+[first[5]]
" />

This should return a list of the 5 most recently modified tiddlers tagged with the title of the current tiddler.

2. Sort then truncate using allbefore
for the OP's usecase:

<$list filter="
[has[dayofmonth]]
+[nsort[dayofmonth]]
+[allbefore[25]]
" />

This should return a list of all the tiddlers with a dayofmonth field that is less than 25.

notes:
*you can squish the same filters into one line, but you can also have whitespace around complete [[]] or [{}] filters. I used the latter for clarity.
*the ! in !nsort makes the sort descending (newest to oldest), by default it is ascending (oldest to newest)

I hope this method helps people to build their todo lists and filterable custom calendars :)