7
$\begingroup$

Bug introduced in 10.1

I wrote a helper function to format real numbers in a certain format for writing .dbf files here. It relies on a new function to 10.1 - StringPadLeft.

Here's that function:

realformat[num_] := ToString@ScientificForm@PaddedForm[num + 0., {12, 11}, 
 NumberFormat -> (Row[{#1, "e", If[ToExpression[(#3 /. "" -> "0")] < 0, "-", "+"], 
 StringPadLeft[StringReplace[ToString@#3, "-" -> ""], 3, "0"]}] &)]

SetAttributes[realformat, Listable]

realformat[{56023.3, 16, -1523532.1}]

{" 5.60233000000e+004", " 1.60000000000e+001", "-1.52353210000e+006"}

However, the first time this is called (ie on a fresh kernel), I get the following error:

Get::noopen: Cannot open C:\Users\username\AppData\Roaming\Mathematica\Paclets\Repository\GeneralUtilities-10.2.1\Kernel\ 64.00000000000Bit\GeneralUtilities.mx\

And the output is as such:

{" 5.60233000000e+StringPadLeft[4, 3.00000000000e+StringPadLeft[, \ 3.00000000000, 0], 0]", " 1.60000000000e+StringPadLeft[1, \ 3.00000000000e+StringPadLeft[, 3.00000000000, 0], 0]", \ "-1.52353210000e+StringPadLeft[6, 3.00000000000e+StringPadLeft[, \ 3.00000000000, 0], 0]"}

Oh dear.

Now I can navigate to the folder C:\Users\username\AppData\Roaming\Mathematica\Paclets\Repository\GeneralUtilities-10.2.1 and manually run the GeneralUtilities package, which solves the issue, but that's rather annoying. All file permissions look okay and I've tried resetting all settings to no avail.

Anybody have a solution or is this a bug?

$Version
10.2.0 for Microsoft Windows (64-bit) (July 7, 2015)
$\endgroup$
6
  • 4
    $\begingroup$ For a workaround, evaluate StringPadLeft; before running realformat which will trigger all necessary autoloading. $\endgroup$
    – ilian
    Commented Aug 13, 2015 at 20:45
  • 1
    $\begingroup$ I've submitted a bug report to the appropriate developers, thank you for pointing this out. $\endgroup$
    – ilian
    Commented Aug 13, 2015 at 21:28
  • 1
    $\begingroup$ @ilian Thank you much! $\endgroup$
    – kale
    Commented Aug 13, 2015 at 23:35
  • $\begingroup$ @ilian Can you offer an explanation for the observation I made regarding the conversion of Integer to Real? I find that quite peculiar. $\endgroup$
    – Mr.Wizard
    Commented Aug 14, 2015 at 7:08
  • 1
    $\begingroup$ @Mr.Wizard While I haven't looked at it in depth, I think what happens is that PaddedForm temporarily overrides the default number formatting parameters (and restores them once it is done), but these non-default values are still in effect when the NumberFormat option value is applied. For a simpler example, consider PaddedForm[1, {2, 3}, NumberFormat -> ((Print@ToString[4]; #1) &)] where the printed form of 4 is getting padded. $\endgroup$
    – ilian
    Commented Aug 14, 2015 at 15:54

2 Answers 2

3
$\begingroup$

Confirmed by WRI (@ilian) as bug introduced in 10.1.

$\endgroup$
1
$\begingroup$

It seems that for some reason all Integer values are converted to Real in the environment in which the autoload process takes place, therefore the value of $SystemWordLength is changed to a Real which breaks the path. I have been unable to figure out the source of the Integer to Real conversion and therefore I do not know what else it may affect, but I can fix the autoload function itself which at least should handle other cases of this same problem.

With[
  {dv := DownValues @ PacletManager`Package`loadWolframLanguageCode},
  dv = dv /. wl : HoldPattern[ToString @ $SystemWordLength] :> RuleCondition[wl];
]
$\endgroup$
1
  • $\begingroup$ That was the path I started down. But I didn't know if the real number conversion happened only when the message was printed... Then when @ilian stated you can call StringPadLeft first, I abandoned that idea. Interesting, nonetheless. $\endgroup$
    – kale
    Commented Aug 14, 2015 at 12:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.