Wolfram Mathematica

« first day (2885 days earlier) ← previous day next day → last day (1582 days later) »

3:03 AM

@1010011010 glad to hear it :) usually my solutions are fragile and finicky but I guess even a 80% failure rate has to succeed sometime

11 hours later…

1010011010

2:17 PM

@b3m2a1 Hi]Something stopped working

It's not related to your package I think, it worked last night and now it doesn't

Somehow within wolframscript , the variable $InputFilename is not populated

I am calling an external library now

And I cannot locate the file anymore, it just stopped working completely since last night

I've been working for 5 hours trying to find the error now

I've replaced all NotebookDirectory[] calls to DirectoryName @ $InputFileName

But Print@$InputFileName gives " " a space

I'm praying this is known behaviour

And now 5 min later it works after all that back and forth

Hahaha

Oh dear

Feeds

3:05 PM

Wolfram Blog: From an Hour of Code to a Lifetime of Coding with the Wolfram Language

posted on December 12, 2019 by Ishwarya Vardhani

Happy Hour of Code! There’s no better reason to start learning or continue honing your programming skills than the Hour of Code, an annual celebration of computer science during Computer Science Education Week. While we like to think that every hour is a great hour to code, we look forward to the Hour of Code [...]

1 hour later…

1010011010

4:28 PM

I have one more question

I'm running the wolframscript, and I'm getting this error:

No more memory available.
Mathematica kernel has shut down.
Try quitting other applications and then retry.
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

The code I'm running creates an approximately 400 by 400 array, *but

The code inside each element is super expensive

The above output was from a workstation with 64 gb of ram

16 cores

I'm confused why the error might occur

The code has been tested extensively and works beautifully for softer parameters

I'd like to make sure I have exhausted all options before turning to systems with more ram

kirkus

4:54 PM

@1010011010 got a MWE you could share?

1010011010

5:07 PM

@kirkus I tried this before, but only very large configurations reproduce it

The following highly non minimal - yet working - example is mega.nz/#!GAwG0KDC!h11QxChxYwBqFAfjUcB_bs3ng6kNqIR75LuvWsyyNO4,

I have managed to reproduce the error on the two machines I have access to with the command:

kirkus

@1010011010 so is this pretty much the same code I already ahve?

1010011010

taskset -ca 0-20 wolframscript -f GetConstants.4-11-101-191-198.1-1-1-2-1.10..201.201.wls

It is the code, but in wls format, the front end crashes if the notebook format is used

I have swapped out some of the NotebookDirectory[] calls with DirectoryName @ $InputFileName

I have tested many edge cases so the error is not really related to anything going wrong in the code, or illegal values, indeterminacy etc

So really the high level commands seem to simply overload the system

I believe some explanation is in order with regards to what th code respresents

kirkus

about how long does it take for the above code to barf with the memory error?

1010011010

On the workstation is took 793.550448 seconds

On my laptop erm...

kirkus

haha ok

1010011010

5:19 PM

I can't remember, but certainly in the 15 mins range

That's a 6 core macbook pro 2018

So without going too much into details, the code represents a certain part of the state space of a lattice of 200, I guess "particles", on the line

if the line has dimension $y$, then the configuration is centered about $y=0$,

And each particle has a spacing of $2\pi$

So the numbers 4,11,101,191,198 correspond to locations on this line, where the leftmost particle on the line is labeled "1", "2", etc. until some number, say N

I chose N = 201 in this example

So particle with index N/2 is usually somewhere in the middle of the line

The locations given correspond to holes punched at those locations of the chain

Or, more precisely: centers of small regions of locations

The 1-1-1-2-1 correspon to the magnitude of both direction in which the region extends, in the order of the way the numbers are given, so the "2" here means that we have a region with 5 spots, centered at 191, where "holes in the chain" exist

We only punch one hole within each region

The numerical code you also partially worked on calculates (in some non-trivial manner) a constant associated uniquely to the way the holes are punched

So one could consider 3,10,100,189,197, i.e. the left-most choices of holes within each region, and the code calculates and assigns as value to this configuration in a unique fashion

The wrappers basically calculate something for all tuples considered within those regions

So it is a little bit tricky, because the code in fact tags two of these tuple configurations

So in that sense what I said was wrong, sorry

The uniqueness is between each possible configuration

So for the configuration considered, each region corresponds one factor in the number of states considered, and the final number must be squared so we are running the calculation $(3*3*3*5*3)^2$ number of times

I think this works out to approx. 164000 calls to the code

So in principle this 400 by 400 array of expensive calculations need not be memory expensive, I would argue

RandomReal 400x400 is done in the blink of an eye

kirkus

I agree intuitively. It seems as if something may be holding onto lots of intermediate results.

1010011010

5:35 PM

So I'm eager to learn how to troubleshoot a problem like this

Where would you start?

kirkus

I would start by sprinkling some ByteCount[] and/or MemoryInUse[] around the suspected areas

some of the wizards here might have some more sophisticated approaches