4
$\begingroup$

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?

$\endgroup$
2
  • 3
    $\begingroup$ Map[StringTrim, l, {-1}] $\endgroup$
    – Kuba
    Commented Jul 27, 2018 at 14:08
  • 3
    $\begingroup$ StringTrim/@l ?? $\endgroup$
    – murray
    Commented Jul 27, 2018 at 14:10

2 Answers 2

6
$\begingroup$
StringReplace[#, " " -> ""] & /@ l

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

$\endgroup$
5
$\begingroup$

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 *)
$\endgroup$
3
  • 1
    $\begingroup$ 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.] $\endgroup$
    – theorist
    Commented Jul 27, 2018 at 17:55
  • 1
    $\begingroup$ @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. $\endgroup$
    – rhermans
    Commented Jul 27, 2018 at 17:58
  • $\begingroup$ 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). $\endgroup$
    – theorist
    Commented Jul 27, 2018 at 18:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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