Yuan Vs Dollar

Most financial apps use a USD standard. But now the Yuan is floating it's pretty obvious USD is in transition to a dependent rather than independent currency. Yuan vs Euro is now the most common XformsTechnology cross-trade, and XformsTechnology programmers are all faced with the same dilemma: how do we transition to the Yuan as a world-currency standard?

This page is for discussion of XformsTechnology patterns to replace USD based systems with Yuans.

This seems like to be judged an OffTopic page, but since there's the excuse of XformsTechnology:

There's something badly wrong with any technology that needs to be redesigned whenever its preferred unit changes. What if the Yuan does not become the standard you're guessing it will? What if the USD remains so, or if the British pound regains its former glory?

Currency conversion is well-analyzed scientifically as a simple subset of units and unit conversion. To have a preferred fundamental currency in software is merely an abbreviation, like the infamous two-digit abbreviation of year that lead to the Y2K near-crisis (crisis avoided at a cost of many billions $USD). The fix for preferred currency is quite similar to the fix for Y2K: abbreviate and use defaults all you like, so long as they can be overridden dynamically without recompilation, let alone redesign.

To be a bit more specific, a preferred fundamental currency is itself a dependent variable on things like date and country, and often also on the goods that the currency is considered to have as buying power, like gold, or an average over multiple goods, like components of cost of living estimates - so USD(2005, United States, gasoline) may not equal USD(2005, Britain, petrol), despite nominally being the "same" currency with the same official exchange rate in both countries. And that's even skipping questions of market inefficiency where currency arbitrage is workable with two-way (or more typically 3-way or N-way) "momentary" inequalities (which these days may mean seconds, and centuries ago meant weeks) in rates in different areas.

It gets complicated, but like the Y2K issues, that certainly is no excuse for pretending the complexity doesn't even exist.

An asian trading firm may well already be using the Yuan as its preferred currency, and its software may reflect that, but today that is not true in Europe, Britain, the U.S., etc.

See for instance historical inflation data from 1665 at http://oregonstate.edu/Dept/pol_sci/fac/sahr/cf166503.xls which surely should provide food for thought to those who want to tie software to one brief era and/or one geographical region. -- DougMerritt

You seem to be missing a little context. There is no centralized market for currency. Banks trade with one-another 1 to 1 to establish their own views of a currency's value. Any particular trade depends entirely on individual bank perceptions of value which slide around according to the vagaries of human analysts considering the bank's overall currency position and exposure.

In order to give some semblance of stability to this, most trades are performed against a USD standard. If you want to swap, say, kiwis vs aussies, you do a cross-trade - kiwis into USD, then USD into aussies. Now this makes sense only so long as USD is regarded as a stable currency. As its stability is being called into question, the architecture of trading systems is likewise becoming questionable. The dependency doesn't have to do with hard-coding a unit; it has to do with hard-coding a process.

This is a domain with which I have no familiarity, so please bear with a stupid question here: Are you saying that a trade from <CurrencyX> to USD to <CurrencyY> is procedurally different from <CurrencyX> to Yuan to <CurrencyY>? Why? Is this because the trading partners and organizations involved will change, hence the need to adopt and adapt to different established protocols? -- DaveVoorhis

• In the low level details, yes, that's true (with "protocol" meaning "business protocol", these days, not "network protocol" so much any more), and my point is that the software should be written at a higher level of abstraction, so that such differences do not require software reimplementation, let alone redesign. Don't know what the aussie guy we're talking to will say about that. -- DougMerritt

[written prior to DaveVoorhis response:] Perhaps I'm misunderstanding, because I still disagree. I know there's no centralized market that sets universal rates (and it's not just bank to bank, that's merely one of many kinds of trades that reflect a view of a currency's value); anything I said that seemed to imply otherwise was merely because the efficient market hypothesis (which is not absolutely true, but is a good approximation after a bit of time lapse) tends to correct imbalances fairly quickly - which I did comment on briefly.

As I see it, the process should be no more hard-coded than should be the unit: what I said about preferred currency units above applies precisely as well to preferred processes. The best process is a dependent variable. It depends on the time, date, country, etc. There have been periods of time when there was no currency world-wide regarded as safe and stable, you know, and in fact that is what gave rise to fraud-proofing coins a couple thousand years ago, and historically very recently, silver and gold standards, and very recently indeed, stable currency standards.

If you insist on regarding those periods as aberrations outside of your system, then I think you'll be missing my point. A robust system should act as if those unstable times are the default, even if optimizations are made for the times that instability is rare.

In recent times, for instance, the USD is becoming less stable (recent weeks vs Yuan, recent years vs Euro), but is nonetheless still considered for the moment a better gold standard than gold or the Yuan, and even over the Euro, although less so than a few years ago. You are speculating that the Yuan will take over the role that the USD currently plays, but nothing you said about stability and "process vs unit" changes my point that system should be able to dynamically adapt, rather than needing redesign. Why hardwire cross-trading? The appropriate approach seems to me to very much reflect the underlying truth that all appropriate units and processes are dependendent variables, expected to change over time. -- DougMerritt

---

Stupid question, but what have Xforms got to do with the Yuan, or any other currency?

Yes. Huh? Somebody please shed some light.