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.
>
>
