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
AFAIK, the only operators used in search are OR (~), NOT, (-), and the wildcard (*). Parentheses do nothing, and we wouldn't be able to use them in tags if they did. The allowed combinations are documented in help:cheatsheet.
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
2. Exclusive group
3. Related group
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)Note that the wildcard thing can trip people up, as it doesn't do necessarily what you think it's doing.
Search query: *_(cosplay)
The top 12 results for *_(cosplay) are the following:
Therefore, only the above will appear in the search results.
Updated
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?
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:
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.
user:approver:ordpool:ordfav:md5:rating:-rating:locked:-locked:-id:source:-source:parent:child:order:status:-status:filetype:-filetype:pixiv_id:upvote:downvote: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:-user:noteupdater:artcomm:favgroup:-favgroup:search: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:-approver:-approver:none/any is treated as approver:any/nonepool:-pool:-pool:none/any is treated as pool:any/nonefav:-fav:parent: