4

Here is a simple test function

test[n_] :=
  Module[{i = 0}, Total[Nest[{++i, #}&, {0}, n], -1]]

On my system V9.0.1 running OS X 10.6.8 and with a clean kernel, the following works

Timing[test[26198]]

{0.106564, 343180701}

but then immediately evaluating 

Timing[test[26199]]

fails. I get a beep and Help > Why the Beep?... shows

alert.png

Can anybody verify this on another system different from mine? Can you cast any light on why it happens? I will submit a bug report to WRI if this is not just peculiar to my system.

m_goldberg
  • 107,779
  • 16
  • 103
  • 257
  • Both work fine here: mac os 10.9, Mathematica 9.01. – bill s Nov 16 '13 at 03:46
  • @bills. Could you try a really large number, say 10^6? – m_goldberg Nov 16 '13 at 03:53
  • I confirm this behavior in Mathematica 8.0.4 under Windows 7 x64: Timing[test[261990]] crashes the kernel. – Alexey Popkov Nov 16 '13 at 05:05
  • Crashes 8.0.4 Linux 64bit – ssch Nov 16 '13 at 11:31
  • 1
    Crashes without Timing too, but the number at which it crashes varies a bit. test[21820] crashes sometimes, but if it doesn't crash on first-run it can be evaluated seemingly endless amount of times without crashing. – ssch Nov 16 '13 at 12:41
  • I tested for all the numbers mentioned, it works. In my system, Windows 8 (64 bits), it seems to work up to 174657. – Hector Nov 16 '13 at 14:49
  • I tried test[n_] := Module[{i = 0}, Total[y = Nest[{++i, #} &, {0}, n], -1]];test[174657];y and it results in "$RecursionLimit::reclim". – Hector Nov 16 '13 at 14:58
  • 4
    You are blowing up the subroutine stack. Whether this is a consequence of evaluation semantics, or vagary of (mis?)implementation of Nest, I do not know. – Daniel Lichtblau Nov 16 '13 at 23:27
  • @DanielLichtblau. Thanks for your insight. Should I report this to WRI tech support? – m_goldberg Nov 16 '13 at 23:33
  • 1
    You can submit it. But the fact is I do not know at this time whether it is a bug or a fact of evaluation semantics. If the latter, there won't be much to be done about it. Time permitting, I hope to look into that next week. – Daniel Lichtblau Nov 16 '13 at 23:42
  • As ssch mentioned it doesn't seem to be related to the Timing at all, so you might want to change that in your question and title... – Albert Retey Nov 17 '13 at 13:32
  • @AlbertRetey. No, because I love the alliteration. – m_goldberg Nov 17 '13 at 13:35
  • @AlbertRetey Also with Timing we have rhyming. – Daniel Lichtblau Nov 20 '13 at 17:46
  • 2
    I looked some more. The issue is that Total is implemented by recursion. This could be done differently (many things could be done differently...) and I imagine a suggestion will be, or has been, filed to this effect. Not sure if/when it might be acted upon. I'd suggest using Flatten first since that one is not done by recursion (not since version 3.0, at any rate). – Daniel Lichtblau Nov 20 '13 at 17:48
  • @m_goldberg and daniel: OK, I understand that my priorities are not shared by the majority :-) – Albert Retey Nov 20 '13 at 23:56

1 Answers1

2

I reported my problem to Wolfram Research technical support. Here is a slightly edited version of the reply I received.

... I tried the same command with larger value[s] of n and the crash could be reproduced with Total applied. Indeed, this number seems to be system dependent. I tested it on several different machines and got different thresholds of n.

...

Regarding this, I will file a report so the developer who is responsible for the function Total will notice the issue.

I think this issue can be marked with .

Community
  • 1
m_goldberg
  • 107,779
  • 16
  • 103
  • 257