Filter comparison operators

[David Allen]

Looking for a filter operator that will let me compare numbers in fields.

<$list filter="[tag[blah]has[year](somehow)year<19]">

</$list>

Just kind of as an example

[TonyM]

David,

There are always so many ways to ask the same question

`[!prefix[2020]]`

<$list filter="tag[blah]get[date-field]!prefix[2020]]">

</$list>

When you say compare numbers is a string comparison enough?

Recent improvements to tiddlywiki has introduced simple maths and additional string operators that make what you ask possible.

Traditionally the comparison less than and greater than is done with the reveal widget

Regards

Tony

[David Allen]

I'm trying to store a list of tiddlers that has a "months" value.  The only relation this number has to built-in tiddlywiki date/time handling is in deciding which tiddlers to include, and I already know how to get the current date.  It is not related in any way to the creation/modification date of the tiddler, so any built-in date stuff in TiddlyWiki will not work.  For the same reason, the reveal widget is useless in this case.

I'm trying to get a filter operator that can compare numbers in a greater than/less than fashion.  Using the prefix method requires a degree of specificity I cannot provide in this case, so the prefix method is also useless.

To be specific, I am looking for a filter operator that can help me store a list of tiddlers whose months value is less than a specified value.

[Mat]

Comparison operators is/has been discussed. Contribute or merely express liking to it.

For now, this more cumbersome approach might work:

<$set name=amount
      filter="[tag[mytag]get[modified]]
              20180403221852352
              +[sort[]allbefore[20180403221852352]count[]]">
<$list filter="[tag[mytag]sort[modified]first<amount>]" >

</$list>
</$set>

So, the idea is to extract all modified dates from the relevant tids. Then add your magic cutoff date. Sort them and cut the sorted list before your magic date. Count how many.

Then sort all relevant tids by modified date and cut out as many as was counted before.

...yeah, would be simpler with "less than"...

<:-)

[David Allen]

That worked, though I needed to add a list to make sure the count wasn't zero.

[TonyM]

Mat

The match operator is effectively the equals operator the git hub issue raises

Are there others?

regards
Tony

[Mat]

TonyM wrote:

The match operator is effectively the equals operator the git hub issue raises

Yeah, but that's the only solved one. This thread here is about "less than", which is also brought up, among other comparison ops, in the issue thread.

<:-)

[TonyM]

Mat,

Yeah, but that's the only solved one. This thread here is about "less than", which is also brought up, among other comparison ops, in the issue thread.

<:-)

I understand, and would like such comparison filters

yet I would remind readers of opportunities already available

• Sorting places items in order and this can be used to establish order tests
• The reveal widget does contain such comparison tests
• The advanced maths tools available in plugins also provide for such tests like evans formulae plugin.

If you have two different values, not matching if you sort them you can test which is first/last or 

with the set select parameter you can test the exact position in a list.

Using the first/last operators we may be able to make a subfilter that resemble other missing tests.

Regards

Tony

[Hubert]

Hi David,

<$list filter="[tag[blah]has[year](somehow)year<19]">

</$list>

I know you're looking specifically for a filter operator. But for the time being, is there any reason why you wouldn't settle for the reveal widget? This should work based on your code above. You can use that for multiple outcomes, use dynamically generated 'variables' and even nest your conditions, if needed:

<$list filter="[tag[blah]has[year]]">
<$vars year={{!!year}}>
<$reveal default=<<year>> type="lt" text="19">

content/actions if field "year" has a value that is less than 19

</$reveal>
</$vars>
</$list>

One thing to note is that I'd use a 4-digit year to avoid problems with no leading zeroes in single digit years, the reveal widget may sometimes return unexpected results in these cases. Once that's taken care of, the reveal widget is probably the best 'scenario routing'/comparison mechanism that we have in TW at the moment, short of js of course.

More here.

Thanks,

Hubert