Reputation
2,221
Top tag
Next privilege 2,500 Rep.
Create tag synonyms
Badges
7 13
Newest
 Enlightened
Impact
~25k people reached

  • 0 posts edited
  • 0 helpful flags
  • 6 votes cast
Mar
19
awarded  Enlightened
Mar
19
awarded  Nice Answer
Mar
19
revised Problems with Displaying Output for Summation
added workaround
Mar
19
answered Problems with Displaying Output for Summation
Mar
19
comment Has compilation of big programs become excessively sluggish in v 10.4?
You are confusing 2 issues. An input is first evaluated and then--if displayed--formatted. A Compile in a notebbok and in a package file evaluate in the same amount of time. If you allow it to format, that formatting takes a certain amount of time--but Get doesn't output a result to be formatted. Formatting CompileFunction takes longer in 10.x than 9, which is addressed by the SystemOption or suppressing output. Your particular compile statement exhibits a new in 10.4 slowdown during evaluation itself. This seems to be an unexpected change from a bugfix, but is still under investigation.
Mar
18
answered Has compilation of big programs become excessively sluggish in v 10.4?
Mar
15
comment Why does merely writing SeriesData[] with zeros give an error, even if it is never called?
One other minor point: Series would never produce a list only containing zeroes--the canonical form is an empty list--which is probably how this bug snuck through.
Mar
15
comment Why does merely writing SeriesData[] with zeros give an error, even if it is never called?
An easy bug to fix. One comment: it would be better to write {0 ..} instead of {(zero_ /; zero == 0) ..}. The latter allows the arguments to evaluate (which may have bad consequences--onsider {Print[foo}), and its much slower.
Feb
15
awarded  Nice Answer
Feb
7
comment Evaluation of Alternatives
@SimonWoods The same thought had occurred to me. I'm going to try to carve out some time this month to improve the documentation.
Feb
6
answered Evaluation of Alternatives
Dec
31
comment Optional throws error when called from a package. Workaround?
Just one point of clarification: while it is true that the FE by default uses the StandardForm/TraditionalForm parser MakeExpression, which is different from the InputForm parser used by package files and a standalone kernel, the FE doesn't actually make the ToExpression call seen above. The FE maintains "box expressions" which you can see using the Cell -> Show Expression menu item. These are sent directly when the head Optional appears to the right of a colon, MakeExpression is parsing the result incorrectly. An old bug, but probably one which should be pretty easy to fix.
Nov
30
awarded  Yearling
Sep
24
awarded  Nice Answer
Sep
12
awarded  Enlightened
Sep
12
awarded  Nice Answer
Sep
10
answered How to get string representation of boxes in v10.2?
Jul
31
awarded  Enlightened
Jul
31
awarded  Nice Answer
Jul
23
answered A With expression local variable specification without head List