J can not answer whether a certain text string already exists in nouns or global symbol directly. To test, J creates a new symbol and add it into symbol table (a binary tree). Because hash or index of slot table can collide, it takes a number of comparison of strings in global symbol table with the new string in order to find the match or confirm the absence. Note that even for the absence, the symbol will always be added to global symbol table. If the hash algorithm is poor, a contrived example would be hash always be the same for all strings, symbol can still work, but number of query will be insanely large and extremely poor performance.
3!:1/3!:3 are intended to be reversible, if symbols have been dereference in 3!:1 and sent to another j session, then it can not be recovered to the same symbol index. On 19 Mar, 2017 11:33 pm, "'Pascal Jasmin' via Programming" < [email protected]> wrote: > > > Assuming that this comes with some improvement for s: then it would be > easy to favour that improvement. > > things not to like about a global symbol table is that every typo is > included, and any "app"/set that is loaded joins that table. AFAIU, > Corruption happens if you create symbols, and then restore a table with > 10&s:, and so any application that relies on 10&s: can crash another > previously "loaded application" > > > A problem is that 3!:1, or 3!:3 anyway, seems to just store indexes for > symbols, which relies on 10 s: for actual persistence. > > A suggestion for 3!:1 of symbols would be to scan the array containing > symbols for null (\0), then store 2&s: if not included, or 5&s: if there is > a \0. AFAIU, utf8 is safe to not include 0 as an extended byte. > > An alternative to 5&s: would be a new 8&s: where "data nulls" are encodes > similar to embedded ' in strings. double nullchars encode a data > nullchar. single nullchar encodes terminating 2&s: nullchar. This format > c/would be used for 3!:1. 2&s: could be modified to be the 8&s: proposal. > > 10&s: could store in this new format for portability. But the problem of > previously assigned symbols in session persists, and so a locale level > symbol table would make the most sense for robustness. Also, an > "application"/locale that just uses `true`false symbols (bad example but > replace with small set of enums), would (presumably) be faster if it didn't > share a symbol table with a very large symbol array principally used to > avoid string fills. > > > A question about symbols/3!:1... the documentation suggests that indexes > are limited to 32bit values. Is that true for j64 too? Query (new) and > query (old) is not completely clear in documentation either, and does that > differ from i. or e. ? > > > > ________________________________ > From: Henry Rich <[email protected]> > To: Programming forum <[email protected]> > Sent: Sunday, March 19, 2017 12:14 AM > Subject: [Jprogramming] Show cause hearing - (10 s: y) > > > > Does anyone use (10 s: y)? > > > It is problematic in that the hash table (0 s: 4) may depend on the CPU > > and the J release level. > > > I would rather decommit (10 s: y) and have the user reload the symbol > > table de novo. Any objections? > > > Henry Rich > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
