Modulo operator

[Vivian Steller]

Another short question:

Is the modulo operator "%" supported in JSR-331 constraints?

I'd like to state a constraint on variables x and y like: "x % y = 0"

Any thoughts? Thanks!

[JacobFeldman]

Vivian,

JSR-331 Var's interface includes:

        /**

* Returns a new Var that is constrained to be the remainder after

* performing integer division of this variable by the given value, i.e.

* mod(this,value).

* 

* @param value

*            the given value.

* @return a Var that represents: mod(this,value).

*/

public Var mod(int value);

Do you really need public Var mod(Var var) too?

Jacob

[Vivian Steller]

Thanks, for the pointer. This is certainly at least a starting point. But I think I'll require public Var mod(Var var)...

Let me elaborate on my use case (I'm curious about your thoughts about this anyway ;)):

In my use case (object-oriented configuration) a user should be able to select the type of a part (which corresponds to a Java type since part-components are represented as classes) within the configuration. Translated to CSP, this means there is a variable x holding the Java type of the part. Sometimes it's required to impose some constraint to that type, say a constraint should be established that says that the type assigned to x should be a sub-type of class A. If B extends A, then x = B should be valid as well as x = A. However, a type C (not extending A) should be ruled out by the constraint.

Now, of course CSP's don't have support for the variable type "Java Class" neither does any constraint for that type natively exist. My idea was to represent the type hierarchy using prime numbers as follows: 

every Java type gets assigned two numbers:

a) a unique prime number: say type(A) = 2, type(B) = 3, type(C) = 5, type(D) = 7...

b) an (also by definition unique) number that represents the type closure of a type: closure(A) = type(2) = 2, closure(B extends A) = type(B) * closure(A) = 3*2 = 6, closure(C) = type(C) = 5, closure(D extends B) = type(D) * closure(B) = 7*3*2 = 42, ...

So, I'd assign the number that represents the closure to x and state a constraint "the type represented by x must be a subtype of A" as "x mod 2 = 0" (or "x mod closure(...) = 0" in general). Back to the question whether 2 should be a variable value here: I think yes, it's very likely that there will exist another constraint that will dynamically constrain the required type...

Would be great if you could add the method in one of the next releases of the spec.

Thanks very much!

Cheers,

Vivian

[Werner Keil]

Jacob/Vivian,

Thanks for discussing this. Was this included with 1.0 or could it be an enhancement for either a MR or future version?

One thing the discussion highlighted is, there could be a more general requirement for Arithmetics in Java.

Probably not for every operation one could imagine, but general purpose calculations, +, -, * or / and a few others like mod() mentioned here. 

Not sure though, if this would make sense before Java gets some overhaul of its type system around V 10?

As the reduction of primitives in favor of actual types (probably similar to languages like Fantom or Smalltalk) would for your example speak more for mod(Var val) than mod(int val) since an "int" as we know it may no longer exist from Java 10, or at least be auto-boxed to some real "Integer" type in any case, not the other way round like it often happens today.

Werner

[Werner Keil]

Btw, the whole closure thing might at least partially improve with Java 8. Not everyone is entirely happy with how it's meant to come, but it should add new capabilities to the Java language. Where new versions of JSRs like 331 made use of it, they would of course be tied to a minimal Java version of e.g. 8.

Werner

[JacobFeldman]

Without waiting for a new Java, we may already use JSR-331 with Groovy. We have a Groovy interface added to JSR-331 (see project org.jcp.jsr331.groovy) that contain examples of JSR-331 problems using operators directly like below:

// Post constraint SEND + MORE = MONEY 

SEND = 1000*S + 100*E + 10*N + D

MORE = 1000*M + 100*O + 10*R + E

MONEY = 10000*M + 1000*O + 100*N + 10*E + Y

p.post(SEND + MORE, "=", MONEY)

The entire example is attached.