I'm new to writing Prolog and would like to know how to state the following properties in a way that's useful for later reasoning.
There are N objects.
Every object has a color.
There are three possible colors: red, green, blue
Let's assume there are two objects: object 1 is red, object 2 has a different, unspecified color. How can I ask Prolog for possible colors of object 2? I'd expect green and blue.
My code so far:
object(obj_1).
object(obj_2).
color_value(red).
color_value(green).
color_value(blue).
color(Obj, Val) :- object(Obj), color_value(Val).
color(obj_1, red).
different_color(O1, O2) :- color(O1, X), color(O2, Y), X \= Y.
different_color(obj_1, obj_2).
When I query for possible colors of obj_2, Prolog includes red. So I'm doing it wrong somehow.
color(obj_2, A).
A = red ;
A = green ;
A = blue.
I suspect there's something wrong with how I use color and different_color.
Your definition of color/1 offers redundant solutions for color(_, red) or color(obj_1, _). Your clause for color(Obj, Val) needs to exclude the case where Obj is obj_1 or Val is red.
A simplistic approach could be:
color(Obj, Val) :-
dif(Obj, obj_1),
dif(Val, red),
object(Obj),
color_value(Val).
color(obj_1, red).
Also, consider #DavidTonhofer's comment about style. :)
Related
How to find a list of colors that have the largest number of nested shapes? Using aggregate library tools.
I will be grateful for your help!
figure(square1, red).
figure(circle, red).
figure(triangle, blue).
figure(rectangle, green).
figure(diamond, purple).
figure(square2, green).
figure(trapezium1, black).
figure(hexagon, grow).
figure(trapezium2, yellow).
contains(square1, rectangle).
contains(circle, diamond).
contains(square1, hexagon).
contains(trapezium2, square2).
contains(trapezium1, triangle).
contains(triangle, square2).
extract (X, L) :- retract(figure(X-L)), !.
extract (_, []).
colorList(_) :- figure(X, Y), extract(X, L),
assertz(name(X-[Y|L])), fail.
colorList(List) :-extractFigures(List).
I'm new to this library and I want a way to operate a (for example) Pixel RGB Double like:
p <- <RGB:(1.0e-2|9.80392156862745e-4|9.900990099009901e-3)>
I know substracts or sums affects the whole RGB
pixel p = p + 1
<RGB:(1.01|1.0009803921568627|1.00990099009901)>
Is there a way to operate the Red, Blue or Green part alone instead of operate the three colors at once?
For RGB, the data declaration looks like this:
data instance Pixel RGB a = PixelRGB a a a
The three fields are the red, green, and blue fields, respectively. So you can do all the usual Haskell-y things like pattern matching and reconstructing. For example:
redder (PixelRGB r g b) = PixelRGB ((r+1)/2) g b
The data declarations for other instances of this data family are shown at the top of the main documentation page.
I realise I've written this like a homework question, but that's because it's the simplest way for me to understand and try to relay the problem. It's something I want to solve for a personal project.
I have cards laid out in a grid, I am starting with a simple case of a 2x2 grid but want to be able to extrapolate to larger n×n grids eventually.
The cards are all face down, and printed on the faces of the cards are either a:
positive non-zero integer, representing the card's 'score'
or the black spot.
I am given the information of the sum of the scores of each row, the number of black spots in each row, and the sum of the scores of each column, and the number of black spots in each column.
So the top row must have a sum score of 1, and exactly one of the cards is a black spot.
The rightmost column must have a sum score of 2, and exactly one of the cards is a black spot.
Etc.
Of course we can see the above grid will "solve" to
Now I want to make a function that inputs the given information and produces the grid of cards that satisfies those constraints.
I am thinking I can use tuple-like arguments to the function.
And then every "cell" or card in the grid is itself a tuple, the first element of the tuple will be the score of the card there (or 0 if it is a black spot) and the second element will be a 1 if the card is a black spot or a 0 otherwise.
So the grid will have to resemble that ^^
I can find out what all the a, b, variables are by solving this system of equations:
(Knowing also that all of these numbers are integers which are ≥0).
I wanted to use this problem as a learning exercise in prolog, I think it seems like a problem Prolog will solve elegantly.
Have I made a good decision or is Prolog not a good choice?
I wonder how I can implement this in Prolog.
Prolog is very good for this kind of problems. Have a look clp(fd), that is Constraint Logic Programming in Finite Domains.
This snippet shows a primitive way how to solve your initial 2x2 example in SWI Prolog:
:- use_module(library(clpfd)).
test(Vars) :-
Vars = [TopLeft, TopRight, BottomLeft, BottomRight],
global_cardinality([TopLeft, TopRight], [0-1,1-_,2-_]), TopLeft + TopRight #= 1,
global_cardinality([TopLeft, BottomLeft], [0-1,1-_,2-_]), TopLeft + BottomLeft #= 1,
global_cardinality([BottomLeft, BottomRight], [0-1,1-_,2-_]), BottomLeft + BottomRight #= 2,
global_cardinality([TopRight, BottomRight], [0-1,1-_,2-_]), TopRight + BottomRight #= 2,
label(Vars).
Query:
?- test(Vars).
Vars = [1, 0, 0, 2].
You can take this as a starting point and generalize. Note that the black dot is represented as 0, because clp(fd) deals only with integers.
Here is the documentation: http://www.swi-prolog.org/man/clpfd.html
I've recently been looking into color spaces and color models. I've become interested in the relationships and conversions between different spaces, and I came across CIEXYZ and CIELUV.
In the conversion algorithm, the CIELUV article mentions the variables u', v', u'ₙ, v'ₙ, and Yₙ. I understand that these are related to the white point (of which a table of common values can be found here,) but I'm not exactly sure what the relationship is.
In the article, it says:
For example, for the 2° observer and standard illuminant C, u'ₙ = 0.2009, v'ₙ = 0.4610
(The values for the 2° observer and standard illuminant C can be found in the table mentioned above, and are given as x₂ = 0.31006 and y₂ = 0.31616.)
Below this, the equations for computing u' and v' are given:
u' = (4x)/(-2x + 12y + 3)
v' = (9y)/(-2x + 12y + 3)
If we plug in the x₂ and y₂ we've been given, we get the expected result of u' = 0.2009 and v' = 0.4610. However, earlier in the article, it said that u'ₙ and v'ₙ should be those respected values. Not u' and v'.
Also, the article makes no mention of Yₙ other than stating that it's the luminance of the (u', v') chromaticity coordinates, information on which I can't find.
So, my question is, what the heck are u', v', u'ₙ, v'ₙ, and Yₙ? Assuming that u' and v' are the target chromaticity and u'ₙ and v'ₙ are the source chromaticity (or vice-versa,) then the main conversion algorithm would make no sense if the target and source are the same, as the resulting u* and v* would equal 0. If someone could shed a little light on this for me, it'd be greatly appreciated. Thanks.
You calculated the u', v' of white point, which are per definition u'ₙ, v'ₙ. These are constant. Computer screen (sRGB), HDTV (Rec.709), movie theater, etc. have own specific white point. You should decide it, and keep constant for the transformation.
Yₙ is the luminance of the white point. This depend on the setting of the television. More power, more luminous will be the white point. Probably you should set it as 1.0 (or 100, or the maximum digital value). You see that L*, u*, and v* are inversely proportional to Yₙ. This is just used to norm L to 100 (in the case of Wikipedia transformation). So you should just it as the maximum Y, or the luminance Y of white (if you have superwhite, like in HDTV).
CIEXYZ (you initial space, and most common "common" space to be used between transformation) have just defines X, Y, Z (or x, y, z or also more frequently x, y, Y). These values represent eye sensitivity (really a linear transformation, just to have positive values, they discovered exact coordinates later (LMS colour space), so that are independent to white space (so you have no parameter for white), but this means also that well defined chromacity (x, y) can be seen as different colour, according the actual colour adaptation.
I short (inverse order from Wikipedia).
you have x, y, Y of a point, according CIEXYZ (linear space). x, and y are the chromacities. Y is the luminance.
you transform to u', v' (for now just chromacities, also just in function to x, y).
and last step is the gamma correction, so you transform from linear space into a perceived function, so you get L*, u*, v*.
Wikipedia is mixing colour model (e.g. RGB, and the generic transformation to/from RGB) with colour space (sRGB [the normal "web colour" space], which is a RGB model with well defined chromacities for Red, Green, Blue and White, and a well defined gamma function). You should treat variables with N subscript as pre-defined constant, for your specific Luv colour space.
I have a basket of flowers and I want them to tag and sort by their Color. Any ideas on how this can be done, will be very helpful.
Thanks much for your time.
The most obvious solution would seem to order by hue.
This would give you a stable sorting comparison operator that would sort your array in this order:
Note that some RGB colors are degenerate in the sense that they don't have a single HLS form. White is such an example. It's up to you how you're going to handle them.
You can do this using the concept of Lexicographic ordering.
Basically, given the HSL representations of 2 colors (say C1 = (H1, S1, L1) and C2 = (H2, S2, L2)), we can define C1 < C2 if and only if ((H1 < H2) || (H1 == H2 && S1 < S2) || (H1 == H2 && S1 == S2 && L1 < L2)), and C1 == C2 if and only if H1 == H2 && S1 == S2 && L1 == L2. Similarly for C1>C2.
This will order the colors first by hue; then by saturation to resolve hue conflicts; and finally by lightness to resolve hue and saturation conflicts.
I've used the precedence order H > S > L in this example, but you could just as easily use some other order according to your needs, or maybe even another color respresentation (e.g., RGB).
If you want to sort it by the actual color, not alphabetically by the name of the color, then the solution isn't very obvious. Sorting is normally done on entities where a clear "greater than" and "less than" semantic can be defined. Colors, though, don't have such a semantic because they're represented by 3 numbers generally (either RGB or HSV). You would have to arbitrarily define your own "ordering" and then sort using that.
you can compare colors in java see this
You could try taking the principal components of variance, then projecting on that axis. (So if all the colours are shades of red, red is non-zero, green and blue are both zero, and the algorithm would say the axis is 1.0, 0.0, 0.0. It then sorts on red. If they are all shades of yellow, then that axis is root(0.5), root(0.5), 0.0, it averages the red and green, and sorts on that).
It won't work well if the colours form three or more distinct "clouds".