I have an excel file, with different worksheets and in this file everything is connected and I also have some computations for almost all values (formulas) and I want to do a multi-objective optimization to this work. Since matlab solves multi-objective optimization problems I would like to use it. So I want to know if it is possible to use matlab optimization toolbox as and add-in for excel, so I won't have to do everything again on matlab.
Thanks.
Excel Link most likely isn't going to be of any use here. It's good when you want to use Excel as a front-end, and then push/pull data to/from MATLAB, and for calling MATLAB functions from Excel. But it isn't going to allow you to use the spreadsheet as a cost function within a call to an optimization function, with the cells updating as the optimization progresses (which is what it sounds as if you are trying to do).
You could try setting up an optimization in MATLAB where the cost function that you write uses actxserver to manipulate your spreadsheet. However, that's not going to be trivial to achieve, and you may find that the speed (or lack thereof) of accessing the spreadsheet is prohibitive.
You'll most likely find that the above is harder than rewriting the cost function in m-code (which you're obviously trying to avoid).
Alternatively if you really can't move out of Excel then you should look at using an Excel optimization package. Solver in the first instance (although it is very light weight), or one of the many other optimization add-ins available.
Related
Excel solver is amazing and wondering if its possible to incorporate the Solver functionality into a web based app instead of keeping everything in Excel. My guess is no because solver solutions are cell based.
On second thought, there is probably a similar solver available with python.
It is possible, but extremely far fetched. You would have to set up Excel on the web server, which makes crazy things to the licensing. Once there, you will have to run Excel in a separate process, but control it from your web app. Using interop in .net might be the least stupid way of doing this.
So just a couple of links to point you in the right direction:
https://www.solver.com/frontline-systems-releases-next-generation-solver-add-in-optimization-excel-online-and-excel-2016
The last few paragraphs point out that you can use the solver with RASOn, JSON C++, R, Python etc in your own apps so that is an option for you.
https://www.solver.com/
Is the homepage of the company that provides the Solver, and access to the more powerful version that exceeds the built-in version in Excel - good though that is. I have not needed the larger version - just turned a model or two around to reduce the computing needs.
The issue here is ADO connection with Excel - is this still the standard way to read/write excel files within a Dephi XE environment? We're coming up with multiple issues when reading/writing using the ACEOLEDB driver (ACE 12) and this includes
Reading cells with hashtags don't return results
"Invalid Floating Point" when exporting grids.
We've also noticed that there's many versions of the ACE 12 driver out on Microsoft's website (via Access Database driver executables) and they each seem to have different issues with Delphi.
With these things in mind,
Is using ADO with Excel bad at this point?
Does anyone else have these issues and what did you do to resolve them (other than using XLS files instead of XLSX)?
ADO in Delphi is leaning to TDataSet model, which mean strictly tabular data... that excel is not. Each excel sheet has a random cells filled, some of those may constitute quazi-tabular ranges, or may not.
Depending on the installed software you can
1) use Excel application to open XLSX, read the cells and pass them to your program. This is most easy and compatible method, though is noticeably slow due to COM IPC marshalling and switching. There are tricks to fasten it, like hiding Excel window, copying arrays of data instead of cell-by-cell approach and such.
Start exploring TExcelApplication component - http://docwiki.embarcadero.com/RADStudio/XE3/en/Using_Component_Wrappers
2) If you do not want to rely on having commercial Excel installed, you may try reading XLSX files with OpenOffice. Vanilla OpenOffice can only read them though, but some other distro's can write them as well. OpenOffice also exposes external APIs both COM-based and HTTP-based. I know there are Delphi projects of Delphi - OOo interacting but personally did not used them and apart of noting that approach i can say no detailed assesment of it.
3) Microsoft also used to sell Office for Developers or such, that gave you Access and Excel kernels as redistributables, that you could pass with your application and install them and use them. Dunno if it is still feasible though.
4) there is a set of commercial components reading and writing those files directly w/o need to have external EXE's doing the job. While that would be the most fast way to work, it would only support some subset of features (which may or may not be ok for your particular goals) and may have troubles with "future compatibility" as Microsoft would roll out updated versions of XLS and XLSX formats (which again may be of some or none concern to you). Like there was TXLSFile for Biff8 format, there is for example OExport library. There is also a component from well known TMS Studio and maybe some more.
5) You can join some open-source project and try to enhance it for your needs, then again that depends upon how much the subset you need.
I know, many people succefulyl use OLE DB to access Excel data, but for me it always sounded as some perversino, because Excel files do not have any internal regular data arrangement at all, less so strictly-tabular RDBMS-like one.
I've really only ever found it possible to manipulate Excel via COM. I've tried alternatives, like ADO, but they always seem so full of archane bugs - or maybe it's just my ignorance.
COM is definitely slow in certain areas. I've used a combination of COM and (within the Excel file) VBA to achieve what I need to do.
Given that Excel is NOT going to go away BUT Microsoft cannot be relied upon not to betray its users by, for instance, doing away with VBA and COM support, it would be great if someone, somewhere (and I wish I had the skills) could create some proper support for Excel from Delphi.
I am given a huge excel file with a great deal of data and formulas and I need to access the functionality implemented therein to create a web service running on MacOSX. I tried at first to use POI to access its functionality from Java but unfortunately POI does not support some functions like MINVERSE, TRANSPOSE, MMULT and others and I found it particularly difficult to implement them (also see this question).
Is there a programmatic way to access the excel sheet? I found RCOMClient for R but it seems it works onl on Windows. Perl, Python, R, Octave, C++, Java or anything if fine provided that it provided full functionality over Excel formulas.
Python Excel: Why Python Excel in NOT an option for my problem. In the tutorial it is written that:
A relative reference is useful only if you have external knowledge of
what cells can be used as the origin. Many formulas found in Excel
files include function calls and multiple references and are not
useful, and can be too hard to evaluate. A full calculation engine is
not included in xlrd.
Unfortunately I need a very good support of the Excel engine.
Sure you can.
Have you checked the wonderful Python Excel project ?
Even better : you could take a look at that stupendous blog post.
Have fun and keep us posted if you need more help.
Don't bother accessing Excel from another language than Python, as Python is where you'll waste the lower amount of time.
In excel is it bad to have about 1000 embedded if statements? I have about 1000 options that I want to pre-populate in other excel fields, what is the best way to do this other then inefficient if statements?
only 7 if statements can be embedded in one another in older versions of excel. 2007 allows more, but it gets unwieldly after that.
A better option may be to build a table with all your different options, then use the VLOOKUP formula to pull the result.
Whether you use Excel or another tool, the important thing is to design it well with a good flow of information that is easy to follow. Excel works great for large spreadsheet projects as long as they are well designed. The additional benefit to a well designed Excel file is that more people can open them.
Yes, it is bad.
Excel is not a good tool to use for complex programs. It would be better to buy Resolver One which gives you a spreadsheet interface, but actually generates Python code under the hood. That way you can audit and test the code for correctness, and you are less tempted to create awfully complex, and often buggy, spreadsheets.
There is a group called the European Spreadsheet Risks Interest Group that holds an annual conference about the risks inherent in complex buggy spreadsheets. A lot of the papers presented at this conference are available on their website.
I have an old Excel 4 macro that I use to run monthly invoices. It is about 3000 lines and has many Excel 5 Dialog Box sheets (for dialog boxes). I would like to know what the easiest way would be to change it into VBA and if it is worth it. Also, if once I have converted it to VBA, how to create a standalone application out of it?
I have attempted this before and in the end you do need to rewrite it as Biri has said.
I did quite a bit of this work when our company was upgrading from Windows NT to Windows XP. I often found that it is easier not to look at the old code at all and start again from scratch. You can spend so much time trying to work out what the Excel 4 did especially around the "strange" dialog box notation. In the end if you know what the inputs are and the outputs then it often more time effective and cleaner to rewrite.
Whether to use VBA or not is in some ways another question but VBA is rather powerful and extensible so although I would rather use other tools like .NET in many circumstances it works well and is easy to deploy.
In terms of is it worth it? If you could say that you were never ever going to need to change your Excel 4 macro again then maybe not. But in Business there is always something that changes eg tax rates, especially end of year things. Given how hard it is to find somone to support Excel 4 and even find documentation on it I would say it is risky not to move to VBA but that is something to balance up.
(Disclaimer: I develop the Excel-DNA library)
Instead of moving the macro to VBA, which uses a COM automation object model that differs from the Excel macro language, rather move it to VB.NET (or C#) running with the Excel-DNA library.
Excel-DNA allows you to use the C API, which mirrors the macro language very closely. For every macro command, like your dialogs, there is a C API function that takes the same parameters. For example, the equivalent of DIALOG.BOX would be xlfDialogBox - there is some discussion and example in this thread: http://groups.google.com/group/exceldna/browse_thread/thread/53a8253269fdf0a5.
One big advantage of this move is that you can then gradually change parts of your code to use the COM automation interface - Excel-DNA allows you to mix and match the COM interfaces and C API.
AFAIK there is no possibility to somehow convert it. You have to basically rewrite in in VBA.
If you have converted to VBA, you cannot run as a standalone application. As VBA states Visual Basic for Application, it is living inside an application (Word, Excel, Scala, whatever).
You have to learn a standard language (not a macro-language) to create standalone applications. But you have to learn much more than the language itself. You have to learn different techniques, for example database handling instead of Excel sheet handling, printing instead of Excel printing, and so on. So basically you will lose a lot of function which is evident if you use Excel.
Here is a good artikel about this topic: http://msdn.microsoft.com/en-us/library/aa192490.aspx
You can download VB2008-Express for free at: http://www.microsoft.com/express/default.aspx