The characteristics of the null value have rather routinely introduced
errors in programs because of its non-intuitive characteristics.
It seems clear why we should want null -- null allows for lazy problem
specification, allowing the designer to not specify some data
elements. But correct handling of null has proven to be a rather
mysterious subject.
--
Raul
On Tue, Feb 8, 2022 at 10:32 AM 'Pascal Jasmin' via Programming
<programm...@jsoftware.com> wrote:
>
> for numeric data _. is safest, but can __ be assumed as a "non natural" value
> in a dictionary?
> for non numeric data, i.0 ('') or a: is null.
>
> The only easy approach is to filter x argument to { for "out of range"
> indexes, and only return values that have keys.
>
> A missing feature of !. (fit) is that it does not modify { with fill. (index
> out of range could result in fills instead of error)
>
> !. could also modify any f such that if rank of x or y is greater than the
> rank of f then x f!.n y provides a fill of n. and f!.(_.;'';a:) could
> attempt item fills in left to right order until there is no error from that
> type of fill.
>
> The "easy approach" seems to make sense for multiple key get request. If you
> are worried about any individidual key being missing, then you should pass
> each key to get one at a time and then in the context of that specific key
> deal with null/not found on individual basis. If you get on multiple keys,
> you do not want to scan the return list for _. or nulls. Multiple key get
> can be used as ORkey = use first key that was found. Use # to see if some
> keys were missing (AND(all)keys). Multi-key get returns a list of "context
> free" values, and so should work "the easy way". Alternatives include
> individual key get/processing, and filter by key list to get a new dictionary
> with only the keys found.
>
> Filtering x for in range, means that all keynotfound get calls return i.0
> regardless of type of values. (on single key get, or multi-key where all
> keys passed are not found) Many/most J functions deal elegantly with i.0 as
> an argument.
>
>
>
>
>
>
>
> On Tuesday, February 8, 2022, 08:54:28 a.m. EST, Hauke Rehr
> <hauke.r...@uni-jena.de> wrote:
>
>
>
>
>
> Where “null” is specified as _. right?
>
> Am 08.02.22 um 05:27 schrieb 'Pascal Jasmin' via Programming:
> > set function is a combination of JP's set or delete functionality with
> > k/q's upsert, with "merge" oriented optimizations for bulk oriented
> > upserts. To get JP's upsert or delete functionality, whenever value is
> > null, delete is performed. This corresponds to keyhasnullvalue get kvdata
> > returns the same when k is not found or associated value is null, and so
> > (key;a:) set kvdata provides the same results if key is deleted as if it
> > were associated with null.
>
> --
> ----------------------
> mail written using NEO
> neo-layout.org
>
> ----------------------------------------------------------------------
> 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
