remove lowercase conversions

[JeffBezanson]

Fixes #1470 and #6211.

[JeffBezanson]

What I discovered doing this:

• The vast majority of cases were simple conversions, T(x) or convert(T,x)
• The lowercase functions had a crazy variety of behaviors (converting, truncating, rounding, parsing, mapping over arrays). Glad to be rid of that.
• The one somewhat-useful operation that we lose is converting reals or complexes to a different precision component-wise, which float32(z) used to do. Is there another appropriate name for this?
• I kept signed and unsigned because these are used in critical places internally where we need to coerce between integers of different signedness. Could consider un-exporting them.

[JeffBezanson]

@tkelman How do we rebuild pcre_h.jl on windows?

[tkelman]

converting reals or complexes to a different precision component-wise, which float32(z) used to do

I guess (isreal(z)?Float32:Complex64)(z) isn't quite concise enough?

How do we rebuild pcre_h.jl on windows?

On appveyor we grab pcre_h.jl out of the nightly binary, so any time you change it things will break temporarily. There's no pcre-config or pcre.h in the binaries so it's messy to regenerate. You should be able to add a sed -i 's/int32/Int32/g' base/pcre_h.jl roundabout line 95 of contrib/windows/msys_build.sh

[goretkin]

It might not be concise, but perhaps more importantly, it won't work for new number types (#1470 (comment))

[JeffBezanson]

Looks like everything is passing. I'll merge this very soon.

[quinnj]

Huzzah!

[johnmyleswhite]

🎉

[nalimilan]

Great!

The one somewhat-useful operation that we lose is converting reals or complexes to a different precision component-wise, which float32(z) used to do. Is there another appropriate name for this?

"components" are called "parts" when considering complex numbers, so what about something like float_parts, parts2float...? Or have a more general function like convertparts(T, x)?

[mikewl]

I would have thought change_precision(T, x) would be appropriate?

[JeffBezanson]

round is a pretty good idea. I like that so far.

[nalimilan]

Good idea.

[JeffBezanson]

I guess the problem with round is that it's defined to yield an integer value. Converting Float64 to Float32 is also a rounding operation though, so it's not so far off.

[StefanKarpinski]

Can't signed(n) and unsigned(n) be replaced with convert(Signed,n) and convert(Unsigned,n)?

[JeffBezanson]

The barrier to that is that there are many uses that depend on them being un-checked. I guess we could use % Unsigned for that.

[jiahao]

I guess the problem with round is that it's defined to yield an integer value.

There's also this syntax:

julia> round(59.43984892, 4)
59.4398

[JeffBezanson]

I don't think it's a good idea to give very different values for round(T,x) for different types T.
Especially since round(float) already gives an integer-valued float. We wouldn't want this:

julia> round(2.5)
2.0

julia> round(Float64,2.5)
2.5

[StefanKarpinski]

I guess we could use n % Unsigned for that.

That's a little weird, but maybe ok :-|

[quinnj]

Gotta love the number of deprecation warnings you see after this got merged!