Types

[wkschwartz]

Fixes #8

By using Pigosat specific types — Literal instead of int32, Formula instead of [][]int32 — we address two problems. First, I'm hoping the API is easier to understand for a beginner. Second, it makes maintenance easier: e.g., we can change the literal type from int32 to int64 just by changing the type Literal int32 line. Eventually we could even add methods like

func (lit Literal) Bool() bool {
    if lit > 0 {
        return true
    }
    return false
}

(I'm not adding this method now because I don't think it's entirely necessary at this point.)

@justinfx, wondering what you think about this. I'd like to get the API right, add a few more features, bump to version 1, then set this project aside.

[justinfx]

I think it's a good idea. In addition to maintainability, I do think it increases readability, since the sat-solving stuff tends to have you looking at a lot of slices of ints and bool. The typedef do help to document what you are looking at along the way.

Are you thinking of merging some of the API I had exposed from my fork before putting the project aside?

[wkschwartz]

Thanks for the feedback.

I want to support the entire PicoSAT feature set but I don't want anything
untested in the library (ideally 100% coverage, currently around 90%). So
if you think the core tracing stuff is most important, I'd like to come up
with test data relating to the current ten test cases in pigosat_test.go.
But if I can't figure out how to test it I'm not going to add it.

Plus there are some things that are super easy to test like the recently
added Print and Res methods. I'll add as many of those as I can.

Any advice on priorities, test data, and API you can suggest is welcome.

On Sunday, February 15, 2015, Justin Israel notifications@github.com
wrote:

I think it's a good idea. In addition to maintainability, I do think it
increases readability, since the sat-solving stuff tends to have you
looking at a lot of slices of ints and bool. The typedef do help to
document what you are looking at along the way.

Are you thinking of merging some of the API I had exposed from my fork
before putting the project aside?

—
Reply to this email directly or view it on GitHub
#9 (comment).

Billy Schwartz
cell: 614-578-8007

[justinfx]

Sometime within the next couple days, I could take the features that I have
exposed and write proper tests for them, and submit each as individual
merge requests, so that you could pick and choose?

On Mon Feb 16 2015 at 1:02:14 PM William Schwartz notifications@github.com
wrote:

Thanks for the feedback.

I want to support the entire PicoSAT feature set but I don't want anything
untested in the library (ideally 100% coverage, currently around 90%). So
if you think the core tracing stuff is most important, I'd like to come up
with test data relating to the current ten test cases in pigosat_test.go.
But if I can't figure out how to test it I'm not going to add it.

Plus there are some things that are super easy to test like the recently
added Print and Res methods. I'll add as many of those as I can.

Any advice on priorities, test data, and API you can suggest is welcome.

On Sunday, February 15, 2015, Justin Israel notifications@github.com
wrote:

I think it's a good idea. In addition to maintainability, I do think it
increases readability, since the sat-solving stuff tends to have you
looking at a lot of slices of ints and bool. The typedef do help to
document what you are looking at along the way.

Are you thinking of merging some of the API I had exposed from my fork
before putting the project aside?

—
Reply to this email directly or view it on GitHub
#9 (comment).

Billy Schwartz
cell: 614-578-8007

—
Reply to this email directly or view it on GitHub
#9 (comment).

[wkschwartz]

That would be great. I'm going to try to work on some features/tests too, especially for low hanging fruit.

I think the easiest way to test completely new features is to add fields to the test data like 0bf1cb6, but as always I'm open to suggestion.

Thanks!