relax type definition of middle

[tlnagy]

this adds support for computing the median of unitful types, fixes PainterQubits/Unitful.jl#202

[tlnagy]

Thoughts @nalimilan?

[ararslan]

This could do with some tests. But that aside, I think Number might be a bit too permissive; for example, that allows Complex, for which middle isn't really well-defined.

[kleinschmidt]

Why isn't that well-defined for Complex? Seems pretty straightforward to me but then again I am a fool when it comes to complex numbers so I could be missing something obvious...

[ararslan]

middle is like the value between two numbers, i.e. the midpoint such that a <= x <= b but there isn't a well-defined order (no <=) for complex numbers. This is also why median isn't defined for collections of complex numbers.

[kleinschmidt]

Could always add a mehod for Complex or whatever the most relevant abstract supertype is that throws a DomainError or something?

[tlnagy]

It would very nice to be able to compute medians of unitful types, but I understand your argument about Complex numbers. I would be happy with something like @kleinschmidt's suggestion.

[ararslan]

Tangentially, I'm slightly surprised that unitful quantities subtype Number rather than Real; I'm having a hard time coming up with a concrete example of units for non-real numbers.

[tlnagy]

What is the best way of figuring out whether we can change the supertype of unitful quantities?

Seems risky to restrict the type from its current definition.

[jameslefevre]

Surely middle should be defined for complex numbers, or whenever x/2+y/2 is defined for that matter? Median will fail on complex numbers because PartialSort fails, which seems correct to me.

Tangentially, I'm slightly surprised that unitful quantities subtype Number rather than Real; I'm having a hard time coming up with a concrete example of units for non-real numbers.

I think impedance?

[nalimilan]

@ararslan Given that allowing Number would help with Unitful and it's not incorrect per se for complex numbers, would you be OK with merging this PR? The fact that complex numbers shouldn't be allowed for median is a separate issue, which is handled anyway by the fact that sorting will fail.

[ararslan]

Sure, sounds good to me.

[ararslan]

Before doing so it would be good to update the docstring as Bogumił mentioned. Might also be nice to have a test for non-reals.

[nalimilan]

OK, let's go with that then. @tlnagy Do you want to update the PR?

[tlnagy]

Thanks everyone for the constructive feedback, I've updated the PR. I think it's ready to merge!

This will close #43

[tlnagy]

bump

[ararslan]

Thanks @tlnagy! (And for the reminder!)

[nalimilan]

To get this included in the upcoming 1.6.0-alpha release, would you make a PR similar to JuliaLang/julia#35869 to use the latest Statistics commit in Julia? Thanks!

[tlnagy]

Hi @nalimilan, I'm not sure how how to create a PR like that?

[nalimilan]

The manual process is to copy the git SHA of the latest commit, put it in stdlib/Statistics.version, run make to download the tarballs, call md5sum and sha256sum on them and save the result to the files with the relevant names. I think there's a more automated way, but I don't remember it. :-/

[tlnagy]

And I should do that when building the latest julia master from source, right?

[tlnagy]

I submitted a PR (JuliaLang/julia#37950) against Base to bump Statistics. It would be great to have it in Julia 1.6!

[jebej]

Tangentially, I'm slightly surprised that unitful quantities subtype Number rather than Real; I'm having a hard time coming up with a concrete example of units for non-real numbers.

frequencies: https://en.wikipedia.org/wiki/Laplace_transform