Re: Should I be using Mathematica at all?
- To: mathgroup at smc.vnet.net
- Subject: [mg98606] Re: Should I be using Mathematica at all?
- From: Joseph Gwinn <joegwinn at comcast.net>
- Date: Tue, 14 Apr 2009 06:15:55 -0400 (EDT)
- Organization: Gwinn Instruments
- References: <firstname.lastname@example.org>
In article <gruppj$nk$1 at smc.vnet.net>, "Paul Ellsmore" <paul.ellsmore at nanion.co.uk> wrote: > Hello again, > > I have had several questions answered by this group, for which I am very > grateful. Now I have a more general topic, which I know will not have > single, clear answers. I just would like to hear your opinions. > > I have some (fairly complicated) legacy Mathematica v5 software which we > currently use in-house. Our intention is to turn this software into a > saleable product. At the moment, I am contemplating upgrading to V7, writing > a GUI for our code (which has no compatibility issues with V7) and > distributing it using PlayerPro. What is the nature of this product? > To protect our IP, I will be using Encode to make it impossible for it to be > reverse engineered. Does anyone know how secure this will actually be? Is it > more or less secure than a compiled C++ program would be, for instance? Are > there any particular issues I should be aware of? > > It turns out that there are some serious problems for us using PlayerPro > (apart from the price!) which are making us reconsider using Mathematica at > all. Top of the list is the inability of Wolfram to offer a trial license > for PlayerPro. What this would mean is that we would be losing 100 or so > every time someone ordered a trial version but did not subsequently buy the > package, because there is no way for us to get our PlayerPro license back. > This is not viable. The best Wolfram can offer is to give our prospective > client a trial version of the full Mathematica package (say for 15 days). As > a workaround, this is very clunky, when I requested my trial of V7 it took > 4 days to get the license. I think that, these days, people expect to go to > a website, download a trial version and start working with it immediately. > > So, I am considering our options, in particular open source code, such as > C++, and I'd be interested in your opinions about this. Our V5 code doesn't > involve any exotic maths, but it makes extensive use of SetDelayed, and > these definitions are frequently nested within long and complicated Do > loops. Speed is crucial to our application, so is there any, in principle, > reason why Mathematica might be able to do things significantly faster than > a compiled C++ program (assuming the C++ code is written by someone who > knows what they are doing)? Is there a better language than C++, bearing in > mind the need to compile (or encode in some way) and distribute the > resulting code? I know there used to be a compiler for Mathematica once upon > a time, is there any easy way to get from mathematica code to a compilable > program. I should stress that we are very happy with Mathematica in terms of > developing our application, it's just generating anything that we could sell > that is problematical. > > I have some experience of writing VB, Visual C and similar applications, but > these never had a large graphical content. Our code will require a lot of > plotting of data (2D only, but lots of curves which need to be interactive > in some sense). Mathematica can do everything we want in this respect, but I > am less sure about the open source code. I am sure there are add-on > packages, but never having used them I don't know whether they can match > Mathematica's built in abilities, any comments? The big issue with translation to C++ or any other language to to avoid lock-in to either Windows or to the compiler make and model. If lock-in is permitted, especially to Windows, every time MS burps you will be forced to play catch-up. While C++ is in theory standardized, there are significant differences in what C++ compilers will accept. Use of the C subset of C++ is usually far less stressful, and allows for graceful transition should the compiler vendor go to find his guru. Platform independence also helps when negotiating with platform and compiler vendors. To avoid lock-in, one must do all testing on at least two platform kinds using compilers from at least two makers. It isn't enough to make platform independence a goal, one must directly test for independence, as its very easy for dependencies to creep in unnoticed. Choice of platforms: If one covers Windows, MacOS, and UNIX/Linux, one has covered 99%. Going from one platform to two is the big step. Adding the third isn't that much harder to achieve, although testing is still an expense. Joe Gwinn