Like it says in the title:

Is it possible to access the stuff on one page from another?

Thanks

CB

Do you mean some kind of #include "Page2" statement? If so, then answer is "no".

Wrote

Is it possible to access the stuff on one page from another?

I think this is actually a good idea. It would allow the user to make use of complex calculations that would not clutter up your current Smath worksheet. MathCad provides similar functionality by having collapsible regions on the worksheet. But the idea of linking one worksheet to another sounds good also. Perhaps it could be implemented like a function [i.e. command(arg1, arg2, arg3) ]. The only drawback is that, if you wanted to share your worksheet, you would need to make sure that you included all linked worksheets as well.

Although not at the top of my wishlist, still this would be a nice feature.

There was a separate product called Mathconnex (it was included in some Mathcad versions - it stoped with Mathcad 11). Among other things it has the capability to connect Mathcad files. I do not know why its development stoped. My personal oppinion is that Mathconnex concept was not accepted by the users.

Perhaps having multiple tabs (similar to excel worksheets, see screenshot from excel below) within the same file would be a better idea. That way everything would be in the same file (no need to worry about multiple Smath files), but functions could be called between the worksheet tabs within the file.

It might be a good idea, but the naming convention of user defined variables and functions must be invented in order to use variables and functions in one worksheet from another. What to do in those cases? If there are variables accesible in multiple tabbed worksheets with the same name, the problem is how to track changes? What would be the order of recalculation?
One of the solution of this problem might be to have two types of worksheet. Only one main worksheet as it is now, and another type (tabbed) worksheets with the feature of defining only variables and functions with unique names defined in them. I am not sure that this might be a good solution. I suppose the realisation of this idea would open other questions to be answered and realised.

Regards,
Radovan

I think for a simple product like Smath the complexities of allowing externally defined functions outweigh the advantages.

But, I like the idea of collapsible sections or a separate tab for user defined functions.. That way you could cut and paste all the functions in that you want and test them, and then if you need to modify the function for a different worksheet then it wouldn't affect the first worksheet.

Wrote

...similar functionality by having collapsible regions on the worksheet...

Actually SMath Studio already have implemented draft of Area Control (but disabled in public releases):


...will be enabled in the future.

P.S.: If you want, you can play with Area using this file: area_demo.xmcd. Just open it in SMath Studio. Note: Area Control is very buggy and cannot be saved or copied.

Hello Greg,

Wrote

I think for a simple product like Smath the complexities of allowing externally defined functions outweigh the advantages.

I agree that the introduciong to much complexities into SMath might be wrong.

Wrote

But, I like the idea of collapsible sections or a separate tab for user defined functions.. That way you could cut and paste all the functions in that you want and test them, and then if you need to modify the function for a different worksheet then it wouldn't affect the first worksheet.

Very good news is that Andrey made collapsable regions . I agree that the simple solution might be just to copy, paste and collapse worksheet sections and collapse part of the worksheet in order to reuse some calculations, make more understandable and readable worksheets. In adition, I still believe that same kind of "packaging" the sequence of calculation into a SMath file and simple reuse of it would be rather welcome and useful. Just look at the recent Andrey's effort about text inside math regions. I think that the SMath worksheets which accepts input variables (numerical, textual) and functions which gives output (numerical or/and textual) that could be loadable into another SMath worksheet by only a single command line would be very benefitial. You can just load it and use it, or change it if that suits you. I know that "Referencing" to another worksheet is already present in Mathcad but I've never liked it (just working the same as colapsable regions but having troubles with the file references on the disk and transfering the files from one computer to another). I meant the loadable worksheet to behave similar like multiline functions (not present in SMath).

Just my thoughts,

Regards,
Radovan

Wrote

Very good news is that Andrey made collapsable regions

This solution will go a long way towards producing flexible and more readable worksheets. Great work, Andrey!

Wrote

I think that the SMath worksheets which accepts input variables (numerical, textual) and functions which gives output (numerical or/and textual) that could be loadable into another SMath worksheet by only a single command line would be very benefitial.

Radovan, I completely agree. With the new capability of creating plugins, I am sure that users would also have the ability to create their own functions. But this is will require medium-to-advanced programming skills. With the functionality you have described above, users who simply know how to use Smath could create their own functions, without the need of learning how to program in Visual Basic, C-sharp, F-sharp, etc.

I am going to call this a "linked function" for want of a better word.

As far as the difficulties mentioned above regarding having a worksheet with dependencies on other worksheets, it may be possible to automatically merge the other Smath file with the current file when a "linked function" is utilized. Thus, the "linked function" would behave just like a native Smath function and the function would travel with the file if it was transmitted to another user. For instance, in Excel, a custom VBA routine created by the user is saved as part of the .xls file and thus travels with the file.

The problem is that if you need external files to go with a worksheet then distribution is more difficult, and you also have to deal with overloaded operators and functions. If they are explicitly included in a worksheet then precedence is established directly. I quite like the idea of an external library of functions, but I think it loses more in simplicity than it gains in flexibility.

Wrote

The problem is that if you need external files to go with a worksheet then distribution is more difficult, and you also have to deal with overloaded operators and functions. If they are explicitly included in a worksheet then precedence is established directly. I quite like the idea of an external library of functions, but I think it loses more in simplicity than it gains in flexibility.

I understand and agree it is very desirable to keep Smath simple, easy-to-use, and easy-to-learn. But, I think that it is possible to add greater capabilities and flexibility (such as the "linked function" feature) without sacrificing much in the program's ease of use.

It seems to me that it all comes down to how the user interface is designed. It is essential to keep the GUI clean and simple, uncluttered by controls and features that would only be used rarely by the experienced user or not at all by the casual user. For instance, the idea of adding the worksheet tabs would be a mistake (who mentioned that idea anyway! ) since it adds unnecessary complexity to the GUI.

However, that doesn't mean that new and powerful (albeit more seldomly used) features could not be added. These features, however, should not be immediately visible to the average user, unless they specifically look for it, nor should it interfere with their daily use of the software. One way to do this is to keep such features buried one or two levels down in the drop down menus along the top of the GUI or the features may be implemented using special keystrokes.

As far as the idea of creating custom functions is concerned, I believe that Andrey has already provided that capability through the use of plugins. Since creating these plugins would require programming skills, the idea of allowing users to create custom functions using Smath worksheets is actually a step away from complexity in the direction of simplicity.

The average user need not concern themselves with creating their own functions unless they come up against a situation in which they find it useful. The average user might only come into contact with them if they were sent a Smath worksheet from another user in which they are used. But if custom functions are automatically merged with the worksheet in which they are used, the custom function would act and behave like a native Smath function. The underlying worksheets of any custom functions used in the current worksheet would be invisible to the user unless they specifically chose to view them. (Once again, please see how Excel implements custom VBA functions within spreadsheets. They act and behave like native Excel functions and these functions are saved as part of the spreadsheet file. It is also possible to view the code of the custom functions, if the user desires to do so.)

So anyway, my take on the issue would be to continue to expand the capabilities of Smath, but endeavor to maintain the simplicity in the user interface at the same time.

Hello,

Based on the previous comments, I tried to present an oversimplified idea about how to make some kind of user defind functions. I do not know if this idea could be realised, neither if this is the optimal and right way. IMHO, from the user perspective, this might be simple enough, not including more complexity and, on the other hand, giving the avarage user the oportunity to have more flexibility and power.

Please look at the hypothetical example.

This file is using load (hypothetical) command in order to call an .sm file caled "SMfile". It passes three arguments to that file. Two variables (x,y) and a function with single argument f(1). Please look at he called .sm file.

There is, say, a protected "arg" vector. The x,y,f(1) are recognised as arg1,arg2,arg3. After tha calculation has been performed, the protected "out" vector is returned to the calling .sm file. We can call it again with another arguments. The advantage of this method is that you can write SMfile only once and use it as many times as you like, providing that the internaly defined variables and functions in the "load" file remained local, not recognised by the parrent file.
About transfering to another machine. I suppose that the mentioned idea by Will might be used here. By saving the appropriate .sm file with "load" commands, every "load" file could be saved together with it. In that case, running this file will no cause any problems on different computers. There should be also a possibility to extract and see "load" files. Moreover, parrent file with load files should be be in the same folder. There should be a mechanism which will ask the user which one to use - internaly saved or the external one with the same name. Again, more flexibility. If you just want to use the internal one, no external "load" files in the same folder as the parrent file will be present.

Making "load" files would be no problem. Any existing .sm file could be easely transformed into a possible "load" file via "arg" and "out" variables.

There is a drawback here because there might be confusing what f(1) or g(1) mean. I said that this is a function with one argument but it could also be regarded as a result from calling those functions. I have no answer here how to overcome this possible confusing.

This is just a raw idea, most likely with many shortcammings - but IMHO it is worth considering.

Regards,
Radovan

Wrote

Based on the previous comments, I tried to present an oversimplified idea about how to make some kind of user defind functions.

Radovan,

I think what you have described above would be a great and very useful implementation of custom functions.

Since you have taken it in hand to present how you would visualize the implementation of custom functions, I thought I might present what I had been thinking as well. (only as another possibility)

I was thinking in the same general direction as you, but tried to visualize a solution using dialog boxes. Also, I would like custom functions to have the look and feel of built-in Smath functions.

So, lets say that you start by creating the Smath worksheet you showed us above (sorry for borrowing your image ) (The syntax of the file could help to designate the arguments and return values as you have shown in the image):


then, you would click on a menu choice "Define Func..." in the "Tools" menu:


This will display a dialog box allowing you to define the custom function either using the currently active Smath file or browse for another one on your local machine. In this case, we would choose "Use Active SMath Worksheet"...


At this point, I envision that Smath would analyze the Smath file to attempt to automatically locate the input variables and the return value. This would then be displayed in a dialog box that would allow the user to type in the function name, description, browse for an image showing sample usage, and then edit the input and output values (this could be done by either changing/deleting variables in the dialog box or simply cancelling the operation and returning to the defining Smath worksheet to rewrite using the correct syntax). The dialog box could possibly look like this:


Thus, the custom function would be available from the list of built-in functions within Smath (within a cateory called "Custom" ) :


This function would look and feel like a native Smath function. If custom functions are used within a Smath worksheet, the function could be merged with the Smath file, allowing it to travel with the file. If a user opened a file that contained the custom function, the function could be automatically added to the list of functions on that users system (or the user could be prompted whether they wanted this done or not).

Anyway, this is not necessarily the way this functionality should be implemented (if it is implemented at all). But just what I envisioned in my mind's eye. I submit it only as an idea and subject to change and improvement. Radovan, what you have written above is equally useful. Hopefully, Andrey can give us his opinion on what he thinks is practical, possible, or more user friendly, and the user community can give more input on whether they think this functionality is something they would want.

Hello Will,

I like your idea . From the user point of view it seems not to complex of making and using custom functions in this way. As far as I am concerned, something similar would be a great step forward for SMath. Of course, Andrey might have a better, viable and more practical solution. I think that sooner or later (depending on his available time) this will be done and we will be pleasantly surprised

Regards,
radovan

Hello.

Many thanks for your ideas! It is a dream for any developer, to see such kind of specifications to implement functionality or anyhow to make own decisions based on these. I will create a support for custom functions as soon as I will finish with units and some minor stuff. And of course I will inform you here about the progress.

By the way, I need in time break for a while, so work on SMath Studio in a pause now (but I still can participate in discussions here and ready for the questions). On Sunday I'll be back and will continue current activities.

Best regards!

Wrote

Wrote

...similar functionality by having collapsible regions on the worksheet...

...will be enabled in the future.

P.S.: If you want, you can play with Area using this file: area_demo.xmcd. Just open it in SMath Studio. Note: Area Control is very buggy and cannot be saved or copied.

Thank you for your work. This can make a huge impact on lots of people presently prevented
from plunging into the world of automated math. analysis by high price of mathcad.

It is great that you are working on Area implementation, since it is a critical function
for what I am thinking to use SMath studio. Namely, we have lots of tools that we
want to give to customers to calculate some parameters from data. Some of the parameters
have to be hidden because they are confidential.

So having ability to have collapsible areas is critical. However, it is also critical
to be able to lock them and store them in a file in encrypted format, so not only the
area can not be opened, but it nobody should be able to see its content even with certain
level of hacking skills. Given this capability, we would start introducing SMath Studio
worksheet to lots of customers all over the world, which would certainly help popularizing
it.

Are you considering adding locking / encrypting capability for the Areas?

Regards,
Yevgen

Hello Yevgen. Nice to meet you on the SMath Studio forum pages.

Wrote

Are you considering adding locking / encrypting capability for the Areas?

Sure. Encryption (i.e. protection by password) of the Area region is one of the most significant parts of the Task to implement Area control.

Regards, Andrey Ivashov.