1
$\begingroup$

When one copies an output containing machine-precision numbers to a input, many trailing 0s appears.

For example :

Evaluate the following expression :

{{41.`,19.200000000000003`},
 {41.`,39.5`},
 {33.6`,49.300000000000004`},
 {33.2`,59.800000000000004`}, 
 {33.2`,61.800000000000004`}}

{{41., 19.2}, {41., 39.5}, {33.6, 49.3}, {33.2, 59.8}, {33.2, 61.8}}

Then copy-paste this output. The result is a input cell with again all the trailing 0s.

I need to Round the values so that the input form stays short (It is not a problem of number formatting/rendering since the numerical values can be changed a little bit in this operation).

Tests already done, without success :

First, a preamble that shows that this is possible

niceValue=49.3
niceValue //InputForm  

49.3
49.3

Then, a example of a difficult case :

irritatingValue=49.300000000000004`  
irritatingValue //InputForm  

49.3
49.300000000000004

Unsuccessfull attempts :

This seems to work :

Round[irritatingValue,1. 10^-6] //InputForm

49.3

But this does not :

Round[irritatingValue,1. 10^-5] //InputForm    

49.300000000000004

so the "solution" Round[..., 1. 10^-n] is inacceptable. Because the problem is certainly due to the binary representation of numbers that we see ultimately in base 10, I have tried also things like : Round[..., 256 $MachineEpsilon] and Round[..., 2^-10] , without success.

Chop[...] doesn't seem neither to bring a solution.

$\endgroup$
  • $\begingroup$ What problem are you actually trying to solve? The numbers carrying over the extra 0's in copy pastes? $\endgroup$ – user6014 Oct 27 '18 at 21:27
  • $\begingroup$ Yes. When I copy-paste long list of numbers, the pasted expression is too long, too difficult to read... $\endgroup$ – andre314 Oct 27 '18 at 21:32
  • $\begingroup$ Why not use copy as plain text instead (keyboard shortcut on MacOS is Shift-Cmd-C)? $\endgroup$ – Carl Woll Oct 27 '18 at 23:46
  • $\begingroup$ Your irritating value differs from the closest binary representation of 49.3 by 3 ulp, which I suppose is due to floating-point rounding error, if indeed the result is supposed to be 49.3. If so, it's not because of the limitations of the binary representation of numbers, other than rounding error. Something similar happens with 0.3 vs. 3 * 0.1. $\endgroup$ – Michael E2 Oct 27 '18 at 23:46
  • $\begingroup$ Have you seen this mathematica.stackexchange.com/q/175308/23291 $\endgroup$ – OkkesDulgerci Oct 28 '18 at 2:14
3
$\begingroup$
In[1]:= {{41.`, 19.200000000000003`}, {41.`, 39.5`}, {33.6`, 
  49.300000000000004`}, {33.2`, 59.800000000000004`}, {33.2`, 
  61.800000000000004`}}

Out[1]= {{41., 19.2}, {41., 39.5}, {33.6, 49.3}, {33.2, 59.8}, {33.2, 
  61.8}}

ToString:

In[2]:= ToString@%

Out[2]= "{{41., 19.2}, {41., 39.5}, {33.6, 49.3}, {33.2, 59.8}, \
{33.2, 61.8}}"

ToExpression:

In[3]:= ToExpression@%

Out[3]= {{41., 19.2}, {41., 39.5}, {33.6, 49.3}, {33.2, 59.8}, {33.2, 
  61.8}}
$\endgroup$
  • $\begingroup$ Unexpected approach, but it seems to do the job for my initial problem. Nevertheless, I need to do more tests tomorrow. $\endgroup$ – andre314 Oct 27 '18 at 21:43
  • $\begingroup$ @Carl Woll's suggestion to copy as plain text is valid too. $\endgroup$ – andre314 Oct 28 '18 at 16:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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