# How to reset the $ModuleNumber? According to the documentation, we can reset$ModuleNumber to a positive machine integer. There is even an example in the doc:

$ModuleNumber = 17; {Module[{x}, x],$ModuleNumber}

{x$17, 18}  However, when I try evaluating it again and again, instead of keeping 17, the "serial number" after $ increases every time.

I double checked that the $ModuleNumber does get reset at the beginning: $ModuleNumber = 17; {$ModuleNumber, Module[{x}, x],$ModuleNumber}

(* first time evaluation: *){17, x$17, 18} (*secend time evaluation: *){17, x$18, 19}
(* third time evaluation: *){17, x$19, 20}  ...... ... I did the test in 9.0.1 home edition on Windows 8, and also in 10.0 on Raspberry Pi with the same result: It's interesting to notice that using loop to automize the evaluation will NOT increase the number during the loop: Do[ Print[$ModuleNumber = 17;
{$ModuleNumber, Module[{x}, x],$ModuleNumber}
],
{5}]

{17,x$19,20} {17,x$19,20}
{17,x$19,20} {17,x$19,20}
{17,x$19,20}  But $ModuleNumber = 17;
Do[
Print[
{$ModuleNumber, Module[{x}, x],$ModuleNumber}
],
{5}]

{17,x$17,18} {18,x$18,19}
{19,x$19,20} {20,x$20,21}
{21,x$21,22}  So question: Do I misunderstand the documentation? What do I miss? And most importantly, how can I reset the $ModuleNumber so the subsequent Module/Unique will use the "serial number" I specified?

-
When I try it in a loop, the first time I get {x$17, 18}, the second {x$18, 19}, and then back to {x$17, 18} in a loop between the two – Rojo Jan 27 '14 at 0:51 If I put them in separate lines in the same cell, I get always {x$17, 18} –  Rojo Jan 27 '14 at 0:52
@Rojo hmm... what's your OS? I tested on win8, win8.1 and RPi, all get the same result... –  Silvia Jan 27 '14 at 0:54
Don't forget that $ModuleNumber is incremented by anything that uses Unique or Module, including code used by Mathematica itself. It is possible that the predictive interface stuff and other hidden things might be incrementing the counter. – rm -rf Jan 27 '14 at 0:54 From the front end, 9.0.1, W8.0 – Rojo Jan 27 '14 at 0:55 ## 1 Answer I think this is a simple matter. When the code $ModuleNumber = 17;
{$ModuleNumber, Module[{x}, x],$ModuleNumber}


is evaluated the second time, x$17 already exists, but Module must generate a new unique symbol, so it generates the next one in the sequence, x$18. This conclusion is supported by the fact that evaluating the following three lines of code over and over again

Remove[x, "x$*"];$ModuleNumber = 17;
{$ModuleNumber, Module[{x}, x],$ModuleNumber}


will give

{17, x$17, 18}  indefinitely. Because the output of Module[{x}, x] is the local variable, that variable gets associated with Out's downvalues when $HistoryLength is not zero. So, regardless of the $ModuleNumber, Mathematica must skip forward in the local variable naming sequence until an entirely new (not already existing) symbol can be created. - @Silvia he's right – Rojo Jan 27 '14 at 1:50 @Silvia When the output of your module is the variable, the variable get's associated with Out's downvalues if $HistoryLength is not zero. So, regardless of the $ModuleNumber, it gets skipped until a free symbol is found. – Rojo Jan 27 '14 at 1:51 @Silvia my weird behaviour was due to the fact that I had $HistoryLength set to 1 –  Rojo Jan 27 '14 at 1:51
@Rojo Ding ding ding! $HistoryLength is what gave me a different behaviour as well. All's good when you set it to 0. This answer appears to be exactly the reason for the behaviour seen in the OP. One can also demonstrate that Module/Unique will skip a symbol if it already exists in the symbol table (as expected) with x5 = 1;Table[Unique["x"], {10}] (in a new session) – rm -rf Jan 27 '14 at 1:53 @Rojo rm-rf I see! Indeed it's the reason. The documentation warns naming conflicts, and I carelessly misread (well didn't read the whole sentence...) it as I can do intentional naming conflicts by reseting the $ModuleNumber, didn't realize the mechanism for avoiding conflicts is still valid.. Many thanks m_goldberg! I feel so silly... –  Silvia Jan 27 '14 at 2:01