Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rethinking method names for sample/population #2

Open
NathanJang opened this issue Sep 29, 2015 · 9 comments
Open

Rethinking method names for sample/population #2

NathanJang opened this issue Sep 29, 2015 · 9 comments

Comments

@NathanJang
Copy link

Have you considered using an enum or a boolean instead of 2 separate implementations for some methods?

For instance

public static func variance(values: [Double], type: DataType) -> Double? with DataType.Sample or something

or

public static func variance(values: [Double], isSample: Bool) -> Double?

and checking for it in the implementation instead of copy-pasting 2 very similar implementations.

@NathanJang NathanJang changed the title Use enum for sample/population Don't use 2 separate methods for sample/population Sep 29, 2015
@evgenyneu
Copy link
Owner

Good suggestion, thanks. I would not do it though, here are the reasons:

  1. That would entangle two separate statistical concepts (sample and population) in the README. Currently they are completely separate entities, which is nice and simple for people to read and understand. Each of them have different formulas, return values and spreadsheet usage examples.
  2. The names of the methods will become less descriptive in my opinion: Sigma.varianceSample([1, 12, 19.5, -5, 3, 8]) vs Sigma.variance([1, 12, 19.5, -5, 3, 8], type: .Sample). In this case I like how the method name alone describes its nature.
  3. This is true that sample and population methods contain some duplication, but they also have some subtle differences. For example, they can vary in the return values. Of course we can try removing the duplication completely and this is a viable option. We can create a single method with one or two additional conditional statements. But in this case I prefer having some duplication in the methods to reduce their individual complexity. Duplication is bad, but only sometimes, depends on the context.

Thanks for your input. Have a good one!

@NathanJang
Copy link
Author

👍

@NathanJang
Copy link
Author

I just remembered another point that I forgot to bring up. I'm not quite sure your method names fit the naming conventions Apple uses. Personally I'd rename

public static func varianceSample(values: [Double]) -> Double? which gives Sigma.varianceSample([1, 12, 19.5, -5, 3, 8])

to

public static func varianceOfSample(values: [Double]) -> Double? which gives Sigma.varianceOfSample([1, 12, 19.5, -5, 3, 8])

or perhaps

public static func variance(sample values: [Double]) -> Double? which gives Sigma.variance(sample: [1, 12, 19.5, -5, 3, 8])

Up to you.

@Schemetrical
Copy link

public static func variance(sample values: [Double]) -> Double? goes well with public static func variance(population values: [Double]) -> Double? 😄

@evgenyneu
Copy link
Owner

@NathanJang good point about naming, I need to think about it.

@evgenyneu
Copy link
Owner

@Schemetrical yes it is a good alternative, thank you. In this particular case I still prefer to keep information of "what the function does" in its name, and not to split it into the function name and parameter name. I described my motivations above.

@NathanJang
Copy link
Author

Sigma.variance(sample: [1, 12, 19.5, -5, 3, 8]) and Sigma.variance(population: [1, 12, 19.5, -5, 3, 8]) would be 2 separate method signatures. Even though it's technically a parameter, it still distinguishes itself from the other.

@evgenyneu
Copy link
Owner

Now I am rethinking this and I am starting to like it. It does play beautifully with Swift parameters. The name of the parameter, population or sample, actually describes the data we pass into. And the parameter name still remains a part of the function name. Beautiful.

@evgenyneu evgenyneu reopened this Oct 1, 2015
@Schemetrical
Copy link

Yep, and this is basically what Apple is doing while converting UIKit methods to swift with constructors too, doing SomeObject(param1: a, param2: b) has a different name than SomeObject(otherParam1: a, otherParam2: b) which is pretty neat.

@NathanJang NathanJang changed the title Don't use 2 separate methods for sample/population Rethinking method names for sample/population Oct 1, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants