My default console width is 80, but when I look into HKCU\Console there isn't a name that has this value. Only one that has supposedly to do with with is: WindowSize but it has value of 0x190050, that is dec: 1638480. Do the last two digits of it represent value I'm searching for ?
In HKCU\Console
0x19 = 25
0x50 = 80
So this is 25x80
In decimal, it's rows times 65,536 plus columns. (25 * 65536) + 80 = 1638480
Documentation is here.
Related
I've attached the page of the textbook that explains how to calculate the minimum necessary digits required when converting from decimal to binary. The textbook explanation and implementation of the formula makes no sense to me.
Is there a typo or something? Or am I misreading it?
The explanation states that the maximum value of the destination number system will always be greater than or equal to that of the source destination system. I don't agree with or understand this - can someone please explain it to me. Please.
I agree with and understand that the maximum value of x amount of digits, in a number system with base b, is equal to (bx - 1), because it can be proven.
In the decimal system, with 1 digit, the maximum value can be calculated as: (bx - 1) => (101 - 1) = 9; which is true because the available digits are 0,1,2,3,4,5,6,7,8,9 and the multiplier is 100 (which is 1).
In the binary system, with 1 digit, the maximum value can be calculated as: (bx - 1) => (21 - 1) = 1; which is true because the available digits are 0,1 and the multiplier is 20 (which is 1).
This method proves true for all positional number systems.
But then Forouzan says "Therefore (b2x - 1) ≥ (b1k - 1)", where (b1k - 1) represents the source system and (b2x - 1) represents the destination system. I don't understand this conclusion... because converting from decimal to binary; the binary is the destination system and the decimal is the source system, and we have just proven that with 1 digit the source system (decimal) has a greater value than the destination system (binary):
9 > 1; 1 cannot be greater than 9...
What am I missing here?? How can "(b2x - 1) ≥ (b1k - 1)" always be true?
Also in the example they then use the formula as x = ⌈6 * (log 10 / log 2)⌉ but 10 is our decimal base and 2 is our binary base - why are they now suddenly multipliers? Shouldn't it be "log10 of some other number" and "log2 of some other number"?
This is really not phrased well in the source text.
It's saying that if you have a number in base b1 (such as 10), and a number of digits k in that base, (such as 1), then you can represent b1^k elements (such as 0, 1, 2, 3, 4, 5, 6, 7, 8 and 9), and the largest such element will be b1^k-1 (i.e., 9).
To find how many digits x in some other base b2, you need to find an x with the property that b2^x-1 >= b1^k-1. b1, b2 and k are fixed, x is an unknown, and you can find it with this formula: x = ceiling(k * log [base b2] (b1)) (such as 4 = ceiling(1 * log [base 2] (10)), i.e., you need 4 binary digits to represent the numbers representable with one decimal digit.)
With our example of b1 = 10, b2 = 2, k = 1 and x = 4, we can see that b1^k-1 = 9 and b2^x-1 = 15, and 15 >= 9 is a true statement.
(log d / log f is another way of writing log [base f] (d))
When it says "Therefore (bx - 1) ≥ (bk - 1)" it means that that the destination space of numbers must be at least as large as the source's. (In order to hold all of them.)
In the second part of your question below the line, I think you may be reading the conclusion wrong. In the division of the logs, they have the same base. They are not logs with different bases as you have written. It is simply log(b1) / log(b2). That relation follows from the line above.
Refer to List of log identities #changing the base and this page about number of digits needed.
I'm trying to wrap my head around the truetype specification. On this page, in the section 'cmap' format 4, the parameter idDelta is listed as an unsigned 16-bits integer (UInt16). Yet, further down, a few examples are given, and here idDelta is given the values -9, -18, -27 and 1. How is this possible?
This is not a bug in the spec. The reason they show negative numbers in the idDelta row for the examples is that All idDelta[i] arithmetic is modulo 65536. (quoted from the section just above). Here's how that works.
The formula to get the glyph index is
glyphIndex = idDelta[i] + c
where c is the character code. Since this expression must be modulo 65536, that's equivalent to the following expression if you were using integers larger than 2 bytes :
glyphIndex = (idDelta[i] + c) % 65536
idDelta is a u16, so let's say it had the max value 65535 (0xFFFF), then glyphIndex would be equal to c - 1 since:
0xFFFF + 2 = 0x10001
0x10001 % 0x10000 = 1
You can think of this as a 16 integer wrapping around to 0 when an overflow occurs.
Now remember that a modulo is repeated division, keeping the remainder. Well in this case, since idDelta is only 16 bits, the max amount of divisions a modulo will need to do is 1, since the max value you can get from adding two 16 bit integers is 0x1FFFE , which is smaller than 0x100000. That means that a shortcut is to subtract 65536 (0x10000) instead of performing the modulo.
glyphIndex = (idDelta[i] - 0x10000) + c
And this is what the example shows as the values in the table. Here's an actual example from a .ttf file I've decoded :
I want the index for the character code 97 (lowercase 'a').
97 is greater than 32 and smaller than 126, so we use index 2 of the mappings.
idDelta[2] == 65507
glyphIndex = (65507 + 97) % 65536 === 68 which is the same as (65507 - 65536) + 97 === 68
The definition and use of idDelta on that page is not consistent. In the struct subheader it is defined as an int16, while a little earlier the same subheader is listed as UInt16*4.
It's probably a bug in the spec.
If you look at actual implementations, like this one from perl Tk, you'll see that idDelta is usually given as signed:
typedef struct SUBHEADER {
USHORT firstCode; /* First valid low byte for subHeader. */
USHORT entryCount; /* Number valid low bytes for subHeader. */
SHORT idDelta; /* Constant adder to get base glyph index. */
USHORT idRangeOffset; /* Byte offset from here to appropriate
* glyphIndexArray. */
} SUBHEADER;
Or see the implementation from libpdfxx:
struct SubHeader
{
USHORT firstCode;
USHORT entryCount;
SHORT idDelta;
USHORT idRangeOffset;
};
I'm writing something that reads bytes (just a List<int>) from a remote random number generation source that is extremely slow. For that and my personal requirements, I want to retrieve as few bytes from the source as possible.
Now I am trying to implement a method which signature looks like:
int getRandomInteger(int min, int max)
I have two theories how I can fetch bytes from my random source, and convert them to an integer.
Approach #1 is naivé . Fetch (max - min) / 256 number of bytes and add them up. It works, but it's going to fetch a lot of bytes from the slow random number generator source I have. For example, if I want to get a random integer between a million and a zero, it's going to fetch almost 4000 bytes... that's unacceptable.
Approach #2 sounds ideal to me, but I'm unable come up with the algorithm. it goes like this:
Lets take min: 0, max: 1000 as an example.
Calculate ceil(rangeSize / 256) which in this case is ceil(1000 / 256) = 4. Now fetch one (1) byte from the source.
Scale this one byte from the 0-255 range to 0-3 range (or 1-4) and let it determine which group we use. E.g. if the byte was 250, we would choose the 4th group (which represents the last 250 numbers, 750-1000 in our range).
Now fetch another byte and scale from 0-255 to 0-250 and let that determine the position within the group we have. So if this second byte is e.g. 120, then our final integer is 750 + 120 = 870.
In that scenario we only needed to fetch 2 bytes in total. However, it's much more complex as if our range is 0-1000000 we need several "groups".
How do I implement something like this? I'm okay with Java/C#/JavaScript code or pseudo code.
I'd also like to keep the result from not losing entropy/randomness. So, I'm slightly worried of scaling integers.
Unfortunately your Approach #1 is broken. For example if min is 0 and max 510, you'd add 2 bytes. There is only one way to get a 0 result: both bytes zero. The chance of this is (1/256)^2. However there are many ways to get other values, say 100 = 100+0, 99+1, 98+2... So the chance of a 100 is much larger: 101(1/256)^2.
The more-or-less standard way to do what you want is to:
Let R = max - min + 1 -- the number of possible random output values
Let N = 2^k >= mR, m>=1 -- a power of 2 at least as big as some multiple of R that you choose.
loop
b = a random integer in 0..N-1 formed from k random bits
while b >= mR -- reject b values that would bias the output
return min + floor(b/m)
This is called the method of rejection. It throws away randomly selected binary numbers that would bias the output. If min-max+1 happens to be a power of 2, then you'll have zero rejections.
If you have m=1 and min-max+1 is just one more than a biggish power of 2, then rejections will be near half. In this case you'd definitely want bigger m.
In general, bigger m values lead to fewer rejections, but of course they require slighly more bits per number. There is a probabilitistically optimal algorithm to pick m.
Some of the other solutions presented here have problems, but I'm sorry right now I don't have time to comment. Maybe in a couple of days if there is interest.
3 bytes (together) give you random integer in range 0..16777215. You can use 20 bits from this value to get range 0..1048575 and throw away values > 1000000
range 1 to r
256^a >= r
first find 'a'
get 'a' number of bytes into array A[]
num=0
for i=0 to len(A)-1
num+=(A[i]^(8*i))
next
random number = num mod range
Your random source gives you 8 random bits per call. For an integer in the range [min,max] you would need ceil(log2(max-min+1)) bits.
Assume that you can get random bytes from the source using some function:
bool RandomBuf(BYTE* pBuf , size_t nLen); // fill buffer with nLen random bytes
Now you can use the following function to generate a random value in a given range:
// --------------------------------------------------------------------------
// produce a uniformly-distributed integral value in range [nMin, nMax]
// T is char/BYTE/short/WORD/int/UINT/LONGLONG/ULONGLONG
template <class T> T RandU(T nMin, T nMax)
{
static_assert(std::numeric_limits<T>::is_integer, "RandU: integral type expected");
if (nMin>nMax)
std::swap(nMin, nMax);
if (0 == (T)(nMax-nMin+1)) // all range of type T
{
T nR;
return RandomBuf((BYTE*)&nR, sizeof(T)) ? *(T*)&nR : nMin;
}
ULONGLONG nRange = (ULONGLONG)nMax-(ULONGLONG)nMin+1 ; // number of discrete values
UINT nRangeBits= (UINT)ceil(log((double)nRange) / log(2.)); // bits for storing nRange discrete values
ULONGLONG nR ;
do
{
if (!RandomBuf((BYTE*)&nR, sizeof(nR)))
return nMin;
nR= nR>>((sizeof(nR)<<3) - nRangeBits); // keep nRangeBits random bits
}
while (nR >= nRange); // ensure value in range [0..nRange-1]
return nMin + (T)nR; // [nMin..nMax]
}
Since you are always getting a multiple of 8 bits, you can save extra bits between calls (for example you may need only 9 bits out of 16 bits). It requires some bit-manipulations, and it is up to you do decide if it is worth the effort.
You can save even more, if you'll use 'half bits': Let's assume that you want to generate numbers in the range [1..5]. You'll need log2(5)=2.32 bits for each random value. Using 32 random bits you can actually generate floor(32/2.32)= 13 random values in this range, though it requires some additional effort.
I know that you can split a power-of-two number in half like so:
halfintR = some32bitint & 0xFFFF
halfintL = some32bitint >> 16
can you do the same thing for an integer which is bounded by a non-power of two space?
(say that you want your range to be limited to the set of integers that will fit into 4 digit base 52 space unsigned)
You could use the following
rightDigits = number % 2704 // 52 squared
leftDigits = number / 2704
Well, of course. & 0xffff is the same as % 0x10000 and >> 16 is the same as / 0x10000. It is just that division by a power-of-two is more efficient when done with bit operations like shifting and masking. Division works with any number (within range of representation).
Once you realize that the & and >> are used for doing modulo und division calculation respectively, you can write what you want as:
lower = some4DigitsNumberBase52 % (52 * 52)
upper = some4DigitaNumberBase52 / (52 * 52)
This is the basis for doing base calculation. You can also derive the solution from the algorithm that displays a number in a specific base: how do you come up with the rightmost two digits and the 2 leftmost digits.
I want to make a short URL service for 2 million assets but I want to use the shortest number of possible characters.
What is the math equation that I would need to use to figure it out? I know it has something to do with factorials, right?
It's not a factorial problem, but an exponential one.
If x is the number of possible characters, you need to solve the following equation for y:
x^y = 2000000
If you want to use all numbers and case-sensitive alpha [0-9A-Za-z], you have 62 possible values. This means you need to solve:
62^y = 2000000
y*log(62) = log(2000000)
y = log(2000000) / log(62)
y = 3.5154313828...
Of course, you can't have 3.5 characters in your URL, so you would need 4. If you want to change the character set you are using for your URL's, simply resolve the problem above using the number of values in your set.
Note Solving this equation assumes fixed-length URL's. For variable-length URL's, see Rob's answer.
#jheddings is close, and got the right answer, but the math was not quite correct. Don't forget you are not limited to all the permutations of characters of a specific length. You can also leverage URLs of length 1 through y characters. Therefore we want the closed value of this sum:
x + x^2 + x^3 + ... + x^y = 2000000
Fortunately, there is a closed form for that sum:
x + x^2 + x^3 + ... + x^y = x*(x^y - 1)/(x-1) = 2000000
x is the number of possible characters in our range. For simplicity sake, let's assume it only includes lowercase, uppercase, and numbers (26+26+10 = 62.)
Then we get the following equation:
2000000 = (62^(y+1) - 62)/(62-1)
2000000 = (62^(y+1) - 62)/(61)
2000000 * 61 = 62^(y+1) - 62
122000000 = 62^(y+1) - 62
122000000 + 62 = 62^(y+1)
122000062 = 62^(y+1)
log(122000062) = (y+1)
log(122000062) / log(62) = y+1
4.511492 = y+1
3.511492 = y
And, as you said, 3.5 characters is impossible so 4 are required. Admittedly the difference doesn't matter in this case. However, in certain scenarios (especially when dealing with base 2) it is very important.
Number of possible short URLs = (Number of possible different characters in ID) raised to the power of (Length of ID in url)
For instance, if you're only using lowercase characters (of which there are 26) and your URLs look like http://domain.com/XXXXX (for your unique id's of 5 characters), then you can make 26^5 = 11,881,376 short urls.
If you were using upper and lower case letters, you'd have 52, so 52^5 = 380,204,032 possible short URLs, et cetera.
You need to answer a number of questions, like what kinds of characters you want to allow in your set.
All letters and all digits? base 36 (5 characters can fit 2mil+)
Distinguish between upper and lowercase? That gets you to base 62 (4 characters)
Remove easily-mistaken characters and numbers (e.g. i/l 0/o)? roughly base 32 (also 5 characters)
You can often solve this kind of problem without any math wizardry.
26+26+10 = 62 characters
Try 1. 62 = 62
Try 2. 62*62 = 3,844
Try 3. 62*62*62 = 238,328
Try 4. 62*62*62*62 = 14,776,336
So 4 is your answer :)
According to the HTTP/URI Spec you can additionally use the following "unreserved characters": ALPHA / DIGIT / "-" / "." / "_" / "~"
That adds an additional 4 characters to your radix and thus
Math.log(2000000) / Math.log(66) = 3.4629721616408813
Although this still means you will end up with a 4 character URL path at maximum.