Assume I want to reserve 8 bytes on the stack and I also want to make sure current stack pointer is 8 byte aligned. I have seen some codes that assure current sp is 8 bye aligned using this logic:
sp = sp & -8;
They AND it with the amount they are going to reserve on the stack (which of course is negative).
How does this logic work?
It works because negative numbers are represented in two's complement, so -8 is equivalent to ~7, of which the 3 least significant bits are 0s and the rest are 1s. ANDing this with a value clears the 3 least significant bits, which obviously results in it being 8-byte aligned. By the way, this trick only works to align things to powers of 2. If you had some strange reason to align things to a 12-byte boundary, for example, sp = sp & -12 would not work as intended.
Related
Quoting from the HDF5 Hyperslab doc -:
The block array determines the size of the element block selected from
the dataspace.
The example shows in a 2x2 dataset having the parameters set to the following-:
start offset is specified as [1,1], stride is [4,4], count is [3,7], and block is [2,2]
will result in 21 2x2 blocks. Where the selections will be (1,1), (5,1), (9,1), (1,5), (5,5) I can understand that because the starting point is (1,1) the selection starts at that point, also since the stride is (4,4) it moves 4 in each dimension, and the count is (3,7) it increments 3 times 4 in direction X and 7 times 4 in direction Y ie. in its corresponding dimension.
But what I don't understand is what is block size doing ? Does it mean that I will get 21 2x2 dimensional blocks ? That means each block contains 4 elements, but the count is already set in 3 in 1 dimension so how will that be possible ?
A hyperslab selection created through H5Sselect_hypserslab() lets you create a region defined by a repeating block of elements.
This is described in section 7.4.2.2 of the HDF5 users guide found here (scroll down a bit to 7.4.2.2). The H5Sselect_hyperslab() reference manual entry might also be helpful.
Here is a diagram from the UG:
And here are the values used in that figure:
offset = (0,1)
stride = (4,3)
count = (2,4)
block = (3,2)
Notice how the repeating unit is a 3x2 element block. So yes, you will get 21 2x2 blocks in your case. There will be a grid of three blocks in one dimension and seven in the other, each spaced 4 elements apart in each direction. The first block will be offset by 1,1.
The most confusing thing about this API call is that three of the parameters have elements as their units, while count has blocks as its unit.
Edit: Perhaps this will make how block and count are used more obvious...
HDFS default block size is 64 mb which can be increased according to our requirements.1 mapper processes 1 block at a time.
According to JPEG2000 specs, Number of tiles in X and Y directions is calculated by following formula:
numXtiles = (Xsiz − XTOsiz)/ XTsiz
&
numYtiles = (Ysiz − YTOsiz)/ YTsiz
But it is not mentioned about the range of numXtiles or numYtiles.
Can we have numXtiles=0 while numYtiles=250 (or any other value) ?
In short, no. You will always need at least one row and one column of tiles to place your image in the canvas.
In particular, the SIZ marker of the JPEG 2000 stream syntax does not directly define the number of tiles, but rather the size of each tile. Since the tile width and height are defined to be larger than 0 (see page 453 of "JPEG 2000 Image compression fundamentals, standards and practice", by David Taubman and Michael Marcellin), you will always have at least one tile.
That said, depending on the particular implementation that you are using, there may be a parameter numXtiles that you can set to 0 without crashing your program. In that case, the parameter is most likely being ignored or interpreted differently.
This question already has answers here:
Objective-C - How to increase the precision of a float number
(3 answers)
Closed 10 years ago.
In my application I am just dividing 50 by 3 I want to store the exact result value of this.
If I use float it gives 16.666666 and if i use double then it gives 16.666667.
Actually,I am creating three labels inside a frame by dividing the height of the frame I am deciding the height of each label. so I f i do not get exact value it creates a gap between labels.if if i pass 60 then it works fine because 60/3 results 20 but if I pass 50 then there is a gap.
If you want to make your frame divide into three equal-height areas, then the height of your frame in pixels needs to be divisible by three. You can't display fractional pixels, they are not divisible; each height as measured in pixels needs to be an integer number.
The only way to store an "exact" value would be to create a class called "Rational" (or similar) and store the numerator and denominator of the fraction as separate ivars. Floats and doubles (or any literal computer representation for that matter) cannot store rational numbers with an infinite number of decimal places or transcendental real numbers.
The way to use the "Rational" class would be to store the numerator and denominator, and then apply the appropriate maths to these values (if you wish to propagate "exactness" through the program). The slightly easier way would be to display the rational number as numerator and denominator but use the float/double approximation for the underlying mathematics.
float t= (float)50/3;
long double t1= (long double)50/3;
NSLog(#"%.30f %.30LF",t, t1);
produced output "16.666666030883789062500000000000 16.666666666666666666088425508008".
I would suggest you to go with long double which is not exact but precise enough.
the code comes from a Qt library that helps produce buttons with the shape of an image; it scans through all lines y and all the width x, generating the following change when the rgb part of the pixel coincides with the masking one (mp is the pointer at the start of the line and it is prefilled with 0xff):
*(mp + (x >> 3)) &= ~(1 << (x & 7));
I can't really interpret it; anyone with background to give a hand?
From the looks of the code, mp points to the current line of a 1 bit per pixel image. The code clears the bit representing the pixel at X. It converts the X offset into a byte offset (x >> 3) and then logical AND's the byte with a mask created from the inverse 1 shifted left by the X position within the byte.
for the mortals; ok, background: http://www.cprogramming.com/tutorial/bitwise_operators.html; &= means we are gonna do a bitwise multiplication; in the rhs, the ~ is for the complement, so it flips 1s with 0s and viceversa; 7 in binary has 3 ones in the end and all zeros at front, so x & 7 preserves the last 3 bits in x; combined with << this will move the 1 in the first bit from the char 1 to the left a certain number of places in accordance with the exponent; since the exponent is only using the last 3 bits of x, it is smaller than 8(2^3); so the bit with the one will get in the position 1-8 within the 8 bits of the char; the flip ~ will turn the thing into all 1s except in that magic position; the multiplication performed by the &= will preserve everything in the lhs except that one bit. now for the lhs; we are kicking the last byte or the last 3 bits of x out with >> in a right shift operation; this means the location we'll modify the same byte (char type of mp) for every 8 increments of x; when we "jump", we'll do so by only one byte; when x=9 it will go to mp+1, when x= 17 it will go to mp+2; so it is like x/2^3 in integer operations, but in one shift operation; ok, now we have the elements to understand the whole thing;
tmask has been prefilled with 0xff, all ones; which means that it will be passive upon the &= operation, preserving what the rhs dictactes; this means that in case the there's a hit in an if statement that checks if the particular pixel is equal to the background, then this line is executed and we will wipe the specific bit related to the pixel;
I use zeros to initialize my matrix like this:
height = 352
width = 288
nFrames = 120
imgYuv=zeros([height,width,3,nFrames]);
However, when I set the value of nFrames larger than 120, MATLAB gives me an error message saying out of memory.
The original function is
[imgYuv, S, A]= changeYuv(fileName, width, height, idxFrame, nFrames)
my command is
[imgYuv,S,A]=changeYuv('tilt.yuv',352,288,1:120,120);
Can anyone please tell me what's going on here?
PS: one of the purposes of the function is to load a yuv video which consists more than 2000 frames. Is there any possibility to implement that?
There are three ways to avoid the error
Process a limited number of
frames at any given time.
Work
with integer arrays. Most movies are
in 8-bit format, while Matlab
normally works with doubles.
uint8 takes 1 byte per element,
while double takes 8 bytes. Thus,
if you create your array as B =
zeros(height,width,3,nFrames,'uint8)`,
it only uses 1/8th of the memory.
This might work for 120 frames,
though for 2000 frames, you'll run
again into trouble. Note that not
all Matlab functions work for
integer arrays; you may have to
reimplement those that require
double.
Buy more RAM.
Yes, you (or rather, your Matlab session) are running out of memory.
Get out your calculator and find the product height x width x 3 x nFrames x 8 which will tell you how much memory you have tried to get in your call to zeros. That will be a number either close to or in excess of the RAM available to Matlab on your computer.
Your command is:
[imgYuv,S,A]=changeYuv('tilt.yuv',352,288,1:120,120);
That is:
352*288*120*120 = 1459814400
That is 1.4 * 10^9. If one object has 4 bytes, then you need 6GB. That is a lot of memory...
Referencing the code I've seen in your withdrawn post, your calculating the difference between adjacent frame histograms. One option to avoid massive memory allocation might be to just hold two frames in memory, instead of reading all the frames at once.
The function B = zeros([d1 d2 d3...]) creates an multi-dimensional array with dimensions d1*d2*d3*...
Depending on width and height, given the 3rd dimension of 3 and the 4th dimension of 120 (which effectively results in width*height*360), may result in a very huge array. There are certain memory limits on every machine, maybe you reached these... ;)