|
|
|
I have to convert a floating point range into inverse units (Hz to uSec, and back) while assuring that any rounding causes the range to widen, not narrow. A simple X = 1000000/Y conversion could result in rounding in either direction, and short of adjusting Y by an empirically determined delta large enough to always force the rounding in the correct direction I'm unable to think of a good way to control the rounding.
--
Rules of thumb should not be taken for the whole hand.
|
|
|
|
|
Isn't a ceiling function what you want, round up, but not down?
"Oh, what a tangled web we weave, when first we practice to deceive." - Sir Walter Scott
Web - Blog - RSS - Math - LinkedIn - BM
|
|
|
|
|
Probably. I'm using doubles and keeping at most 9SF, so it's doubtful that a single division will throw the bogobits into the part being kept.
--
Rules of thumb should not be taken for the whole hand.
|
|
|
|
|
Multiply by 1o to the number of digits you wish to keep, ceil it, then divide by the power of 10 again. See if this gives you what you want.
"Oh, what a tangled web we weave, when first we practice to deceive." - Sir Walter Scott
Web - Blog - RSS - Math - LinkedIn - BM
|
|
|
|
|
To set it globally for your app you can use _controlfp() or _controlfp_s().
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Need algorithms when next putting a clock forward/back from Windows information (GetTimeZoneInformation())...
|
|
|
|
|
Hmarik wrote: Need algorithms when next putting a clock forward/back from Windows information (GetTimeZoneInformation())...
I'm really glad to know you need that.
Really though, you should perhaps be a bit more specific in your request. Well, at least to me it seems somewhat ambiguous.
|
|
|
|
|
AFAIK there is no algorithm involved; in Europe the start and end dates of "summertime"
are agreed upon, a couple of years beforehand. I guess exact dates are available on the web...
BTW the UK do it slightly different.
Luc Pattyn
|
|
|
|
|
The summertime begins at the last sunday in march at 2 o'clock (since 2002), the wintertime at begins at the last sunday in octobre at 2o'clock (since 2002).
Before 2002 there were no rule, it was declared yearly. (Link in German: http://www.zeitumstellung.de/)
Regards,
Ingp
------------------------------
PROST Roleplaying Game
War doesn't determine who's right. War determines who's left.
"Would you like us to drop a bomb on you too? We have 10,000 of them!"
- espeir
"Perhaps we should lend them a nuke or two."
- espeir
|
|
|
|
|
Hi,
I'm trying do determine an ID3v2 tag size. Acording to the ID3 site it's stored in the first 10 bytes of the tag, acctually there the last 4 of those 10.
This is how they explain it.
The ID3v2 tag size is encoded with four bytes where the most significant bit (bit 7)
is set to zero in every byte, making a total of 28 bits. The zeroed bits are ignored,
so a 257 bytes long tag is represented as $00 00 02 01.
An ID3v2 tag can be detected with the following pattern:
$49 44 33 yy yy xx zz zz zz zz
Where yy is less than $FF, xx is the 'flags' byte and zz is less than $80
I think $00 00 02 01 is a hexadecimal represantation of the bytes. I understand that 1 byte = 01111111 maximum (bit7 =0), so 1 byte can represent 127 bytes (in tag size) maximum. In the example zz is less then $80, so it's less then 128. If so, I come to 4 * 127 * 127 = 64516 bytes in tag size. That's not 256 MB as they claim on the ID3 site.
I'm probably doing something wrong here.
Can anyone explain to me how 257 bytes (tag size) are represented by $00 00 02 01 in hexadecimal?
If you want to know The Truth, STOP lying.
|
|
|
|
|
Expand the hex string 00 00 02 01 to binary, and you get 00000000 00000000 00000010 00000001. Now, we ignore the most significant bit (left-hand end of each byte) giving the bit string 0000000 0000000 0000010 0000001, which when read as normal 8-bit bytes and padded to fill the top byte (padding in brackets) is (0000)0000 00000000 00000001 00000001, or hex 00 00 01 01 which is, in decimal, 257.
This following is a C function to get the size of the tag (assumes int is 32 bits and char is 8 bits.) The first of the four bytes from the ID3 tag is placed in the first position in the array, so for the example input, encodedSize[0] = 0x0, encodedSize[1] = 0x0, encodedSize[2] = 0x2, encodedSize[3] = 0x1 .)
int getTagSize(char encodedSize[4])
{
int retval = 0;
retval = encodedSize[0] << 21 | encodedSize[1] << 14 | encodedSize[2] << 7 | encodedSize[3];
return retval;
}
Not that this function doesn't do any form of sanity check on the input data, which is a Bad Thing™ in real code you must check that each byte of the encoded size is < 0x80, and do whatever is appropriate in your app when encountering an invalid ID3 tag if the test fails.
As for the aside about maximum tag size, the max value with this encoding is $7f 7f 7f 7f, which represents 268435455 bytes, or 256 MB, of ID3v2 tag. I don't see where you're getting 4*127*127 from, but the reason why 127*127*127*127 = 260144641 is wrong is that, while the maximum value for each byte is 127, the total number of values for each byte is 128, and so there are 128*128*128*128 = 268435456 possible values for the tag size (0-268435455)
|
|
|
|
|
There was an error in my reasoning . I did (127+127+127+127)*127 instead of 127*127*127*127, silly me :->.
I get it now. I don't understand C programming, I just got the basics of VB.Net, but I'll learn as I get along.
Reading (and eventually writing) mp3-tags seemed easy, as I could see the tag (more or less) when I open the file in notepad. And I love a challenge .
Thanks for the help. On to the next problem.;)
If you want to know The Truth, STOP lying.
|
|
|
|
|
|
has it been proved whether or not there are a finite number of twin primes yet?
Russell
|
|
|
|
|
The Twin Prime Conjecture is still a conjecture.
"Oh, what a tangled web we weave, when first we practice to deceive." - Sir Walter Scott
Web - Blog - RSS - Math - LinkedIn - BM
|
|
|
|
|
It cant be proven that a finite number exists... can it? because there is an infinite number of... numbers!
|
|
|
|
|
Just the fact that the set of integers is an infinite set does not in any way impact the provability. There are numerous other conjectures which have been proven on this set of (all integer) numbers. One common technique is to assume the conjecture is false, then demonstrate that such an assumption leads to a contradiction, therefore the opposite must be true.Some examples of proven and open conjectures[^]
|
|
|
|
|
It can; you just can't check it directly (that is, by checking each number).
For instance, even though there are infinitely many natural numbers, you can prove that there are an infinite number of primes, but only a finite number of even primes:
Proof there are an Infinite number of primes > 1:
Assume there are a finite number of primes, and call them p_1, p_2, ..., p_n.
Think of the number p_1 * p_2 * ... * p_n + 1. This number is bigger than any of the primes, and so it can't be a prime itself. But if you try to divide that number by any of the primes, you'll always end up with a remainder of one, and so the new number must be a prime itself. But that is a contradiction, because we assumed the only primes were p_1 through p_n. Because our hypothesis leads to a contradiction, it must be false. Thus, there must be infinitely many primes.
Proof there are a finite number of even primes:
Any even number is divisible by 2. Because 2 != any even number greater than 2, any even number greater than 2 is divisible by a number that is neither equal to 1 nor to itself. Since there are only finitely many even numbers equal to 2 or less (only one, which is two itself), there are only a finite number of even primes.
Basically, by using different techniques that let you talk about abstract sets of numbers, including infinite sets, you can prove things about infinite sets of things, without having to check each and every number individually (which is of course impossible).
So even though it hasn't been proven mathematically (yet) whether or not there are infinitely many twin primes, it should be possible. (Although there is a famous mathematical theorem that says that there are mathematically true statements that cannot be proven, so there is a slim chance that this theorem might be one of those. On the other hand, nothing like this has been found yet, outside of some very abstract statements that were used to prove that very theorem itself, so most likely a proof can be found.)
|
|
|
|
|
I have 6 floats, and each one has a weighting (lets represent the weighting by another float). Now I can get an overall score for the values by getting the sum of all the values multiplied by their weighting, however this will only give me an absolute value, with no reference point, unless I compared a number of different sets. Is there any way to ‘normalize’ the data, for example to get a percentage value. I could use an absolute reference point, but it would either need to be set higher than I would expect the overall score to ever get, or I would end up with scores greater than 100% (when the score gets above the reference score).
I do remember using Probability Density Functions with Normal Distributions to normalize data back in the day, however I’m not sure if this would work for what I have, or if it did would probably be pretty complex.
Any thoughts on the matter would be greatly appreciated.
|
|
|
|
|
I think that you can use the relative score, i.e.
rel_score(i)= value(i)*weight(i)/overall_score
if you like a percentage, then multiply it by 100.
Hope that helps.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Hi,
is there any one that can help me with my programe, in c++ to load a image of a car, do sobel to find edges and perform hough tranform to find the license plate.
i am getting lots of errors and iam stuck, i need some help or example code.
the sobel funtion below, iam getting errors can someone suggest a fix.
void CShowImageDlg::OnSobel()
{
// TODO: Add your control notification handler code here
BITMAP bm;
m_bmpBitmap.GetBitmap(&bm);
BYTE *image = (BYTE *) bm.bmBits;
BYTE *out;
BYTE *p1, *p2, *p3;
int width = bm.bmWidth;
int height = bm.bmHeight;
int h,w,ctr=0;
p1 = image; p2 = p1+width; p3 = p2+width;
for (h=0;h
|
|
|
|
|
Hi,
1.
I think something is wrong in the line p1 += 2; p2 += 2; p3 +=2;
isnt the idea here to move to the next scanline ?
2.
I suspect the Bitmap class also has a "stride" or "scanwidth" indicating the exact
distance you should move forward to get to the next scanline. It is not necessaraly true
that stride=width. I am not familiar with the details, but have a look at BitmapData
and LockBits.
3.
may I suggest you use pre and /pre tags to isolate code snippets; it (almost) preserves
all white space; and finally there is a checkbox that prevents HTML interpretation (so
your less than operators dont get eaten, see your for statements). Unfortunately if
you check it, pre tags dont work anymore...
Good luck with your image processing !
Luc Pattyn
|
|
|
|
|
I´m looking for a algorithm to calculate the sun up. Who can help me.
|
|
|
|
|