Skip to content

armstrong-numbers: port #988

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

Merged
merged 2 commits into from
Aug 8, 2019
Merged

Conversation

guygastineau
Copy link
Contributor

@guygastineau guygastineau commented Aug 8, 2019

I have rebased the last ten commits of @Tuxified's work from #893 onto the current master.
canonical-data.json

@guygastineau guygastineau mentioned this pull request Aug 8, 2019
1 task
@guygastineau
Copy link
Contributor Author

I intend to make a test generator for this. It has been awhile since I have done so. I should have some work up for that later tonight or tomorrow.

@guygastineau guygastineau changed the title WIP armstrong-numbers: port armstrong-numbers: port Aug 8, 2019
@guygastineau
Copy link
Contributor Author

guygastineau commented Aug 8, 2019

At first I thought I would add integer delimiting into the generator. Then I was sad when I realized that converting them back into integers destroys the formatting.

Then I felt silly when I realized that the generator needs it in a string 🤣

@guygastineau
Copy link
Contributor Author

Okay, I think I am finished messing with this. 😄

Copy link
Contributor

@emcoding emcoding left a comment

Choose a reason for hiding this comment

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

Hi @guygastineau Thanks for bringing the exercise back to live :-)

config.json Outdated
"slug": "armstrong-numbers",
"uuid": "77c5c7e6-265a-4f1a-9bc4-851f8f825420",
"core": false,
"unlocked_by": "isogram",
Copy link
Contributor

Choose a reason for hiding this comment

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

@guygastineau I didn't realize before that Isogram has moved since the last time we discussed adding this exercise. Let's make it

Suggested change
"unlocked_by": "isogram",
"unlocked_by": "series",

Sorry that I missed this.

Copy link
Contributor

Choose a reason for hiding this comment

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

Note to self: without the lambda, it could be a level 1 side exercise. Then, it may need a more step by step help in the readme.

(This doesn't need to be addressed in this PR, unless you'd prefer to do so, Guy. )

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great, I figured there might need to be some changes to it in the config.json.
I'm on it 😃

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 mean, I will change it to unlock from series I don't especially feel like writing step-by-step instructions for closures in a lvl 1 exercise readme extension.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

changed

def self.include?(number)
raise_to_length = ->(n) { n ** number.digits.size }
number.digits.sum(&raise_to_length) == number
end
Copy link
Contributor

@emcoding emcoding Aug 8, 2019

Choose a reason for hiding this comment

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

:-)
Since the solution file is sometimes consulted by (new) mentors and students, and to avoid miscommunications in general, I'd prefer to have a solution that is in sync with the solution that we strive for.
That's mostly a matter of opinion, I don't think we have a policy for this.

And I'm slightly confused too. ;-) Does this mean that you think the original solution is not good enough? Or?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, I just really wanted to use stabby lambda for the hell of it, and the guide for porting exercises on this track says the solution doesn't need to be ideal (although I think this one is fun 😃)

I have no problem reverting it. That is a simple fix 😃

(I think that porting guide was written before the profound track anatomy project happened, so wanting example solutions that fit the level of the exercise is a reasonable desire given all that you all have done to polish this track 😃)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Reverted.

Copy link
Member

Choose a reason for hiding this comment

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

The example solution is a proof of concept, and if it is not "normal" this means that we will likely spot it quickly, if for some reason it comes to be a solution submitted by a student. So there are some advantages to having a non ideal solution, as long as it "proves the concept".

Copy link
Member

Choose a reason for hiding this comment

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

On the other hand, since this isn't example.rb it may be being presented in the note as an acceptable solution... one to approve. In that situation, the story changes.

Copy link
Contributor

@emcoding emcoding Aug 8, 2019

Choose a reason for hiding this comment

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

Oh, I just really wanted to use stabby lambda for the hell of it

Yeah, you mentioned the lambda fun somewhere else, so that's what I thought it was 🤓 .

FYI:
My thinking is: The beauty of this exercise to me is that it does 'light math', that can be solved with 'early' Ruby methods without being scary mathy. And then it can be refactored to use digits.sum.
For other purposes, this exercise would need more 'progressions' in other aspects, to make the learning curve between exercises steep enough on the higher levels.

Thanks for reverting :-)

@emcoding emcoding requested review from pgaspar and kotp August 8, 2019 09:46
@guygastineau
Copy link
Contributor Author

guygastineau commented Aug 8, 2019

Also, I noticed that you all have a very explicit merge history here. I am very impressed 😍

This PR has a load of commits, so I would be more than happy to rebase it into just a couple commits.
I would probably squash @Tuxified's commits into 1 (might use fixup on one or two that aren't relevant to the final product here), and I can squash mine together, but I'll fixup or drop any that don't need to be there (like the one introducing the lambda).

Anyway, this is just an idea to keep both contributors in the history without having a 20 commit merge for this simple exercise. Let me know what you all would prefer, and if I should do anything about it 😄

def self.include?(number)
exponent = number.digits.size

number.digits.sum { |digit| digit ** exponent } == number
Copy link
Member

Choose a reason for hiding this comment

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

Don't use spaces around ** as it emulates how we expect to see it (similar to xy, very close together), and makes it clear it isn't a typographical error due to style showing intent.

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'll change it, but I strongly disagree. I think operators should always have spaces in languages where it is possible, but I would not consider myself a real rubyist yet (, so I defer to your opinion).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

Copy link
Contributor

Choose a reason for hiding this comment

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

In case it's a comfort: no spaces around exponents is recommended by one of the Ruby Styleguides. Not saying I like it, but I settle for consistency :-)
https://rubystyle.guide/#spaces-operators

def self.include?(number)
raise_to_length = ->(n) { n ** number.digits.size }
number.digits.sum(&raise_to_length) == number
end
Copy link
Member

Choose a reason for hiding this comment

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

The example solution is a proof of concept, and if it is not "normal" this means that we will likely spot it quickly, if for some reason it comes to be a solution submitted by a student. So there are some advantages to having a non ideal solution, as long as it "proves the concept".

def self.include?(number)
raise_to_length = ->(n) { n ** number.digits.size }
number.digits.sum(&raise_to_length) == number
end
Copy link
Member

Choose a reason for hiding this comment

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

On the other hand, since this isn't example.rb it may be being presented in the note as an acceptable solution... one to approve. In that situation, the story changes.

@guygastineau
Copy link
Contributor Author

So, which solution do you all want?

Copy link
Member

@pgaspar pgaspar left a comment

Choose a reason for hiding this comment

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

Good work! Added a couple comments on ways I think we can simplify the generator 👍

This PR has a load of commits, so I would be more than happy to rebase it into just a couple commits.

Thank you - this is appreciated! Squashing this to two commits as you are suggesting sounds great to me.

@guygastineau
Copy link
Contributor Author

guygastineau commented Aug 8, 2019

Thanks for all the pointers everybody 😄

I will wait to squash into two commits until the work is approved (so I don't have to do it twice).

kotp
kotp previously approved these changes Aug 8, 2019
@guygastineau
Copy link
Contributor Author

Thanks @kotp

I'll rebase this after dinner.

pgaspar
pgaspar previously approved these changes Aug 8, 2019
Copy link
Member

@pgaspar pgaspar left a comment

Choose a reason for hiding this comment

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

Thank you!

Tuxified and others added 2 commits August 8, 2019 18:42
- not using Integer.digits as that is only available on Ruby 2.4
  - fix conflicts
  - implement generator
@guygastineau guygastineau dismissed stale reviews from pgaspar and kotp via fe88c70 August 8, 2019 22:46
@guygastineau
Copy link
Contributor Author

I suppose I could have done some squashes mixed in with the fixups, but at least both contributors are represented in the history (which was my main goal here).

@guygastineau
Copy link
Contributor Author

It's ready for you all now. Thanks for working with me on this ;)

Are there any exercises that need generators? I think there used to be a file or an issue somewhere showing which ones needed a generator implemented. I'm happy to hunt them down and make them ;)

@kotp kotp merged commit 27126d8 into exercism:master Aug 8, 2019
@guygastineau guygastineau deleted the armstrong-numbers branch August 9, 2019 01:46
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

Successfully merging this pull request may close these issues.

5 participants