Skip to content

queen-attack: represent positions as objects #935

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

Conversation

HarrisonMc555
Copy link
Contributor

Closes #721.

I decided to use objects, since it seems like most people were agreeing it was more explicit. I will also be using objects to encode the position for #722, which is deals with a similar issue.

@stkent
Copy link
Contributor

stkent commented Oct 9, 2017

Nice change! Please also bump the canonical data version as appropriate: https://github.com/exercism/problem-specifications#test-data-versioning :)

@HarrisonMc555
Copy link
Contributor Author

@stkent Thanks for the reminder, totally forgot about that! Since we're changing the type of one of the data keys I assume this is a major bump, correct?

@stkent
Copy link
Contributor

stkent commented Oct 9, 2017

That would be my interpretation of the guidelines, yes!

@HarrisonMc555
Copy link
Contributor Author

Thanks, bumped major number.

@Insti Insti changed the title Queen attack position encoding queen-attack: represent positions as objects Oct 9, 2017
"position": "(2,2)"
"position": {
"file": 2,
"rank": 2
Copy link
Contributor

Choose a reason for hiding this comment

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

The description uses the terms row and column I think we should stick with those.

Copy link
Member

Choose a reason for hiding this comment

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

Agree with @Insti, we should follow what is in the description (or else change the description).

Copy link
Contributor

@Insti Insti Oct 10, 2017

Choose a reason for hiding this comment

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

I'd argue against changing the description. (But it is certainly an option.)

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 agree, row/column works great for me. Made the change.

Copy link
Member

@NobbZ NobbZ left a comment

Choose a reason for hiding this comment

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

deleted

Copy link
Member

@NobbZ NobbZ left a comment

Choose a reason for hiding this comment

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

As with #936, I do not think that the proposed changes justify a major bump.

1.0.1 should be bumped enough, since only representation of testdata changed, which each language is free to choose anyway and no one is forced to change anything in the corresponding exercises of their tracks.

@NobbZ
Copy link
Member

NobbZ commented Oct 9, 2017

It seems as if I had to revoke my request for changes, as per the version numbering documentation, we have to bump MAJOR when we break test generators, and this changes propably will:

MAJOR changes should be expected to break even well-behaved test generators.

I previously always understood the version as a version of the exercise, to understand evolvement of exercises, but it seems as if it were only meant to check for compatibility in testgenerators, nothing more, nothing less.

NobbZ
NobbZ previously approved these changes Oct 9, 2017
@NobbZ NobbZ dismissed their stale review October 9, 2017 20:56

Misunderstanding versioning guidelines

@NobbZ NobbZ mentioned this pull request Oct 9, 2017
Copy link
Member

@petertseng petertseng left a comment

Choose a reason for hiding this comment

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

I am glad it is getting done.

No opinion on rank/file vs row/column, but I will remark that I often forget which is which and have to remind myself that we talk about the a-file, b-file, etc., so there is an advantage to row/column even if it is not specific to the domain

Squash on merge.

(Don't worry, I'm not merging until we deal with rank/file vs row/column, this approval just means I ultimately would take either)

@HarrisonMc555
Copy link
Contributor Author

I'm totally fine with row/column, let's use that. Just submitted the patch. Anything else?

Copy link
Member

@petertseng petertseng left a comment

Choose a reason for hiding this comment

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

require 'json'
require_relative '../../verify'

json = JSON.parse(File.read(File.join(__dir__, 'canonical-data.json')))

raise "There should be exactly two cases, not #{json['cases'].size}" if json['cases'].size != 2

verify(json['cases'][0]['cases'], property: 'create') { |c|
  c['queen']['position'].values_at('row', 'column').all? { |x| (0...8).cover?(x) } ? 0 : -1
}

verify(json['cases'][1]['cases'], property: 'canAttack') { |c|
  w, b = %w(white black).map { |color|
    c["#{color}_queen"]['position'].values_at('row', 'column')
  }
  diffs = w.zip(b).map { |wb| wb.reduce(:-).abs }
  diffs.include?(0) || diffs.uniq.size == 1
}

says it is good.

Squash on merge.

Copy link
Member

@petertseng petertseng left a comment

Choose a reason for hiding this comment

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

these two don't need to be fixed in this PR.

"position": {
"row": 2,
"column": 2
}
},
"expected": 0
},
{
"description": "queen must have positive rank",
Copy link
Member

Choose a reason for hiding this comment

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

this is very awkward that the description (and thus the keys in the JSON file) use "row" yet the description uses "rank". We'll want to fix that up later (or now??)

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'm willing to change it now.

"position": {
"row": 2,
"column": 2
}
},
"expected": 0
Copy link
Member

Choose a reason for hiding this comment

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

a little awkward that these are 0/-1 instead of just true/false. Probably worth fixing later on.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right now it's using 0/1 as false/true and -1 as error. It would probably be better to use the accepted "error" methodology, but that's probably worth its own pull request. Should one of us open an issue?

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree that a separate PR for this is a good idea.

@HarrisonMc555
Copy link
Contributor Author

@petertseng I made the changes in the test case descriptions like you mentioned.
@Insti Do things look good? I think I'm ready to merge, I'll go ahead and squash the commits now.

queen-attack: use rank/file instead of x and y

queen-attack: bump major version for queen-attack

queen-attack: Use row/column instead of rank/file in test keys

queen-attack: use row/column instead of rank/file in json descriptions
@HarrisonMc555 HarrisonMc555 force-pushed the queen-attack-position-encoding branch from 3577218 to 330c197 Compare October 11, 2017 23:16
@petertseng petertseng merged commit 44a1e12 into exercism:master Oct 12, 2017
@HarrisonMc555 HarrisonMc555 deleted the queen-attack-position-encoding branch October 12, 2017 20:50
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.

6 participants