What function that depends by following variablesc (First Operand's sign[0/1], Second Operand's sign[0/1], Result's sign[0/1] and Operation sign[0/1]) can identify an overflow in the 4-bit ripple-carry adder/substractor?
P.S.
An overflow occurs only if:
the sum of two positive numbers yields a negative result, the sum has overflowed.
the sum of two negative numbers yields a positive result, the sum has overflowed.
I only know the method with checking the 2 last carries but it seems that there's another method.
Your PS already contains the correct logic formula written in prose (for addition). Remember that a number is "positive" if its sign bit is zero and the number is negative if its sign bit is one.1 This means you can translate "yields a negative result" to "the operation sign is 1". You can translate the other statements about operands or results to logic conditions in the same way, to finally derive a general boolean formula.
1: I know that zero is neither positive nor negative, but treating zero as positive does no harm in this case.
Related
I am working on a code in Least Square Non Negative solution recovery context on Matlab, and I need (with no more details because it's not that important for this question) to know the number of non zero elements in my matrices and arrays.
The function NNZ on matlab does exactly what I want, but it happens that I need more information about what Matlab thinks of a "zero element", it could be 0 itself, or the numerical zero like 1e-16 or less.
Does anybody has this information about the NNZ function, cause I couldn't get the original script
Thanks.
PS : I am not an expert on Matlab, so accept my apologies if it's a really simple task.
I tried "open nnz", on Matlab but I only get a small script of commented code lines...
Since nnz counts everything that isn't an exact zero (i.e. 1e-100 is non-zero), you just have to apply a relational operator to your data first to find how many values exceed some tolerance around zero. For a matrix A:
n = nnz(abs(A) > 1e-16);
Also, this discussion of floating-point comparison might be of interest to you.
You can add in a tolerance by doing something like:
nnz(abs(myarray)>tol);
This will create a binary array that is 1 when abs(myarray)>tol and 0 otherwise and then count the number of non-zero entries.
Problem: given two integers a, b (a>b) and the only data type can be used is int; besides compiler adopt two's complement computation method.
Can ab>a promise the result ab is right without overflow?
If the answer is yes, how can I prove? otherwise, how to find counterexample and what's the right condition?
To answer the question in part, in the C# program
using System;
public class Program
{
public static void Main()
{
int a = 654321;
int b = -654321;
var iBool = a * b > a;
Console.WriteLine(iBool);
}
}
the condition a * b > a evalues to true, which is analytically wrong. b is negative and a is positive, so a*b must be negative, but of larger absolute value than b, which means that a*b cannot be larger than a. However, the implementation decides otherwise.
No.
Let's look at positive numbers first. In order for the promise to be wrong, the overflow must be so large that it not only overflows but is larger than a, so something well in excess of twice INT_MAX would be needed (to be precise it needs to be something larger than abs(INT_MIN)+INT_MAX+a).
Intuitively that looks like it can't happen, but it is not as impossible as it seems because a and b only both need to be significantly larger than one half the bit size of int, but not too close to the maximum.
It's easier to see that the promise doesn't hold with negative a and b. The precondition a > b implies that if a is negative, then b is negative as well, and thus the result of multiplying them is always positive.
Positive numbers are always larger than negative numbers, no matter which numbers you choose, so a*b > a is always true whenever a and b are both negative, you always promise no overflow has happened, regardless of whether that is the case.
Except, well except when a and b are small enough, integer overflow will happen.
Take any two non-special, but decidedly negative integers, say -5'000'000 and -500'000, which fulfill the precondition a > b.
Multiply them and you get 2'500'000'000'000 which is significantly overflowing (several times, actually).
The result is 329033728, which is definitively larger than -5'000'000, so you wrongly promise that no overflow has happened.
given an n-bit 2's complement adder/subtractor what is the overflow logic. i don't have access to internal circuit design. Only 2 n-bit numbers, sum, add/sub, carry(in), carry(out)
There are a few rules for determining overflow in this case. (Note: this only applies to addition, but treating A - B as A + (-B), you can figure out the rules for subtraction as well).
If the two inputs have different signs, then there's no possibility of overflow.
If they have the same sign, but the output has a different sign, then you have an overflow. For example, if you add two positive numbers but get a negative result, you know it's an overflow (since two positives can't sum to a negative).
In other words, Overflow = (Sign(A) == Sign(B)) and (Sign(Sum) != Sign(A)).
This is literally the number I obtain (from symsum function), which is of type sym:
a=328791078344903739363762093060350430076929707044786898291940722052812676355129485878814911641516759087483581972443760841410582114920781832660013389681326267351368505696628653562484228680842650173635989588528021721039959787053654401351638478786763875479187208098871238084448485336138651690856082810553570419028927840285091142054111375001
I would like to make mathematical operations (in particular, take a natural log) on this number and so want to transform it to double, however the output from double(a) is simply "Inf". How to go about this problem and convert it from "sum" to a numeric type?
Your number is ~3.3x10335 but the largest number that can be represented by MATLAB's double precision floating point numbers is ~1.8x10308 (see the output of realmax). Converting your number to double precision causes overflow because the number is larger than can be represented so MATLAB just returns Inf.
For an exhaustive overview of floating point representations and arithmetic, you can check out this PDF.
Can you count the digits and insert a decimal point before converting to double?
If so, take advantage of the fact that the natural log of a number that overflows may not itself overflow.
Using "^" for power, you can represent your number as 3.28791078344903739363762093060350430076929707044786898291940722052812676355129485878814911641516759087483581972443760841410582114920781832660013389681326267351368505696628653562484228680842650173635989588528021721039959787053654401351638478786763875479187208098871238084448485336138651690856082810553570419028927840285091142054111375001 * (10 ^ 335).
The decimal log of (10^335) is 335. Its natural log is 335*log(10).
The natural log of the original number is:
log(3.287910783449037393637620930603504300769297070447868982919407220528)
+ 335*log(10)
All inputs, intermediate results, and the final result of this calculation are in the double range.
FormatCurrency(
(SUM(iif(IsNothing(Fields!Planned.Value),0,Fields!Planned.Value))-(SUM(iif(IsNothing(Fields!Actuals.Value),
iif(IsNothing(Fields!Forecasts.Value),0,Fields!Forecasts.Value),
iif(Fields!Actuals.Value=0,iif(IsNothing(Fields!Forecasts.Value),
0,
Fields!Forecasts.Value),Fields!Actuals.Value))))),
iif(Parameters!DecimalDigits.Value=1,1,iif(Parameters!DecimalDigits.Value=2,2,0)),0,0,0)
)
this is my expression which is returning negative values and how to remove this negative sign in front of the number
The easiest way is to turn the expression around. For instance, if
Planned - Actual
is giving you negative numbers and you want positive numbers then maybe you want
Actual - Planned
Otherwise you could just take the whole expression away from zero to reverse the sign:
0 - <expression>
Or if you really want to kill the negative sign regardless, then use Absolute - this returns the value as a positive number regardless
Abs(<expression>)
I would also remove the formatting part of the expression and put that into the Format property. Almost everything in SSRS can be an expression, so you don't have to do everything in the Value expression.