I am working on a planning software being coded in Eiffel language, I've created the following code but I am not quite sure of which kind of post conditions and/or pre conditions should be specified for this class' routines.
If you can provide syntax hints for this it would be great because I am not a master in Eiffel language, and its keywords are still a bit tricky & hard to understand for me at my current level of knowledge.
class TIME
feature -- Initialization
make (one_hour, one_min, one_sec: NATURAL_8)
-- Setup ‘hour’, ‘minute’, and ‘seconds’ with
-- ‘one_hour’, ‘one_min’, and ‘one_sec’, as corresponds.
require
do
hour := one_hour
minute := one_min
second := one_sec
ensure
end
feature -- Setters
set_hour (one_hour: NATURAL_8)
-- Updates `hour' w/ value ‘one_hour’.
require
do
hour := one_hour
ensure
end
set_min (one_min: NATURAL_8)
-- Updates `minute' w/ value ‘one_min’.
require
do
minute := one_min
ensure
end
set_sec (one_sec: NATURAL_8)
-- Updates `second' w/ value ‘one_sec’.
require
do
second := one_seg
ensure
end
feature -- Operation
tick
-- Counts a tick for second cycle, following 24 hr format
-- During the day, “tick” works as follows
-- For example, the next second after 07:28:59 would be
-- 07:29:00. While the next second of 23:59:59
-- is 00:00:00.
do
ensure
end
feature -- Implementation
hour: NATURAL_8
minute: NATURAL_8
second: NATURAL_8
invariant
range_hour: hour < 24
range_minute: minute < 60
range_second: second < 60
end
Here is what I would use:
For the constructor:
make (one_hour, one_min, one_sec: NATURAL_8)
-- Setup `hour', `minute', and `seconds' with
-- `one_hour', `one_min', and `one_sec', as corresponds.
require
Hour_Valid: one_hour < 24
Minute_Valid: one_min < 60
Second_Valid: one_sec < 60
do
hour := one_hour
minute := one_min
second := one_sec
ensure
Hour_Assing: hour = one_hour
Minute_Assing: minute = one_min
Second_Assing: second = one_sec
end
In other words, the preconditions indicates what is requirement for the arguments to be valid in the context of the class. You may be tempted to ask why put those preconditions if those are already in the invariants. The answer is: both are not there for the same reason. See an invariant as the state that a class must (always) be to be valid. The only one that have to be sure that this invariant is valid is the class itself or it's descendant (but not the client of a class). In other word, it is the role of the feature make to be sure that the invariant is valid, not of the callers of the feature make. That take us to the reason of the precondition I put to make. Because yes, it is the role of make to be sure that the invariants are respected, but if make want to respect the invariants, it have to restrict the client about what value it can receive as arguments. So, in others words, the precondition 'Hour_Valid: one_hour < 24' assure that the feature `make' can be sure that it can respect the invariant 'range_hour: hour < 24'.
Now, for the postcondition. You can find strange to put a postcondition like 'Hour_Assing: hour = one_hour' when the first line of the routine is 'hour := one_hour'. The point is, if I inherit of the class TIME and I change the implementation (for exemple, I use a timestamps like the number of second since the the beginning of the day), the respect of the postcondition will not be as trivial, but the postcondition will still applies to the new make routine. You have to see those (precondition and postcondition) as documentations. It is like saying to the callers of the feature make that if the argument one_hour is valid, I can guaranty you that hour will be equal to one_hour and that, whatever the implementation might be.
Now, I would put equivalent precondition and postcondition to every setters. For example:
set_hour (one_hour: NATURAL_8)
-- Updates `hour' with the value ‘one_hour’.
require
Hour_Valid: one_hour < 24
do
hour := one_hour
ensure
Hour_Assign: hour = one_hour
end
For the invariants, I think that you put good ones in your code already. So no more explanations are require here I think. To finish, it is very important to see every contracts (preconditions, postconditions and invariants) as documentation. Those must be optional and if the compiler remove them, the resulting program must be equivalent to the one with the contracts. See it like code documentation that can help you debug.
I am not an expert in Eiffel, my experience mostly comes from C# CodeContracts, but here it goes.
I will provide just an example syntax for your set_hour feature. Hopefully, you can generalize this to your whole example:
set_hour (one_hour: NATURAL_8)
-- Updates `hour' w/ value ‘one_hour’.
require
-- generally you can put here any boolean expression featuring arguments/class variables
hour_in_range: one_hour < 24 -- the part before : is optional, it's called
-- a name tag, helps with debugging.
do
hour := one_hour
ensure
hour_is_set: hour = one_hour -- it may seem excessive, but for verification tool such as automated proovers this information is valuable.
hour < 24 -- this one duplicates your invariant, you may or may not want to add contracts like this, depending on your needs/style/etc.
Related
I'm building a moving and sensing bot in CoppelliaSim for school. CopelliaSim uses Lua for scripting. Basically every time the bot's forward sensors hit something, one of three if statements will run. I want it to count how many times any of these if statements runs, and once that count gets to a certain amount (like 20), I'll run something else, which will do the same thing (find collisions, add to the count, reach an amount, and switch back to the first).
i=0
result=sim.readProximitySensor(noseSensor) -- Read the proximity sensor
-- If we detected something, we set the backward mode:
if (result>0) then backUntilTime=sim.getSimulationTime()+3
print("Collision Detected")
i=i+1
print(i)
end
result=sim.readProximitySensor(noseSensor0) -- Read the proximity sensor
-- If we detected something, we set the backward mode:
if (result>0) then backUntilTime=sim.getSimulationTime()+3
print("Collision Detected")
i=i+1
print(i)
end
result=sim.readProximitySensor(noseSensor1) -- Read the proximity sensor
-- If we detected something, we set the backward mode:
if (result>0) then backUntilTime=sim.getSimulationTime()+3
print("Collision Detected")
i=i+1
print(i)
end
Above is the start of a function and one of the three If statements. I'm printing just to see if it actually increments. It is printing, but it is not incrementing (just 1 over and over). This bot has 3 sensors on it (an if statement for each sensor) and it adds 1 to i for the first collision and ignores the rest, even if it's from the same sensor. I feel like my problem is just some simple syntax issue with Lua that I don't know and can't find how to properly fix.
I'm happy to provide more code if this little snippet was not sufficient to answer this question.
Assuming that you have a looping function such as sysCall_actuation which is being executed per simulation step. As Joseph Sible-Reinstate Monica has already stated, you are setting your variable i back to zero every time a simulation step is executed. To achieve your goal, you would have to set your variable to 0 outside your function. There are two appropriate approaches to achieve that:
Define the variable outside any function, in the beginning of your file (or before you define any function that uses your variable e.g right before the definition of sysCall_actuation).
-- Beginning of the file.
local i = 0
..
function sysCall_actuation()
..
i = i + 1
..
end
Define your variable in sysCall_init function, which is the appropriate approach in CoppeliaSim.
function sysCall_init()
i = 0
..
end
Finally, you can use your variable in your sysCall_actuation function with basic comparison operations:
function sysCall_actuation()
..
if i > 20 then
i = 0 -- Reset 'i' so this function will not be running every step again and again.
-- Do something here.
..
end
As a side note, practice using local variables whenever you can, to keep the memory clean and avoid having ambiguous variables.
I've been told in Java that I should avoid modifying the original parameters such as
public int doStuff(int begin, int end) {
/* loop or something */
begin++; //bad
end--; //also bad
/* end loop */
return
}
instead, I should do something like
public int doStuff(int begin, int end) {
int myBegin = begin; //something like this
int myEnd = end;
/* stuff */
return
}
So, I've been doing this in lua
function do_stuff(begin, last)
local my_begin = begin
local my_last = last
--stuff
my_begin = my_begin + 1
my_last = my_last - 1
--stuff
end
But, I'm wondering if
function do_stuff(begin, last)
--stuff
begin = begin + 1
last = last - 1
--stuff
end
is also discouraged, or is it nice and concise?
There are no rules. Let taste, clarity, and need decide.
Nevetheless, a common idiom is to provide default values for parameters as in
function log(x,b)
b = b or 10
...
end
If you were told not to modify the parameters of functions, then there was probably a reasoning associated with that. Whatever that reasoning is would apply as much to Lua as to Java, since they have similar function argument semantics. Those reasons could be one or more of (but not limited to):
If you modify a parameter... you don't have it anymore. If you suddenly have a need for the original value you were passed, it's gone now.
Creating confusion, depending on how the parameters are named. The word "begin" suggests the beginning of something. If you change it, it isn't necessarily the beginning anymore, but merely the current element you're operating on.
Creating potential errors, if dealing with reference types (non-basic types in Java, tables and such in Lua). When you modify an object, you're changing it for everyone. Whereas incrementing an integer is just changing your local value. So if you're frequently modifying parameters, you still need to think about which ones you ought to be poking at and which ones you shouldn't be.
To put it another way, if you agreed with the suggestion for doing so in Java, then it applies just as much to Lua. If you didn't agree with the suggestion in Java, then you have no more reason to follow it under Lua.
In Lua functions, threads, tables and userdata types are passed by reference. So unless you have one of those you are working with a local copy anyway.
So in your example:
function do_stuff(begin, last)
--stuff
begin = begin + 1
last = last - 1
--stuff
end
begin and last are local non-reference variables in do_stuff's scope.
The only reason to make a copy of them is that you might want to store there initial value for later use. For that purpose you can either create a backup copy of the initial value or you create a working copy of it. Whatever you prefer.
Only make sure you know what is passed by reference and what by value so you avoid changing things you don't want to change and the other way around.
This question already has answers here:
Lua for loop reduce i? Weird behavior [duplicate]
(3 answers)
Closed 7 years ago.
im trying this in lua:
for i = 1, 10,1 do
print(i)
i = i+2
end
I would expect the following output:
1,4,7,10
However, it seems like i is getting not affected, so it gives me:
1,2,3,4,5,6,7,8,9,10
Can someone tell my a bit about the background concept and what is the right way to modify the counter variable?
As Colonel Thirty Two said, there is no way to modify a loop variable in Lua. Or rather more to the point, the loop counter in Lua is hidden from you. The variable i in your case is merely a copy of the counter's current value. So changing it does nothing; it will be overwritten by the actual hidden counter every time the loop cycles.
When you write a for loop in Lua, it always means exactly what it says. This is good, since it makes it abundantly clear when you're doing looping over a fixed sequence (whether a count or a set of data) and when you're doing something more complicated.
for is for fixed loops; if you want dynamic looping, you must use a while loop. That way, the reader of the code is aware that looping is not fixed; that it's under your control.
When using a Numeric for loop, you can change the increment by the third value, in your example you set it to 1.
To see what I mean:
for i = 1,10,3 do
print(i)
end
However this isn't always a practical solution, because often times you'll only want to modify the loop variable under specific conditions. When you wish to do this, you can use a while loop (or if you want your code to run at least once, a repeat loop):
local i = 1
while i < 10 do
print(i)
i = i + 1
end
Using a while loop you have full control over the condition, and any variables (be they global or upvalues).
All answers / comments so far only suggested while loops; here's two more ways of working around this problem:
If you always have the same step size, which just isn't 1, you can explicitly give the step size as in for i =start,end,stepdo … end, e.g. for i = 1, 10, 3 do … or for i = 10, 1, -1 do …. If you need varying step sizes, that won't work.
A "problem" with while-loops is that you always have to manually increment your counter and forgetting this in a sub-branch easily leads to infinite loops. I've seen the following pattern a few times:
local diff = 0
for i = 1, n do
i = i+diff
if i > n then break end
-- code here
-- and to change i for the next round, do something like
if some_condition then
diff = diff + 1 -- skip 1 forward
end
end
This way, you cannot forget incrementing i, and you still have the adjusted i available in your code. The deltas are also kept in a separate variable, so scanning this for bugs is relatively easy. (i autoincrements so must work, any assignment to i below the loop body's first line is an error, check whether you are/n't assigning diff, check branches, …)
This is a question from my midterm today and I wonder how to solve this. All i know is to prove the greedy algorithm using induction.
Question:
You are working on a programming project. There are n Java classes C1, C2, ..., Cn (the bossy architect says so). The architect also says that these classes have to be implemented in order (you are not allowed to implement C2 before you have completed C1 and so on).
Each of the Java classes takes at most 8 hours to implement. You work exactly 8 hours a day, and you should not leave a Java class unfinished at the end of the day.
To complete the project as soon as possible, a strategy is to implement as many classes as you can everyday. Prove that this greedy strategy is indeed the optimal one.
(Hint: let ti be the total number of classes completed in the first i days using the above strategy. The strategy always stays ahead if ti is no less than the total number of classes completed in the first i days using any other strategy)
This problem is similar to the classic task scheduling case where the waiting time in the system must be minimized.
Let C1, C2, ..., Cn your projected classes and c[1], c[2], ..., c[n] their required implementation time. Let's suppose you implement C1, C2, ... Cn in this order. Therefore, the total time (waiting + implementation) for each class Ck will be:
c[1] + c[2] + ... + c[k]
Therefore, we have the total time:
T = n·c[1] + (n – 1)·c[2] + ... + 2*c*[n – 1] + c[n] = sum(k = 1 to n) of (n – k + 1)·c[k]
(Sorry about the presentation — superscripts, subscripts, and math equations aren't supported...)
Let's suppose the implementation times in our permutation are not sorted by ascending order. We can therefore find two integers a and b such that a < b with c[a] > c[b]. If we switch them in the computation of T, we have:
T' = (n – a + 1)·c[b] + (n – b + 1)·c[a] + sum(k = 1 to n except a, b) of (n – k + 1)·c[k]
We finally compute T – T':
T – T' = (n – a + 1)(c[a] – c[b]) + (n – b + 1)(c[b] – c[a]) = (b – a)(c[a] – c[b])
Following our initial hypothesis (a < b and c[a] > c[b]), we have b – a > 0 and c[a] – c[b] > 0 as well, hence T – T' > 0.
This proves that we decrease the total waiting time by switching any pair of tasks so that the shorter one is done first.
Your problem statement is the same, except that before starting implementing a new class, you have to check whether you should start it now (if there is enough time left on the present day) or tomorrow. But the principle proven here holds when it comes to minimizing the total "waiting" time.
This is not a programming question for SO. The problem is not asking for a coding solution, rather its a proof that greedy is optimal. Which can be done with a proof by contradiction (no doubt taught in the class before the midterm).
What you want to do is to calculate the total time taken by greedy (there's only one solution) and disprove that any swaps in day would lead to a better solution. You probably also have to add something that mentions how swapping will allow u to permute the order to the optimal solution, if it exists.
I was going to write some formulae, but i realize Jeff Morin already has the equations, just going in the opposite direction. I think starting from the greedy solution might be easier to explain, since 'in order' is pretty much defined by the problem and you can only shift the work +- which day its done on.
The problem statement is incomplete. There is no indication that any class will take less than 8 hours. Since you can't leave any class unfinished, then you must start each class at the start of the day to be sure to have at least 8 hours to work on it. So if C2 really takes 3 hours and C3 really takes 5 hours, then a greedy algorithm would allow both classes to be done the same day. But after C2 takes 3 hours, you have to wait to day 3 to start C3 to be sure that you have enough time to finish since you don't know how long C3 will take.
So the restrictions really end up dictating that the effort will take n days, 1 day per class. So the implementation algorithm is strictly sequential, not greedy.
Edit Restrictions stated in problem.
(1) There are n Java classes C1, C2, ..., Cn
(2) these classes have to be implemented in order (you are not allowed to implement C2 before you have completed C1 and so on).
(3) Each of the Java classes takes at most 8 hours to implement
But there is no estimate for any class taking less than 8 hours.
(4) You work exactly 8 hours a day
(5) You should not leave a Java class unfinished at the end of the day.
The gist of this (3,4,& 5) is let's assume that I work on class 1 for 5 minutes. I now have 7 hours 55 minutes left. Can I start on Class 2? No because it might take up to 8 hours and I must finish before the end of my 8-hour day. So I must wait to day 2 to start class 2 and so on. Thus the implementation is strictly sequential and will take n days to complete, 1 day per class.
In order to use the Greedy algorithm you'd need additional information.
(6) You also know that each class has a known number of hours needed to code the class - h1, h2, h3, ..., hn. So class 1 takes h1 hours, class 2 takes h2 hours and so on. (From item 3 no class takes more than 8 hours)
I would like to make sure I have properly adjusted for multiple testing, which I am doing through permutation. I do not want to over-adjust, so I only want to include comparisons that were specified a priori. Here is a dataset that is similar in construction to the one I am analyzing:
data test;
call streaminit(1234);
do a=1 to 5;
do b=1 to 2;
do i = 1 to 8;
censored = rand('BERNOULLI',0.5);
if censored = 0 then ttd = rand('NORMAL',10);
else ttd = 30;
id = 16*(A-1)+8*(B-1)+i;
output;
end;
end;
end;
drop i;
run;
If I were interested in comparing each level of a and b to every other level, I would run the following:
proc lifetest data=test;
time ttd * censored(1);
strata a b / diff=all adjust=simulate(nsamp=1000000 seed=1234);
run;
Instead, I would like to compare each level of a to every other level of a within b (10 comparisons at 2 levels makes 20 comparisons). On top of that, I would like to compare the two levels of b within each level of a (5 comparisons). So in all that is 25 comparisons I have to adjust for, but adjusting for all pairwise comparisons as I have done in the above code accounts for 45 comparisons. Is there a way in proc lifetest to just specify the 25 pairwise comparisons I am interested in? If not, is there some way around this so I can adjust post hoc just for the 25 comparisons I am interested in?
While this is a very statistics-related question, the primary question is about problems specific to programming in SAS and not about which methods to use or the appropriateness of the chosen method, so I am posting it here and not on Cross Validated, though I admit that a post hoc adjustment outside of proc lifetest may be the way to go and so would be willing to let Cross Validated have a shot at it as well.