I'm writing a guessing game in QBasic , which kind of tells you that im not to this, and every time I run the code the rndnum is always 0. what should i change?
To get a different random number you must first seed it. Here's the example from the QB 4.5 Help file:
RANDOMIZE TIMER ' This is the best seed. The time is constantly changing
A = INT(RND*100)+1 ' Generate a random number
Print A
If you are saying that the very first returned number is zero every time the program is run then all you need is to add the randomize statement as a one-time called procedure. If you are instead saying that as you are iterating through the same code in a loop it is returning zero every time then there is something else wrong - most likely that for whatever reason QBasic does not recognize RND as a function and therefore assumes it's a variable, which would by default be set to zero. The correct syntax would be something like:
Lowerbound = 1
Upperbound = 100
RANDOMIZE
FOR X = 1 TO 10
PRINT INT((Upperbound - Lowerbound + 1) * RND + Lowerbound)
NEXT X
Related
I am writing some code for data processing. The requirement is to sort the data, which comes in lists called u_B (5000 values of speed data) and P_B (5000 pieces of the related power data) into "bins" by speed, so that it is possible to calculate the mean speed and power within each bin. The code below is just trying to get the "bin" for the range of speeds 24-25m/s. What I expect to happen is that the code cycles through the u_B list, checks if each speed is within the required range, and if it is, puts it in the "bin", along with the corresponding power value. I have altered it to output the speeds it considers to be in the right range, and they seem to be all as I expect them to be, but when the bin is outputted right at the end it contains not only the data within the right range, but also a whole load of other data that does not fit within the speed range. I cannot work out why this other data is being added to the bin. If anyone can spot what I am missing I would be grateful.
i = 25;
inc = 1;
for n = 1:5000
if (u_B(n) >= (i-1)) && (u_B(n) < (i + 1))
disp(u_B(n))
bin(inc,1) = u_B(n);
disp(bin(inc,1))
bin(inc,2) = P_B(n);
inc = inc + 1
end
end
disp(bin)
This shows the first set of outputs from within the if-statement, the 24.7s are the speed u_B(n) and the value that has been put into the bin, they are the same as expected, the 0 for power and 2 for inc are both fine. the list from this goes on and only contains speed values in the right range.
screenshot of code and output
This shows the output of what is in the bin, the first 10 values are the ones I want to be in there, and all the rest have lower speeds, and therefore shouldn't be in the bin.
screenshot of code and output
I'm using a numerical integration method to approximate an integral. I need to use a minimum number of iterations that give an answer correct to 5 decimal places.
I cannot seem to find a generalised way of doing this. I've only been able to get it working for some cases.
Here is what I'e tried:
%num2str(x,7) to truncate the value of x
xStr = num2str(x(n),7);
x5dp(n) = str2double(xStr); %convert back to a truncated number
%find the difference between the values
if n>1 %cannot index n-1 = 0
check = x5dp(n)-x5dp(n-1);
end
This will find the first instance at which the first 5dp are the same, it doesn't take into account that changes might occur beyond that point, which has happened, the iteration I am looking for was about 450, but it stopped at 178 due to this.
Then I tried this
while err>errLim & n<1000
...
r = fix(x(j)*1e6)/1e1 %to move the 6th dp to the 1stplace
x6dp = rem(r,1)*10 %to 'isolate' the value of the 6th dp
err = abs(x(j)-x(j-1)) % calculate the difference between the two
%if the 6th decimal place is greater than 5 and err<1e-6
% then the 6th decimal place won't change the value of the 5th any more
if err<errLim && x6dp<5
err=1;
end
...
end
This works for one method and function I tested it one. However when I pasted it into another method for another function, I get the iteration ending before the final result is achieved. the final 4 results are:
4.39045203734423 4.39045305948901 4.39045406364900 4.39045505024365
However, the answer I need is actually 4.39053, this has stopped the iteration about 300 steps too early.
I'd like to use k to calculate the times of the for loop executed. It would be billions of times and I tried long64, then after some time k became negative. Is there any other way to do this?
Sorry I think I made a wrong description. My code is a 3-layer for nest block and each of them is calculating 2*256^3 numbers, once the value is equal to 0, I'd like to make k+=k. In the end I set print, 'k=', k and when idl was running, I found k ran from positive to negative. I used a cluster to do the computation so it didn't take quite a long time.
My guess is that you are not really using a long64 for k. The type for the loop variable in a for loop comes from the start value. For example, in this case:
k = 0LL
for k = 0, n - 1 do ...
k is a int (16-bit) because 0 is a int. You probably want something like:
for k = 0LL, n - 1LL do begin ...
I am recording voltage changes over a small circuit- this records mouse feeding. When the mouse is eating, the circuit voltage changes, I convert that into ones and zeroes, all is well.
BUT- I want to calculate the number and duration of 'bursts' of feeding- that is, instances of circuit closing that occur within 250 ms (75 samples) of one another. If the gap between closings is larger than 250ms I want to count it as a new 'burst'
I guess I am looking for help in asking matlab to compare the sample number of each 1 in the digital file with the sample number of the next 1 down- if the difference is more than 75, call the first 1 the end of one bout and the second one the start of another bout, classifying the difference as a gap, but if it is NOT, keep the sample number of the first 1 and compare it against the next and next and next until there is a 75-sample difference
I can compare each 1 to the next 1 down:
n=1; m=2;
for i = 1:length(bouts4)-1
if bouts4(i+1) - bouts4(i) >= 75 %250 msec gap at a sample rate of 300
boutend4(n) = bouts4(i);
boutstart4(m)= bouts4(i+1);
m = m+1;
n = n+1;
end
I don't really want to iterate through i for both variables though...
any ideas??
-DB
You can try the following code
time_diff = diff(bouts4);
new_feeding = time_diff > 75;
boutend4 = bouts4(new_feeding);
boutstart4 = [0; bouts4(find(new_feeding) + 1)];
That's actually not too bad. We can actually make this completely vectorized. First, let's start with two signals:
A version of your voltages untouched
A version of your voltages that is shifted in time by 1 step (i.e. it starts at time index = 2).
Now the basic algorithm is really:
Go through each element and see if the difference is above a threshold (in your case 75).
Enumerate the locations of each one in separate arrays
Now onto the code!
%// Make those signals
bout4a = bouts4(1:end-1);
bout4b = bouts4(2:end);
%// Ensure column vectors - you'll see why soon
bout4a = bout4a(:);
bout4b = bout4b(:);
% // Step #1
loc = find(bouts4b - bouts4a >= 75);
% // Step #2
boutend4 = [bouts4(loc); 0];
boutstart4 = [0; bouts4(loc + 1)];
Aside:
Thanks to tail.b.lo, you can also use diff. It basically performs that difference operation with the copying of those vectors like I did before. diff basically works the same way. However, I decided not to use it so you can see how exactly your code that you wrote translates over in a vectorized way. Only way to learn, right?
Back to it!
Let's step through this slowly. The first two lines of code make those signals I was talking about. An original one (up to length(bouts) - 1) and another one that is the same length but shifted over by one time index. Next, we use find to find those time slots where the time index was >= 75. After, we use these locations to access the bouts array. The ending array accesses the original array while the starting array accesses the same locations but moved over by one time index.
The reason why we need to make these two signals column vector is the way I am appending information to the starting vector. I am not sure whether your data comes in rows or columns, so to make this completely independent of orientation, I'm going to make sure that your data is in columns. This is because if I try to append a 0, if I do it to a row vector I have to use a space to denote that I'm going to the next column. If I do it for a column vector, I have to use a semi-colon to go to the next row. To completely avoid checking to see whether it's a row or column vector, I'm going to make sure that it's a column vector no matter what.
By looking at your code m=2. This means that when you start writing into this array, the first location is 0. As such, I've artificially placed a 0 at the beginning of this array and followed that up with the rest of the values.
Hope this helps!
I was wondering about slightly different JavaScript which ranges comprehensions in CoffeeScript compiles into. Is there any reason why following differencies in generated JavaScript?
Iterating a range by integer step
numbers = (i for i in [start..end] by 2)
compiles into:
for (i = start; i <= end; i += 2) {
_results.push(i);
}
But when iterating by fractional step
numbers = (i for i in [start..end] by 1/2)
generates bit more complicated JavaScript:
for (i = start, _ref = 1 / 2; start <= end ? i <= end : i >= end; i += _ref) {
_results.push(i);
}
So why this additional start <= end condition?
You'll get similarly elaborate code if you just do numbers = (i for i in [start..end]). This is because CoffeeScript doesn't know which direction the range goes when the beginning or ending is a variable. The compiler has a special optimization where it will output simpler code if a constant step is provided, but unfortunately 1/2 is counted as an expression rather than a constant.
Coffeescript doesn't know completely what the expression 1/2 evaluates to. It could be Math.random() - .5 and it would depend on the particular running of the script.
Therefore, it's impossible for Coffeescript to know if the step is negative or positive, so it just keys the condition based on the relative positioning of start and end rather than on the sign of the constant step.
This is constant vs. expression, rather than integer vs. fraction. When the step is a constant (such as 2), CoffeeScript knows whether step is positive at compile time and outputs the correct code for that. When the step is an expression (such as 1/2), it needs to determine whether it is positive at runtime.
Unfortunately, CoffeeScript appears to recognize fractional number as expressions regardless of how they are written (0.5 or 1/2), so there's no simple way to avoid this problem.