Currencies could be applicable, but not converting between countries (for practical reasons already mentioned). The use could be:
100 cent == 1 dollar 1000 dollar == 1 kdollar etc 1 == 100 percent 100 bip == 1 percent etc 1 dollar * 1 percent == 1 cent I could see some nice applications for this stuff (including replacing a special "Price" type that I have) On Friday, February 19, 2016, Jeffrey Sarnoff <[email protected]> wrote: > Jake, > > code_warntype( function, (argtype, ..) ) is helpful, and so is the > Benchmarks package https://github.com/johnmyleswhite/Benchmarks.jl > > for Unitful, > > julia> code_warntype(+,(typeof(1m),typeof(1m))) > Variables: > #self#::Base.#+ > x::Unitful.RealQuantity{Int64,Unitful.UnitData{(m,)}} > y::Unitful.RealQuantity{Int64,Unitful.UnitData{(m,)}} > > Body: > begin # /home/jas/.julia/v0.5/Unitful/src/Unitful.jl, line 321: > return $(Expr(:new, > Unitful.RealQuantity{Int64,Unitful.UnitData{(m,)}}, > :((Base.box)(Int64,(Base.add_int)((top(getfield))(x::Unitful.RealQuantity{Int64,Unitful.UnitData{(m,)}},:val)::Int64,(top(getfield))(y::Unitful.RealQuantity{Int64,Unitful.UnitData{(m,)}},:val)::Int64))))) > end::Unitful.RealQuantity{Int64,Unitful.UnitData{(m,)}} > > and > @benchmark 1m+1cm shows 0 bytes were allocated > > for your code > > julia> code_warntype(+,(typeof(1m),typeof(1m))) > Variables: > a::Meter{1,0} > b::Meter{1,0} > mag::Int64 > aval::Any > bval::Any > #s4::Int64 > > Body: > begin # none, line 4: > GenSym(0) = (Main.normalize)(a::Meter{1,0},b::Meter{1,0}):: > Tuple{Int64,Any,Any} > #s4 = 1 > GenSym(4) = (Base.getfield)(GenSym(0),1)::Any > GenSym(5) = (Base.box)(Base.Int,(Base.add_int)(1,1)) > mag = GenSym(4) > #s4 = GenSym(5) > GenSym(6) = (Base.getfield)(GenSym(0),2)::Any > GenSym(7) = (Base.box)(Base.Int,(Base.add_int)(2,1)) > aval = GenSym(6) > #s4 = GenSym(7) > GenSym(8) = (Base.getfield)(GenSym(0),3)::Any > GenSym(9) = (Base.box)(Base.Int,(Base.add_int)(3,1)) > bval = GenSym(8) > #s4 = GenSym(9) # none, line 5: > return call((top(apply_type))(Main.Meter,1,mag::Int64):: > Type{_<:Meter{1,magnitude}},aval + bval::Any)::Meter{d,magnitude} > end::Meter{d,magnitude} > > and > @benchmark 1m+1m show 48 bytes allocated > > Anything code_warntype highlights indicates type ambiguity or lack of type > specialization; that derails multidispatched specialization, and so costs > time. And code that does not allocate memory is, in a sense, doing more > with less -- or doing more earlier, so it does less at runtime. > > > > On Friday, February 19, 2016 at 3:13:10 AM UTC-5, Tamas Papp wrote: >> >> Exchange rates are prices, and thus are (1) dynamic (and can be very >> volatile even in the short run) and (2) dispersed: you observe multiple >> exchange rates depending on quantity, location, assets exchanged >> (banknotes or other claims). >> >> It is very difficult to make a "general" library for exchange rates, not >> because of the coding, but because of conceptual issues. Specific >> applications (eg accounting with a given source of "official" exchange >> rates, or a trader in a specific market) allow you to make further >> assumptions and simplify. >> >> In particular, I don't see how exchange rates fit with SI units at all. >> >> Best, >> >> Tamas >> >> On Thu, Feb 18 2016, Jeffrey Sarnoff wrote: >> >> > I am thinking about how Currencies would fit with software for handling >> SI >> > and other physical dimensions and the usual units of measure. >> > The following approach seems workable and (mostly) not disruptive to >> the >> > working and evolving code Andrew Keller offers the community. >> > >> > A currency behaves as a representation of, or a stand-in or proxy for >> all >> > the banknotes, sovereign wealth and other property interests of a >> nation. >> > Two or more currencies for which there is a market that allows one to >> be >> > converted into another at an agreed upon, current rate of exchange are >> not >> > that different from two or more units of length or units of time that >> are >> > allowed to be converted into one another using a predefined >> multiplicative >> > ratio. >> > >> > (now, 1.0 US Dollar = 8.45536 Swedish Krona, refreshing the page, >> now >> > 1.0 US Dollar = 8.45518 Swedish Krona) >> > >> > The most impactful distinction is that rates of exchange are dynamic >> while >> > the physical conversion factors (BIPM standards, CODATA values) >> persist. >> > However currencies may be accommodated, it must protect our ability >> work >> > with units with ease and with invisibly amortized processing overhead. >> > So, the request that gets the appropriate exchange rate to use when >> > converting from one currency to another must come from the Units code >> in a >> > way that does not require other physical unit conversions to operate >> any >> > differently. >> > >> > One of the things on Andrew's future to do list is allow measures and >> their >> > uncertainties to be used and to interact respecting the uncertainty >> math. >> > In any currency exchange trade, there is a buyer and a seller. >> Usually, >> > when they (or their requests) meet, they disagree. The buyer wants to >> pay >> > as little as possible and the seller wants to receive as much as >> possible. >> > That separation is called the bid-ask spread (the buyer bids, the >> seller >> > asks); almost always it is very, very small relative to the total value >> > being exchanged. The uncertainties associated with physical measures >> and >> > conversions usually are very, very small relative to the total quantity >> > being determined or the value being mapped into different units. When >> > uncertainty management is introduced, it is conceivable that currency >> > support could take advantage of that analogous role. >> >>
