I am having trouble figuring out the dividing for the Marie Sim. I do not want the -1, but it keeps showing the negative. I only want it up to 2. Any suggestions?
This is my code:
ORG 100
Input
Store x
Input
Store y
loop, load x
Subt y
Store x
Load x
Output
Skipcond 0
Jump loop
Load x
Halt
x, Dec 0
y, Dec 0
Output:
11
8
5
2
-1
I noticed some of the above responses created infinite loops if the program encountered a remainder when dividing. I resolved this and my program outputs 2 decimal values the result and the remainder respectively.
This is a very old post but hopefully, this will be of use to any newcomers to Assembly.
STORE x
INPUT
STORE y
loop, Load x
If, Subt y
Skipcond 000
Jump Else
Then, Jump Endif
Else, Store x
Load Counter
Add One
Store Counter
Jump loop
Endif, Load Counter
Output
Load x
Output
HALT
x, Dec 0
y, Dec 0
Counter, Dec 0
One, Dec 1
//The code below fixes your problem but creates an infinite loop whenever the division problem has a remainder.
ORG 100
INPUT
STORE x
INPUT
STORE y
loop, LOAD x
SUBT y
STORE x
SKIPCOND 000
OUTPUT
SKIPCOND 400
JUMP loop
HALT
x, Dec 0
y, Dec 0
Try this:
Input
Store x
Input
Store y
loop, load x
Subt y
Store x
Load x
Output
Skipcond 400
Jump loop
Load x
Halt
x, Dec 0
y, Dec 0
ORG 100
input
store var1
input
store var2
loop, load var1
Subt var2
Store var1
Store remain
load qout
Add one
Store qout
Load remain
Subt var2
Skipcond 000
Jump loop
load qout
output
load remain
output
halt
var1, dec 0
var2, dec 0
one, dec 1
remain, dec 0
qout, dec 0
Related
I have a task where I need to take a number, e.g. 13002, and print it digit by digit using UART (including non-leading 0's). The UART expects that whatever it prints will go in the $s0 register but I can call it whenever I need using a jal.
This means I need to place a digit in $s0 and jump (the UART code has a jr $ra in it so it will return properly once complete.
My problem is I don't know how to iterate over the digits in the number.
My approach so far is to mod the number by 10 (Because it's a decimal number represented in binary) but that gives me the digits in reverse order.
E.g. 13002 % 10 = 2 (then divide 13002 by 10, integer division will truncate the decimal), 1300 % 10 = 0, divide again by 10, 130 ...so on and so forth.
As mentioned above however, that gives me the digits in reverse order. How would I properly iterate over the number?
I wrote some pseudocode in python but it's having trouble with numbers that have 0's in them:
def iterateOverDigits(n):
while (n >= 10):
x = n
i = 0
while (x >= 10):
x = x // 10
i += 1
print(x)
x = n
x = x % (10 ** i)
n = x
iterateOverDigits(1302) # This prints 132
In [1]: def by_digit(n):
...: for char in str(n):
...: print(char)
...:
In [2]: by_digit(120405)
1
2
0
4
0
5
In [3]:
Change the print statement to the following to remove the newlines between each digit:
print(char, end="")
Bellow is a function from ffmpeg defined in libavcodec/h264.h:
static av_always_inline void write_back_intra_pred_mode(const H264Context *h,
H264SliceContext *sl)
{
int8_t *i4x4 = sl->intra4x4_pred_mode + h->mb2br_xy[sl->mb_xy];
int8_t *i4x4_cache = sl->intra4x4_pred_mode_cache;
AV_COPY32(i4x4, i4x4_cache + 4 + 8 * 4);
i4x4[4] = i4x4_cache[7 + 8 * 3];
i4x4[5] = i4x4_cache[7 + 8 * 2];
i4x4[6] = i4x4_cache[7 + 8 * 1];
}
What does this function do?
Can you explain the function body too?
The function updates a frame-wide cache of intra prediction modes (at 4x4 block resolution), located in the variable sl->intra4x4_pred_mode per slice or h->intra4x4_pred_mode for the whole frame. This cache is later used in h264_mvpred.h, specifically the function fill_decode_caches() around line 510-528, to set the contextual (left/above neighbour) block info for decoding of subsequent intra4x4 blocks located below or to the right of the current set of 4x4 blocks.
[edit]
OK, some more on the design of variables here. sl->mb_xy is sl->mb_x + sl->mb_y * mb_stride. Think of mb_stride as a padded version of the width (in mbs) of the image. So mb_xy is the raster-ordered index of the current macroblock. Some variables are indexed in block (4x4) instead of macroblock (16x16) resolution, so to convert between units, you use mb2br_xy. That should explain the layout of the frame-wide cache (intra4x4_pred_mode/i4x4).
Now, the local per-macroblock cache, it contains 4x4 entries for the current macroblock, plus the left/above edge entries, so 5x5. However, multiplying something by 5 takes 2 registers in a lea instruction, whereas 8 only takes one, so we prefer 8 (more generally, we prefer powers of 2). So the resolution becomes 8(width)x5(height) for a total of 40 entries, of which the left 3 in each row are unused, the fourth is the left edge, and the right 4 are the actual entries of the current macroblock. The top row is above, and the 4 rows below it are the actual entries of the current macroblock.
Because of that, the backcopy from cache to frame-wide cache uses 8 as stride, 4/3/2/1 as indices for y=3/2/1/0 and 4-7 as indices for x=0-3. In the backcopy, you'll notice we don't actually copy the whole 4x4 block, but just the last line (AVCOPY32 copies 4 entries, offset=4[y=3]+8[stride]*4[x=0]) and the right-most entry for each of the other lines (7[x=3]+8[stride]*1-3[y=0-2]). That's because only the right/bottom edges are interesting as top/left context for future macroblock decoding, so the rest is unnecessary.
So as illustration, the layout of i4x4_pred_mode_cache is:
x x x TL T0 T1 T2 T3
x x x L0 00 01 02 03
x x x L1 10 11 12 13
x x x L2 20 21 22 23
x x x L3 30 31 32 33
x means unused, TL is topleft, Ln is left[n], Tn is top[n] and the numbered entries ab are y=a,x=b for 4x4 blocks in a 16x16 macroblock.
You may be wondering why TL is placed in [3] instead of [0], i.e. why isn't it TL T0-3 x x x (and so on for the remaining lines); the reason for that is that in the frame-wide and block-local cache, T0-3 (and 00-03, 10-13, 20-23, 30-33) are 4-byte aligned sets of 4 modes, which means that copying 4 entries in a single instruction (COPY32) is significantly faster on most machines. If we did an unaligned copy, this would add additional overhead and slow down decoding (slightly).
I am learning Stata and want to know how to generate random integers (without replacement). If I had 10 total rows, I would want each row to have a unique integer from 1 to 10 assigned to it. In R, one could simply do:
sample(1:10, 10)
But it seems more difficult to do in Stata. From this Stata page, I saw:
generate ui = floor((b-a+1)*runiform() + a)
If I substitute a=1 and b=10, I get something close to what I want, but it samples with replacement.
After getting that part figured out, how would I handle the following wrinkle: my data come in pairs. For example, in the 10 observations, there are 5 groups of 2. Each group of 2 has a unique identifier. How would I arrange the groups (and not the observations) in random order? The data would look something like this:
obs group mem value
1 A x 9345
2 A y 129
3 B x 251
4 B y 373
5 C x 788
6 C y 631
7 D x 239
8 D y 481
9 E x 224
10 E y 585
obs is the observation number. group is the group the observation (row) belongs to. mem is the member identifier in the group. Each group has one x and one y in it.
First question:
You could just shuffle observation identifiers.
set obs 10
gen y = _n
gen rnd = runiform()
sort rnd
Or in Mata
jumble(1::10)
Second question: Several ways. Here's one.
gen rnd = runiform()
bysort group (rnd): replace rnd = rnd[1]
sort rnd
General comment: For reproducibility, set the random number seed beforehand.
set seed 2803
or whatever.
What I am trying to do is combine two postscript files into a pdf. I have already tried using ghostscript to combine them however the issue with that is ghostscript produces a pdf with one ps file on one page and the other on page two which is not what i wish to accomplish
%!PS-Adobe-3.0
%%Pages: 1
%%DocumentData: Clean7Bit
%%LanguageLevel: 2
%%EndComments
%%Page: 1 1
save
6 dict begin currentpagedevice/PageSize get dup 0 get
0 sub 0 sub/w exch
def 1 get 0 sub 0 sub/h exch
def/x 87 def/y 87 def 0 0/b y h mul x
w mul gt def b{w y}{h x}ifelse div/c x h mul y w mul gt def c{w x}{h y}ifelse
div gt{h add translate -90 rotate b{w y h x w mul y div sub 2 div 0}{h
x 0 w y h mul x div sub 2 div}}{translate c{w x 0 h y w mul x div sub 2 div}{h
y w x h mul y div sub 2 div 0}}ifelse ifelse translate div dup scale
end 9 dict begin
{/T currentfile/ASCII85Decode filter def/DeviceGray setcolorspace
/F T/LZWDecode filter def
<</ImageType 1/Width 87/Height 87/BitsPerComponent
1/ImageMatrix[1 0 0 -1 0 87]/Decode
[0 1]/DataSource F>> image
F closefile T closefile}
%%BeginData:;
exec
J3Vsg3$\8+#CjR`&3*WA'+TR\#<!\`;#aOp`$+XV`%h8\!!!K[!9Aet#*;BOP%d==7jS.,hsVBYnDH
N[+5cZ=UtTfLSkWhgRG8\?,WGcN^j5#cP]3KsWRSLmE;_bp<GM2!Q!1FiRE6!+E91]DA$X`8iQFZYB
0mS8-o5Xu!f_0094V'pA:#g3R,3i_$'Yp\)8e-_&1fqhs%"+h!UL4I6R#tNA[6Bt^^UAX[:aRMSIU!
416=^MmJq2-+0!fVFnDer\kkA9UY#Q*n/l#Ih/>7,IEq;.)e7/q%Q&SL"j'""q7'ad9:Z00;\?qF/.
8a*mIt,hY3"qji0!BA*e-tRs6.F-k:_SnL*&QCrBB*lce!!;K8Fj4Hp6d?"Tg3Y4:8BLi#B-/VXSPS
#XP\B&qLYW4;Koo&C`>f_omCk&%aL+C?WTr*(:Q0YB"7Y0#*i?(aUW\?B(Z"l6;3X;8O\%8-n:/*6;
f^!W~>
%%EndData
end restore showpage
%%Trailer
%%EOF
Here is the second file
The file is to big here is a link to it http://pastebin.com/R0Kgarem
Not sure how I would go about solving this problem. I need the 2 ps files under each other without any white space.
Assuming you mean one toward the top of the page and the other toward the bottom of the page (a 2-up), you just need to prevent the first file from executing showpage (by redefining, or editing to remove the word showpage), and then translate (0 -y translate, where y is the height of the first image) before executing the second file. This assumes the first image is already positioned at the top of the page, otherwise you need to translate it to the correct position first.
I'm developing tic-tac-toe game, and I need algorithm to check when game ends(and who win).
In 3x3 game I would check each possible win-situation(there is 8 capabilities). But in 7x7(needed 4 signs in a row or collumn, or diagonal)is a lot of possible win patterns.
If you are using a bitboard for each player, you can use bit shift operations to test a board for a win.
The bitboard would have following structure:
6 14 22 30 38 46 54
5 13 21 29 37 45 53
4 12 20 28 36 44 52
3 11 19 27 35 43 51
2 10 18 26 34 42 50
1 9 17 25 33 41 49
0 8 16 24 32 40 48
If the player occupies a position in the game board, then the associated bit would be 1 otherwise 0 (notice that bits 7, 15, 23, ... are 0). To check if the player has a winning board you could use following function:
bool haswon(int64_t board)
{
int64_t y = board & (board >> 7);
if (y & (y >> 2 * 7)) // check \ diagonal
return true;
y = board & (board >> 8);
if (y & (y >> 2 * 8)) // check horizontal -
return true;
y = board & (board >> 9);
if (y & (y >> 2 * 9)) // check / diagonal
return true;
y = board & (board >> 1);
if (y & (y >> 2)) // check vertical |
return true;
return false;
}
With the help of a example I will try to explain: The following bitboard of one player includes beside vertical and diagonal wins a winning combination in the first row.
0101010
1110111
0111011
1101110
0001000
1010101
0011110 ... four occupied positions --> winning board
The steps for the horizontal check are:
y = board & (board >> 8)0101010 0010101 0000000
1110111 0111011 0110011
0111011 0011101 0011001
1101110 & 0110111 = 0100110
0001000 0000100 0000000
1010101 0101010 0000000
0011110 0001111 0001110
y & (y >> 2 * 8)0000000 0000000 0000000
0110011 0001100 0000000
0011001 0000110 0000000
0100110 & 0001001 = 0000000
0000000 0000000 0000000
0000000 0000000 0000000
0001110 0000011 0000010
The horizontal check results in a board with one bit set, this means the board includes a win and the function returns true.
I have used a similar function to check a connect four game for a win. I saw this fascinating function in the sources to The Fhourstones Benchmark from John Tromp.
While a very basic approach is to look at runs in all the directions from every single cell, here are an approach then only ever checks a cell in a single "line" once. A "line" is a row, column, or diagonal that can possibly win, like in a Vegas slot machine :)
For each "line", move to start of that "line" and;
Set counter to 0.
For each cell in the "line" (traversing the line in order):
If the cell is P1 and counter is >= 0, add one to counter
If counter = 4 then P1 wins.
If the cell is P1 and counter is negative, set counter to 0
If the cell is P2 and counter is <= 0, subtract one from counter
If counter = -4 then P2 wins
If the cell is P2 and counter is positive, set counter to 0
Important Edit: If the cell contains neither P1 or P2, reset counter to 0 (doh!). I omitted this trivial but required step. Otherwise "11-11" would be counted as a win.
The "lines" can be traversed given a starting point and row/column offset per iteration (e.g. start at (0,0) and advance (1,1) for longest diagonal from NW to SE). Diagonals with lengths less than 4 can avoid being checked entirely, of course.
Happy coding.
loop though all positions. For each position check the four fields down diagonal-down-right and right (always including the field itself). Put in apropriate checks to avoid blowing up you app when you are checking fields that don't exist.
Simple. Make 4 for loops, for all rows, columns, increasing diagonals, decreasing diagonals.
In each, test if there are 4 consecutive pieces.