On Wed, 4 Dec 2019, Artur Tarassow wrote: > I am bit puzzled why one cannot assign new values to a stringified > series (using current git). Why should be the behavior differently > compared to numerical series? > > <hansl> > set verbose off > nulldata 2 > > series foo = seq(1,2)' > strings s = defarray("A", "B") > stringify(foo, s) > print foo > > series foo = 1 # "Cannot overwrite entire string-valued series </hansl> Well, the intent is to preserve the integrity of such series. We obviously couldn't have anything like series foo = log(foo) and still have a string-valued series.

In the case of assigning a scalar value (that's within the range of the existing encodings) to the entire series, as above, no harm would be done. The question then is whether we just issue a blanket ban on assigning to an entire string-valued series (the case at present), or take the trouble to code an observation-by-observation check on the validity of such an assignment.

We could do the latter but it didn't seem worthwhile to me when we first introduced such series. It wasn't clear to me that there was any real use case -- do you have one?

On Thu, 5 Dec 2019, Artur Tarassow wrote: > Am 04.12.19 um 23:19 schrieb Allin Cottrell: >> On Wed, 4 Dec 2019, Artur Tarassow wrote: >> >>> I am bit puzzled why one cannot assign new values to a stringified >>> series (using current git). Why should be the behavior differently >>> compared to numerical series? >>> >>> <hansl> >>> set verbose off >>> nulldata 2 >>> >>> series foo = seq(1,2)' >>> strings s = defarray("A", "B") >>> stringify(foo, s) >>> print foo >>> >>> series foo = 1 # "Cannot overwrite entire string-valued series >> </hansl> >> >> Well, the intent is to preserve the integrity of such series. We >> obviously couldn't have anything like series foo = log(foo) and still >> have a string-valued series. >> > Ok, I understand this. Thanks. > >> In the case of assigning a scalar value (that's within the range of >> the existing encodings) to the entire series, as above, no harm would >> be done. >> >> The question then is whether we just issue a blanket ban on assigning >> to an entire string-valued series (the case at present), or take the >> trouble to code an observation-by-observation check on the validity >> of such an assignment. > > What about a compromise that for a string-valued series one cannot > change separate entries but assigning a complete new value, e.g. by > doing <series foo = 1>, is allowed?  I was think of something like: > > <> > series y = normal() > series foo = seq(1,2)' > strings s = defarray("A", "B") > stringify(foo, s) > > foo[1] = "C"       # not allowed > series foo = 99    # allowed > series foo = y     # allowed as y is of same length as foo > </> That's the opposite of what we have now: please take a look at chapter 15 of the Guide on string-valued series, especially section 15.3. The guiding ideas are that (a) a string-valued series (internally) is an integer-valued encoding of a set of strings, and (b) once a given series is string-valued it should stay that way. From that perspective "series foo = y", where foo is supposed to be string-valued and y = normal() cannot possibly work. It's fairly easy to check that assignment to an individual observation of a string-valued series works OK, not so easy to check assignment to an entire such series.

>> We could do the latter but it didn't seem worthwhile to me when we >> first introduced such series. It wasn't clear to me that there was >> any real use case -- do you have one? > > I have a really huge panel data set ( > 4GB) and run multiple > estimations by means of a loop-block. Each round I export some list of > series and want to construct a series "foo" holding some > round-specific string value(s). Currently, I need to generate each > round some new series "foo_$i$. > > As deleting a series within a loop-block is also not allowed, I could > not think of an alternative solution to this. I'm not sure I understand the case, but you can use the --force option if you're confident this isn't going to destroy the integrity of the loop: (Sorry, that should be documented!)