The ability to set and maintain a consistent 2 fixed decimal places for currency data throughout a workflow would make KNIME much more friendly to accounting and business users. The lack of ability to set a uniform decimal place presentation not only makes it more difficult to review and work with currency, but when the decimal place precision is inconsistent (such as when passing through nodes like GroupBy) and requires re-rounding by formula to return to fixed decimal currency amounts it can erode confidence in the appropriateness of the platform and calculation results.
Making currency more friendly and approachable would go a long way toward making the platform more approachable to a wider world of business users.
I can tell you that we have a ticket open for this (AP-17966), and I have added a +1 on that ticket from you. If there is an update on it weāll let you know here.
The default view in the Node Monitor and Out-Port Tables for a fixed decimal or currency data type should be right aligned as well. Fingers crossed! Thanks for the quick response.
Aaand up-vote ā¦ such basics should really have been taken care of years ago. Oh wait, this post is from years back. Sarcasm intended and sorry for the burn ā¦ not having a great time atm, just want to have fun again.
The one great feature of COBOL compared with modern programming languages was its capabilities in handling fixed decimal calculations instead of (fashionable?) floating point. That is one of the main reasons it was ideally suited for business billing and payroll back in the day.
āFixed decimalā is much better for currency and āeverydayā arithmetic without continuously bumping into the rounding issues associated with floating point arithmetic.
Java does have the BigDecimal data type which is what we ought to be using for monetary, and other āpreciseā calculations with fixed decimal places, but itās verbose to use and slower and besides that, inaccessible to us from KNIME unfortunately.
KNIME is in desperate need of additional numeric data types for such use cases.
I whish there was someone who could / would be able to compare such basics amongst all available solutions available. Vendors way often advertise using shiny graphs, animations making everyone flash their eyes in awe but that more resembles a magician diverging the attention of the audience from what they should pay attention to instead ā¦ the basics like number or data handling and accuracy in general.
I was really surprised that this suggestion didnāt get immediately pounced on by other users and KNIME staff as a top priority. I can chalk the lack of forum attention up to pre-dating the facelift and voting structure, but I have had several direct conversations with KNIME development about the extreme importance of prioritizing a currency friendly data type given their growth strategy of making inroads into general business users.
It was a hesitation point for me when switching from Alteryx, and I continue to hear the lack of support for a currency data type used as evidence that KNIME is built for data science and not business users. Those users and companies continue to license very expensive and less capable platforms like Alteryx. If you want growth in those users, then you need to focus on their basic needs. The goal seems to be to tap into the tens of millions more general business users in the world for growth (vs the small number of data scientists), yet development has certainly seemed to prioritize data science bells and whistles on the development side.
Ideally we would get both a fixed decimal data type and a ācurrencyā specific data type (which could basically be the fixed decimal type with an added universal currency format presentation throughout the platform).
do you mind if I draw your both attention to this. I apologize in advance if you feel a bit misused ā¦ I only have good intentions
Admittedly, there have been a few occasions where some aspects like data type accuracy, (compute & render) performance, charts or other subjects were discussed thoroughly in the recent past. Whilst these discussions might draw a bad picture of Knime, it is far better than impressions might gave.
Though, it feels the formerly stable core extensions became less reliable (my perception) given i.e. the many different chart nodes, or the Number Format Manager.
In awareness of your post Armin:
I wonder if there is s chance to exchange in another format with the purpose of collecting feedback through other means instead of or in addition to mere forum topics. I understand that the mentioned topics do drive little attention and, as a consequence, more users to Knime. On the contrary, as mentioned in my prev. post, if it would be possible comparing different solutions on how they handle the basics each user simply expects, might trigger huge waves in favor of Knime.
You hit upon the flaw in the forum based development priority structure. Since data scientists are currently the predominant platform / forum users, they also drive development priorities by their forum voting, which then keeps the platform focused on a a small number of highly specialized users.
Separately KNIME management very much knows that the biggest growth opportunity for the platform lies in wider business user adoption. They are extremely well positioned to do this because of the massive advantage of having open source entry software, and a shifting focus toward paid individual user hub capabilities.
As @mwiegand points out, we need to make sure the suggestions that fit the KNIME business plan are also being solicited and prioritized. This could be done with user group conversations, specific forum threads, case studies with users of other platforms, or generally polling for targeted suggestions. I am sure that these issues are currently recognized and being weighed by KNIME management. The browser based platform/ new UI development was a massive project (and an understandable priority). I expect we will start to see development projects start to shift more toward alignment with business user needs, as is evidenced by development of the new Expressions node coming in v5.3.
Doesnāt the same apply though with requests like this?
It has 8 votes and the responses are only from power users. If this really was of great concern to the general public, this topic would have a) gathered a lot more votes or b) been raised a lot more often (either here or in the KNIME Analytics Platform board). So if KNIME devs were to allocate time to implement this feature, it would also only benefit a small group going by the numbers.
I also tend to disagree with that the data scientists drive the development currently. To me, the Implemented Fixes board is pretty evident whereby the majority affects the general functionality of the platform.
I guess sending out a survey to all KNIME users asking what their top tier feature requests would be could possible be a way to gain more traction with those not frequently visiting the forum.
I feel content to say that many users might not really be aware of this as they generally expect these sort if things to just work. Only by digging deep into the rabbit hole, which I experienced lately by challenging myself, I got pretty surprised and learned about these inconsistencies.
Though, from a visual perspective, if I use a rounding node, inspect the results and confirmed all to be fine, I profoundly question the software I use, if I do not understand the context, if all of a sudden rounded digits show more decimals than expected. Wouldnāt you agree?
My point was more to say that you arenāt getting votes from the āGeneral publicā or groups that havenāt adopted the platform in great numbers. I would actually point to this topic only getting 8 votes in several years as evidence that it is a problem. Go into a room of Alteryx business users and ask them what they would want in order to switch platforms and you would get pretty different votes.
I was speaking along the lines of new feature requests, not bugs and fixes which tend to be beneficial to all users. I will certainly grant that I over generalized. Recent focuses on charts and reports were certainly just as business user focused. Not trying to knock the platform, developers or managementā¦ I just see so much massive potential for growth and a broader user base once a few underlying pieces are in place.
There are also more and more of these low code automation and analytics platforms hitting the market, so I feel a sense of urgency to get the ideas across for KNIMEās benefit.
let me take a step back. The forum certainly is an important source of feedback and ides for us. However, as you mentioned, it is not the only one. We are in close contact with customers, prospects, partners and people dealing with data science in general. We observe market trends and changes in technology, we use our products internally, we teach how to use KNIME and see where new users struggle, and last but not least we have a vision and strategy for our product. All these requests and pieces of inspiration need to be weighted against each other and against practical constraints. For example, backwards compatibilityāi.e., keeping existing workflows runningāis very important to us. As a result, some changes need to be planned carefully. Furthermore, we want to make use of synergies, since it is often beneficial to do multiple closely related things together.
Now back to the topic: Fixed decimal numbers. As noticed, this topic did not get huge amounts of traction in the forum, nor via other channels. I understand the benefits of having such a data type. However, for many use cases floating point numbers suffice. Sometimes using integers is an alternativeācalculating with integer cents, instead of fixed two-decimals dollars, then only format numbers as a last step.
Introducing a new Decimal data type requires to touch/test a lot of nodes, which is considerable effort. Our current priorities include a focus on converting node dialogs to modern UI. This also includes some efforts towards harmonization and consolidation. From this point of view, it makes more sense to us to proceed here and, if demand persists/increases, reconsider fixed decimal numbers.
From that point of view you would be correct not to prioritize something like this, but I want to take a final shot at offering an alternate perspective. I have been part of those partner / power user conversations and have provided this feedback since before I added it as a forum post. I believe that there is a disconnect between the growth plan and the culture / vision / strategy of the product (as they have been expressed to me). I recognize that this is traditionally more of a discussion for a CEO or senior management, but you never know where ideas will get traction. I also know from conversations that this is a difficult ask on the development side, but I truly believe that it is the key first step to a massive growth in users.
First off, I am not a typical KNIME user. I am a business management consultant with a 20+ track record of highly profitable growth for my clients. I have accumulated a very wide array of technical proficiencies to remove limitations, dependencies and allow me to drive change as a singular agent when necessary. Free advice is often ignored, but you can go to the .com domain of my user name for context if you wish.
This forum idea was never a technical development request on my end. I am likely in a unique position of not only being the person that gets called into businesses professionally to consult on business strategy issues like this, but also having accumulated a case study worth of interactions with less technical target users of your growth strategy in my direct daily client interactions. The needs and philosophy non-technical business users lead us to interact with your platform very differently than your technical or data science users. If you want to break into this market in a meaningful way and drive massive growth, then you need to shift your focus from seeing the endpoint / completion of a workflow execution as your primary concern. The key to this market is to re-focus on the platform interaction and context along each step of the journey.
However, for many use cases floating point numbers suffice. Sometimes using integers is an alternativeācalculating with integer cents, instead of fixed two-decimals dollars, then only format numbers as a last step.
This is fine for technical users who are creating workflows that are focused on the completion of some endpoint function. However, business users need to be able to quickly internalize, solve and explore live on the fly while sharing insights with other non-technical business users. This means that context to the data is required at every step to understand results and provide confidence in the software. Currency needs be calculated and displayed simply and cleanly. A customizable universal currency format provides platform wide confidence that the platform is intended for finance and business use, context for review and avoids constant calculation and formatting workarounds. I have never had an initial live workflow walkthrough of workflow steps or interactive calculation session without issues raised such as currency formatting requests, context confusion, rounding and calculation complications, or outright confidence questions. (In the case of the one workflow where I used the integer workaround, they even offered to buy me an Alteryx licenseā¦)
Again. I love KNIME. Only trying to help it grow and thrive given the goal of growth in the area of non-technical general business users who are likely heavily underrepresented in feedback vs proficient users or those with more of a technical background.
Hi @nan, picking up on the suggestion of using integer instead of double for monetary values, and then performing division at the endā¦ I agree that this is certainly a valid and common approach in many systems, and Iāve certainly thought about that before.
Unfortunately it is not a suitable option in KNIME because of the lack of support for the Long datatype in the Math Formula (and many other) nodes, which we would need to use here, unless we only deal with values up to (+/-) 21.4 million ($21,474,836.47). This is the total value for a 32bit Integer field. If Long were properly supported across the calculation nodes, this would be become a viable option. (@mwiegand and I have had discussions on the range limitations of Integer elsewhere on the forum)
I know this might seem like it only affects āpower usersā, but put bluntly, who would expect (and accept) that Math Formula (the node that really should be capable of simple arithmetic) is incapable of returning the following as an integer value:
(it returns āmissing valueā unless you untick the āConvert to Intā)
I accept your point that it is difficult to move forward with such changes whilst ensuring backward compatibility, but improved support for Long here could be done iteratively. Math Formula really should support it, and I donāt see why that would require a massive reworking of other nodes, except of course that the future is now likely to be the Expressions node rather than an enhancement of Math Formula.
So, I remain hopeful that in the new Expressions node era, full support for Long will be included, and it would be great to see consideration for BigDecimal too.
Conceivably, for those nodes that donāt have existing support for Long data types, or new datatypes such as BigDecimal, the immediate solution would be for them to ignore any data types that they cannot use, just as Math Formula does, (and String Manipulation (Multi Column) doesnāt do(!) but should )
I have worked with a client who decided to switch to Alteryx. I wonder why? One significant risk to workflow stability is using outdated software. This can happen when software is not regularly updated or when deprecated nodes continue to be used, undermining developersā efforts to maintain current code. One example could be:
The dogma of āendless backwards compatibilityā will cause more harm than good. I once inquired about the āexit strategyā for deprecated nodes and the influx of new chart nodes but did not receive a clear answer.
This leads me to another point:
KNIME sometimes feels like it lacks a clear vision, especially since the integration of the Modern UI. This, along with the new columnar-based backend, gives the impression of a company still finding its direction. This might be more of a communication issue in explaining KNIMEās vision effectively.
To summarize, here are some key areas of concern:
Modern vs. Classic UI
Row vs. Columnar Based Backend
The numerous chart nodes
The shortcomings of these nodes, following the 80-20 rule, with basic features still missing months, if not years, later (similarly observed with the Modern UI)
Performance and reliability issues, as discussed in this thread
These points reflect actual perceptions. Providing a clearer picture of the vision would help put these issues into perspective.
Please note that my summary may seem critical, but in reality KNIME certainly is not in a bad situation. Feedback from power users, should be seen as a litmus test. We represent not only the general user base but also those who leverage KNIME at an enterprise level. Speaking about enterprises, their decision which tool to chose likely will be based on the word of mouth. Something KNIME has a clear edge with the community of any competitor.
As a closing point. There are many features and bugs reported but itās unclear how many votes are necessary to gain sufficiently enough attention to get integrated or resolved. Like this topic which has eight votes, is open since years and, from perspective of many users, has both huge potential to improve reliability and therefore the chance of KNIME being utilized in enterprises more frequently. What is the vision about this?
I think youāre a bit underestimating the impact of your feedback.
Certainly, as @nan mentions we have numerous sources which we consider when making up our priorities - let it be user feedback outside the forum, customer feedback, market trends etc. Feedback from our community in the forum however usually end up being discussed pretty shortly after posted - itās simply very important to us. Still, we unfortunately canāt act on each feedback immediately (Iād wish we could). Backwards compatibility of workflows is sometimes a factor and will remain important to us (imagine your workflow would produce different results after an update?!), but also itās the sheer amount of possibilities what we could do next - itās a nice problem to have of course - but challenging at the same time to find a way to serve the entire user-base with not only cool new features but also seemingly simpler, quality of life improvements or updates to existing nodes. For larger projects I think itās important to involve our community early - weāre happy to have Modern UI, Columnar Backend and the new visualization nodes out there in the hands of our users to be able to collaborate on the remaining 20%.
Regarding the problem with the currency typeā¦ thatās good feedback, thanks. This one didnāt come up so far in conversations outside the forum, so weāll investigate further what we can do - very good points raised by all of you.
PS: @iCFO yes - weāre working on the offering for individual users on C-Hub and also having Data Apps there ;-).
Thanks for the compliment Just to clarify, I didnāt want to make the impression the voice of the community isnāt heard. By all means, the level of interaction, as we see in this thread, is quite astonishing and incomparable more to experiences I have on a weekly basis with other vendors.
So, big shout out to all of the Knime Team Members for taking the time. It feels to me that receiving some kudos for the hard work everyone invests has gotten scarce over the past years. I hope my I could convey my gratitude for your support sufficiently
Looking forward to the upcoming community hacking days for version 5.3
Thanks for the patience with forum members trying to muscle into business management priorities.
I wouldnāt bother if I didnāt love KNIME so much, and truly believe that this change (with an additional alternate marketing approach to match) would lead to exponential desktop user / hub account growth. KNIMEās open source desktop entry level provides a strategic advantage over other platforms that may not be there 2 years from now, hence my unsolicited push for urgency toward business focused development, positioning and marketing asap.
Just to clarify, I didnāt want to make the impression the voice of the community isnāt heard. By all means, the level of interaction, as we see in this thread, is quite astonishing and incomparable more to experiences I have on a weekly basis with other vendors.
