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

the fate of hist #314

Open
ozgurakgun opened this issue Sep 4, 2015 · 1 comment
Open

the fate of hist #314

ozgurakgun opened this issue Sep 4, 2015 · 1 comment
Labels

Comments

@ozgurakgun
Copy link
Collaborator

Originally reported by: Özgür Akgün (Bitbucket: ozgurakgun, GitHub: ozgurakgun)


I want it gone. It doesn't seem to add anything over freq, nobody ever used it, is a bit of a headache to implement.


@ozgurakgun
Copy link
Collaborator Author

There are 3 versions of hist that make sense to me.

  1. Has only one argument: the collection of values. Produces a histogram of values in the form of a list-of-pairs, where the first component is the value, and the second component is the count. There are no 0 entries.
  2. Has two arguments: the collection of values, and a list of values-of-interest. Produces a histogram of values in the form of a list of counts, one per each entry in the list of values-of-interest argument. This is what's in the Essence paper, page 21, fig 4.
  3. Has two arguments: the collection of values, and a list of value-ranges-of-interest (in the form of tuples). Produces a histogram of values in the form of a list of counts, one per each entry in the list of value-ranges-of-interest.

Conjure (tries to) implement number 1 at the moment. I am tempted to provide 2&3 as well, since they can be useful (and to match the paper). I think I'll just overload the operator hist, since the behaviour is entirely dependent on the types of the parameters. More soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant