Back transformed Median of log normal data, not equal to median of original data l was working with these data:
160,320,160,160,320,320,160,320,160,320,160,320.
I needed to calculate the median so decided to calculate while the data was log transformed and I would just back transform for the median of the original data.
However, this wasn't the case for this dataset: the log transformed median is 5.421747, which back transforms to 226.2742, while the median of the original data is 240.
I had to do this to 30-odd datasets and it only happened in this one. I know that I  am getting something wrong when adding the two mid-points and dividing by 2.
 A: In principle, median(log()) yields the same as log(median()). As @Henry rightly comments, there is no issue here with any sample with an odd number of values, as the median is then the middlemost value and its logarithm is both the median of the logarithms and the logarithm of the median on the original scale.
In practice, the issue may arise if you have an even number of values. You have here $6$ values of $160$ and $6$ of $320$ and hence an even number of values. So, you're using (or your software is using) the arithmetic mean of the two co-medians (*), here $160$ and $320$, as a conventional rule for the median of an even number of values.
For consistency with working on logarithmic scale you would need to use the geometric mean of the co-medians, namely here $\root \of {160 \times 320}$, which is indeed $226.2742$ to the same number of decimal places as in your question.
Let's suppose that you have an even number of values, so that after sorting the median is to be calculated from the co-medians $x_{(n/2)}$ and $x_{(n/2 + 1)}$. Then you won't notice a difference between arithmetic and geometric means if those two values are identical, but you should notice a difference otherwise.
(*) Co-medians as a term for the two middle values in a sample with an even number of values was an independent suggestion of Stephen M. Stigler and Roger Koenker.
