.. (לתיקייה המכילה) | ||
The assignment cannot be printed correctly. Is it possible to fix this? | |
Fixed in v1.01. It is a pitty nobody told us anything about this in the previous assignments... Also - the due date was fixed in the assignment (14/12/04, of course). |
How do we add a method to an existing class? | |
Simly use the following syntax: Assuming you'd like to add a method called foo to the class Object, just write the following code in some file and load it ("'myfile.st' r"): Methods Object foo "Put your code here" ] |
can you publish pseudo code of The procedure for computing the median in O( nlog(n) ) time? | |
No... think about this a little. Anyways - this is not crucial: you won't lose points for performing worse. |
[IMPORTANT] The subclasses method does not return classes that I've added; what should I do about this? | |
Yet another LST bug... Your statistics should be calculated on the built-in classes ONLY; you do not have to overcome this bug, of course. Same is true for Q1/part 2. (fixed in v1.02) |
In the fourth example for the MED metric: | |
Right, my mistake. (fixed in v1.02) |
Suppose we add methods to the class Class. Should we consider them in the metrics calculations? | |
No. Do the two parts in separate executions. |
Is it enough to use instanceSize to implement NIV or I missed something? | |
It is not enough - see a question below regarding what instanceSize actually returns. |
Can we assume that both values and weights are integers in a distribution? | |
Yes. |
Can you explain what do you mean by "easily extensible system"? | |
Your program should be as tolerent as possible to changes and extensions. To be more specific, this means that when you add a new feature (e.g. new statistic ot metric), as few existing objects, classes and methods as possible will be affected. Here is an example: Someone proposed to add the OOP metrics as methods to the class Class. If we ignore the question of whether this is conceptually right or not, the result of such solution will be that - the class Class is affected by this operation, and needs to be tested again. - all instances of class Class are affected - All objects who "speak" with Class will potentially be affected - the above will hold for any change we will do in the future - we will have to re-test the whole system for every little change. So, every change you make will affect the whole LST system! Obviously, the cost of this solution is too high. Try to think of a design in terms of - changes required in the code of existing classes and objects in the system for extensions - coupling, namely objects and classes that are not affected directly by such extensions, but may be affected because of changes in other classes with whom they communicate. |
How can we pass a method as a message to another method? How do we use it inside the method? | |
Assume you can't. This is complicated and beyond the scope of this course (unless you insist :-). So - just assume that methods have to be called in the conventional |
I couldnt quite understand the definition of Variance, could you give me some example? | |
Let's take this small example: [1, 2, 3, 6] -> [1, 1, 2, 1] (which is actually {1,2,3,3,6}) - The weighted mean = (1+2+3+3+6)/5 = 15/5 = 3 - The sum of square distances from the mean = (1-3)^2+(2-3)^2(3-3)^2(3-3)^2(6-3)^2=14 - Its wighted average (the variance) = 14/5 = 2.8 |
What's new in v1.03? | |
- The definition of DES has been clarified - DES is the number of decsendents in the subtree whose root is c, including c - The definition of DEP has been clarified - DEP is the number of edges between the root and its furthest descendent |
Regarding part 2/question 1 - can we add another method to Class except the required method? | |
Yes |
Can you please explain what instanceSize actually does? | |
instanceSize returns the number of fields per instance of the class, which includes the number of fields in the class itself and all its ancestors. |