Jeffrey: I love trying to figure out what you're saying... it's a good replacement for a daily crossword puzzle. :P
Yes if it was relatively easy to define affine transformations between units, then this could possibly open up other more interesting uses in computer graphics, etc. On Fri, Feb 19, 2016 at 9:41 AM, Jeffrey Sarnoff <[email protected]> wrote: > Then also, any named store or carrier of value (as a unique id) and any > named store or carrier of value with named invariant subvaluations. > > For interconversion of units of temperature to be unexceptional, > interconversion logic would 'know' (predispatch on @generated type info) to > apply a linear transformation; for many other physical units > interconversion within a physical dimension would (and does) 'know' to > apply a simple scaling (a linear transformation without the translation). > Presupposing this, what additional things would become supportable > immediately if we augment that predispatch with the ability to apply an > affine transformation (any one or more of {translate, scale, rotate})? > > > On Friday, February 19, 2016 at 7:50:55 AM UTC-5, Tom Breloff wrote: >> >> 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. >>>> >>>>
