nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Enter a number between 0 and 99,999,999

Dom39Hasek

Trying to enter crypto transactions for meme tokens trading at a fraction of a penny (in some cases I purchase a billion or more in a single transaction) the limit imposed is a major problem for me, what can be done about it?

Is Quicken still having y2k issues?

C'mon now, it's 2023, get your act together (I CAN'T be the only one having this issue!!!

Find more posts tagged with

Comments

Tom Young

That's not a y2k issue, it's a hard stop coded into the program.

The only workarounds I know of is to break the transaction into multiple transactions or increase the cost by some power of 10 and reduce the quantity accordingly.

Dom39Hasek

Hi Tom,

Thanks for the feedback! My Y2k comment was (I thought) obviously sarcasm! I will take your advice and do some sort of multiple to accommodate this limit. How do I get this in front of someone at Quicken who could maybe fix this problem in a future release?

Chris_QPW

How do I get this in front of someone at Quicken who could maybe fix this problem in a future release?

You can use Help report a problem…

But I doubt this is ever going to be changed.

These crypto transactions are running up against fundamental constraints.

Both current floating-point processors and the C++ double variables that are most likely used in Quicken have a decimal precision of 15 digits. When transactions are requiring billions on one side of the decimal point and 8 or more digits on the other side of the decimal point, something has to give. Not to mention there is "visual" aspect of how do you present such a long number in various places in Quicken.

UKR

https://community.quicken.com/discussion/comment/20398535#Comment_20398535

We recently discussed floating point arithmetic and 8-decimal places precision in another discussion.

Back in the Nineties (yes, 1990, last millenium!) IBM had the same issue.
Most business programs used "packed decimal" arithmetic for their Dollars-and-Cents calculations. As long as your numbers did not need more than 15 digits to be correctly calculated, everything was fine.
For some large companies that wasn't enough. If you needed to calculate the Federal Budget Deficit with precision to the Cent, some other absurdly large amounts or some currency conversions, you needed more digits.
So IBM, instead of having to redesign all their processor chips' microcode invented a long packed decimal format with 31 digits length. They supported this in "macrocode", just outside of the processor chips' microcode instructions and in new versions of their compilers with new instruction codes.

Would sure like to know if someone at Intel, AMD and/or Microsoft and all the other UNIX providers have figured out a way to support decimal instructions with more than 15 digits length. And I'm not talking conversion to floating point arithmetic.

And, assuming such long decimal arithmetic was available, it would be interesting to know how much work it would take to rewrite Quicken to get off the 99,999,999.99 limit.
Just imagine … Bill Gates or Warren Buffet or the next 1-Billion-Dollar Lottery Winner … they would all be able to use Quicken for their transactions without running into the 100-million per transaction limit …

Rocket J Squirrel

Would sure like to know if someone at Intel, AMD and/or Microsoft and all the other UNIX providers have figured out a way to support
decimal instructions with more than 15 digits length

C# has a decimal type.

The decimal type is appropriate when the required degree of precision is determined by the number of digits to the right of the decimal point. Such numbers are commonly used in financial applications, for currency amounts (for example, $1.00), interest rates (for example, 2.625%), and so forth. Even numbers that are precise to only one decimal digit are handled more accurately by the decimal type: 0.1, for example, can be exactly represented by a decimal instance, while there's no double or float instance that exactly represents 0.1. Because of this difference in numeric types, unexpected rounding errors can occur in arithmetic calculations when you use double or float for decimal data. You can use double instead of decimal when optimizing performance is more important than ensuring accuracy. However, any difference in performance would go unnoticed by all but the most calculation-intensive applications. Another possible reason to avoid decimal is to minimize storage requirements. For example, ML.NET uses float because the difference between 4 bytes and 16 bytes adds up for very large data sets.

Chris_QPW

The C# and similar kinds of libraries aren't possible for Quicken for one main reason, the database. Other than converting every number into text and storing it that way, there wouldn't be any way to store these in the database as "numbers".

So, right there you would have to change the database, and you would also have to change every place that you use a number. Basically, you are talking about a total rewrite of Quicken.