3
$\begingroup$

In 11.1, a Dataset consisting of an Association with composite keys with an Infinity causes failure in keying-in:

as = {{-\[Infinity], 0}, {0, 1}, {1, 2}, {3, \[Infinity]}} -> 
   Table[<|"a" -> RandomReal[]|>, {4}] // AssociationThread 

This works:

as // Key[{0, 1}]

<|"a" -> 0.701279|>

But not in Dataset:

Dataset[as][ Key[{0, 1}]]

Failure[[WarningSign] Message: Key Key[{0, 1}] is not one of {1, 2, 3, 4}.Tag: Dataset]

Yet pre-filtering out at least one Key containing an Infinity works, eg 1st infinity out:

Dataset[as // Query[(;; 3)]][ Key[{0, 1}]]

<|"a" -> 0.701279|> (* when Normal'd *)

Similarly:

Dataset[as // Query[(2 ;;)]][ Key[{0, 1}]]

<|"a" -> 0.701279|>

Yet filtering out as a Dataset query again fails:

Dataset[as][2 ;;][Key[{0, 1}]]

Failure[[WarningSign] Message: Key Key[{0, 1}] is not one of {}. Tag: Dataset]

Further showing the kludge nature of Dataset's type system, if the keys are Quantities:

asq = ({{-\[Infinity], 0}, {0, 1}, {1, 2}, {3, \[Infinity]}} // 
     Map[Quantity[#, "Days"] &]) -> 
   Table[<|"a" -> RandomReal[]|>, {4}] // AssociationThread 

<|{-[Infinity]days,0days}-><|a->0.777112|>,{0days,1day}-><|a->0.715397|>,{1day,2days}-><|a->0.5147|>,{3days,[Infinity]days}-><|a->0.635806|>|>

It works:

Dataset[asq][Key[{Quantity[0, "Days"], Quantity[1, "Days"]}]]

<|"a" -> 0.715397|>

Anyone have similar experiences with composite keys failing?

$\endgroup$
  • $\begingroup$ Probably has nothing specifically to do with Infinity. Here is an actual MWE: Dataset[<|{"x",0}-> a,{"y",1}-> b|>][Key[{"x",0}]] $\endgroup$ – chuy Apr 19 '17 at 14:47
  • $\begingroup$ @chuy, good eye, thanks, I hadn't tested variations. $\endgroup$ – alancalvitti Apr 19 '17 at 16:02
4
$\begingroup$

As noted in a comment by @chuy, this problem is not directly related to the use of Infinity. The problem is essentially the same as that reported in (140541): there is a type-inferencing failure when attempting to type-check a part reference. See that question for more discussion on this point.

Analysis (current as of version 11.1.0)

We can reproduce the problem like this:

Dataset[<|{"a", 0} -> 1, {"b", 0} -> 2|>][Key[{"a", 0}]]
(* Failure - Key[{a, 0}] is not one of {1, 2}. *)

As usual, the operation works if we bypass the type system:

<|{"a", 0} -> 1, {"b", 0} -> 2|> // Query[Key[{"a", 0"}]]
(* 1 *)

We can pinpoint the type inferencing failure:

Needs["Dataset`"]
Needs["TypeSystem`"]

Dataset[<|{"a", 0} -> 1, {"b", 0} -> 2|>] // GetType
(* Assoc[Vector[AnyType, 2], Atom[Integer], 2] *)

Query[Key[{"a", 0}]] // Normal
(* GeneralUtilities`Slice[Key[{"a", 0}]] *)

TypeApply[
  GeneralUtilities`Slice[Key[{"a",0}]]
, {Assoc[Vector[AnyType,2],Atom[Integer],2]}
]
(* FailureType[{Part, "Mismatch"}
   , <|"Type" -> Assoc[Vector[AnyType, 2], Atom[Integer], 2], "Part" -> Key[{"a", 0}]|>]
*)

If we look at relevant parts of the trace, we can see that the ultimate failure lies in the internal function SmallConformsQ:

trace display

The expression SmallConformsQ[{x, 0}, Vector[AnyType, 2]] generates a suspicious trace:

trace display

The test Length[2] == {x, 0}] in the last expression is nonsensical and surely the result of a bug.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.