My second feature request of the day: efficient mathematical manipulation of multiple columns. Instead of "only" normalising alll columns in one go, an arbitrary mathematical operation on all columns would be extremely useful. Think log-transforms, arcsin, etc. Maybe even a self-tuning Box-Cox transformation, though I admit that'd be stretching it. :-)
Until this is out the door, at least having the "column list to loop start" node support all the modern column filter GUI logic would be a massive asset. Not quite as computationally efficient, but a low-hanging fruit for starters.
We are currently working on the low hanging fruit ;-) Not sure if the updated Column List Loop Start node will make it into the upcoming release, though.
Everything an be done in Java if you know the syntax - however, for the non-coders it takes Google effort. The "math expression" features with a GroupBy-like column selection interface would make it so much easier!
I understand the appeal. But as a coder (and not part of the Knime team) I can tell you that what you ask for is quite complex in the general sense. It's not impossible, but if you try to do it right, you inevitably come up with a programming language or something equally complicated... You might not have realized, but what you're using in Math Formulas, Rule-Based Filters and the like are all very very basic (functional) programming languages.
On the one hand, that means that you may have to wait a long time for a good solution. And if you get it, it might not be simple. On the other hand, it shows that programming is actually not that hard. You might empower yourself a lot by giving it a try. My tip is to try the Java Snippet (not simple) first, because it has the editor with the most assistance. Far from what the eclipse integrated editor does, but quite useful.
Now I will understand if other programmers will say the languages are not really programming languages yet, or not really functional languages, which, in many senses, is correct. But, on a third hand (don't ask where it's attached...) thinking about what we're using as simple programming languages led me to the realization that many of the current shortcomings of Knime have already been solved in other such languages - which gives me hope they may one far away day be solved in Knime, too. I'm specifically talking about specs (Haskell type system), automatic sensible handling of special values (categories like functor, monoid; monads), or not tightly coupling Strings to everything (pointers, enums). Especially with a few nudges like these, Knime can be a great tool to teach people about the fun and power of programming, without them even realizing. Which I think is a far better way to go than to feed their fears and non-knowlegde and implement another not-quite-programming language on top of everything. After all, it's the appeal of what you're asking for that brings many people to try programming in the first place.
I've done my share of coding (or rather: fiddling with stolen code snippets) whenever it's been truly inevitable, but I don't enjoy it. I'm just the analyst type, not the coder type, I guess. :) And for me, the power of KNIME is thus just the opposite: avoiding code as much as possible. If I could only generate efficient code from my elaborate workflows, rather than having to pollute them with code... :-D
you're speaking of "coding". We tend to forget that this last stage of programming is just an encoding of thoughts into something different, something computer-readable. Yes, most "coding" creates textual artifacts like snippets, but a lot of other formats are imaginable. The Knime system is a good example of the rare breed of real-life, useful visual programming languages (albeit a specialised one). You are, in fact, programming. And also "coding".
So I think we're on the same page here. Yes, using text for programs is a rather odd, and non-empowering choice. That's one of the reasons we're both here. Knime on the one hand gives me hope we will overcome this stage some day, but on the other hand the amount of Java Snippets we still need is a good indication of how unperfect it still is, even in its specialised niche.