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.

Sign up for GitHub

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

prime-factors: add canonical data #513

Merged
merged 1 commit into from
Jan 27, 2017
Merged

prime-factors: add canonical data #513

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions exercises/prime-factors/canonical-data.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
{
"for": {
"description": "returns prime factors for the given input number",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are these 2 lines trying to achieve?

It's better to stick with the standard format. Have a look at some of the recent files added by @petertseng for good examples of what to do.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The format that I was following (from other exercises) had the "method name" as the key for a block, then a description for what that method did, then the cases for that method call tests.

The examples I was following are here:

Somewhere in my travels through all different tickets and discussions around canonical data, I thought I read something that suggested a preference for the method name being included (not just the cases key). So that's what that is for.

Copy link
Contributor

@Insti Insti Jan 26, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, Thanks. It's probably fine, further discussion here: #507 (review)

"cases": [
{
"description" : "no factors",
"input" : 1,
"expected" : []
},
{
"description" : "prime number",
"input" : 2,
"expected" : [2]
},
{
"description" : "square of a prime",
"input" : 9,
"expected" : [3, 3]
},
{
"description" : "cube of a prime",
"input" : 8,
"expected" : [2, 2, 2]
},
{
"description" : "product of primes and non-primes",
"input" : 12,
"expected" : [2, 2, 3]
},
{
"description" : "product of primes",
"input" : 901255,
"expected" : [5, 17, 23, 461]
},
{
"description" : "factors include a large prime",
"input" : 93819012551,
"expected" : [11, 9539, 894119]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

caveat: I've not tried this problem myself recently.

Are these numbers (93819012551, 901255) within the bounds of reasonableness (<1sec) for today's computers without having to rely on Project Euler style optimisation trickery?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just completed this in elixir and ruby. it is interesting because a naive solution in ruby will take a very long time to complete. But there is an efficient solution that does not take too long (less than 1 sec i believe). I found it a good test to challenge the implementation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. Great 😄 Thanks.

}
]
}
}