in PDDL I can define "sub" types like this:
(:types
one two - parent other
)
one and two are also parent, other is distinct.
So like, the predicate (both ?x - parent) accepts ones and twos.
I want to do multi-level inheritance, I tried
(:types
sprite fanta - fizzy water - drink
food
)
I want sprite and fanta to be fizzy, and fizzy and water are both of the type drink.
So my predicate (pour ?x - drink) should accept sprite, but at the moment it doesn't.
How do I correctly set up this type tree?
object
├── drink
│ ├── fizzy
│ │ ├── fanta
│ │ └── sprite
│ └── water
└── food
I hope it's not too late to answer your question.
This code should do what you want:
(:types
food drink - object
water fizzy - drink
fanta sprite - fizzy)
Hope it helped! You can find a whole PDDL reference here.
Related
So what I want to do is render each material 1 at a time. Which means that each Material will have it's own vertices. Is there some kind of function within Assimp when I process a mesh that will tell me which material the vertices belong to.
Of course I would put the position, the normal and the texCoord in the vertex and I need the induces.
There is no query to get these meshes implemented in Asset-Importer-Lib right now. But you can write this easily by yourself:
Import your model
Check whether there are any meshes loaded
Loop over all meshes stored in aiScene
Sort them for meshes with the same material index
Loop over all vertices of the list of meshes.
I wrote a blog-post about that: Batch-Rendering for Assimp-Scene
I am reading CLRS page 309, and I am confused by the definition of black-height of RBT.
The definition in in this book is
the number of black nodes on any simple path from, but not including,
a node x down to a leaf
I also referred to wikipedia, black-height is defined as
the uniform number of black nodes in all paths from root to the leaves
and geeksforgeeks.org
Black height is number of black nodes on a path from a node to a leaf.
Leaf nodes are also counted black nodes.
But none of them give examples, especially no edge cases.
Can you explain it with the following cases?
What is the black-height of a RBT:
nil
B-(nil nil)
B-R-B-(nil nil)
\ \
\ B-(nil nil)
B-(nil nil)
By the definition of CLRS, I calculate the black-height of root is
0
1
2
(In my opinion, am I right?)
And in CLRS lemma 13.1's proof, height is also used. What is the height of the above three trees?
0
1
2
(In my opinion, am I right?)
And, what is the black-height of a tree?
1
2
3
(not sure, I doubt the wikipedia's definition is different from the definition from CLRS)
And also, Exercise 13.1-1 uses this definition.
I would like to submit a OOP problem. Maybe it has been solved elsewhere, but I wasn't able to find it...
Imagine something like this (python-like pseudo-code)
class Point:
x: int
y: int
# Some methods here
class Point3D(Point):
z: int
class Circle:
center: Point
radius: int
# Some methods here
class Sphere(Circle):
center: Point3D
In a staticly typed langage - unless I make a mistake - a Point3D instance will pass as a center attribute for Circle, since it inherits from Point, wich has to be unallowed, because it would turn into a Sphere-like.
How can we achieve that without losing methods factorisation?
The Liskov Substitution Principle (LSP) states that replacing an instance of a base classe with an instance of a derived class shall always work. This is a core feature of OOP, not an issue.
The issue is in you model -- let's consider what the relationship between a 2D point and a 3D point is. Having Point3D inherit from Point2D states that a Point3D is a Point2D, that is, all Point3D's are also Point2D's.
But this does not actually fit what you're modeling! In math, only 3D points from the 2D plane (the ones with z == 0) are actually 2D points. This discrepancy is the source of that loophole that might turn your Circle into a sphere.
The OOP model for this could actually be the opposite: all 2D points are 3D points, with z == 0. Thus Point2D inheriting from Point3D would kind of make sense. It would, however, open up a new set of problems with mutability: if you are able to access a Point2D as a Point3D and modify it, then you can set its z coordinate to be non-zero, and end up with an inconsistent Point2D that is not actually 2D anymore. LSP is broken again.
It is tempting to represent the relationship between a 2D and a 3D point in OOP in either direction:
A 3D point contains one more coordinate that a 2D point doesn't use, thus it should be the derived class
... or...
Mathematically, a 2D points is also a 3D point, so it should be the derived class
... but the bottom line is simply that neither class can inherit from the other one, because the LSP is broken either way. Keep them as separate classes, apples with apples and Circles with Point2Ds, and use some other language features if you need to factor common code between points -- generic programming, for example.
I would like to use the water and waterMesh classes from the Ogre3D Demos in order to create the water with some waves. For the moment I added the classes in my project and create a waterMesh Object in this way:
WaterMesh *waterMesh;
waterMesh = new WaterMesh("waterMesh", 100.0f, 64);
Great, I have a water surface 100×100. I would like to create some waves now. I can I do it?Is it updateMesh that I should use?
Looking at the source code I think that you can only push a surface at some point, and the WaterMesh will compute resulting waves after some delta time in its updateMesh method. There seems to be no way to create a typical 'ocean' waves, unless you modify the source code.
But if it's all you need, then use the push(Real x, Real y, Real depth, bool absolute) method.
Code quality metric tool like Sonar does provide the ability to drill down to a class and find out the number of:
Afferent (incoming) couplings
Efferent (outgoing) couplings
What are these two parameters? Can you please describe with a simple contrived example?
According to wikipedia:
Afferent Couplings (Ca): The number of classes in other packages that depend upon classes within the package is an indicator of the package's responsibility. Afferent = incoming.
Efferent Couplings (Ce): The number of classes in other packages that the classes in the package depend upon is an indicator of the package's dependence on externalities. Efferent = outgoing.
So, if you have classes (or packages or whatever) with the following structure:
class Foo {
Quux q;
}
class Bar {
Quux q;
}
class Quux {
// ...
}
Then Foo and Bar each have one efferent coupling, and Quux has two afferent couplings.
Since you mentioned Sonar, here is the definition provided by their documentation page
Afferent couplings : A class afferent couplings is a measure of how
many other classes use the specific class.
Efferent couplings : A class efferent couplings is a measure of how
many different classes are used by the specific class.
Coupling is a measure of dependencies.
Afferent Coupling :
Who depends on you.
Measure of how many other packages use a specific package.
Incoming dependencies.
Efferent Coupling :
Who do you depend on.
Measure of how many different packages are used by a specific package.
Outgoing dependencies.
In the booke fundamentals of software architecture these two concepts are used to calculate the instability of a class or package. The formula ce/ce+ca will give you the insrability (buginess factor).
Other users have already given answers from the definition perspective. Here, I have given an example of Afferent Coupling (Ca) and Efferent Coupling (Ce) for package-level granularity.
Suppose, package1 has 3 classes (i.e., A, B, C) and package2 has 2 classes (i.e., P, Q). For package1, class A has 2 out-going edges, class B has 1 out-going edge, and class C has 1 in-coming edge. Similarly, for package2, class P has 2 in-coming edges, and class Q has 1 in-coming and 1 out-going edge. [see the figure].
To calculate the Ca for a package, count the number of classes out of the package that has dependencies on it. You can proceed one by one for all classes of that package and then, take the union of dependent classes.
To calculate the Ce for a package, count the number of classes dependent on other packages inside the analyzed package. Count for all classes of that package and then, take the union.
So, the calculation will be as follows--
package1
Ca = {} union {} union {Q}
= {Q}
= 1
Ce = {P, Q} union {P} union {}
= {P, Q,}
= 2
package2
Ca = {A, B} union {A}
= {A, B}
= 2
Ce = {} union {C}
= {C}
= 1
Afferent Coupling and Efferent Coupling are used to calculate the Instability (I) of a package also. Instability is the ratio between Efferent Coupling (Ce) and the total package coupling (Ce + Ca). The formula is
I = Ce / (Ce + Ca)
The value of instability is between 0 to 1. The value towards 1 means unstable package (i.e., prone to change) and the value towards 0 means stable package.
For this example,
Instability for package1 = 2/(1+2) = 0.67 and,
Instability for package2 = 1/(2+1) = 0.33
So, we can conclude that package1 is more unstable than package2 by measuring the afferent and efferent coupling.
For additional info you may check this paper also.