Donmai

Search syntax question

Posted under General

As I understand, it is possible to add ~ in front of a tag in searches to indicate you want result from any of these tags, for instance ~A ~B ~C ~D would yield AorBorCorD as result.
However, is there any method to search for (AorB)and(CorD)? Other than separately run C + AorB and D + AorB

This is basically how all of the different operators work in conjunction...

There are three different groups that get AND'ed with each other:

1. Inclusive group

  • Tags in this group may not have any of the above operators, i.e. plain vanilla tags
  • ALL of these tags MUST be tagged on the post

2. Exclusive group

  • Tags in this group are preceded by the NOT (-) operator
  • NONE of these tags may be tagged on the post

3. Related group

  • Tags in this group are preceded by the OR (~) operator
  • Wildcard tags are added as the top N tags that match by postcount, limited to your tag query limit (Help:Users)
  • At least ONE of these tags MUST be tagged on the post
  • Consequently, only ONE of these tags needs to be on the post to match

Regular search

Example (tag limit 6):

Search query: girls_und_panzer kantai_collection -comic -everyone ~dog_ears ~cat_ears *_girl

The top 6 results for *_girl are the following: (magical_girl, monster_girl, demon_girl, bunny_girl, dragon_girl, flower_knight_girl)

Therefore, the above search query works out to be:

(girls_und_panzer AND kantai_collection) AND 
    (dog_ears OR cat_ears OR magical_girl OR monster_girl OR demon_girl OR bunny_girl OR dragon_girl OR flower_knight_girl) AND NOT
    (comic OR everyone)

Wildcard search

Note that the wildcard thing can trip people up, as it doesn't do necessarily what you think it's doing.

Example (tag limit 12):

Search query: *_(cosplay)

The top 12 results for *_(cosplay) are the following:

  • hakurei_reimu_(cosplay)
  • shimakaze_(kantai_collection)_(cosplay)
  • hatsune_miku_(cosplay)
  • alice_(wonderland)_(cosplay)
  • kaname_madoka_(cosplay)
  • kirisame_marisa_(cosplay)
  • hestia_(danmachi)_(cosplay)
  • akemi_homura_(cosplay)
  • little_red_riding_hood_(grimm)_(cosplay)
  • tomoe_mami_(cosplay)
  • mash_kyrielight_(cosplay)
  • izayoi_sakuya_(cosplay)

Therefore, only the above will appear in the search results.

Edit:
  • (2017-01-14)
    • Clarified language for Related group

Updated

Wildcard searches aren't implemented here in the way you're thinking. As explained above, a wildcard search is functionally equivalent to a bunch of OR searches chained together; a *_difference search yields the same results as a ~height_difference ~age_difference ~size_difference search. The use of multiple wildcards in the same search (e.g. open_*e* partially_un*ed) is not supported (see topic #10395) and likely won't produce the results you're expecting. For the same reasons, you can't negate wildcards from searches, so adding -no_pan* to your search doesn't do anything.

iridescent_slime said:

Wildcard searches aren't implemented here in the way you're thinking. As explained above, a wildcard search is functionally equivalent to a bunch of OR searches chained together; a *_difference search yields the same results as a ~height_difference ~age_difference ~size_difference search. The use of multiple wildcards in the same search (e.g. open_*e* partially_un*ed) is not supported (see topic #10395) and likely won't produce the results you're expecting. For the same reasons, you can't negate wildcards from searches, so adding -no_pan* to your search doesn't do anything.

Individually search open_*e* include results from ~open_clothes ~open_jacket ~open_hoodie ~open_vest ~open_dress ~open_blazer, and partially_un*ed include results from ~partially_undressed ~partially_unbuttoned ~partially_unzipped ~partially_unbottoned, and no_pan* include results from ~no_panties ~no_pants ~no_pantsu!! ~no_pangs ~no_panies ~no_pangties, so I was expecting the search result to be for

(no_shirt AND no_bra)
 AND (open_clothes OR open_jacket OR open_hoodie OR open_vest OR open_dress OR open_blazer)
 AND (partially_undressed OR partially_unbuttoned OR partially_unzipped OR partially_unbottoned)
 NOT (partially_undressed OR (no_panties OR no_pants OR no_pantsu!! OR no_pangs OR no_panies OR no_pangties))

Would it be fit to request such a feature in danbooru?

c933103 said:

So, I tried to search no_shirt no_bra -no_pan* open_*e* partially_un*ed -partially_undressed , but then the first result is post #2939984 which currently doesn't have an open_*e* tag, and post #2673289 , which have a no_pan* tag.
Is there some limitations regarding the usage of these asterisk is this aspect, other than the tag-limit-based limit which should not applies here?

Le sigh...

As I explained in my post, all wildcards get treated as part of the Related (OR) group, which means ONLY ONE of the tags needs to show up for there to be a match. For the post #2939984, the post you indicated, it had partially unzipped, which matched partially_un*ed. That is literally it. None of the other wildcards matter since it found its match and therefore satisfied the search requirements.

iridescent_slime said:

The use of multiple wildcards in the same search (e.g. open_*e* partially_un*ed) is not supported (see topic #10395)...

Not true. It is supported, however they all only add to one giant OR group. ANY hit from ANY of the wildcards will produce a match.

For the same reasons, you can't negate wildcards from searches, so adding -no_pan* to your search doesn't do anything.

Mostly correct. What it currently does is subtract the literal tag no_pan* from the results. The same for the OR (~) operator. It adds the literal tag no_pan* to the Related (OR) group. Basically it does nothing though, as currently there are no tags with * in the name.

BrokenEagle98 said:

Not true. It is supported, however they all only add to one giant OR group. ANY hit from ANY of the wildcards will produce a match.

Ah, got it. Strange that this isn't mentioned in the wiki, yet there's a bit about not being able to combine wildcards with OR searches when in reality they seem to work just fine.

Just out of curiosity, if two wildcards are used, will tags be pulled from the most populated tags among both search terms? Like, if a Gold member searches for brick_* tile_*, is this equivalent to ~brick_wall ~brick_floor ~tile_floor ~tile_wall ~tile_roof ~tile_ceiling, with less common tags like brick_oven getting dropped from the search? Or does something else happen?

iridescent_slime said:

Ah, got it. Strange that this isn't mentioned in the wiki, yet there's a bit about not being able to combine wildcards with OR searches when in reality they seem to work just fine.

Just out of curiosity, if two wildcards are used, will tags be pulled from the most populated tags among both search terms? Like, if a Gold member searches for brick_* tile_*, is this equivalent to ~brick_wall ~brick_floor ~tile_floor ~tile_wall ~tile_roof ~tile_ceiling, with less common tags like brick_oven getting dropped from the search? Or does something else happen?

No the limit applies individually to each wildcard.

Given a Gold user with a limit of 6 tags:

  • brick_*
    • brick_wall
    • brick_floor
    • brick_oven
    • brick_(ppg)
    • brick_(borderlands)
    • brick_road
  • tile_*
    • tile_floor
    • tile_wall
    • tile_roof
    • tile_ceiling
    • tile_background
    • tile_mosaic

So the only one's dropped that I could see are brick_jock and brick_arch.

Gold users could theoretically have 6 wildcard tags in the search for a maximum of 36 OR'ed tags together. Platinum + could have 12 wildcard tags for a maximum of 144 OR'ed tags.

However, the one downside to wildcards is that you have less control over which tags get chosen. Additionally, they are not like inclusive terms. So with the above example, if any one of those 12 tags appear on a post, then that post counts as a match. To reiterate, it does not need to have a match from each wildcard, i.e. one from the brick_* group and one from the tile_* group.

I just wanted to add an addendum for what I posted in forum #142087 to cover how metatags are handled. Basically each metatag, both plain and negative, are treated as their own AND group equal in weight to the Inclusive, Exclusive and Related groups.

However, there is a difference in how certain metatags are handled in comparison to others. Some can have multiple instances, and some can only have one. In the latter case, it uses the right-most instance of that metatag in the search query string. There are some that are a hybrid of both, depending on what is used for the metatag.

Single instance

  • user:
  • approver:
  • ordpool:
  • ordfav:
  • md5:
  • rating:
  • -rating:
  • locked:
  • -locked:
  • -id:
  • source:
  • -source:
  • parent:
  • child:
  • order:
  • status:
  • -status:
  • filetype:
  • -filetype:
  • pixiv_id:
  • upvote:
  • downvote:

Single instance with ranges

These can only be used once in a tag string, but they can handle multiple instances by using comma-delineation, ranges (..), or comparisons (>,=,<)

  • id:
  • date:
  • age:
  • width:
  • height:
  • mpixels:
  • ratio:
  • score:
  • favcount:
  • filesize:
  • tagcount:
  • charcount:
  • copycount:
  • gencount:
  • artcount:
  • metacount:

Multiple instances

  • -user:
  • noteupdater:
  • artcomm:
  • favgroup:
  • -favgroup:
  • search:

Multiple instances with None/Any

None or any count towards their own instance, however any gets overwhelmed by any other instance, and none mostly overwhelms everything else.

  • flagger:
  • -flagger:
  • appealer:
  • -appealer:
  • commenter:
  • -commenter:
  • noter:
  • -noter:

Hybrid

  • -approver:
    • -approver:none/any is treated as approver:any/none
    • Other uses treated as multiple
  • pool:
    • none/any treated as singular (can't have both)
    • series/collection get added to the tag Inclusive group
    • Wildcards in pool name follow the same rules as tags
    • Any other pool name/id gets added to the tag Inclusive group
  • -pool:
    • -pool:none/any is treated as pool:any/none
    • Every other pool name/id/series/collection get added to the tag Exclusive group
    • Wildcards (*) are treated literally and also added to the tag Exclusive group
  • fav:
    • Multiple, added to the tag Inclusive group
  • -fav:
    • Multiple, added to the tag Exclusive group
  • parent:
    • none/any treated as singular (can't have both)
    • Other uses treated as multiple

The ability to do arbitrary boolean searches is a longstanding feature request. Adding it would require rewriting most of the query engine, which would be a nontrivial job, for not much benefit given that searches this complex are rarely needed. Don't hold your breath.

1