Storing array from program in MathCad sheet?

[ptc-4310378]

I would like to store in the worksheet a nested aray generated by a program in the sheet, to avoid the recalculations which are no longer needed once the data is generated.

I tried to assign the array to a variable using cut and paste but this was flagged by a "Matrix too big message" (The array is 100 x 5).

What would be the way to permanently assign this Array to a variable?

Thank you.

[VladimirN]

Laurent Muller wrote:

...I tried to assign the array to a variable using cut and paste but this was flagged by a "Matrix too big message" (The array is 100 x 5).

What would be the way to permanently assign this Array to a variable?

Thank you.

Try to embed and work with a Excel component in the Mathcad worksheet (in main menu go to "Insert" -> "Component..." -> "Microsoft Excel"):

[ptc-4310378]

Thanks Vlad. It looks like Excel is not very happy with nested Arrays though.

Looks like I will have to "unest" the array, store it, and then "renest" it to feed it to the calcs.

Thanks again for your advice.

[wayne]

Another way, is to generate the matrix, then copy the matrix, then reassign the matrix by pasting on the RHS.
Then disable the program.

[RichardJ]

No need for Excel. Go to "Insert" "Data Table". Right click on the first cell, and "Paste Table". However, it will also not accept nested arrays.

When you copy the matrix, be aware that Mathcad only copies at the displayed precision, NOT the full precision! So first increase the number of decimal places to 15, then copy!

[ptc-4310378]

.......yes.....not for nested arrays unfortunately as you say.

I know it is another subject....but as you mention it:

-- I was doing a cut and paste of a single array between MathCad 2001 files. Got to large precision in the original file.....but it would only give me three decimals in the receiving file. Had to first paste into Exel with full precision and then the cut and paste from Excel would give me full precision in the new file. Go figure! Cut and paste of other similar arrays was working.....but not this one. Strange.

Thanks.

[AndyWesterman]

Hello Laurent,

how deep is the nesting in your array?

attached is array 100*5 * 8*8 that will copy to b:=

It does struggle if Iincrease 100 to ~120 or 5 to 8 (maybe less), at the higher values just gives "bigmatrix" as the result,

regards

Andy

[ptc-4310378]

The array is only one deep (100*5). Good to know you can go deeper!

Wayne's suggestion is exactly what I was atempting and didn't work for me (Matrix too big).

But I see it is working fine with AW's example.....

Am on 2001.....so maybe this is the issue: If I try to expand the Nested Array in 2001, then "Matrix too big" flags up.

I gave it a try in 15, but the solver function that works in 2001 doesn't work in 15. So I have to stick with 2001.

File is attached (sorry for the mess, it is work in progress). The Nested Array is on page 15 (SwTT). But if you are on Mcad 15, chances are it won't execute (no solution found), like it did for me in 15.

I will reduce the size of the array while cleaning the file up (size is only for plot resolution) to cut down recalc time if I cannot assign to a variable.

Thanks for all the help.

[wayne]

Mathcad makes some assumptions about automatic vectorizations, my guess is that this is what changed from the 2001 version. I suggest you stick with 15.

[ptc-4310378]

Very interesting....although the function definition is already vectorized, in 15 vectorization needs to be reapplied when using the function?

Don't really want to use 15 as it is only a temporary student licence while I am in school. I'd like to use the files later on my old 2001 once I do not have 15 anymore and 15 files are not backwards compatible. How much can a non -student 15 license be had for? I am a very casual and occasional user only and a big investment here is not possible for me (and the Professors want the work turned-in in Excel anyway....)

I got the 15 student license hoping that it would help with some symbolic manipulations (that I can cut and paste back in 2001), but haven't found a big advantage with 15 yet on symbolics for my applications. So the motivation to shell out big $$ is not really there.

Although.....in 15 SwT(TT) recalculates in the blink of an eye, vs minutes in 2001, which would make the whole issue of storing the array completely mute......

[ptc-4310378]

Never mind...I looked up the price for 15 on the PTC site....out of my reach!

[LucMeekes]

Laurent,

There's another possibility, apart from storing the result in the sheet. You can store it anywhere on disk.

Assuming it's about SwT(TT), you can use a WRITEPRN("C:\swttt.prn"):=SwT(TT) to store the result.

In order to retreive it into a variable use e.g. SwTTTT:=READPRN("C:\swttt.prn").

By selectively enabling/disabling the WRITEPRN statement you can control when the result is calculated.

Note that the same remarks wrt accuracy/number of significant digits apply as when copying it....!

Success!

Luc

[ptc-4310378]

Luc,

Would this work with Nested Arrays? Thought I'd have to "unest"/"nest" to WRITE/READ?

Thanks

Laurent

[LucMeekes · Accepted solution]

Laurent,

this does work with nested arrays, no problem (that is, in Mathcad 11) to any depth. Just try it out in your version.

Be sure to read the (nested) array in with Mathcad, and do not fumble with the data file outside of mathcad, unless you really know what you're doing.

But for your purpose, storing calculation results and retreiving them back in Mathcad, this should be no problem.

Success!

Luc

[wayne]

Luc,
I am not clear on what problem this method is solving, you still have to bring it back into the worksheet to use. And if you want to stop recalculation time, you still must disable the program that created it, or am I missing something (not an unusual occurance )?

Another possibility, is to do preporcessing in one worksheet, and reference that sheet into another for post processing. This might required some reorganizing, but can solve a lot of problems with recalculating.

[ptc-4310378]

Wayne,

Luc's allows to export the data, disable the time consuming function that generates it as well as the WRITE statement. Then assign the data to a variable with READ.

Assigning the data to the variable is what I needed. With 15, it looks like it is a simple cut and paste deal. But for my dinosauric version, Luc's will do (as cut and paste of the Array does not work with 2001)?

[wayne]

Thanks laurent,
Just curious, why you don't take a little time and convert the sheet to M15?. I don't think the solvers are really a problem, in the one example you just needed to vectorize the SwTT.

Any way, glad Luc could help.

WAyne

[ptc-4310378]

Wayne,

I posted above about my 15 being a student license only that I won't be able to use once out of school. I'd be stuck with files I would no longer be able to access if I ever had to, as 15 is not backwards compatible to 2001. As I am not a power user, 2001 does most of what I need.

[RichardJ]

I posted above about my 15 being a student license only that I won't be able to use once out of school.

It has no way to know when you are out of school. It will not automatically disable itself the day you graduate

If you want to switch computer maybe that will be a problem though? Can't say for sure, since I have never been in that situation.

[ptc-4310378]

Vendors of other student licenses I am using are asking every year for school accreditation, which may happen here too, and the licensing for MathCad at installation time goes through an academical portal. Reloading 15 after a recent virus induced rebuild didn't seem straight forward already, so am not taking a chance.

Would not take a chance using an academical license for professional purpose either.

Got 15 just in case there was a feature I could use not available in my version, but what I need it for is basic enough so have not encountered this situation yet.

[LucMeekes]

Wayne,

it is possible to disable a single equation in a worksheet. By disabling just the "WRITEPRN..." statement i mentioned above, takes care of:

-not trying to evaluate the expression, and

-not overwriting the result data file

in one stroke.

If you put the READPRN statement just below that expression and keep it enabled always makes sure that from that point on you can calculate with the result.

One could split up the calculation in two sheets, one to calculate the nested array and store it, the other to retrieve the result and continue calculations. But then you'd have to keep track of stuff, possibly duplicate statements and then keep them synchronized, that's begging for trouble.

In any case the WRITEPRN method prevents that you have to (hand-)copy the data, which is to be avoided at all times, since it is hand-work.

Success!

Luc

[wayne]

Thanks Luc,

Actually, in my work I don't cut and past either. I do use file references extensively, it's common for me to have calculations 3 or 4 references deep. If I work on the deepest sheet, all the current versions of the previous files (functions definitions, variables) are automatically brought in, but then are static and do not effect the speed, after opened. It's just like a continuing set of calculations, the coordination problems you mentioned do not occur.

(I realize that the above is a little off track from the original question)

Wayne

[LucMeekes]

Wayne,

I know referencing, used it often, and as far as I can tell it does not solve Laurent's problem of (re)calculation. Even if you 'hide' the calculation deep in the hierarchy, the result needs to be known and thus needs to be calculated (or retrieved).

Referencing a sheet from within another sheet effectively embeds the contents of that referenced sheet at the reference point.

I'm a bit puzzeled by your remark that you can "work on the deepest sheet and all the current....are automatically brought in". If you have a (top) sheet0 that references sheet1, then within sheet0 below where it references sheet1 all that is defined in sheet1 is known in sheet0, but also all that needs evaluation in sheet1 needs to be evaluated when sheet0 needs it. By the same rule all that is defined in sheet0 before the reference to sheet1 is known in sheet1. But if you work on sheet1 separately from sheet0 it does NOT know the stuff from sheet0, unless you specifically reference sheet0 in sheet1 as well. But that makes referencing sheet1 within sheet0 problematic: you'd get a cicular reference.

Or am I in the mist now...?

Success!

Luc

[wayne]

Luc,

I am more linear than that, I typically only reference in files at the beginning of a document. Something like this:

Criteria ---- Beams, reference in Criteria, ------

Columns, reference in Beams

(which will include Criteria) etc.

Lateral Loads, reference in Criteria

Shear walls, reference in Lateral Loads

Braced Frames, reference in Lateral Loads

The Criteria sheet also includes file references containing functions for analysis and design.

If I need Beam results in Braced frames, and wanted to keep it as a separate string of files, then I would export and import files, or cut and paste. (only on large porjects)

Within a group, like Beams, if a file becomes slow (especially for revisions), then I start a new file and reference in the last one. It takes longer to open, but recalculation time, and other problems with big files are greatly reduced.

So one possibility for Laurant would be to start a new file after the creation of SwTT and reference the previous file in. This does not create any precision issues, disabling programs or updating exports.

[RichardJ]

By disabling just the "WRITEPRN..." statement i mentioned above, takes care of:

-not trying to evaluate the expression, and

-not overwriting the result data file

in one stroke.

There's a button in the Extra Components worksheet (Extra Components.mcd) that allows you to control the execution of various statements and blocks of code. I originally wrote it to control the writing of files without havaing to disable and enable eveluation, and that's still what I use it for most, but it could be used for anything.

[ptc-4310378]

Success! Works like magic, thanks!

Strange that the PRN heading says "file written with MCad 8.0" when using 2001. Maybe an old DLL?

One more question (must admitt I didn't open the book on this one, sorry):

-- Is there a way to use relative paths for the PRN file location?

Thanks very much. This helps.

[LucMeekes]

Laurent,

In Mathcad 11 it says "// Datafile written by Mathcad" (no version...)

Mathcad knows the variable CWD (current working directory). Just type CWD= and see what it returns. In many cases it would point to the directory where your current worksheet is stored, unless you're on a new worksheet started from scratch, where it might point to a default directory.

In general adding no path as in WRITEPRN("swttt.prn"):=SwT(TT), should lead to the .prn file being stored in that same (current) directory.

Success!

Luc

[ptc-4310378]

More success. Thanks.

2001 knows CWD, great. Thanks for saving me some User's Manual Time here!