I'm very new to PDDL and stumbling into something basic.
The object model is something along the line of:
Object A has multiple numeric properties: Object B is a collection of Object A,
as part of the pre-condition in an action where the parameter passed is Object B, properties of all Object A's (that are contained in Object B) need to satisfy certain criteria.
Using functions, I can define numeric properties of Object A, but I don't know how to capture "Object B is a collection of Object A"?
I'm not sure if it adheres to your problem specification, but couldn't you just define a predicate is_part_of(?x - ObjectA ?y - ObjectB) to define this property?
Then in the precondition you can use a forall quantifier on all objectA. In the forall body state that when the predicate is true, the objects have to satisfy the criteria. Note that PDDL has the when keyword that makes this easy. Otherwise you could encode this as just a simple or by encoding the alternative.
Related
The other day I noticed that I sometimes put data in front of objects and other times not:
object A
data object B
What's the difference between an object and a data object?
The fact that data is allowed on an object declaration is in fact a bug (KT-6486) which should be fixed.
data is an annotation which causes the compiler to generate equals, hashCode, toString, copy and componentN functions. It doesn't make much sense when applied to an object declaration for two reasons:
An object declaration cannot have a constructor, and all these functions work based on properties defined in the primary constructor.
There's only one instance of any object at runtime.
So no componentN functions would be generated, copy can't work, and the generated equals/hashCode/toString implementations will be equivalent to the default ones from Any which are based on identity.
I am studying OWL and I am trying to build an Ontology using Protege.
I found an option called Equivalent To in Protege.
What is that option for please? Is it for dividing the space of instances? or is it to set the Object properties that a class can have?
Equivalent to applies to class expressions, object properties and data properties.
Equivalence in class expressions
In class expressions, equivalence means that two classes have the same individuals in any interpretation (i.e., the two classes are alternate names, or equivalent definitions, for the same set of individuals).
Equivalence in data and object properties
For object and data properties, asserting that two properties are equivalent means that their domains and ranges apply to both properties, and that every assertion using one property can be rewritten as using the other.
Example
For example, suppose I declare a hasOwner object property and an ownedBy as equivalent, then: MyCar hasOwner Me implies MyCar ownedBy Me.
I'm trying to implement the classical tree structure in frege, which works nicely as long as I don't use "derive":
data Tree a = Node a (Tree a) (Tree a)
| Empty
derive Show Tree
gives me
realworld/chapter3/E_Recursive_Types.fr:7: kind error,
type constructor `Tree` has kind *->*, expected was *
Is this not supported or do I have to declare it differently?
Welcome to the world of type kinds!
You must give the full type of the items you want to show. Tree is not a type (kind *), but something that needs a type parameter to become one (kind * -> *).
Try
derive Show (Tree a)
Note that this is shorthand for
derive Show (Show a => Tree a)
which resembles the fact that, to show a tree, you need to also know how to show the values in the tree (at least, the code generated by derive will need to know this - of course, one could write an instance manually that prints just the shape of the tree and so would not need it).
Generally, the kind needed in instances for every type class is fixed. The error message tells you that you need kind * for Show.
EDIT: eliminate another possible misconception
Note that this has nothing to do with your type being recursive. Let's take, for example, the definition of optional values:
data Maybe a = Nothing | Just a
This type is not recursive, and yet we still cannot say:
derive Show Maybe -- same kind error as above!!
But, given the following type class:
class ListSource c -- things we can make a list from
toList :: c a -> [a]
we need say:
instance ListSource Maybe where
toList (Just x) = [x]
toList Nothing = []
(instanceand derive are equivalent for the sake of this discussion, both make instances, the difference being that derive generates the instance functions automatically for certain type classes.)
It is, admittedly, not obvious why it is this way in one case and differntly in the other. The key is, in every case the type of the class operation we want to use. For example, in class Show we have:
class Show s where
show :: s -> String
Now, we see that the so called class type variable s (which represents any future instantiated type expression) appears on its own on the left of the function array. This, of course, indicates that s must be a plain type (kind *), because we pass a value to show and every value has per definition a type of kind *. We can have values of types Int or Maybe Int or Tree String, but no value ever has a type Maybe or Tree.
On the other hand, in the definition of ListSource, the class type variable c is applied to some other type variable a in the type of toList, which also appears as list element type. From the latter, we can conclude, that a has kind * (because list elements are values). We know, that the type to the left and to the right of a function arrow must have kind * also, since functions take and return values. Therefore, c a has kind *. Thus, c alone is something that, when applied to a type of kind * yields a type of kind *. This is written * -> *.
This means, in plain english, when we want to make an instance for ListSource we need the type constructor of some "container" type that is parameterized with another type. Tree and Maybe would be possible here, but not Int.
is operator overloading in fact polymorphism or parameter overloading?
Is it true that polymorphism usually refer to different classes responding to the same "message" (the method name) and do different things, so
bird.give_sound()
and
car.give_sound()
can do different things. And parameter overloading is more about talking about the same class, doing different things when the parameters sent along with the message (the method name) are different. So
bird.give_sound()
and
bird.give_sound(:frighten_sound)
can be different.
So operator overloading is strictly parameter overloading? like this following:
"foo" + "bar"
"foo" + 3
at least in Ruby, it is sending the + message to the string containing foo, the first line is sending with a parameter string, the second one is sending a parameter 3, and the + do slightly different things, but it is the same receiver class String
In the following example, it is polymorphism:
"foo" + 3
1 + 3
because the + message invoke different methods of different classes, but using the same message name +. So in these 2 cases, they are polymorphism, not operator overloading?
Is the above accurate and correct? Is there something that might be added to it or be corrected above?
Thank you for the clarification of context in your comment. Yes, I would say you are correct.
To summarize as short as possible...
Given identical method name (or "message"):
different behaviour based on parameter type is overloading,
different behaviour based on object type is polymorphism.
I'm going to take a stab in the dark and say that it's kind of (but not really) both.
Each object has to deal with the given object (the object on the right side of the operator) in a specific way. With strings, it seems that the toString method (or other language equivalent) would be used. So you would always be appending a string (passed to the method as an Object). (Polymorphism)
However, your object may need to perform different logic based upon the object given. For example, say you have a Student object. You may have one version of the method that takes a Class object, and adds it to the Student's class schedule. You then might have an overload that takes, say, a Book and adds it to the Student's collection of required reading material. (Parameter Overloading)
Polymorphism is when one data type dynamically behaves as another datatype.(Dynamic typecasting)
Shape
Qudrilateral
Rect
Rhombus
Elliptoid
Oval
Circle
Polymorphism is automatically selecting the proper area() method for a given object context
Operator overloading is when you select the correct area method for a method context(i.e. number of arguments passed or type of arguments passed) So if Rect had two area methods, one that accepted one argument(square) and one that accepted two arguments(any other rectangle)
So depending on the usage context, defining the operators for a given object can result in either Polymorphism or Operator Overloading.
Good Question.
The problem you found, its that we have 2 different concepts which similar syntax, that clash when applied programming: Overloading and parameter inheritance.
When I found operator overloading, I usually think in terms of overloading (methods) functions, to make more clear.
When I read these:
// (string) x = (string) "foo" + (int) 3
x = "foo" + 3
I think of these:
// (string) x = (string) "foo".concat((int) 3)
x = "foo".concat(3)
There is an additional problem, that each programming language handles operators with classes different.
I would suggest, to avoid operator overloading with object parameters, and explicity use functions.
This might be an odd question, but it has actually caused me some headache.
In Object oriented programming, there are accepted names for key concepts. In our model, we have classes with methods and fields. Now, going to the data world:
An instance of a class is called an object.
An instance of a field is called... what?
A value? Isn't the term value a little broad for this? I have been offered "property" as well, but isn't property also part of the model and not the data?
(This is not purely academic, I am actually coding these concepts.)
Updated: Let me take an example. I have a class "Person" with a field "age". If I create 20 Person instances, each such instance is called an object. So far so good. But let's say I take Person "Igor", and set his age to 20. What is the storage location that contains the number 20 now called? Is it a field, or a value, or something else?
Another update: A quote from Pavel Feldman in this related question describes in different words what I tried to describe above:
"I'd say that in class-based OOP field belongs to class and does not have a value. It is so when you look at reflection in c# or java - class has fields, field has type, name, etc. And you can get value of the field from object. You declare field once, in class. You have many objects with same fields but different values."
A field can't be instantiated. A field can only contain a value. The value can be either a primitive/native type or a reference/pointer to an object instance.
As per your update: if the object represents a real world entitiy, then it's often called property. With a "real world entity" I mean something personal/human, e.g. Person, Product, Order, Car, etc. If the object does not represent something personal/human, e.g. List, String, Map, then it's more often called field. That's just what I've observed as far.
Agree with BalusC. However I think what you are asking is what to call the field of an instantiated object. Remember that an object contains both state (data) and operations (methods) you could refer to an object field as state
A field is a field weather you talk about it in the context of a class, or in the context of an object.
class C {
int i; // i is a field
}
and
obj = new C();
obj.i = 7; // obj.i is a field
As opposed to parameter vs argument there is no distinction in terminology for "instantiated" an "uninstantiated" fields.
An instance of a class is an object, a class may contain fields that point to other instantiated objects (or a null pointer). It makes no sense to say an instance of a field, but rather you might talk about the object to which a particular field points to, which may be different for different instances. Or you may talk about the type of a field (which class it belongs to)
Isn't the answer basically that we have no name for values of fields of an instance of a class (or object)?
It's like giving a name to the value returned by a method of an instance of a class...
I guess "state" is the best answer anyway as suggested "BalusC".