Related
expJ:listarray(J);
(expJ) ["-(l[1]*l[3]*m[3]*('diff(r[3](t),t,1))^2*sin(r[3](t)-r[1](t))+(2*l[1]*l[2]*m[3]+l[1]*l[2]*m[2])*('diff(r[2](t),t,1))^2*sin(r[2](t)-r[1](t))-l[1]*m[1]*g*cos(r[1](t)))/2","-(l[2]*l[3]*m[3]*('diff(r[3](t),t,1))^2*sin(r[3](t)-r[2](t))+((-2*l[1]*l[2]*m[3])-l[1]*l[2]*m[2])*('diff(r[1](t),t,1))^2*sin(r[2](t)-r[1](t))-2*l[2]*m[2]*g*cos(r[2](t)))/2","(l[2]*l[3]*m[3]*('diff(r[2](t),t,1))^2*sin(r[3](t)-r[2](t))+l[1]*l[3]*m[3]*('diff(r[1](t),t,1))^2*sin(r[3](t)-r[1](t))+3*l[3]*m[3]*g*cos(r[3](t)))/2"]
for i:1 thru 3 do(
for k:1 thru 3 do(
J[i,1]:ssubst("m3","m[3]",J[i,1])
));
I wanna substitute numbers in front of m as they are 1,2,3 with algorithm, but when I put mi ,it recognizes this as different variable, so somehow I need to indicate ssubs("mi","m[i]",J[i,1]) as i is separate from m.
Any suggestions?
OK, here is a way to substitute v(k) for v[k]. I believe that's OK since Matlab recognizes parentheses for array subscripts.
%o5 is the input (as strings) which you gave above. I've parsed the strings in %o7 and extracted the list of subscripted variables (via sublist and subvarp) in %o10. From there I created a list v(k) = v[k] in %o14 and then substituted those back into the parsed expressions in %o15.
I hope that this is going in the direction that will be helpful to you. You might still need to modify this approach to get what you want, but in any event, I will repeat my very strong advice against string processing. If there is still something more to do, it is almost certainly better to achieve it by working with expressions than with strings.
(%o5) [-(l[1]*l[3]*m[3]*('diff(r[3](t),t,1))^2*sin(r[3](t)-r[1](t))+(2*l[1]*l[\
2]*m[3]+l[1]*l[2]*m[2])*('diff(r[2](t),t,1))^2*sin(r[2](t)-r[1](t))-l[1]*m[1]*\
g*cos(r[1](t)))/2, -(l[2]*l[3]*m[3]*('diff(r[3](t),t,1))^2*sin(r[3](t)-r[2](t)\
)+((-2*l[1]*l[2]*m[3])-l[1]*l[2]*m[2])*('diff(r[1](t),t,1))^2*sin(r[2](t)-r[1]\
(t))-2*l[2]*m[2]*g*cos(r[2](t)))/2, (l[2]*l[3]*m[3]*('diff(r[2](t),t,1))^2*sin\
(r[3](t)-r[2](t))+l[1]*l[3]*m[3]*('diff(r[1](t),t,1))^2*sin(r[3](t)-r[1](t))+3\
*l[3]*m[3]*g*cos(r[3](t)))/2]
(%i6) linel:65;
(%o6) 65
(%i7) map (parse_string, %o5);
d 2
(%o7) [((- l l m (-- (r (t))) sin(r (t) - r (t)))
1 3 3 dt 3 3 1
d 2
- (2 l l m + l l m ) (-- (r (t))) sin(r (t) - r (t))
1 2 3 1 2 2 dt 2 2 1
d 2
+ l m g cos(r (t)))/2, ((- l l m (-- (r (t)))
1 1 1 2 3 3 dt 3
d 2
sin(r (t) - r (t))) - ((- 2 l l m ) - l l m ) (-- (r (t)))
3 2 1 2 3 1 2 2 dt 1
sin(r (t) - r (t)) + 2 l m g cos(r (t)))/2,
2 1 2 2 2
d 2
(l l m (-- (r (t))) sin(r (t) - r (t))
2 3 3 dt 2 3 2
d 2
+ l l m (-- (r (t))) sin(r (t) - r (t))
1 3 3 dt 1 3 1
+ 3 l m g cos(r (t)))/2]
3 3 3
(%i8) grind (%);
[((-l[1]*l[3]*m[3]*('diff(r[3](t),t,1))^2*sin(r[3](t)-r[1](t)))
-(2*l[1]*l[2]*m[3]+l[1]*l[2]*m[2])
*('diff(r[2](t),t,1))^2*sin(r[2](t)-r[1](t))
+l[1]*m[1]*g*cos(r[1](t)))
/2,
((-l[2]*l[3]*m[3]*('diff(r[3](t),t,1))^2*sin(r[3](t)-r[2](t)))
-((-2*l[1]*l[2]*m[3])-l[1]*l[2]*m[2])
*('diff(r[1](t),t,1))^2*sin(r[2](t)-r[1](t))
+2*l[2]*m[2]*g*cos(r[2](t)))
/2,
(l[2]*l[3]*m[3]*('diff(r[2](t),t,1))^2*sin(r[3](t)-r[2](t))
+l[1]*l[3]*m[3]*('diff(r[1](t),t,1))^2*sin(r[3](t)-r[1](t))
+3*l[3]*m[3]*g*cos(r[3](t)))
/2]$
(%o8) done
(%i9) listofvars (%o7);
(%o9) [l , m , g, t, l , m , m , l ]
1 1 2 2 3 3
(%i10) sublist (%, subvarp);
(%o10) [l , m , l , m , m , l ]
1 1 2 2 3 3
(%i11) map (op, %o10);
(%o11) [l, m, l, m, m, l]
(%i12) map (args, %o10);
(%o12) [[1], [1], [2], [2], [3], [3]]
(%i13) map (lambda ([v], apply (op(v), args(v))), %o10);
(%o13) [l(1), m(1), l(2), m(2), m(3), l(3)]
(%i14) map (lambda ([v1, v2], v1=v2), %o10, %o13);
(%o14) [l = l(1), m = m(1), l = l(2), m = m(2), m = m(3),
1 1 2 2 3
l = l(3)]
3
(%i15) subst (%, %o7);
d 2
(%o15) [((- l(1) l(3) m(3) (-- (r (t))) sin(r (t) - r (t)))
dt 3 3 1
d 2
- (2 l(1) l(2) m(3) + l(1) l(2) m(2)) (-- (r (t)))
dt 2
sin(r (t) - r (t)) + l(1) m(1) g cos(r (t)))/2,
2 1 1
d 2
((- l(2) l(3) m(3) (-- (r (t))) sin(r (t) - r (t)))
dt 3 3 2
d 2
- ((- 2 l(1) l(2) m(3)) - l(1) l(2) m(2)) (-- (r (t)))
dt 1
sin(r (t) - r (t)) + 2 l(2) m(2) g cos(r (t)))/2,
2 1 2
d 2
(l(2) l(3) m(3) (-- (r (t))) sin(r (t) - r (t))
dt 2 3 2
d 2
+ l(1) l(3) m(3) (-- (r (t))) sin(r (t) - r (t))
dt 1 3 1
+ 3 l(3) m(3) g cos(r (t)))/2]
3
(%i16) grind (%);
[((-l(1)*l(3)*m(3)*('diff(r[3](t),t,1))^2*sin(r[3](t)-r[1](t)))
-(2*l(1)*l(2)*m(3)+l(1)*l(2)*m(2))
*('diff(r[2](t),t,1))^2*sin(r[2](t)-r[1](t))
+l(1)*m(1)*g*cos(r[1](t)))
/2,
((-l(2)*l(3)*m(3)*('diff(r[3](t),t,1))^2*sin(r[3](t)-r[2](t)))
-((-2*l(1)*l(2)*m(3))-l(1)*l(2)*m(2))
*('diff(r[1](t),t,1))^2*sin(r[2](t)-r[1](t))
+2*l(2)*m(2)*g*cos(r[2](t)))
/2,
(l(2)*l(3)*m(3)*('diff(r[2](t),t,1))^2*sin(r[3](t)-r[2](t))
+l(1)*l(3)*m(3)*('diff(r[1](t),t,1))^2*sin(r[3](t)-r[1](t))
+3*l(3)*m(3)*g*cos(r[3](t)))
/2]$
(%o16) done
(%i17) listofvars (%o15);
(%o17) [g, t]
The inner merged observable isn't terminating with this code (rxjs 5.5.6):
let source = new Subject<string[]>();
// when the source emits a vector of strings, output
// each string with a 1s delay
source.switchMap(v => Observable.from(v)
.map(s => Observable.of(s).delay(1000).do(s => console.log('do: ' + s)))
// only one active observable at time
.mergeAll(1)
).subscribe(val => console.log('result: ' + val));
// emit two vectors, 1.5s apart
Observable.interval(1500).take(2).map(i => ['a' + i, 'b' + i, 'c' + i])
.subscribe(v => source.next(v));
Output is:
do: a0
result: a0
do: b0
do: a1
result: a1
do: c0
do: b1
result: b1
do: c1
result: c1
The expected output is:
do: a0
result: a0
do: a1
result: a1
do: b1
result: b1
do: c1
result: c1
That is, after the second vector emits, the switchMap should unsubscribe from the observable on the first vector, canceling that observable. And while the unsubscribe is clearly working, the inner observable is still running, as evidence by the "do: a0 .. b0 .. c0" in the output from the first example.
And in fact the expected output is exactly what you get from this code:
let source =
Observable.interval(1500).take(2).map(i => ['a' + i, 'b' + i, 'c' + i]);
source.switchMap(v => Observable.from(v)
.map(s => Observable.of(s).delay(1000).do(s => console.log('do: ' + s)))
.mergeAll(1)
).subscribe(val => console.log('result: ' + val));
But why doesn't the first example behave the same way?
I need another set of eyes to tell me what is wrong with my Eiffel implementation of Burnikel and Ziegler's division, specifically "Algorithm 2 - 3n/2n". The Eiffel feature is shown below. The type "like Current" is an ARRAYED_LIST [NATURAL_8]. In other words, the implementation uses digits (i.e. limbs) containing 8-bit values, so numbers are in base-256. A manual trace of a failing call follows. (Sorry the arguments are so large, but I cannot reproduce the error with shorter values.) Execution follows step 3b in this case.
Here's the problem. The algorithm seems to be fine to Step 5, where the remainder "r" ends up with more digits then the divisor. I believe the error is in step 3b, perhaps with the call to feature `ones' which is "supposed" to supply a value that is "Beta^n - 1". (Maybe I do not understand B&Z's "Beta^n" notation.
Here is the Eiffel code:
three_by_two_divide (a, a3, b: like Current): TUPLE [quot, rem: like Current]
-- Called by `two_by_one_divide'. It has similar structure as
-- `div_three_halves_by_two_halfs', but the arguments to this
-- function have type {JJ_BIG_NATURAL} instead of like `digit'.
-- See Burnikel & Zieler, "Fast Recursive Division", pp 4-8,
-- Algorithm 2.
require
n_not_odd: b.count >= div_limit and b.count \\ 2 = 0
b_has_2n_digits: b.count = a3.count * 2
a_has_2n_digits: a.count = a3.count * 2
local
n: INTEGER
a1, a2: like Current
b1, b2: like Current
tup: TUPLE [quot, rem: like Current]
q, q1, q2, r, r1: like Current
c, d: like Current
do
n := b.count // 2
-- 1) Split `a'
a1 := new_sub_number (n + 1, a.count, a)
a2 := new_sub_number (1, n.max (1), a)
-- 2) Split `b'.
b1 := new_sub_number (n + 1, b.count, b)
b2 := new_sub_number (1, n.max (1), b)
-- 3) Distinguish cases.
if a1 < b1 then
-- 3a) compute Q = floor ([A1,A2] / B1 with remainder.
if b1.count < div_limit then
tup := school_divide (a, b1)
else
tup := two_by_one_divide (a, b1)
end
q := tup.quot
r1 := tup.rem
else
-- 3b) Q = beta^n - 1 and ...
q := ones (n)
-- ... R1 = [A1,A2] - [B1,0] + [0,B1] = [A1,A2] - QB1.
r1 := a + b1
if n > 1 then
b1.shift_left (n)
else
b1.bit_shift_left (zero_digit.bit_count // 2)
end
r1.subtract (b1)
end
-- 4) D = Q * B2
d := q * b2
-- 5) R1 * B^n + A3 - D. (The paper says "a4".)
r1.shift_left (n)
r := r1 + a3 - d
-- 6) As long as R < 0, repeat
from
until not r.is_negative
loop
r := r + b
q.decrement
end
check
remainder_small_enough: r.count <= b.count
-- because remainder must be less than divisor.
end
Result := [q, r]
ensure
-- n_digit_remainder: Result.rem.count = b.count // 2
quotient_has_correct_count: Result.quot.count <= b.count // 2
end
In the trace, the arrow points to a line I believe is bad, but I don't know what to do with it. Here is the trace:
three_by_two_divide (a = [227,26,41,95,169,93,135,110],
a3 = [92,164,19,39],
b = [161,167,158,41,164,0,0,0])
n := b.count // 2 = 4
-- 1) Split `a'.
a1 := new_sub_number (n + 1, a.count, a) = [227,26,41,95]
a2 := new_sub_number (1, n.max (1), a) = [169,93,135,110]
-- 2) Split `b'.
b1 := new_sub_number (n + 1, b.count, b) = [161,167,158,41]
b2 := new_sub_number (1, n.max (1), b) = [164,0,0,0]
-- 3b) Q = beta^n -1 and ...
--> q := ones (4) = [255,255,255,255] <-- Is this the error?
-- ... R1 = [A1,A2] - [B1,0] + [0,B1].
r1 := a + b1 = [227,26,41,96,75,5,37,151]
b1.shift_left (n) = [161,167,158,41,0,0,0,0]
r1.subtract (b1) = [65,114,139,55,75,5,37,151]
d := q * b2 = [163,255,255,255,92,0,0,0]
r1.shift_left (n) = [227,25,135,184,172,220,37,151,0,0,0,0] -- too big!
r := r1 + a3 - d -= [227,25,135,184,8,220,37,152,0,164,19,39] -- too big!
I know this is long, but any help is appreciated.
I would suggest to check that r1 = [65,114,139,55,75,5,37,151] is still the same before doing r1.shift_left (n). There are two options:
d := q * b2 affects r1 while it should not. Most probably there is some aliasing, i.e. r1 is aliased with some other variable that is updated and this aliasing should be removed.
r1 is still the same after d := q * b2. The issue is with shift_left that fails to (re)initialize some data or uses global data that it should not.
The Problem
I want:
p <= (d-a) * b
Trying to directly instantiate a DSP block by using a DSP48E1 instead of simply writing p <= (d-a) * b plus it helps me understand how this block works for the future. So far I've had little luck with it though.
Referencing this article:
http://www.xilinx.com/support/documentation/user_guides/ug479_7Series_DSP48E1.pdf
Attempt
These are my current settings:
a <= std_logic_vector(to_unsigned(5, 30));
b <= std_logic_vector(to_unsigned(1, 18));
d <= std_logic_vector(to_unsigned(20, 25));
dsp : DSP48E1
generic map (
USE_DPORT => True,
ALUMODEREG => 0,
CARRYINREG => 0,
CARRYINSELREG => 0,
CREG => 0
)
port map(
clk => clk,
acin => std_logic_vector(to_unsigned(1, 30)), -- cascaded data input
alumode => "0000", -- control bits to select logic unit inputs
bcin => std_logic_vector(to_unsigned(1, 18)), -- cascaded data input
carrycascin => '0', -- cascaded data input
carryin => '0', -- carry input
carryinsel => "000", -- selects carry source
cea1 => '1', -- clock enable if AREG = 2 or INMODE0 = 1
cea2 => '1', -- clock enable if AREG = 1 or 2
cead => '1', -- clock enable for AD pipeline register
cealumode => '0', -- clock enable for ALUMODE --0
ceb1 => '1', -- clock enable if BREG = 1 or INMODE4 = 1
ceb2 => '1', -- clock enable if BREG = 1 or 2
cec => '0', -- clock enable for C
cecarryin => '0', -- clock enable
cectrl => '0', -- clock enable for OPMODE and CARRYINSEL ctrl registers
ced => '1', -- clock enable for D
ceinmode => '0',-- **** clock enable input registers
cem => '0', -- clock enable for the post multiply M register and the internal multiply round CARRYIN register
cep => '1', -- clock enable
inmode => "01101", -- *selects functionality of preadder [3] = sign, [4] = B multiplier sel
multsignin => '0', -- MACC extension sign
opmode => "0000101", -- *** Control input to A, Y and Z multiplexers
pcin => std_logic_vector(to_unsigned(1, 48)), -- cascade input
rsta => rst,
rstallcarryin => '0',
rstalumode => '0',
rstb => rst,
rstc => '0',
rstctrl => rst,
rstd => rst,
rstinmode => rst,
rstm => rst,
rstp => rst,
a => a,--_dsp, -- bits 29:25 used in second stage preadder
b => b,--_dsp,
c => c_dsp,
d => d,--_dsp,
p => p_dsp
);
I always get p = 0 even if I force d = 20, a = 5, b = 1.
I figured I should keep ALUMODE and OPMODE at 0 since I'm skipping the final stage and just want a straight subtraction and multiplication.
Photos
Look at table 2-7 from the DSP48E1 user guide page 34.
Your current configuration performs, at the post-adder, P = Z + X + Y + CIN, with Z = 0, X = 0 and Y = 0. You see the problem here?
The OPMODE signals control the value of the multiplexers. You want OPMODE(6 downto 4) = "000", so that Z keeps its null value. However, you want OPMODE(3 downto 0) = "0101" to set X/Y to the multiplier output M. ALUMODE should keep it's current value, it's fine.
First off, I would like to state this is on a practice exam I am taking. I know the answers to be: cout = 4ns, and S = 7ns. Just looking for a little explanation. Thanks in advance.
For the VHDL implementation of a full adder shown below, when do the outputs cout and S settle at their final values (consider the worst case timing path with the worst case inputs)?
architecture concurrent_behavior of full_adder is
signal t1, t2, t3, t4, t5: std_logic;
begin
t1 <= not A after 1 ns;
t2 <= not cin after 1 ns;
t4 <= not ((A or cin) and B) after 2 ns;
t3 <= not ((t1 or t2) and (A or cin)) after 2 ns;
t5 <= t3 nand B after 2 ns;
S <= not((B or t3) and t5) after 2 ns;
cout <= not(t1 or t2) and t4) after 2 ns;
end concurrent_behavior;
You basically just trace through the dependencies, and add up the dependencies for each route through the logic. Normally it's easiest to trace backwards from an output to the inputs it needs. For example:
cout <= not(t1 or t2) and t4) after 2 ns;
So, the last stage for cout has a 2 ns delay. Its inputs are t1, t2 and t4, so its 2 ns delay can't start until t1, t2 and t4 are all ready (i.e., the single longest of those delays determines the start time for the last stage).
In this case, t1 and t2 are delayed by 1 ns apiece, and t4 is delayed by 2 ns. Therefore, the last stage starts 2 ns after the initial input. That gives 2+2 = 4 ns from initial input to final output.
Looking at it from an algorithmic viewpoint, we could state it that the delay for any signal is the delay of the final "stage" for that signal plus the maximum of the delays for any of its inputs.
For S:
total = 2 + max_delay(B, t3, t5)
total = 2 + delay(t5);
total = 2 + 2 + max_delay(t3, B)
total = 2 + 2 + delay(t3)
total = 2 + 2 + 2 + max_delay(t1, t2, A, cin)
total = 2 + 2 + 2 + delay(t1) (or delay(t2) -- they're the same).
total = 2 + 2 + 2 + 1