Bank transactions do not send in the same field amounts that contain operations to compute. Also they limit the kind of digits they accept for interchanging. A change of sign is a different kind of transaction with different responsabilities, so signs are prohibited, they are replaced by a separate codification of the transaction type.
So the risk may only exist when presenting a signed number to a user and asking him to accept the transaction. There are simialr issues when amounts are using grouping separators and ambiguously use the decimal separator with a precision counting as many digits as there are digits in groups (for most locales, groups are made with 3 digits, so prices always avoid using formats with 3 decimals and most currencies have 0 or 2 decimals of precision). This could be a problem in locales grouping digits by group of 2. If group separators are used to show a price to a user in a UI, it is strongly suggested to avoid anything else than a (narrow) space. If the document will be printed you may avoid all separators and replace the decimal sepator by the currency symbol, or use a modified typography to render the decimals (e.g. in superscript or smaller font size). But the most common confusion when presenting prices to users, is to not clearly state if taxes and additional fees will be applied or have been included, or will have to be paid after the purchase when receiving the product (e.g. buying a product in Australia from Europe: you accept the price in AUD, you know that there will be bank fees to process the change operation, you pay the price to the seller, later your bank performs the change operation and applies a new currency rate plus fees, and you have a second line of payment in your bank account, then a week later you receive the product but to get it you must first pay the import taxes and VAT to the customs (via the postal or delivery service, plus sometimes a new fee to the devlivery service that had to advance the custom taxes and acts as an intermediate). The total price is much higher than that was advertized. Some sellers (notably on the Internet) do not explain clearly that these products will cost more and what to expect, even if they target customers in other countries in their own language as if they had a local branch in that country. Banks are protected from these errors, but not customers. 2015-07-20 17:46 GMT+02:00 "Jörg Knappen" <jknap...@web.de>: > I stumbled over a very strange snippet of javascript code, where an > apparent > minus sign is interpreted as a space here: > > http://stackoverflow.com/questions/31507143/why-does-2-40-equal-42 > > Imagine such kind of behaviour in bank transactions ... > > --Jörg Knappen >