This site is supported by donations to The OEIS Foundation.
User talk:Charles R Greathouse IV/Keywords/Table
Contents
Comments
I like the idea of having extra information in keywords. Originally I had through of parenthesized substrings, but nesting those looks bad: keyword(subpart(subsubpart(etc))). The current idea of delimiting them with a - or : is better. I prefer the - because, if exposed to the DOM, it allows styling through the |= selector. This could allow users to write their own stylesheets, Greasemonkey scripts, XSLT, or whatever. (Also, they're less visually distracting.)
My thoughts on particular keywords follow. I like the general idea a lot, but I figure now is the time for criticism before things get further developed.
- cadd: This should be under add. If a user searches for keyword:add, we want all completely additive sequences to come up too. I suggest add-comp.
- cmult: Ditto. mult-comp.
- ccopr: Ditto. copr-comp.
- base-1-Rom: Technical issues: except for the early-style Roman numerals, they're technically slightly-positional rather than unary. Right now I think there's value to allowing searching for all nontraditional bases, so I favor base-alt-Rom to allow keyword:base-alt as a search for users looking for Etruscan, phinary, money bases, etc. Of course the truly obscure ones should fall directly under base-alt until there's a critical mass.
- fini?: I thought it was worth pointing out the difference between v.1 suggestion fini?, which would not appear on a search for keyword:fini, and v.2 suggestion fini:?, which would. I very slightly favor the first, but would be happy to get more input on this.
- fini-yes-N-full: Absolutely the wrong way to do it! If I'm searching for a sequence I think is fully recorded in the OEIS, it's quite possible -- even likely -- that I won't know how many terms it has. This should be fini-yes-full or even fini-full for that reason. I would *also* have fini-yes-N so that all the searches work properly: keyword:fini-yes, keyword:fini-yes-7, etc.
- conv-num: Should be frac-num. If the property "the sequence of fractions associated with this sequence and some other sequence are convergents to the continued fraction of some constant" is given a keyword (I don't think it should!) it should certainly be in addition to frac-X not in its place. Programs, scripts, etc. that interact with fractions shouldn't need to treat these any differently from other fractions. Contrast the case of gcofr, where the sequences should *not* be treated as fractions (so I like gcofr-num).
- conv-den: Ditto. Drop.
- scofr: I favor cofr, but perhaps I'm a mushy traditionalist for so thinking.
- mono-sincr: I'm torn; I want to make searching for any increasing sequence easy (keyword:mono-sincr|keyword:mono-lincr is bad), but I also want to keep the keywords terse (mono-incr-strict is long and belongs on many sequences). Feelings?
- mono-cons: I would describe these simply as "constant sequences" and drop the redundant "monotonic" in the description. The keyword is good as-is, I think -- it's a compromise from the mathematically pure but inconvenient system of marking such sequences mono-lincr and mono-ldecr. There are issues with the name, though, and I have no good solution: I fear confusion between cons (a real number represented as a string of (generally) nonidentical digits) and mono-cons (a sequence with all terms equal).
- nrad: I'm not sure what this is supposed to represent. Is this a different way to represent real numbers like cons?
OK, that should do for now.
- Yes, it is a nested radical expansion of a constant (see Golden ratio#Continued fraction and nested radicals expansions for the nested square radical expansion of phi, Silver number#Continued fraction and nested radicals expansions for the nested cubic radical expansion of the silver number, where in both cases we get the trivial all one's sequence {1, 1, 1, ...}, but there might be less trivial examples...) — Daniel Forgues 04:38, 10 February 2011 (UTC)
Another addition to "mult-family":
- mult-gf2x: Sequence is multiplicative when terms are interpreted as (binary encoded) polynomials over GF(2), with A048720 used for their multiplication (Examples: A193231)
— Antti Karttunen 12:22, 23 February 2015 (UTC)
Do you still want people to contribute suggestions to the keywords suggestion table?
I've noticed that you removed the link to your Keywords/Table subpage from your Keywords subpage. Do you still want people to contribute suggestions to the keywords suggestion table? Or is the table getting too cluttered? — Daniel Forgues 14:50, 9 May 2011 (UTC)
Bounded sequences
That's an interesting idea. I think that I would prefer to do this differently: give explicit upper and lower bounds (probably as a range). This could be part of an extended keyword (as has been suggested, e.g., by David Wilson) or as another mechanism. For example, a lower-bound range of [0, 7] means that 7 is known to occur eventually and no term is less than 0. This could replace nonn and signed, of course. By extending the range to extended reals there's no need to differentiate between bounded, unbounded, and questionably-bounded sequences. (There's the small matter of how to encode infinities; "infinity" is probably best but ∞ looks nice.)
Charles R Greathouse IV, 11:35, 9 May 2011 (UTC)
I answered you (agreement) on User_talk:M._F._Hasler/Work_in_progress/Improvements_of_OEIS#Keyword_parentheticals. Maybe use of trailing ":"? I slightly disfavour "-" which does not look that much as a separator, and might create issues when a more general keyword (namely, key phrases) pattern would be allowed. (I think this should be implemented sooer or later, with almost no effort it would yield fasic functionality implementing "categories" for sequences.) — M. F. Hasler 18:04, 30 January 2013 (UTC)
Unique
I suggest a keyword dupe/dupl/uniq or similar to ID sequences which contain (or can contain) duplicates.--Bill McEachen 16:42, 30 March 2014 (UTC)