From what I understand, in mathematics, the mod operator is the result of the remainder of Euclidean division. Where 0 ≤ r < |b|, meaning that the result will always be positive.
In programming however, there are operators in many languages which can be used to mean either the remainder operator or modulo operator which differ with respect to how they handle negative values.
(I believe that mod operator in math, remainder operator in programming, and mod operator in programming yield the same results for positive numbers)
According to Modulo operation with negative numbers
"With a remainder operator, the sign of the result is the same as the
sign of the dividend while with a modulo operator the sign of the
result is the same as the divisor."
So the mod operator in programming is not referring to the mod operator in math?
Is the sign of the answer the main distinguishing factor between mod operator vs remainder operator in programming?
Mathematically, the modulus is part of group theory, and the idea of a set. You can generate all the numbers in a set by addition, with the modulus. So if your set is integers modulus 10, you count 0-9 and then start over at 0. There is no concept of a negative number under modulus.
In programming, the remainder is what portion is left after doing a division. So if you divide 3 by 10, you're left with 0 and a remainder of 3. If you divide -3 by 10, you get 0 with a remainder of -3, rather than -1 remainder 7. But the mathematical modulus is 7.
Those who designed integer division that we now use decided that it's more logical to round towards 0, rather than round towards negative infinity, so by necessity, a negative division will result in a negative remainder.
If you want to convert a remainder to a modulus, you need to add your modulus to any negative remainders in order to map them into the proper range.
Is it true to say that : there are no fractional power units in F#
In addition to what has already been said, the best resource for information about (not just) F# units of measure is Andrew Kennedy's PhD thesis, who actually designed F# units. He mentions fractional units:
The most important decision is whether or not to allow fractional exponents
of dimensions. The argument against them is philosophical: a quantity with a
dimension such as M1/2 makes no sense physically, and if such a thing arose, it
would suggest revision of the set of base dimensions rather than a re-evaluation of
integral exponents. The argument in favour is pragmatic: sometimes it is easier
to write program code which temporarily creates a value whose dimension has
fractional exponents. In this dissertation the former view prevails, and fractional
exponents are not considered. However, most of the theory would apply just the
same; any potential differences are highlighted as they arise.
I think this is essentially the reason why F# does not have fractional units, because the F# design quite closely follows Andrew Kennedy's work to make sure it is sound.
Update: With F# 4.0, support for fractional exponents has been implemented
Units with fractional exponents are quite common and there is nothing special about them.
Probably everyone in technology has come across a voltage noise density, which is measured per sqrt(Hz).
This makes a lot of sense physically, the noise power is proportional to the bandwidth, and the noise voltage is the sqrt of the power, no strange mathematics here.
To create a new base unit every time one comes across a fractional power exponent is not the right approach.
These units are not SI units and their use breaks library compatibility.
If you define the sqrtHz as a new unit and I define the rootHz, our code can't work together.
Anyway, I would need to introduce quite a big set of base units to have a complete set
Hz^-2, Hz^3, Hz^-5,...
Just to offer rational exponents seems to be the better choice, btw. Boost.units does so.
Absence of literally fractional power units of measure does not anyhow discounts F# unit facility as it allows presenting seemingly fractional exponent unit relationships the other way around having smallest fraction as a base dimension:
let takeSqrt (x: float<_>) = sqrt(x)
has inferred signature of float<'u ^ 2> -> float<'u> this way avoiding introduction of imaginary "naturally fractional" float<'u> -> float<'u^1/2>.
let moreComplicated (x: float<_>) (y: float<_>) =
sqrt(x*x + y*y*y)
has inferred signature of float<'u ^ 3> -> float<'u ^ 2> -> float<'u ^ 3>, where all unit measure conversions stay valid relative to some derived implicit base dimension float<'u>.
The fact that the piece of code below
[<Measure>]type m
let c = sqrt(1.0<m>)
does not even compile with diagnostics The unit of measure 'm' does not match the unit of measure ''u ^ 2' can be considered as a blame, or a blessing, but is a clear indication that the unit measure checks are in place.
EDIT: After reading OP's comment and the except from Andrew Kennedy's paper, it appears #nicolas is correct -- F# doesn't support units of measure with fractional exponents.
Shouldn't the answer be as easy as saying, yes, hertz are measured in s^-2 which is the same as s^(1/2)? There ya' go.
Also, I like the philosophical idea of using , say m^(1/2) if it came up in calculations and perhaps one day understanding what that unit means in the literal sense.
I am using OpenCV library. It doesn't have a modulo operator that can be applied to WHOLE matrix.
It has a Multiplication, Subtraction operators for a matrix.
Is there any way I can combine these operations to have an alternative to modulo operation?
I am looking for modulo of 2*pi.
If there are multiple of 2*pi in a row of matrix, the product of that row will be zero. It will ease my life and save considerable performance compare to looping every element of matrix.
Thanks.
If you've also got Division and Floor, you can use:
mod(a,b) = a - floor(a/b) * b
If I compare two floating-point numbers, are there cases where a>=b is not equivalent to b<=a and !(a<b), or where a==b is not equivalent to b==a and !(a!=b)?
In other words: are comparisons always "symmetrical", such that I can get the same result on a comparison by swapping the operands and mirroring the operator? And are they always "negatable", such that negating an operator (e.g. > to <=) is equivalent to to applying a logical NOT (!) to the result?
Assuming IEEE-754 floating-point:
a >= b is always equivalent to b <= a.*
a >= b is equivalent to !(a < b), unless one or both of a or b is NaN.
a == b is always equivalent to b == a.*
a == b is equivalent to !(a != b), unless one or both of a or b is NaN.
More generally: trichotomy does not hold for floating-point numbers. Instead, a related property holds [IEEE-754 (1985) §5.7]:
Four mutually exclusive relations are possible: less than, equal, greater than, and unordered. The last case arises when at least one operand is NaN. Every NaN shall compare unordered with everything, including itself.
Note that this is not really an "anomaly" so much as a consequence of extending the arithmetic to be closed in a way that attempts to maintain consistency with real arithmetic when possible.
[*] true in abstract IEEE-754 arithmetic. In real usage, some compilers might cause this to be violated in rare cases as a result of doing computations with extended precision (MSVC, I'm looking at you). Now that most floating-point computation on the Intel architecture is done on SSE instead of x87, this is less of a concern (and it was always a bug from the standpoint of IEEE-754, anyway).
In Python at least a>=b is not equivalent to !(a<b) when there is a NaN involved:
>>> a = float('nan')
>>> b = 0
>>> a >= b
False
>>> not (a < b)
True
I would imagine that this is also the case in most other languages.
Another thing that might surprise you is that NaN doesn't even compare equal to itself:
>>> a == a
False
The set of IEEE-754 floating-point numbers are not ordered so some relational and boolean algebra you are familiar with no longer holds. This anomaly is caused by NaN which has no ordering with respect to any other value in the set including itself so all relational operators return false. This is exactly what Mark Byers has shown.
If you exclude NaN then you now have an ordered set and the expressions you provided will always be equivalent. This includes the infinities and negative zero.
Aside from the NaN issue, which is somewhat analogous to NULL in SQL and missing values in SAS and other statistical packages, there is always the problem of floating point arithmetic accuracy. Repeating values in the fractional part (1/3, for example) and irrational numbers cannot be represented accurately. Floating point arithmatic often truncates results because of the finite limit in precision. The more arithematic you do with a floating point value, the larger the error that creeps in.
Probably the most useful way to compare floating point values would be with an algorithm:
If either value is NaN, all comparisons are false, unless you are explicitly checking for NaN.
If the difference between two numbers is within a certain "fuzz factor", consider them equal. The fuzz factor is your tolerance for accumulated mathematical imprecision.
After the fuzzy equality comparison, then compare for less than or greater than.
Note that comparing for "<=" or ">=" has the same risk as comparison for precise equality.
Nope, not for any sane floating point implementation: basic symmetry and boolean logic applies. However, equality in floating point numbers is tricky in other ways. There are very few cases where testing a==b for floats is the reasonable thing to do.
Of course most languages have library functions for this, but suppose I want to do it myself.
Suppose that the float is given like in a C or Java program (except for the 'f' or 'd' suffix), for example "4.2e1", ".42e2" or simply "42". In general, we have the "integer part" before the decimal point, the "fractional part" after the decimal point, and the "exponent". All three are integers.
It is easy to find and process the individual digits, but how do you compose them into a value of type float or double without losing precision?
I'm thinking of multiplying the integer part with 10^n, where n is the number of digits in the fractional part, and then adding the fractional part to the integer part and subtracting n from the exponent. This effectively turns 4.2e1 into 42e0, for example. Then I could use the pow function to compute 10^exponent and multiply the result with the new integer part. The question is, does this method guarantee maximum precision throughout?
Any thoughts on this?
All of the other answers have missed how hard it is to do this properly. You can do a first cut approach at this which is accurate to a certain extent, but until you take into account IEEE rounding modes (et al), you will never have the right answer. I've written naive implementations before with a rather large amount of error.
If you're not scared of math, I highly recommend reading the following article by David Goldberg, What Every Computer Scientist Should Know About Floating-Point Arithmetic. You'll get a better understanding for what is going on under the hood, and why the bits are laid out as such.
My best advice is to start with a working atoi implementation, and move out from there. You'll rapidly find you're missing things, but a few looks at strtod's source and you'll be on the right path (which is a long, long path). Eventually you'll praise insert diety here that there are standard libraries.
/* use this to start your atof implementation */
/* atoi - christopher.watford#gmail.com */
/* PUBLIC DOMAIN */
long atoi(const char *value) {
unsigned long ival = 0, c, n = 1, i = 0, oval;
for( ; c = value[i]; ++i) /* chomp leading spaces */
if(!isspace(c)) break;
if(c == '-' || c == '+') { /* chomp sign */
n = (c != '-' ? n : -1);
i++;
}
while(c = value[i++]) { /* parse number */
if(!isdigit(c)) return 0;
ival = (ival * 10) + (c - '0'); /* mult/accum */
if((n > 0 && ival > LONG_MAX)
|| (n < 0 && ival > (LONG_MAX + 1UL))) {
/* report overflow/underflow */
errno = ERANGE;
return (n > 0 ? LONG_MAX : LONG_MIN);
}
}
return (n>0 ? (long)ival : -(long)ival);
}
The "standard" algorithm for converting a decimal number to the best floating-point approximation is William Clinger's How to read floating point numbers accurately, downloadable from here. Note that doing this correctly requires multiple-precision integers, at least a certain percentage of the time, in order to handle corner cases.
Algorithms for going the other way, printing the best decimal number from a floating-number, are found in Burger and Dybvig's Printing Floating-Point Numbers Quickly and Accurately, downloadable here. This also requires multiple-precision integer arithmetic
See also David M Gay's Correctly Rounded Binary-Decimal and Decimal-Binary Conversions for algorithms going both ways.
I would directly assemble the floating point number using its binary representation.
Read in the number one character after another and first find all digits. Do that in integer arithmetic. Also keep track of the decimal point and the exponent. This one will be important later.
Now you can assemble your floating point number. The first thing to do is to scan the integer representation of the digits for the first set one-bit (highest to lowest).
The bits immediately following the first one-bit are your mantissa.
Getting the exponent isn't hard either. You know the first one-bit position, the position of the decimal point and the optional exponent from the scientific notation. Combine them and add the floating point exponent bias (I think it's 127, but check some reference please).
This exponent should be somewhere in the range of 0 to 255. If it's larger or smaller you have a positive or negative infinite number (special case).
Store the exponent as it into the bits 24 to 30 of your float.
The most significant bit is simply the sign. One means negative, zero means positive.
It's harder to describe than it really is, try to decompose a floating point number and take a look at the exponent and mantissa and you'll see how easy it really is.
Btw - doing the arithmetic in floating point itself is a bad idea because you will always force your mantissa to be truncated to 23 significant bits. You won't get a exact representation that way.
You could ignore the decimal when parsing (except for its location). Say the input was:
156.7834e10... This could easily be parsed into the integer 1567834 followed by e10, which you'd then modify to e6, since the decimal was 4 digits from the end of the "numeral" portion of the float.
Precision is an issue. You'll need to check the IEEE spec of the language you're using. If the number of bits in the Mantissa (or Fraction) is larger than the number of bits in your Integer type, then you'll possibly lose precision when someone types in a number such as:
5123.123123e0 - converts to 5123123123 in our method, which does NOT fit in an Integer, but the bits for 5.123123123 may fit in the mantissa of the float spec.
Of course, you could use a method that takes each digit in front of the decimal, multiplies the current total (in a float) by 10, then adds the new digit. For digits after the decimal, multiply the digit by a growing power of 10 before adding to the current total. This method seems to beg the question of why you're doing this at all, however, as it requires the use of the floating point primitive without using the readily available parsing libraries.
Anyway, good luck!
Yes, you can decompose the construction into floating point operations as long as these operations are EXACT, and you can afford a single final inexact operation.
Unfortunately, floating point operations soon become inexact, when you exceed precision of mantissa, the results are rounded. Once a rounding "error" is introduced, it will be cumulated in further operations...
So, generally, NO, you can't use such naive algorithm to convert arbitrary decimals, this may lead to an incorrectly rounded number, off by several ulp of the correct one, like others have already told you.
BUT LET'S SEE HOW FAR WE CAN GO:
If you carefully reconstruct the float like this:
if(biasedExponent >= 0)
return integerMantissa * (10^biasedExponent);
else
return integerMantissa / (10^(-biasedExponent));
there is a risk to exceed precision both when cumulating the integerMantissa if it has many digits, and when raising 10 to the power of biasedExponent...
Fortunately, if first two operations are exact, then you can afford a final inexact operation * or /, thanks to IEEE properties, the result will be rounded correctly.
Let's apply this to single precision floats which have a precision of 24 bits.
10^8 > 2^24 > 10^7
Noting that multiple of 2 will only increase the exponent and leave the mantissa unchanged, we only have to deal with powers of 5 for exponentiation of 10:
5^11 > 2^24 > 5^10
Though, you can afford 7 digits of precision in the integerMantissa and a biasedExponent between -10 and 10.
In double precision, 53 bits,
10^16 > 2^53 > 10^15
5^23 > 2^53 > 5^22
So you can afford 15 decimal digits, and a biased exponent between -22 and 22.
It's up to you to see if your numbers will always fall in the correct range... (If you are really tricky, you could arrange to balance mantissa and exponent by inserting/removing trailing zeroes).
Otherwise, you'll have to use some extended precision.
If your language provides arbitrary precision integers, then it's a bit tricky to get it right, but not that difficult, I did this in Smalltalk and blogged about it at http://smallissimo.blogspot.fr/2011/09/clarifying-and-optimizing.html and http://smallissimo.blogspot.fr/2011/09/reviewing-fraction-asfloat.html
Note that these are simple and naive implementations. Fortunately, libc is more optimized.
My first thought is to parse the string into an int64 mantissa and an int decimal exponent using only the first 18 digits of the mantissa. For example, 1.2345e-5 would be parsed into 12345 and -9. Then I would keep multiplying the mantissa by 10 and decrementing the exponent until the mantissa was 18 digits long (>56 bits of precision). Then I would look the decimal exponent up in a table to find a factor and binary exponent that can be used to convert the number from decimal n*10^m to binary p*2^q form. The factor would be another int64 so I'd multiply the mantissa by it such that I obtained the top 64-bits of the resulting 128-bit number. This int64 mantissa can be cast to a float losing only the necessary precision and the 2^q exponent can be applied using multiplication with no loss of precision.
I'd expect this to be very accurate and very fast but you may also want to handle the special numbers NaN, -infinity, -0.0 and infinity. I haven't thought about the denormalized numbers or rounding modes.
For that you have to understand the standard IEEE 754 in order for proper binary representation. After that you can use Float.intBitsToFloat or Double.longBitsToDouble.
http://en.wikipedia.org/wiki/IEEE_754
If you want the most precise result possible, you should use a higher internal working precision, and then downconvert the result to the desired precision. If you don't mind a few ULPs of error, then you can just repeatedly multiply by 10 as necessary with the desired precision. I would avoid the pow() function, since it will produce inexact results for large exponents.
It is not possible to convert any arbitrary string representing a number into a double or float without losing precision. There are many fractional numbers that can be represented exactly in decimal (e.g. "0.1") that can only be approximated in a binary float or double. This is similar to how the fraction 1/3 cannot be represented exactly in decimal, you can only write 0.333333...
If you don't want to use a library function directly why not look at the source code for those library functions? You mentioned Java; most JDKs ship with source code for the class libraries so you could look up how the java.lang.Double.parseDouble(String) method works. Of course something like BigDecimal is better for controlling precision and rounding modes but you said it needs to be a float or double.
Using a state machine. It's fairly easy to do, and even works if the data stream is interrupted (you just have to keep the state and the partial result). You can also use a parser generator (if you're doing something more complex).
I agree with terminus. A state machine is the best way to accomplish this task as there are many stupid ways a parser can be broken. I am working on one now, I think it is complete and it has I think 13 states.
The problem is not trivial.
I am a hardware engineer interested designing floating point hardware. I am on my second implementation.
I found this today http://speleotrove.com/decimal/decarith.pdf
which on page 18 gives some interesting test cases.
Yes, I have read Clinger's article, but being a simple minded hardware engineer, I can't get my mind around the code presented. The reference to Steele's algorithm as asnwered in Knuth's text was helpful to me. Both input and output are problematic.
All of the aforementioned references to various articles are excellent.
I have yet to sign up here just yet, but when I do, assuming the login is not taken, it will be broh. (broh-dot).
Clyde