I know, the subject line sounds really pretentious, but as much as I enjoy working with Igor, it does feel outdated in many ways.
A few points that Igor could really benefit from:
Features like these are standard in many programming and data analysis environments.
Just to repeat myself: I enjoy using Igor. it offers a lot of easy and straightforward solutions to many everyday problems and I am grateful to that. But sometimes I really long for a better handling, especially when programming.
We are in the process of what one of the owners has termed a "nuke and repave" of the source code. Some time in the (possibly distant) future, things may be improved.
I have a real love-hate relationship with Igor. At this point I've got several thousand lines of (occasionally) useful utility code that makes some pieces of my work incredibly easy.
As I use Igor, it's much more of an IDE with fantastic graphing and analysis built in. If I have to do something more than once, shouldn't I be scripting it?
I really like how easy it is to generate code from the menu commands. The problems I have stem from more than just the failings as an IDE, however.
It's normal for me to bounce between three or four languages in a week (sometimes in a day), so anything that makes me work too hard to remember things makes me grumpy.
On one hand I can express some ideas in Igor very easily - I really like writing things like "foo = q + 3*p" - on the other, I feel like I'm too often battling the language to do trivial things.
I've built some pretty sweet analysis tools in Igor - the ability to create right click menus with the window hooks totally made my day when I found it. But my inclination to stick with Igor lessens every time I switch to Igor after writing some python in vim (why isn't it easier to play nicely with an external editor? If I didn't have to leave vim to work with my code, I'd be a lot happier).
Maybe it's not typical, but I do most of my work in Igor from the command prompt or scripts. It would be nice if those features didn't feel like they were a second thought.
When I look at Igor, I see something that is almost awesome. At this point I'm leaning towards switching to working with something like Spyder or R - I'd like to help make Igor more awesome, but since I can't touch the guts, I'm inclined to take my ball and play elsewhere. We've got some instrumentation that is run with Igor (it's the reason my advisor started using Igor, which is why I use Igor), but right now none of my data is captured in Igor, but I still use it for my data analysis - which would be a ringing endorsement, but at this I feel like I'm on my way out of the relationship.
Just my 2cents (also as a Mac user):
What would help for me (as a programmer):
- improved IDE
- the possibility to make a bit like IDL some stand alone version of your code
- 64 bit
- long names anywhere
- code completion & folding
For most of my co-workers:
- as much as possible code should history compliant (some action don't show up in history)
- more word like features in the report (copy paste & scale graphs with mouse etc.)
for(;bar != 0;)
// do something
A lot of the quirks in Igor today stem from the fact that, when we release new versions of Igor, we try very hard to maintain backwards compatibility. To new Igor users the end result is that some things seem inconsistant and perhaps even nonsensical. For example, Igor originally only supported 1D waves. At some point this was extended to 4D wave support. Many operations were upgraded to support multidimensional waves, but in a lot of cases it is not obvious how an operation should treat multidimensional data, so we still have a lot of operations that are not multidimensional aware.
I know that these explanations don't do much to make learning Igor easier for a new user, but perhaps you can at least understand that a lot of the inconsistencies are historical and that we are not intentionally making Igor difficult to use :)
We always love to get feedback from our users about things they like, things they don't like, and changes/new features they'd like to see. As John mentioned earlier, we are currently overhauling a lot of Igor's parts, and when that's done I expect that a lot of the complaints people have with the IDE and editing procedure files will be addressed.
While I understand that Wavemetrics sees Igor mainly as a graphing and data analysis program, I think it is important to consider that much of that analysis and graphing is done using self written macros and functions. Thus, the text editor component is of central importance to many (possibly the majority of) users. And things like call tips and tab completion are useful from the command line as well.
Concerning the shortcomings of multidimensionality, I can't name a specific grievance off the top of my head. As aclight wrote, most of the multidimensionality is squashed into the matrixop and imagetransform operations -- not always the most straightforward manner of solving things. I will drop you a line the next time I hit a wall.
No matter what, I am more than curious to see what the "nuke and repave" project results in!
How is the nuking and paving going?
Waiting with baited breath.
You are not telling us exactly what kind of MD integration you have in mind. IP7 has (already) a new built-in Integrate2D. As the help says:
"The Integrate2D operation calculates a two-dimensional numeric integral of a user function or a wave. The result of the operation is stored in the variable V_value and the variable V_Flag is set to zero if there are no errors."
I'm guessing you might see a beta in a year. So you might want to consider breathing before then :)
or is it
sigh * sigh
Pronounced (Psi Star Psi) nerd joke from MIT undergrad days
Just curious. Any chance that the nuke and repave is going to be using a cross-platform library like Qt? It'd be a lot of work initially, but would result in it being much easier to maintain versions for different operating systems - we could even have a Linux version.
We are using Qt as the base framework so this should, at least in theory, provide a possible path to Linux.
And yes, it is a lot of work initially.
Just to put things in perspective, I estimate it will take us at least another year before even an early beta, so this project is a long way from bearing any fruit.
We're happy to hear your suggestions but it's too early for us to say what features will be in Igor7.
It would be good to get a heads up if this is not going to be backwards compatible for some things, mainly GUI's in XOP's.
I take it OS X and Windows are then going to be 64 bit? Will 64 bit be the default version? Since it's on QT, would we be able to run on Linux? If so, what's going to happen with XOP's?
We won't know the answer to those questions for a long time.
I expect that we will be beta testing Igor7 for a year so you will have plenty of time to prepare.
Given that IP7 doesn't appear to be out yet, I can't comment on this.
But this is actually a good example of what I mean: Integrate1D does a 1D integral, Integrate2D does a 2D integral, will Integrate3D do a 3D and Integrate4D do a 4D? Why not a single command? And it's not as if the special command names for each dimensionality follow a stringent system. Depending on what you want to do you need to use the ImageTransform operation for anything above 1D, in other cases (i.e. interp) each dimensionality has a command of its own.
When I discuss the advantages and disadvantages of different data analysis environments with colleagues, the one thing Igor scores really badly on is the clarity of syntax. Multidimensionality is definitely a good example of this (on the other hand, what Igor always wins with is the interactivity of plots/images and the ease of generating GUIs).
Again, I'm a big fan, but there are some grievances.
The short answer is: "I don't know".
The long answer is: you need to understand that we have finite development resources so we add functionality based on our estimate of what our customers might need/use and what they request. When dealing with data of more than 1D you will find that the number of customers using higher dimensionality falls exponentially with increasing dimensions so in as much as I would love to support integration in 15-dimensional space I really don't have the time to implement it in IGOR.
The next issue to consider is that when we add functionality we do our best to preserve backward compatibility. When I added Integrate1D (March 2003) there was already a built-in operation called Integrate which did something different. Now I could have lumped the new functionality into the old operation and used some complicated set of flags to differentiate (no pun) between the two but I thought it would be cleaner if it used a completely different name. At this point, I suppose I could have used "IntegrateND" as a descriptive name while stating unambiguously in the documentation that it only supports 1D... Instead I chose Integrate1D which tells you exactly what it does.
Over the years it became apparent that many people use this operation to perform 2D or 3D integrations in a manner described in the documentation. In some applications the extra overhead is prohibitive so I added the 2D version. At this point you could argue that the 2D version should be implemented under Integrate1D, but you need to consider that at any point in time there are new IGOR users who would never even dream of finding 2D integration under Integrate1D. Also, when you have access to IP7 you will find that the operation is significantly different to justify its own set of flags and keywords. After years of working with Integrate1D we (would like to) think that we learned some lessons so it is designed differently.
There was an internal historic reason for ImageTransform. Another reason for the InterpXXX operations. Much of the obscure ImageTransform functionality is now taken over by MatrixOP. I hope that we can clean up the Interp situation -- I'd happy to hear some suggestions.
We appreciate your support and feedback.
Purely out of wild speculation and naive curiosity I must ask ...
Can IP7 be created with a "modern", consistent, forward-thinking language set AND still maintain solid, backward-compatibility? How mutually exclusive are these two requests? Could one satisfy the two apparently divergent issues via a "composite" framework of sorts -- for example, using a "compatibility XOP" that allows users to transition from the old to the new by plugging-in an "#include IP6LanguageSet" or "#pragma IP6" command line in their code as needed?
While I understand much of the current language set in IP and would need to readjust to learn a new one, I would be more than happy to put in the effort if I could for example write something like ...
variable cMax3 = wave.max.column(myMatrix)
... or an equally "modern" equivalent that makes the coding cleaner and more understandable all around.
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville
I also have a "feature request" for IP7. Since I heavily use the DataBrowser I would really welcome if it would be possible to add an option to print in the history when one duplicates a wave, or copies waves from another IGOR experiment (through Browse Experiment), etc. (basically for any of the features accessible through the DataBrowser). This way the history would be more consistent and thus more helpful - now all this info is missing and it is really difficult to follow the steps taken when the DataBrowser was used.
Thanks for any replies!
So, here's a question. I have an XOP with a couple of windows that I draw myself. (Partly for historical reasons, partly because I do things like changing text style and color to indicate status.) The XOP is limited to MacOS for numerous reasons, not the least of which is that all of us using it prefer Macs.
These windows currently use Carbon QuickDraw calls. Stop laughing, the code is 15 years old. QuickDraw is long deprecated, and is no longer documented in the standard Xcode documentation (unless I'm missing it). So I probably need to update it soon. When I update, which of these approaches is likely to continue to work under Igor 7?
I would most prefer the middle way, since then I get all the control handling and resizing for free.
I don't know how XOP windows will work in Igor Pro 7. Only number 3 has a high likelihood of working. Number 1 and number 2 may work but I won't really know for a while, possibly a long while.
Iff WM are going the Qt route then you may be missing option 4. Option 4 being make the GUI in Qt. I have recently started writing apps with the Python/numpy/Pyside/Qt combo. It is simple to design a GUI with the Designer program (has all the layout managing, etc). The same code can then be used cross platform on OSX/Windows/Linux, assuming that you have a compiler. It does require that you know C++, but I guess you already have that.
It may require that WM provide special functionality in the XOP toolkit.
Back to top