Timeline for Machine-precision numbers cause loss of precision
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 14, 2020 at 14:18 | comment | added | Bob Hanlon | @qthana - The code that I posted in my comment does not produce any negative values. Values from code with known precision-induced errors are by definition meaningless. | |
| Jun 14, 2020 at 14:05 | comment | added | q than a | How the negative values appear after zeros ? @MarcoB | |
| Jun 14, 2020 at 14:03 | comment | added | q than a | How those negative values appear ? @BobHanlon | |
| Jun 13, 2020 at 17:23 | answer | added | Michael E2 | timeline score: 3 | |
| Jun 13, 2020 at 16:51 | comment | added | Bob Hanlon |
Calculate with arbitrary-precision then convert to machine precision for display. Look at Table[ Nest[Mod[2 #, 1] &, FractionalPart[Pi], n], {n, 100}] // N[#, 20] & // N
|
|
| Jun 13, 2020 at 15:22 | history | edited | MarcoB | CC BY-SA 4.0 |
Formatted code, altered title, tags
|
| Jun 13, 2020 at 15:18 | comment | added | MarcoB |
As as aside, your Table[Nest[...], {n, 100}] expression is functionally equivalent to NestList[Mod[2#, 1]&, FractionalPart[Pi], 100]. The only difference is the fact that the latter expression includes your starting value; if you really don’t want that, you can use Rest@NestList[...].
|
|
| Jun 13, 2020 at 15:14 | comment | added | MarcoB | As you said, because In your second example you are working with machine precision numbers instead of arbitrary precision. The very small values close to zero In the middle of your run are rounded to zero at machine precision, but they retain their value at arbitrary precision. | |
| Jun 13, 2020 at 14:24 | history | asked | q than a | CC BY-SA 4.0 |