5
$\begingroup$

I am doing a nested integration. So far the result was successfully saved with Save["filename.wl", IntOutput] and looked as following:

{8.699216412022851*^-8, 8.70971945796472*^-8, 
     8.724312065608903*^-8, 8.739384913073602*^-8, 8.751210081392647*^-8, 
     8.756863232442175*^-8, 8.754946986080317*^-8}

Now I have a fast oscillating term added and I increase precision with WorkingPrecision->22. Using the same Save function, the content of filename.wl is now:

{8.699216412022879139524462907795`21.69897000433602*^-8, 
     8.70971945796480158227693635290900000000000000000001`21.69897000433602*^\
-8, 
     8.72431206560898340384359591002399999999999999999999`21.69897000433602*^-8\
, 8.739384913073543185225410529993`21.698970004336026*^-8, 
     8.751210081392679873974725075826`21.69897000433602*^-8, 
     8.756863232442135389693899773939`21.69897000433602*^-8}

When I open this file and try to evalute it, contrary to the previous successful tries, I get the syntax error: enter image description here

What might be the case? How can I fix this syntax error and what might be the origins?

UPD To reproduce the issue (I am using Mathematica 13.0.1):

  1. Initialize an array:
IntOutput={8.699216412022879139524462907795`21.69897000433602*^-8,8.70971945796480158227693635290900000000000000000001`21.69897000433602*^-8,8.72431206560898340384359591002399999999999999999999`21.69897000433602*^-8,8.739384913073543185225410529993`21.698970004336026*^-8,8.751210081392679873974725075826`21.69897000433602*^-8,8.756863232442135389693899773939`21.69897000433602*^-8}
  1. Run
Save["filename.wl", IntOutput]
  1. Open filename.wl and Run it.

I checked, the error is reproducible for me with these steps.

$\endgroup$
21
  • 2
    $\begingroup$ Don't copy&paste the contents of the file. Simply use Get["filename.wl"]. $\endgroup$
    – Domen
    Commented May 7 at 20:26
  • 2
    $\begingroup$ Yes, I get same output you show using V 14 on windows. The \` is there. This is because Save does not use PageWidth->Infinity by default. But again, this does not affect the content if it is read using the Get command. Save does not accept PageWidth->Infinity option. Only stream output does. There might be an option in preferences to change this. I do not know. $\endgroup$
    – Nasser
    Commented May 7 at 21:35
  • 1
    $\begingroup$ @Nasser It is a bug. The problem is not "\" but I think its position within the number because if you do the same with N[{Sqrt[1/17777777777777]}, 1000] there are several "\" and works fine with Save and running the opened file with it. $\endgroup$ Commented May 7 at 22:13
  • 1
    $\begingroup$ @Nasser out = N[{Sqrt[1/17777777777777]}, 1000]; Save["file.wl", out] $\endgroup$ Commented May 7 at 22:17
  • 1
    $\begingroup$ @Nasser, Save uses OpenAppend, which accepts PageWidth, so you can do SetOptions[OpenAppend, PageWidth -> Infinity] and it works also for Save :) $\endgroup$
    – Domen
    Commented May 8 at 14:24

2 Answers 2

2
$\begingroup$

TL;DR: It's not a bug, you are just using the functionality incorrectly.


As I have already mentioned in the comments, in my opinion, this is not a bug. I suggest you read the tech note on Reading and Writing Wolfram System Files, where you can see that there are several ways of storing Wolfram Language expressions in external files.

The main idea is that you store the expression in a file, then use Get to load the expression back into the Wolfram Session. If you use this approach, everything works as expected, and there is no syntax error. You are not meant to open this file in a front-end and expect that it should be executable just because it looks like it should be! For example, besides Save, there is also DumpSave, which saves definitions for a symbol in internal Wolfram Language format. If you open this file in a front-end and evaluate the cell, it will obviously not work.

@azerbajdan has a very funny argument in the comments below his answer. He claims that since there is a "Run All Code" button, the code should be runnable. This is of course a non-sense. Mathematica front-end is in its basic form a text-editor, and you can open any file you want with it. Let's say you do:

Export["file", "+*'*-=", "Text"]

and open the file in Mathematica.

enter image description here

Look, there is a red "Evaluate" button in the top-left! But when you click it, you will get back syntax errors. Are you surprised by this? Is this a bug? I hope it's obvious that this is not a bug. The same goes with using Save and the .wl format that is used.


In the tech note I linked above, you can also find an answer on why these backslashes appear when you do Save. It is the PageWidth (as mentioned by @Nasser) which is used when writing to the file stream. You can simulate the same behaviour with:

out = N[1/10^(25/2), 54];
Export["file", FullDefinition[out], "WL", PageWidth -> 20];
FilePrint["file"]

(* Created with the Wolfram Language : www.wolfram.com *)
out = 3.16227766016\
8379331998893544432\
7185337195551393252\
168268575048528`54.\
*^-13 

If you really want, you can change the PageWidth used in Save by setting it on the OpenAppend, which is used inside Save:

SetOptions[OpenAppend, PageWidth -> Infinity];
Save["file2", out]
FilePrint["file2"]

out = 3.1622776601683793319988935444327185337195551393252168268575048528`54.*^-13

To conclude, use Save together with Get to store and load the definitions of your symbols. However, if you want to save your results in a format which is compatible with using Mathematica front-end, you have to use some other approach.

$\endgroup$
6
  • $\begingroup$ My argument is not as funny is your argument with Export["file", "+*'*-=", "Text"]. What is it supposed to prove? If you type in code with errors then how you expect it should work without errors? Contrary with you, me and OP have given examples of correct code that produces incorrect result that is caused by a bug in Save. That is all. What is incomprehensible about it? $\endgroup$ Commented May 8 at 14:51
  • $\begingroup$ Gentleman, I would suggest to wait for the comments from technical support. My original confusion was exact as azerbajdzan described. Domen's explanation and pointing at 'Get' perfectly works to me. Nevertheless, I would summarize, this polemics with the following question: Should running WL script bottom be of the same meaning as a 'Get' function ? (please correct me if I interpret wrong). If the answer is yes, then it is indeed can be sort of a bug or discrepancy. Otherwise it is just a feature of the Save/Get functions, and WL file should not be treated as rude as I used it prior. $\endgroup$
    – seva011
    Commented May 8 at 15:35
  • 2
    $\begingroup$ Save should be able to save files correctly regardless of PageWidth. What a nonsense it is to avoid some numbers because we are using PageWidth->78. ".wl" file is like ".m" file and when opened it must be runnable the more that the content was created automatically and not by hand. Suppose you have some large ".wl" file and want to edit it. So you open it in Mathematica and then have to spend a day by correcting errors that were caused by Save. ".wl" file is definitely not only feature of the Save/Get. $\endgroup$
    – three777
    Commented May 8 at 15:35
  • $\begingroup$ @three777, again, Save makes no errors, and you can edit its content and it will still work when you use Get. If you need to manually edit the output file, just don't use Save, because this is not its purpose. It's as simple as that :) $\endgroup$
    – Domen
    Commented May 8 at 15:54
  • $\begingroup$ COMMENT from SUPPORT: "The file you mention is a .wl (Wolfram Language) plain text file and not a notebook file. As the Stack Exchange case suggests use Get to read the contents f the file into the kernel. BackSlash characters () ae escape characters used in plain text files to indicate things such as line returns. The program appears to be working as designed. I can see NO reason to assume there is any kind of bug here." $\endgroup$
    – seva011
    Commented May 9 at 16:02
4
$\begingroup$

It is a bug and should be reported to Wolfram.

Save puts \ in a wrong place for some numbers as can be seen in the first file.

In the second file we see that \ was placed in an allowed position and no error occurs on executing the code.

out = N[1/10^(25/2), 54];
Save["file1.wl", out]

out = N[1/10^(25/2), 55];
Save["file2.wl", out]

enter image description here

enter image description here

$\endgroup$
4
  • $\begingroup$ Why would this be a bug? .wl files exported via Save are supposed to be used via Get, and this works fine. They are not notebooks, so there is no need for them to be runnable in a notebook. Using your logic, why don't you then use DumpSave to save a file in binary, then open it via frontend and complain that it does not run and there is a bug? $\endgroup$
    – Domen
    Commented May 8 at 10:53
  • 2
    $\begingroup$ @Domen No. You can work with .wl file like you can do with .nb file or .m file or any other file that Mathematica supports. It is not meant to be used only by Get. You totally miss the point of OP question as can be seen also from your comments below OP question. $\endgroup$ Commented May 8 at 10:57
  • 2
    $\begingroup$ @Domen Have you ever had opened a .wl file? Probably not because there is a button Run All Code. Why do they in Wolfram put such a button on the window of .wl file? Not so easy to understand for people that think "they have a patent on reason", or "they know-it-all". $\endgroup$ Commented May 8 at 11:07
  • $\begingroup$ @azerbajdzan, I sent a request to Support, asking them to take a look over this thread. I agree with you, and believe you got my (OP's) point. Till any comments from Support I will use proposed Get function to handle with lists. $\endgroup$
    – seva011
    Commented May 8 at 12:38

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.