From df7653e2ea8f5a451cb02df0fb2a418d2fcc6e00 Mon Sep 17 00:00:00 2001 From: Ralf Gommers Date: Sat, 14 Nov 2020 16:51:56 +0000 Subject: [PATCH] Update mutability example Closes gh-82 --- spec/design_topics/copies_views_and_mutation.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/spec/design_topics/copies_views_and_mutation.md b/spec/design_topics/copies_views_and_mutation.md index cc48508a2..1911718b7 100644 --- a/spec/design_topics/copies_views_and_mutation.md +++ b/spec/design_topics/copies_views_and_mutation.md @@ -12,14 +12,13 @@ This simple example illustrates that: ```python x = ones(1) -x += 2 -y = x # `y` *may* be a view +y = x[:] # `y` *may* be a view on the data of `x` y -= 1 # if `y` is a view, this modifies `x` ``` Code as simple as the above example will not be portable between array -libraries - for NumPy/PyTorch/CuPy/MXNet `x` will contain the value `2`, -while for TensorFlow/JAX/Dask it will contain the value `3`. The combination +libraries - for NumPy/PyTorch/CuPy/MXNet `x` will contain the value `0`, +while for TensorFlow/JAX/Dask it will contain the value `1`. The combination of views and mutability is fundamentally problematic here if the goal is to be able to write code with unambiguous semantics.