Skip to content

Conversation

@williamdemeo
Copy link
Member

a very modest start

∣C∣ -- # of constraints (resp.)
: ℕ
𝐶 : Fin ∣C∣ → Constraint{χ} ∣V∣ ∣D∣
record Constraint (var : Type ν)(dom : Type δ){ρ : Level} : Type (lsuc (ι ⊔ ν ⊔ δ ⊔ ρ)) where
Copy link
Collaborator

Choose a reason for hiding this comment

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

Isn't the level that you want (lsuc ι) ⊔ ν ⊔ δ ⊔ (lsuc ρ) ? This is lower (in general). The nice thing about parameters is that they don't cause level creep.

Copy link
Member Author

Choose a reason for hiding this comment

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

Correct. How could you possibly have noticed that?!

Copy link
Collaborator

Choose a reason for hiding this comment

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

Experience?

Some of the informal (i.e., non-agda) material in this module is similar to that presented in
\begin{code}

record CSPInstance (var : Type ν)(dom : Type δ){ρ : Level} : Type (lsuc (ι ⊔ ν ⊔ δ ⊔ ρ)) where
Copy link
Collaborator

Choose a reason for hiding this comment

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

This seems oddly formed to me - shouldn't the Constraint be a parameter?

Copy link
Member Author

@williamdemeo williamdemeo Jul 14, 2021

Choose a reason for hiding this comment

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

Well, there's not a single constraint (though you could view it as such). Rather, there is a tuple of contraints, so I use arity to represent the "number" of constraints, and then the constraints are modeled as a function from arity to the Constraint type. Does it still seem odd to you? Perhaps it would have been easier to comprehend if I had called the arity field ∣constraints∣ or something similar? (and then rename the cs field constraints...?)

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think I was not precise. Isn't a CSPInstance supposed to be an instance of a CSP? In other words, it should be parametrized by a single "problem". The definition used here only have a very diffuse 'problem' that it depends on, quite indirectly.


record Constraint (∣V∣ ∣D∣ : ℕ) : Type (lsuc (χ ⊔ ρ)) where
field
scope : Fin ∣V∣ → Type χ -- a subset of Fin ∣V∣
Copy link
Collaborator

Choose a reason for hiding this comment

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

This seems overly general. There is little point in having witnesses to whether something is in scope. You might as well use Bool instead. And then Vec (Fin |V|) Bool might be easier?

Copy link
Member Author

@williamdemeo williamdemeo Jul 14, 2021

Choose a reason for hiding this comment

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

Very good point. I want to make the FiniteCSP module very special and easy to use, so I'll try the Vec approach you suggest. (That's actually what I started with, but thought it was maybe too special... but probably you're right.)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Because Fin |V| has decidable equality (and is finite!), you gain very little from having scope be so very general. You may as well have other things also have decidable equality.

@williamdemeo williamdemeo marked this pull request as draft July 17, 2021 13:20
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.

2 participants