Inconsistent behaviour with each and peach in KDB - kdb

As a minimal example, for instance if I have:
q) x:flip `a`b!(enlist 1;enlist 2);
q) y:flip `c`d!(enlist 3;enlist 4);
q) (raze x), (raze y)
`a`b`c`d!1j 2j 3j 4j # works as expected
But with peach involved,
q) {(raze x), (raze y)} peach x
enlist 1j 2j # I was expecting `a`b`c`d!1j 2j 3j 4j
There is no 3j 4j in the output - why has my raze y been ignored?
Indeed, each also gives a different output
q) {(raze x), (raze y)} each x
({:(raze x), (raze y);}';flip `a`b!(enlist 1j;enlist 2j))
I thought peach was just a parallel version of each, so both should yield the same...
What's going on?

That was not an inconsistent behavior of peach and each.
First, Functions in kdb has implicit parameters as x,y,z if not specified any.
So f:{x+y} is equivalent to f:{[x;y] x+y}
But f:{[a;b] a+b} will not have x,y,z as implicit parameter
For more details, see section Implicit Parameters in http://code.kx.com/q4m3/6_Functions/#617-implicit-parameters
Peach Case:
When you do {(raze x), (raze y)} peach x :
i) Another way of writing this function is:
f:{[x;y] (raze x),(raze y)}
And call is like: f[;] peach x
So you are passing global x to local x of a function but nothing in y, that's why you are getting only 1 and 2 and not 3 &4 in output.
ii) Why only 1 and 2 and not ab!1 2 in output?
When you pass each row of table (x in your case) to a function, it goes in form of a dictionary. And raze on dictionary gives only values.
You have to modify your function for correct working like this(Use Each Both ):
flip {x,y}' [x;y]
' is each both which is used when you have more then one arguments and you want to apply each on all of them simultaneoulsy.
This will take one row at a time from both global x and y and copy it to local x and y in dictionary form and then join them.
Each Case:
Each is just giving you message that your function requires 2 arguments and hence it couldn't execute it.
Why Peach worked and Each didn't?
Peach and Each are not same for some scenarios.
When you have dyadic function, then peach works like each prior(':) and not as Each.
They are same only for monadic functions. In your case you have dyadic function.

x and y can be implicit arguments to a function. Your use of x and y for the name of the list variables is confusing and not recommended.
To make it clear what is happening consider if I renamed the variables a,b:
q)a:flip `a`b!(enlist 1;enlist 2);
q)b:flip `c`d!(enlist 3;enlist 4);
q)(raze a), (raze b)
a| 1
b| 2
c| 3
d| 4
q){(raze a), (raze b)} peach x
a b c d
-------
1 2 3 4
You can see how peach/each handle the implicit function arguments with this example:
q)x:x
q)y:y
q){(x;y)} each 1
{(x;y)}'[1]
q){(x;y)} peach 1
1
I can't tell for sure what behaviour you want so all I can do is point out why there's an issue.

Related

Ungroup a dictionary

Suppose the parent vector p is defined as list where each element is a pointer to the position index of the parent of the given item in the same vector.
Then children of each parent can be found as:
q) c:group p:0N 0 1 0 2
| ,0
0| 1 3
1| ,2
2| ,4
If c is given, what is the efficient way to flatten children dictionary c back to the parent vector p?
Obviously ungroup does not work on dictionaries directly:
q) ungroup c
'type
But we can ungroup tables:
q) {#[;`k] `v xasc ungroup ([]k:key x;v:value x)} c
0N 0 1 0 2
Is there more efficient solution how to get p given c ?
There is no native q command for the type of ungroup you're looking for.
One option that may be useful is the following function:
invgroup:{key[x]#[raze x;value x;:;til count x]}
Effectively what this does is, returns the values of the group dictionary as a single list (raze x), indexes into this list at each set of associated indices (value x) and assigns these the correct index from the original list.
Then we use these indices to index into the distinct values of the original list (key x) to pull out the original list
p ~ invgroup group p:0N 0 1 0 2
1b
Simple solution is:
q) #[raze c;value c;:;key c]
q) 0N 0 1 0 2

How to know which Maple command automatically maps on list entries or not?

In Mathematica, almost all commands automatically thread (or map) over a list.
In Maple, how does one determine which command automatically acts over entries of a list or a set?
For example:
y+p*x=2*sqrt(x*y);
r:=[solve(%,y)];
This gives list of two entries (the solutions)
#r := [-p*x+(2*(1+sqrt(1-p)))*x, -p*x+(2*(1-sqrt(1-p)))*x]
Now I found that collect automatically maps on each list entry
collect(r,x);
# [(-p+2+2*sqrt(1-p))*x, (-p+2-2*sqrt(1-p))*x]
But another command does not (I just picked this one)
MmaTranslator[Mma][LeafCount](r);
#37
For the above one needs to explicitly iterate over the entries of a list or a set.
map(MmaTranslator[Mma][LeafCount],r)
#[17, 19]
Is there a way in Maple to find which command automatically threads over entries of a list or a set other than trial and error?
Maple 2018.1
I don't know of any place in the documentation that says exactly which commands will automatically map over a list.
But the collection of such commands is not large. The vast majority of commands will not automatically map over a list. Most of the ones which auto-map over a list relate to simplication or related manipulation of expressions. The collection of commands which auto-map over a list contains at least these:
collect, combine, expand,
evala, evalc, evalf,
factor, normal, radnormal, rationalize, simplify
The auto-mapping over lists for those commands is mostly a convenience to provide a shorter syntax than wrapping explicitly with the map command.
There are also commands which preserve structure (unless explicitly
told, via options, that the outer list structure is the thing to alter) and thus usually accomplish the same thing for a list as mapping over the list:
convert, eval, evalindets, subs, subsindets
Modern Maple has another shorter syntax which can map a command over a list (or a set, or a Vector, etc). It is called the "elementwise" operation, and its syntax consists of appending ~ (tilde) to the command.
Eg,
discont~( [ csc(x), sec(x) ], x );
[{Pi _Z1~}, {Pi _Z2~ + 1/2 Pi}]
As far as your other example goes, note that LeafCount computes a value (metric) for the first argument considered as a single expression. But a list of items is still a single expression. So it certainly should not be surprising that (without the ~) it acts on the list as a whole, rather than automatically mapping over it. It counts the enclosing list as an additional "leaf".
MmaTranslator:-Mma:-LeafCount( L0 );
8
L0 := [ sin(x), 1/2*x*cos(x) ]:
MmaTranslator:-Mma:-LeafCount~( L0 );
[2, 5]
map( MmaTranslator:-Mma:-LeafCount, L0 );
[2, 5]
For an example similar to your original there is no difference in applying collect (which auto-maps) and applying it elementwise with collect~. Here, the first two results are the same because the addtional argument, x, happens to be a scalar. Eg,
r := [p*x+(2*(x^2+p^2))*x, p*x+(2*(x^2-p^2))*x]:
collect(r, x);
3 2 3 2
[2 x + (2 p + p) x, 2 x + (-2 p + p) x]
collect~(r, x);
3 2 3 2
[2 x + (2 p + p) x, 2 x + (-2 p + p) x]
map(collect, r, x);
3 2 3 2
[2 x + (2 p + p) x, 2 x + (-2 p + p) x]
I should mention that the above examples will behave differently if the second argument is a list such as [x,p] rather than a scalar such as x.
s := [a*b+(2*(a^2*b+b^2))*a, a*b+(2*(a^2*b-b^2))*a]:
collect(s, [a,b]);
3 2 3 2
[2 b a + (2 b + b) a, 2 b a + (-2 b + b) a]
map(collect, s, [a,b]);
3 2 3 2
[2 b a + (2 b + b) a, 2 b a + (-2 b + b) a]
collect~(s, [a,b]);
3 2 2 3
[2 b a + (2 b + b) a, -2 a b + (2 a + a) b]
zip(collect, s, [a,b]);
3 2 2 3
[2 b a + (2 b + b) a, -2 a b + (2 a + a) b]
In the above, the elementiwise collect~ example acts like zip when the second argument is also a list. That is, the first item in the first argument is collected wrt the first item in the second argument, and the second item in the first argument is collected wrt to the second item in the second argument.
Another feature of the elementwise operator syntax is that it will not map the command over the operands of a scalar expression (ie. not a list, set, Vector, etc). This is in stark contrast to map, which can be used to map an operation over the operands of an expression.
Here are two examples where map applies the command to the operands of a scalar expression, while using elementwise ~ gets the command applied only to the scalar expression itself. In the first example the operands are the summands of a sum of terms. In the second example the operands are the arguments of an unevaluated function call.
T := x^2 * sin(x) + y^2 * cos(x):
F( T );
2 2
F(x sin(x) + y cos(x))
F~( T );
2 2
F(x sin(x) + y cos(x))
map( F, T );
2 2
F(x sin(x)) + F(y cos(x))
G( arctan(a, b) );
G(arctan(a, b))
G~( arctan(a, b) );
G(arctan(a, b))
map( G, arctan(a, b) );
arctan(G(a), G(b))
So, if you don't want to map a command inadvertantly over the operands of a scalar expression (addend, multiplicands, etc) then you can use the elementwise ~ syntax without having to first test whether the first expression is a scalar or a list (etc).
Again, if there is an additional argument then it makes a difference whether it is a scalar to a list.
F( T, a );
F(sin(x) + cos(x), a)
F~( T, a );
F(sin(x) + cos(x), a)
map( F, T, a );
F(sin(x), a) + F(cos(x), a)
F( T, [a,b] );
F(sin(x) + cos(x), [a, b])
map( F, T, [a,b] );
F(sin(x), [a, b]) + F(cos(x), [a, b])
F~( T, [a,b] );
[F(sin(x) + cos(x), a), F(sin(x) + cos(x), b)]
zip( F, T, [a,b] );
[F(sin(x) + cos(x), a), F(sin(x) + cos(x), b)]

Is is possible to implement a user-defined operator in MATLAB? [duplicate]

This question already has answers here:
Any way to accomplish i++ in matlab?
(2 answers)
Closed 9 years ago.
I am wondering if it is possible to create my own operators in MATLAB 2013a.
As an example, say that I want to define a new operator === to check if all of the elements between two matrices are equal. In this case,
x = ones(10,1);
y = ones(10,1);
z = 2*ones(10,1);
all(x==y) = 1
x===y = 0
all(z==y) = 0
z===y =0
Would it be possible to implement something like this? If so, how can I go about it?
[taken from a previous answer of mine]
Try using operator. It is used to define new user-defined operator symbols or to delete them (you will need the symbolic toolbox though).
operator(symb, f, T, prio) defines a new operator symbol symb of type T (Prefix | Postfix | Binary | Nary) with priority prio. The function f evaluates expressions using the new operator.
Given the operator symbol "++", say, with evaluating function f, the following expressions are built by the parser, depending on the type of the operator, where :
Prefix: The input ++x results in f(x).
Postfix: The input x++ results in f(x).
Binary: The input x ++ y ++ z results in f(f(x, y), z).
Nary: The input x ++ y ++ z results in f(x, y, z)).
see more at matlab's documentation.

How to divide a pair of Num values?

Here is a function that takes a pair of Integral
values and divides them:
divide_v1 :: Integral a => (a, a) -> a
divide_v1 (m, n) = (m + n) `div` 2
I invoke the function with a pair of Integral
values and it works as expected:
divide_v1 (1, 3)
Great. That's perfect if my numbers are always Integrals.
Here is a function that takes a pair of Fractional
values and divides them:
divide_v2 :: Fractional a => (a, a) -> a
divide_v2 (m, n) = (m + n) / 2
I invoke the function with a pair of Fractional
values and it works as expected:
divide_v2 (1.0, 3.0)
Great. That's perfect if my numbers are always Fractionals.
I would like a function that works regardless of whether the
numbers are Integrals or Fractionals:
divide_v3 :: Num a => (a, a) -> a
divide_v3 (m, n) = (m + n) ___ 2
What operator do I use for _?
To expand on what AndrewC said, div doesn't have the same properties that / does. For example, in maths, if a divided by b = c, then c times b == a. When working with types like Double and Float, the operations / and * satisfy this property (to the extent that the accuracy of the type allows). But when using div with Ints, the property doesn't hold true. 5 div 3 = 1, but 1*3 /= 5! So if you want to use the same "divide operation" for a variety of numeric types, you need to think about how you want it to behave. Also, you almost certainly wouldn't want to use the same operator /, because that would be misleading.
If you want your "divide operation" to return the same type as its operands, here's one way to accomplish that:
class Divideable a where
mydiv :: a -> a -> a
instance Divideable Int where
mydiv = div
instance Divideable Double where
mydiv = (/)
In GHCi, it looks like this:
λ> 5 `mydiv` 3 :: Int
1
λ> 5 `mydiv` 3 :: Double
1.6666666666666667
λ> 5.0 `mydiv` 3.0 :: Double
1.6666666666666667
On the other hand, if you want to do "true" division, you would need to convert the integral types like this:
class Divideable2 a where
mydiv2 :: a -> a -> Double
instance Divideable2 Int where
mydiv2 a b = fromIntegral a / fromIntegral b
instance Divideable2 Double where
mydiv2 = (/)
In GHCi, this gives:
λ> 5 `mydiv2` 3
1.6666666666666667
λ> 5.0 `mydiv2` 3.0
1.6666666666666667
I think you are looking for Associated Types which allows for implicit type coercion and are explained quite nicely here. Below is an example for the addition of doubles and integers.
class Add a b where
type SumTy a b
add :: a -> b -> SumTy a b
instance Add Integer Double where
type SumTy Integer Double = Double
add x y = fromIntegral x + y
instance Add Double Integer where
type SumTy Double Integer = Double
add x y = x + fromIntegral y
instance (Num a) => Add a a where
type SumTy a a = a
add x y = x + y

Why does fold left expect (a -> b -> a) instead of (b -> a -> a)?

I wonder why the function expected by fold left has type signature a -> b -> a instead of b -> a -> a. Is there a design decision behind this?
In Haskell, for example, I have to write foldl (\xs x -> x:xs) [] xs to reverse a list instead of the shorter foldl (:) [] xs (which would be possible with b -> a -> a). On the other hand, there are use cases which require the standard a -> b -> a. In Scala, this could be appending: xs.foldLeft(List.empty[Int]) ((xs, x) => xs:+x) which can be written as xs.foldLeft(List.empty[Int]) (_:+_).
Do proportionately more use cases occur requiring the given type signature instead of the alternative one, or are there other decisions which led to the design that fold left has in Haskell and Scala (and probably lots of other languages)?
Conceptually speaking, a right fold, say foldr f z [1..4] replaces a list of the following form
:
/ \
1 :
/ \
2 :
/ \
3 :
/ \
4 []
with the value of an expression of the following form
f
/ \
1 f
/ \
2 f
/ \
3 f
/ \
4 z
If we were to represent this expression on a single line, all parentheses would associate to the right, hence the name right fold: (1 `f` (2 `f` (3 `f` (4 `f` z)))). A left fold is dual in some sense to a right fold. In particular, we would like for the shape of the corresponding diagram for a left fold to be a mirror image of that for a left fold, as in the following:
f
/ \
f 4
/ \
f 3
/ \
f 2
/ \
z 1
If we were to write out this diagram on a single line, we would get an expression where all parentheses associate to the left, which jibes well with the name of a left fold:
((((z `f` 1) `f` 2) `f` 3) `f` 4)
But notice that in this mirror diagram, the recursive result of the fold is fed to f as the first argument, while each element of the list is fed as the second argument, ie the arguments are fed to f in reverse order compared to right folds.
The type signature is foldl :: (a -> b -> a) -> a -> [b] -> a; it's natural for the combining function to have the initial value on the left, because that's the way it combines with the elements of the list. Similarly, you'll notice foldr has it the other way round. The complication in your definition of reverse is because you're using a lambda expression where flip would have been nicer: foldl (flip (:)) [] xs, which also has the pleasant similarity between the concepts of flip and reverse.
Because you write (a /: bs) for foldLeft in short form; this is an operator which pushes a through all the bs, so it is natural to write the function the same way (i.e. (A,B) => A). Note that foldRight does it in the other order.
Say you have this:
List(4, 2, 1).foldLeft(8)(_ / _)
That's the same as:
((8 / 4) / 2) / 1
See how the first parameter is always te accumulator? Having the parameters in this order makes placeholder syntax (the underscore) a direct translation to the expanded expression.