word choice improvements

[JeffreySarnoff]

consider each [group] of the rows

suggestion	to replace		source
namesfrom	names		@nickrobinson251
phase	angle		@ExpandingMan
streampos	position		@JeffreySarnoff
diagindex	diagind		@imciner2
nextindex	nextind		@jakobnissen
previndex	prevind		@zdroid
thisindex	thisind		@jakobnissen
valuetype	valtype		@quinnj
stepsize	step		@CameronBieganek
joinstring	join		@iamed2
VarArg	Vararg		various

select one from each alternative set

alternatives	suggestion	to replace		source
{a1,a2), b				@musm
a1	countzeros	count_zeros
a2	countones	count_ones
b	count_lines	countlines

---

From time to time people mention similar preferences. Let's collect the suggestions. I'll copy them into this table.

---

moved from discourse

[imciner2]

As long as we are listing index-related ones: diagindex instead of diagind (or even the full word diagonalindex, but that might be making it too long).

[jakobnissen]

There was also some discussion about "position" being exported for a fairly obscure use case. Also, nextind should be nextindex. And also see #35285

[nickrobinson251]

Perhaps names could also be renamed, since it is such a generic word for quite a specific (and i believe rarely used) function. Possible more verbose option: namesfrom

[musm]

Totally agree on the index changes, it's really weird that we have firstindex, lastindex , but at the same time have prevind,nextind, thisin

[bramtayl]

Any sp... function is confusing. Maybe zeroes(SparseArray, m, n) instead of spzeroes(m, n)? Not sure if there's an issue open for that already

[oscardssmith]

I think the problem with this was that it's ambiguous with zeros(Int...) where the type is the eltype.

[bramtayl]

Oh, hmm, well, maybe a SparseElement dummy type then? There must be a nicer syntax then sp

[musm]

We have exported the methods: count_ones, count_zeros and countlines. Change count_ones -> countones and count_zeros -> countzeros, for symmetry. (Either this or countlines -> count_lines).

[JeffreySarnoff]

mentioned on slack, as a "spelling choice" VarArg rather than Vararg.

[musm]

Fixed up the recommendation:

Either: count_ones change to countones count_zeros change to countzeros (matching countlines )

or countlines to count_lines
(matching count_ones,countzeros )

[JeffreySarnoff]

see revised organization at top

[nickrobinson251]

xref #40466

[JeffreySarnoff]

@nickrobinson251 included above thank you

[musm]

signed(T), unsigned(T) -> signedtyped(T), unsignedtype(T) (ref https://github.com/JuliaLang/julia/pull/30445)

join -> remove or rename to joinstring (ref https://github.com/JuliaLang/julia/issues/37861, edit: I see this is already included above)

[goretkin]

parent -> parentarray or parentwrap

from the docstring:

Return the underlying "parent array”. If the input is not a wrapped object, return the input itself.

See also https://github.com/JuliaLang/julia/issues/27175#issuecomment-394488091 suggesting that this function is not that useful

and possible puns: https://github.com/JuliaData/SplitApplyCombine.jl/blob/0b6dd36ad8da02955bd5a5b2e3ed22214cc6a5f4/src/group.jl#L342 https://github.com/Jejulia/TreesHeaps.jl/blob/6a4d39161dc380a739ab97d3f16c7db1a5e6493a/src/Interface.jl#L58-L59 https://github.com/JuliaCollections/LeftChildRightSiblingTrees.jl/blob/f0748dda17c7e8f914a7157759f2bb395905281d/src/abstracttrees.jl#L8 https://github.com/rofinn/FilePathsBase.jl/blob/94cc2946936583a84038813abf22731902d30fba/src/path.jl#L198 https://github.com/BioJulia/GenomicAnnotations.jl/blob/93c9c61ad1251fcf0d664b0a35e7301647898b00/src/record.jl#L381 https://github.com/JuliaPlots/AbstractPlotting.jl/blob/fb515a42f66e592bdbf1e1201286d267ae601756/src/scenes.jl#L235

[fph]

It has been discussed here that it would make sense to rename

sinc(x) = sin(pi*x) / (pi*x) -> sincpi(x) sin(x)/x -> sinc(x)

So that sincpi(x) ≈ sinc(pi*x) holds, in analogy with sinpi(x) ≈ sin(pi*x). However that's a breaking change, and I am not sure that the consistency is worth the trouble.

Note that in Mathematica and C++ (Boost) sinc(x) = sin(x)/x, while in Matlab and in Numpy sinc(x) = sin(pi*x)/(pi*x).

[oscardssmith]

IMO, the more likely deprecation path would be to move sinc to special functions.

[imciner2]

See https://github.com/JuliaLang/julia/issues/17322 for another set -> atol/rtol to abstol/reltol.

[CameronBieganek]

Suggestion:

• Rename findfirst to findfirstindex.
• Rename findlast to findlastindex.
• Rename findall to findallindices.

This would allow new definitions for findfirst and findlast that operate on an iterator and return a value rather than an index. (They would have to return Union{Some{T}, Nothing}.) It's a pretty big change, but it might be nice. :)

Related discussion in #44996.

[KronosTheLate]

IMO, the more likely deprecation path would be to move sinc to special functions.

Is that happening? If not, I think that sinc(x)=sin(x)/x and sincpi(x) = sin(x*pi)/(x*pi) (and the same for cos) would be a clear improvement on the current situation, and warrant a breaking 2.0 change.

[PallHaraldsson]

I think we should add sincpi and cospi as aliases (it's also more explicit), ASAP (a trivial PR), if you want sinc and cosc redefined, since the former isn't a breaking change, and redefining the latter will then be less of a braking change, if people have moved to the new alternative. The docs for those should be changed to strongly suggest using the aliases. [Even if moved to SpecialFunctions.jl there will be name confusion, so good to have changed here first?]

[KronosTheLate]

That sounds like a good move toward a more consistent naming convention, which I believe is an end goal everyone wants.

[PallHaraldsson]

TL:DR Just soft deprecate sinc in Base? Or also add sincpi? A potential downside of the synonym sincpi, is that it might imply to some that sinc is unnormalized, not a synonym for sincpi. Julia doesn't have both soft and regular deprecation as Python, but maybe should formalize that.

I think that sinc(x)=sin(x)/x and sincpi(x) = sin(xpi)/(xpi) (and the same for cos) would be a clear improvement on the current situation, and warrant a breaking 2.0 change.

We can never do that. At least not for a long time. I mean sinc(x) is now normalized i.e. sinc(x) = sin(xpi)/(xpi) ?!

I fully support sinpi as the synonym, to make clear which is used, but for those that use sinc meaning the same, we would need to deprecate and know it hasn't been used for a long time before introducing a new definition for it. But likely never use it since we wouldn't know if code out there has stopped using it. Only if we drop it, in 2.0, then maybe reintroduce in 3.0...

I see on Wikipedia:

Alternatively, the unnormalized sinc function is often called the sampling function, indicated as Sa(x).

That would be one way out of this mess, define Sa as synonym for unnormalized sinc, but I would hesitate to export two-letter functions from Base... I'm not sure if upper-case S is always used for this, then it might be an argument for it ok... though I still doubt it. But it could go into SpecialFunctions.jl with no bad effect. Is there a similar equivalent for cosc (and tanc, is that even used?).

[In my previous comment I wrote "former isn't a breaking change" but it seems I mixed up former and latter.]

[PallHaraldsson]

Should this go into 2.0 milestone? I mean we can introduce all the new names, or whatever subset of we want without breaking anything? We just can't delete the old name, would have to be synonyms in 1.x. I think we can deprecate them though.

Python has deprecation (you should never use, rewrite old code that uses) and soft deprecation (use new stuff, don't be to concerned if using older), formalized. Maybe Julia should too.

I think deprecation will slow down code and issue warnings, only if opted into (for developers).

I feel like "2.0" is never going to happen, so moving to that "milestone" feels like a trash can. I might be wrong, and I would want work on 2.0 to start ASAP. It doesn't mean dropping 1.x