I saw the following code: a += b += c - please, does anyone know what does it mean?
a = a + b
b = b + c
or:
b = b + c
a = a + b
It depends on associativity of += operator. Usually it's right to left, so it's the second answer: a+=b is evaluated after b+=c.
It can only be evaluated as:
a += (b += c)
If it would be evaluated as this:
(a += b) += c
then it would evaluate a += b to a numeric value, and then try to change the numeric value, not a variable, which is not possible.
In most high-level languages, expressions like this are evaluated left to right because += is right-to-left associative. In this case, the value of c is added to the value of b, then the value of b (after addition by c) is added to a.
This is equivalent to your second block.
Related
We want to compare a^b to c^d, and tell if the first is smaller, greater, or equal (where ^ denotes exponentiation).
Obviously, for very large numbers, we cannot explicitely compute these values.
The most common approach in this situation is to apply log on both sides and compare b * log(a) to d * log(c). The issue here is that logs are floating-point operations, and as such we cannot trust our answer with 100% confidence (there might be some values which are incredibly close, and because of floating-point error we get a wrong answer).
Is there an algorithm for solving this problem? I've been scouring the intrernet for this, but I can only find solutions which work for particular cases only (e.g. in which one exponent is a multiple of another), or which use floating point in some way (logarithms, division) etc.
This is sort of two questions in one:
Are they equal?
If not, which one is greater?
As Peter O. observes, it's easiest to build in a language that provides an arbitrary-precision fraction type. I'll use Python 3.
Let's assume without loss of generality that a ≤ c (swap if necessary) and b is relatively prime to d (divide both by the greatest common divisor).
To get at the core of the question, I'm going to assume that a, c > 0 and b, d ≥ 0. Removing this assumption is tedious but not difficult.
Equality test
There are some easy cases where a = 1 or b = 0 or c = 1 or d = 0.
Separately, necessary conditions for a^b = c^d are
i. b ≥ d, since otherwise b < d, which together with a ≤ c implies a^b < c^d;
ii. a is a divisor of c, since we know from (i) that a^b = c^d is a divisor of c^b = c^(b−d) c^d.
When these conditions hold, we can divide through by a^d to reduce the problem to testing whether a^(b−d) = (c/a)^d.
In Python 3:
def equal_powers(a, b, c, d):
while True:
lhs_is_one = a == 1 or b == 0
rhs_is_one = c == 1 or d == 0
if lhs_is_one or rhs_is_one:
return lhs_is_one and rhs_is_one
if a > c:
a, b, c, d = c, d, a, b
if b < d:
return False
q, r = divmod(c, a)
if r != 0:
return False
b -= d
c = q
def test_equal_powers():
for a in range(1, 25):
for b in range(25):
for c in range(1, 25):
for d in range(25):
assert equal_powers(a, b, c, d) == (a ** b == c ** d)
test_equal_powers()
Inequality test
Once we've established that the two quantities are not equal, it's time to figure out which one is greater. (Without the equality test, the code here could run forever.)
If you're doing this for real, you should consult an actual reference on computing elementary functions. I'm just going to try to do the simplest thing that works.
Time for a calculus refresher. We have the Taylor series
−log x = (1−x) + (1−x)^2/2 + (1−x)^3/3 + (1−x)^4/4 + ...
To get a lower bound, truncate the series. To get an upper bound, we can truncate but replace the final term (1−x)^n/n with (1−x)^n/n (1/x), since
(1−x)^n/n (1/x)
= (1−x)^n/n (1 + (1−x) + (1−x)^2 + ...)
= (1−x)^n/n + (1−x)^(n+1)/n + (1−x)^(n+2)/n + ...
> (1−x)^n/n + (1−x)^(n+1)/(n+1) + (1−x)^(n+2)/(n+2) + ...
To get a good convergence rate, we're going to want 0.5 ≤ x < 1, which we can achieve by dividing x by a power of two.
In Python, we'll represent a real number as an infinite generator of shrinking intervals that contain the true value. Once the intervals for b log a and d log c are disjoint, we can determine how they compare.
import fractions
def minus(x, y):
while True:
x_lo, x_hi = next(x)
y_lo, y_hi = next(y)
yield x_lo - y_hi, x_hi - y_lo
def times(b, x):
for lo, hi in x:
yield b * lo, b * hi
def restricted_log(a):
series = 0
n = 0
numerator = 1
while True:
n += 1
numerator *= 1 - a
series += fractions.Fraction(numerator, n)
yield -(series + fractions.Fraction(numerator * (1 - a), (n + 1) * a)), -series
def log(a):
n = 0
while a >= 1:
a = fractions.Fraction(a, 2)
n += 1
return minus(restricted_log(a), times(n, restricted_log(fractions.Fraction(1, 2))))
def less_powers(a, b, c, d):
lhs = times(b, log(a))
rhs = times(d, log(c))
while True:
lhs_lo, lhs_hi = next(lhs)
rhs_lo, rhs_hi = next(rhs)
if lhs_hi < rhs_lo:
return True
if rhs_hi < lhs_lo:
return False
def test_less_powers():
for a in range(1, 10):
for b in range(10):
for c in range(1, 10):
for d in range(10):
if a ** b != c ** d:
assert less_powers(a, b, c, d) == (a ** b < c ** d)
test_less_powers()
Is a - b + c - d = a + c - b - d mathematically correct?
I believe this statement can be correct but only sometimes if the order of evaluation does not matter so if I were to do
{(a - b) + c} - d and choose numbers that would evaluate to {(a + c) - b} - d where b and c are both the same numbers then this may be correct.
Is there a more mathematical and logical explanation for this?
I also think it has to do with associativity but that would prove that this statement is never correct since addition and multiplication are associative (separately) but not addition and subtraction together
This highly depends on the definition of + and -. So far as you have written, they are but free untyped infix symbols so it's hard to tell.
A simple example. Suppose values are of fixed-width floating point type (like one of those defined in IEEE-754, for instance). Next, if we have
a = 10e100
b = -10e-100
c = -10e100
d = -10e-100
and the expressions are evaluated greedily left-to-right, then
a - b + c - d = ((a - b) + c) - d
When the type has enough order bits to contain decimal orders of -100 and 100, but its mantissa is not wide enough to correctly represent 10e100 + 10e-100, specifically, the RHS argument is simply lost in this expression, then the value of the whole large expression is
((10e100 - -10e-100) + -10e100) - -10e-100 =
= (10e100 + -10e100) - -10e-100 = 0 - -10e-100 = 10e-100
But the second expression would evaluate to
((a + c) - b) - d = ((10e100 + -10e100) - -10e-100) - -10e-100 = 20e-100
So you see, the result can differ by 100% depending on the order of evaluation.
The shorthand for declaration and initialization in go is
var a, b, c = 1 , 2, 3
Equivalent to following way of declaration and initialization (as per specs)
a:=1
b:=2
c:=3
var a int
var b int
var c int
a=1
b=2
c=3
But I am not getting the answer for the problem found in following code:
package main
import "fmt"
func main() {
var a int = 0
var b int = 1
fmt.Println("init a ",a)
fmt.Println("init b ",b)
a, b = b, a+b
fmt.Println("printing a after `a, b = b, a+b`",a)
fmt.Println("printing b after `a, b = b, a+b`",b)
}
Output should be:
printing a after 'a, b = b, a+b' 1
printing b after 'a, b = b, a+b' 2
Since the value of b is evaluated with a + b i.e 1+1 = 2. But its giving 1.
Here is the playground links of both the working code where you can observe the difference.
a,b = b, a+b
a=b, b=a+b
I know I am missing something to understand, basically how the shorthand expression are evaluated especially when the same variable is involved in the expression.
But where is the proper documentation to refer. Could anyone help on this?
See here
The assignment proceeds in two phases. First, the operands of index
expressions and pointer indirections (including implicit pointer
indirections in selectors) on the left and the expressions on the
right are all evaluated in the usual order. Second, the assignments
are carried out in left-to-right order.
Based on that a+b (0+1) is evaluated first. Then it's assigned. Thus you get the result of a = 1 and b = 1
In Maxima, I want to change the following equation:
ax+b-c-d=0
into the following format
(ax+b)/(c+d)=1
Note:
something like ax+b-c-d+1=1 is not what I want.
Basically I want to have positive elements in one side and negative elements in another side, then divide the positive elements by the negative elements.
Here is a quick attempt. It handles some equations of the form you described, but it's probably easy to find some which it can't handle. Maybe it works well enough, or at least provides some inspiration.
ptermp (e) := symbolp(e) or (numberp(e) and e > 0)
or ((op(e) = "+" or op(e) = "*") and every (ptermp, args(e)));
matchdeclare (pterm, ptermp);
matchdeclare (otherterm, all);
defrule (r1, pterm + otherterm = 0, ratsimp (pterm/(-otherterm)) = 1);
NOTE: the catch-all otherterm must be precede pterm alphabetically! This is a useful, but obscure, consequence of the simplification of "+" expressions and the pattern-matching process ... sorry for the obscurity.
Examples:
apply1 (a*x - b - c + d = 0, r1);
a x + d
------- = 1
c + b
apply1 (a*x - (b + g) - 2*c + d*e*f = 0, r1);
a x + d e f
----------- = 1
g + 2 c + b
Can anyone say how ruby evaluates this:
a = 1
b = 2
a, b = b, a + b
a will be 2 and b will be 3, not 4 as you might expect
It seems that instead of working from left to right it does both sides in parallel somehow?
It is expressed as :-
a = 1
b = 2
a, b = b, (a + b)
a # => 2
b # => 3
This is called parallel assignment. Here all RHS expressions will be evaluated first (left to right). After that assignment will be happened from left to right.
It means, the calculation as follows :
a, b = b, a + b
a, b = 2, (2 + 1)
a, b = 2, 3 # now the real assignment will be happened here.
This is called parallel association, and, like name suggests, it works like all the assignments are done in parallel. You can for example write:
a = 1
b = 2
a, b = b, a
a #=> 2
b #=> 1
a = 1
b = 2
a, b = b, a + b
a
#=> 2
b
#=> 3
Here first rvalue is assigned to first lvalue and the result of second rexp is assigned to second lvalue. These assignments are parallel in nature not sequential.
a, b = b, a is a swap operation using parallel assignments. This makes me think Ruby might be using temporary variables to perform parallel assignments. I invite for corrections here.