Skip to main content
Bumped by Community user
Tweeted twitter.com/StackMma/status/1217235030696697858
added 2 characters in body
Source Link
Kvothe
  • 4.8k
  • 11
  • 32

ParallelDo is having problems evaluate an expression that evaluates fine outside ParallelDo. The problem is not due to the use of functions with side effects because I managed to trace the problem to the following very simple parallelizable task.

If I define the following function that takes arguments with a certain Head (the last Head before symbol to be precise, see Taking Head of function in operator form (and manipulating arguments in operator form)).

tstToString[expr_?(FixedPointList[Head,#][[-3]]===bla&)]:=ToString[expr];

This works fine in ParallelDo, however if I define

tstToString2[expr_?(head[#]===bla&)]:=ToString[expr];

and the function

head[expr_]:=FixedPointList[Head,expr][[-3]]

then tstToString2 works fine outside ParallelDoParallelDo, but not within it. In ParallelDo it will always leave tstToString2[bla[stuff][stuff]] unevaluated. For example:

ParallelDo[Print[tstToString[bla[{f, pe, 0}][1][1, 0]]<>"b"],{vv,0,0}]

will give an error for StringJoin since the first expression will still not be a string.

How do I reliably write code that works the same in ParallelDo, when something as simple as this can screw it up. Are there some general practices that I am missing?

(The point is not to find a work around here, but to find some guiding principles for what screws things up. Otherwise I am afraid I cannot reliably work with ``.)


The answer might be version dependent because it occurs for 11.1.1 for Linux x86 that is used on a cluster I use but not on my own machine running 11.3.0 for Linux x86.

ParallelDo is having problems evaluate an expression that evaluates fine outside ParallelDo. The problem is not due to the use of functions with side effects because I managed to trace the problem to the following very simple parallelizable task.

If I define the following function that takes arguments with a certain Head (the last Head before symbol to be precise, see Taking Head of function in operator form (and manipulating arguments in operator form)).

tstToString[expr_?(FixedPointList[Head,#][[-3]]===bla&)]:=ToString[expr];

This works fine in ParallelDo, however if I define

tstToString2[expr_?(head[#]===bla&)]:=ToString[expr];

and the function

head[expr_]:=FixedPointList[Head,expr][[-3]]

then tstToString2 works fine outside ParallelDo, but not within it. In ParallelDo it will always leave tstToString2[bla[stuff][stuff]] unevaluated. For example:

ParallelDo[Print[tstToString[bla[{f, pe, 0}][1][1, 0]]<>"b"],{vv,0,0}]

will give an error for StringJoin since the first expression will still not be a string.

How do I reliably write code that works the same in ParallelDo, when something as simple as this can screw it up. Are there some general practices that I am missing?

(The point is not to find a work around here, but to find some guiding principles for what screws things up. Otherwise I am afraid I cannot reliably work with ``.)


The answer might be version dependent because it occurs for 11.1.1 for Linux x86 that is used on a cluster I use but not on my own machine running 11.3.0 for Linux x86.

ParallelDo is having problems evaluate an expression that evaluates fine outside ParallelDo. The problem is not due to the use of functions with side effects because I managed to trace the problem to the following very simple parallelizable task.

If I define the following function that takes arguments with a certain Head (the last Head before symbol to be precise, see Taking Head of function in operator form (and manipulating arguments in operator form)).

tstToString[expr_?(FixedPointList[Head,#][[-3]]===bla&)]:=ToString[expr];

This works fine in ParallelDo, however if I define

tstToString2[expr_?(head[#]===bla&)]:=ToString[expr];

and the function

head[expr_]:=FixedPointList[Head,expr][[-3]]

then tstToString2 works fine outside ParallelDo, but not within it. In ParallelDo it will always leave tstToString2[bla[stuff][stuff]] unevaluated. For example:

ParallelDo[Print[tstToString[bla[{f, pe, 0}][1][1, 0]]<>"b"],{vv,0,0}]

will give an error for StringJoin since the first expression will still not be a string.

How do I reliably write code that works the same in ParallelDo, when something as simple as this can screw it up. Are there some general practices that I am missing?

(The point is not to find a work around here, but to find some guiding principles for what screws things up. Otherwise I am afraid I cannot reliably work with ``.)


The answer might be version dependent because it occurs for 11.1.1 for Linux x86 that is used on a cluster I use but not on my own machine running 11.3.0 for Linux x86.

Source Link
Kvothe
  • 4.8k
  • 11
  • 32

Possible bug ParallelDo (or better practices for ParallelDo)

ParallelDo is having problems evaluate an expression that evaluates fine outside ParallelDo. The problem is not due to the use of functions with side effects because I managed to trace the problem to the following very simple parallelizable task.

If I define the following function that takes arguments with a certain Head (the last Head before symbol to be precise, see Taking Head of function in operator form (and manipulating arguments in operator form)).

tstToString[expr_?(FixedPointList[Head,#][[-3]]===bla&)]:=ToString[expr];

This works fine in ParallelDo, however if I define

tstToString2[expr_?(head[#]===bla&)]:=ToString[expr];

and the function

head[expr_]:=FixedPointList[Head,expr][[-3]]

then tstToString2 works fine outside ParallelDo, but not within it. In ParallelDo it will always leave tstToString2[bla[stuff][stuff]] unevaluated. For example:

ParallelDo[Print[tstToString[bla[{f, pe, 0}][1][1, 0]]<>"b"],{vv,0,0}]

will give an error for StringJoin since the first expression will still not be a string.

How do I reliably write code that works the same in ParallelDo, when something as simple as this can screw it up. Are there some general practices that I am missing?

(The point is not to find a work around here, but to find some guiding principles for what screws things up. Otherwise I am afraid I cannot reliably work with ``.)


The answer might be version dependent because it occurs for 11.1.1 for Linux x86 that is used on a cluster I use but not on my own machine running 11.3.0 for Linux x86.