It is possible, but makes is somewhat impractical, because you need to convert numbers back and forth every time you touch them on an application level. Not worth the extra headache.
Speaking from experience, if you exclusively deal with integers internally and then apply the appropriate formatting when outputting to the user (which you need to deal with regardless of internal representation), it makes dealing with monetary data so much easier. Integers are generally better supported, faster, and more convenient for most languages, databases, and serialization formats.
Floating point (up to a certain amount of absurdity) you can describe with integers (value, scale).
Real numbers you can describe with integers (numerator, denominator, scale).
Irrationals are more difficult. That's why we try not to use them :). Hopefully your company's commission tiers are not defined in terms of circles or euclidean distances.
Accounting rules often care more about consistency than precision per se. As long as the code follows accepted accounting rules (say bankers rounding) choosing a known precision works. Often GAAP and other standards don’t define all details for, say amortization, but if you use a scheme the code should always use that method.
Not insisting, and could be seen as a bad practice, but I think I have experience worth sharing.
Unless you operate 2+degree currency polynomials, it may be okay to store money in minimal integer units at an application level too. It may be adjusted in only ui formatters. One should be careful with constants in code and external apis, but nothing you can’t get used to or catch with a test. We store timeouts in milliseconds, weights in grams, and so on anyway - not a new thing.
As an example, the primary database I maintain for our company is able to hold decimal .00 natively, but we use its fields as if they were multiplied by 1000, i.e. 12,345.00 is stored and operated as 12.35 (and goes as int64 1235 to ODS) (rounding 5.00 off is fine for this particular accounting model). Nobody made a three-digit mistake ever in a whole decade, because square/cubic money is not a thing naturally, and ratios & exchange rates work as usual. It is like storing cents, but the other way round.
Storing in-app amounts in floats has a downside of accumulating an error in for-looped calculations and the need for periodic rounding (although it should run on a really big dataset to collect that enough). If a language has a money type and it can be programmed accordingly, then a problem disappears. If not, then it persists either way in different forms.
I dunno... the only alternative seems to be storing as a float everywhere, since most coding languages don't support a decimal type... and using floats for currency honestly just feels scary to me, since they're not fixed-precision.
I mean I know there are min/max ranges in the float specification that can guarantee no loss of accuracy to two decimal places... but then I need to manually make sure there's never anywhere in the code that might ever sum up transactions to beyond that, or whatever. Or people thinking it's OK to divide and then multiply, which you're hopefully less likely to do if it's an integer.
I feel much more peace of mind storing currency data as integers and doing the conversion. It feels quite natural really, since I'm already used to doing that with datetimes for different timezones.
Python has Decimal, JavaScript has BigNum and so on. I disagree with you - most languages support arbitrary precision numbers. Floats are not needed or wanted.
You so not want to invent your own arbitrary precision numbers
Applications can handle integers just fine, even more of a reason to use them. 64-bit integers will work everywhere seamlessly and you only need to convert once, when showing them in the UI and/or collecting user input.
I'm wary of incentivizing corporations as a personal wealth vehicle, but I still agree with you. Payroll, sales, capital gains, and value added taxes are a great place to shift or grow tax revenues should we ever reduce the corporate tax rate.
The point of capital gains taxes having a separate rate lower than income tax is mostly to account for the fact that corporations pay income tax, so income received from corporations has already been taxed once. One of the perks of abolishing corporate income tax is that it naturally should be paired with abolishing the distinction between capital gains and earned income, a double-whammy of tax code simplification.
>is clearly intended to presuppose the guilt of the defendant
This does not presuppose guilt in a way that would represent a direct conflict of interest in the US Justice system.
The Department of Justice is an executive agency whose directive is to bring indictments like this to trial - like a District Attorney.
The US court system, or the judicial branch, have no obligation to agree with the Department of Justice's position and are actually often don't side with them on matters like this where they test the precedent and definition of the law.
Ironically, the Chinese court system on the other hand has the rule of 3 Supremes - in that the views of the Communist party takes precedent over written law in judgements. In China, if a similar charge levied by the executive branch, this actually means guilt is presupposed in those passing judgement due to their lack of separation.
Perhaps to their target market ... I looked at it and thought 'hmmm, 44 seconds to do a simple image transform sounds pretty slow ....'. I assume it was a very high resolution image or thousands of slices or something but without them stating those metrics it was a bit meaningless to me.
edit: OK I downloaded the image and see it's gigantic ... I reckon they should at least hint at that for the folks who are not quite over the threshold of spending the time to do their experiment ...
I thought the exact opposite. 44 seconds to do a circular motion blur (without any context) as the headline, huh??? What would an average person reading that think?
Of course, after downloading the universe image (which itself took a long time), then it's kind of understandable. Otherwise, it's just confusing as hell. "44 seconds to radial blur the universe" would have at least been better.
It's 'inflated' as in a large section of their enterprise software is included with Azure, similar to GCP with G suite. That being said, Amazon Chime and Workdocs are also included in AWS revenue, but probably make up a much less significant portion of AWS revenue compared to GCP and Azure.
