I have a list of bit, which I would like to unpack to stages,
Stage #1 unpack it to struct A, and depending on the value i receive in A.next field i would like to unpack the "REST" to another struck, which can be B, C or D.
My problem is how to inform the next unpack from where to start unpacking.
Code:
unpack(packing.low, l, A);
if (A.next==B) {unpack(packing.low, l, B, LAST_UNPACK_SIZE)};
if (A.next==C) {unpack(packing.low, l, C, LAST_UNPACK_SIZE)};
if (A.next==D) {unpack(packing.low, l, D, LAST_UNPACK_SIZE)};
In general, for the purpose of customizing unpacking, it's suggested to extend the method do_unpack() of the struct. From outside the packing will remain simple, and inside you can encapsulate the logic. But not sure it matches your flow, because from A variable you probably can't access B,C,D variables.
For this specific case, you might try some trick, like passing a buffer list of bit to the first stage and then unpacking the rest from the buffer:
unpack(packing.low, l, A, buffer);
case A.next {
B: { unpack(packing.low, buffer, B) };
C: { unpack(packing.low, buffer, C) };
D: { unpack(packing.low, buffer, D) };
default: { error(...) };
};
Related
Write a function to swap a number in place without using temporary variables in Scala. The function parameters are immutable, so how can we avoid using temporary variables to implement the function?
The solution in C/C++ is:
void swap(int a, int b) {
a = a - b;
b = b + a;
a = b - a;
cout << a << " " << b << endl;
}
What will be the equivalent solution in Scala since in def swap(a: Int, b: Int): Unit a and b both are immutable if I am not mistaken?
Your solution for C++ is not the best one, because it might cause integer overflow if a or b is big enough.
The right solution would be using xor:
a = a ^ b;
b = b ^ a;
a = b ^ a;
But this kind of trick makes sense only if variables are mutable, so in your Scala version, you'd have to reassign function parameters to vars.
Another issue is, you should never do this in production code.
This algorithm is called xor swap and was beneficial on some early processors, but it's not useful now. It gives you no benefit of better performance and is less readable that plainly using a temporary variable.
As has been established, it can't be done as a method or function. What you can do is create a class with constructor parameters, which can be mutable.
class Swap(var a:Int, var b:Int) {
a ^= b
b ^= a
a ^= b
println(s"a:$a, b:$b")
}
Now every time you create a new Swap instance, the values of the constructor parameters will be swapped.
val myswap = new Swap(4, 579) //sends "a:579, b:4" to STDOUT
A rather pointless exercise.
For example I have A,B,C,D flowables emitting independently. For example where this maps to Foo:
Flowable<Foo> fooStream = Flowable.combineLatest(A,B,C,D -> Foo::new);
And it emits whenever A, B, C or D emits an update. a new Foo is emitted downstream.
Which combination of operators, if any, could I use for merging (A,B,C,D)'s latest result into Foo ONLY some select flowable (lets say A) emits?
There is exactly operator you need: withLatestFrom
A.withLatestFrom(B, C, D, Foo::new)
It will emit every time A emits, with latest values from B, C and D.
Keep in mind B, C and D must have value in them. So if for ex. D didn't emit anything at all, stream will get stuck.
I have written this code
def getParallelList[T](list : List[T]) : ParSeq[T] = {
val parList = list.par
parList.tasksupport = new ForkJoinTaskSupport(new scala.concurrent.forkjoin.ForkJoinPool(10))
parList
}
for {
a <- getList1
b <- getList2
c = b.calculateSomething
d <- getParallelList(getList3)
} { ... }
I want to know if this is a good (or best) way to make the for loop execute in parallel? Or should I explicitly code in futures inside of the loop.
I tested this and it seemed to work... but I am not sure if this is the best way ... also I am worried that what happens to the values of a,b,c for different threads of d. If one thread finishes earlier? does it change the value of a, b, c for others?
If getList3 is referentially transparent, i.e. it is going to return the same value every time it's called, it's better idea to calculate it once, since invoking .par on a list has to turn it to a ParVector, which takes O(n) (as List is a linked list and can't be immediately converted to a Vector structure). Here is example:
val list3 = getParallelList(getList3)
for {
a <- getList1
b <- getList2
c = b.calculateSomething
d <- list3
} { ... }
In the for comprehension, the values for (a, b, c) will remain the same during processing of d values.
For best performance, you might consider making getList1 or getList2 parallel, depending on how evenly work is split for a/b/c values.
How can I write an algorithm that determines if a function f from the finite set A to the finite set B is an onto function.
This is what I have so far:
A: array ( members of set A )
B: array ( members of set B )
Mapped: associative array of Boolean variables.
for each b in B:
Mapped[b] = false
for each a in A:
Mapped[f(a)] = true
Onto = true;
for each b in B:
Onto = Onto AND Mapped[b]
return Onto
Is this correct?
Yeah, that'll work. A potentially easier approach would be
for each a in A:
remove f(a) from B
return (is B empty?)
And then of course you should sort B first, so you can remove more quickly.
In Python
def cross(A, B):
"Cross product of elements in A and elements in B."
return [a+b for a in A for b in B]
returns an one-dimensional array if you call it with two arrays (or strings).
But in CoffeeScript
cross = (A, B) -> (a+b for a in A for b in B)
returns a two-dimensional array.
Do you think it's by design in CoffeeScript or is it a bug?
How do I flatten arrays in CoffeScript?
First I would say say that 2 array comprehensions in line is not a very maintainable pattern. So lets break it down a little.
cross = (A, B) ->
for a in A
for b in B
a+b
alert JSON.stringify(cross [1,2], [3,4])
What's happening here is that the inner creates a closure, which has its own comprehension collector. So it runs all the b's, then returns the results as an array which gets pushed onto the parent comprehension result collector. You are sort of expecting a return value from an inner loop, which is a bit funky.
Instead I would simply collect the results myself.
cross = (A, B) ->
results = []
for a in A
for b in B
results.push a + b
results
alert JSON.stringify(cross [1,2], [3,4])
Or if you still wanted to do some crazy comprehension magic:
cross = (A, B) ->
results = []
results = results.concat a+b for b in B for a in A
results
alert JSON.stringify(cross [1,2], [3,4])
Whether this is a bug in CS or not is a bit debatable, I suppose. But I would argue it's good practice to do more explicit comprehension result handling when dealing with nested iterators.
https://github.com/jashkenas/coffee-script/issues/1191