Table modification

Table amend/dmend work mostly the same as for dictionaries. Following example increases the "b" field by 1 for records at positions 0 and 2.

o)a:(+:)`a`b`c!(1 2 3;1 2 3;1 2 3); .[a;(`b;0 2);+;1]
a b c
-----
1 2 1
2 2 2
3 4 3
o)

To create a new integer field of ones, do:

o)a:(+:)`a`b`c!(1 2 3;1 2 3;1 2 3); @[a;`d;:;1]
a b c d
-------
1 1 1 1
2 2 2 1
3 3 3 1
o)

You can also combine primitive function application with creating a new field:

o)a:(+:)`a`b`c!(1 2 3;1 2 3;1 2 3); @[a;`a`b`d;+;1]
a b c d
-------
2 2 1 1
3 3 2 1
4 4 3 1
o)

Multiplication also works:

o)a:(+:)(,`a)!,(1 2 3); @[a;`a`b;*;2]
a b
---
2 2
4 2
6 2
o)

... however, the following code won't work, as interpreter does not try to analyze lambda result types.

o)a:(+:)`a`b`c!(1 2 3;1 2 3;1 2 3); @[a;`a`b`d;{x+y};1]
** runtime error: `amend`:
fields: invalid table field

More complex example shows creating of a new field and vector addition as single amend expression:

o)a:(+:)`a`b`c!(1 2 3;1 2 3;1 2 3); @[a;`a`b`d;+;(4 4 4;1;2)]
a b c d
-------
5 2 1 2
6 3 2 2
7 4 3 2
o)

Version 0.5.0 introduced extra logic to avoid breaking tables.Before it was possible to amend table, changing table field into non-compatible shaped scalars/vectors. That would lead to platform process crashed eventually.

That behaviour was fixed. However that means additional steps:

e.g. following amend is rejected correctly in 0.5.0+

o) a:(+:)`a`b`c!(!3;10+!3;20+!3); 
o) @[`a;`a`b`c;:;(!3;!4;!4)];
** eval error: `amend`:
arguments length mismatch: [field length]

Extra logic for checking new fields is quite heavy on resources, thus it's applied only if verbs used in 3d amend/dmend argument are potentially shape-changing:

That's means, ideally you should avoid making amends/dmends on tables for given verbs if you are for performance/RAM usage.