I have a badly structured data and I need to clean it up, suppose I have the following list:

l={{"a","b","c"},{"e"," f","g"},{" a"," b"}}

As you can see they are string, yet some are having an extra Space, instead of being "a" for example it is " a" I was wondering how one deletes those extra spaces to achieve the right format of data. I have tried StringTrim[] but it seems it does not work on a list?

  • 3
    Map[StringTrim, l, {-1}] – Kuba Jul 27 at 14:08
  • 3
    StringTrim/@l ?? – murray Jul 27 at 14:10
up vote 6 down vote accepted
StringReplace[#, " " -> ""] & /@ l

{{"a", "b", "c"}, {"e", "f", "g"}, {"a", "b"}}

With a larger string list

l = With[
   {size = 100},
   MapAt[
    StringJoin[" ", #, " "] &,
    RandomChoice[CharacterRange["a", "z"], {size, size}],
    RandomInteger[{1, size}, {size, 2}]
    ]];

My own

First@RepeatedTiming[ 
  StringDelete[" "] /@ l
  ]
(* 0.000750 *)

@murray

First@RepeatedTiming[ 
  StringTrim /@ l
  ]
(* 0.00497 *)

@Coolwater

First@RepeatedTiming[
  StringReplace[#, " " -> ""] & /@ l
  ]
(* 0.000801 *)

@Coolwater operator mode

First@RepeatedTiming[
  StringReplace[" " -> ""] /@ l
  ]
(* 0.000757 *)

@Kuba

First@RepeatedTiming[
  Map[StringTrim, l, {-1}]
  ]
(* 0.0482 *)
  • 1
    Interestingly, I found ParallelMap is much slower than Map (3 - 18x slower) for all except the last command (where it was 2x faster). I didn't play with the coarseness options. [Since I was using Parallelize, I benchmarked using wall clock (with AbsoluteTime[]), and a single run with size = 2000, rather than RepeatedTiming with size = 100.] – theorist Jul 27 at 17:55
  • 1
    @theorist RepeatedTiming is supposed to be more reliable. Sometimes a particular calculation slows down because the OS may be doing unrelated stuff, and you want to remove the outliers, but I agree that I chose an unnecessarily small number for the data size. – rhermans Jul 27 at 17:58
  • Need to confirm RepeatedTiming uses wall clock rather than CPU time, since the former is needed to get meaningful comparisons when parallelizing; found it does :). I then repeated the comparison using RepeatedTiming, with size = 100, using a 5-second duration to improve accuracy. I found ParallelMap took longer, for the above commands, by factors of 21, 3.5, 19, 21, and 1.3, respectively—roughly the same results I got with a single run of size = 2000 with AbsoluteTiming, except for the last command, which was also now slower with ParallelMap (perhaps b/c of the diff. in size). – theorist Jul 27 at 18:47

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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