Re: [julia-users] Unitful.jl for physical units

[Scott Jones]

On Friday, February 19, 2016 at 10:31:07 AM UTC-5, Tom Breloff wrote:

> Jeffrey:  I love trying to figure out what you're saying... it's a good 
> replacement for a daily crossword puzzle.  :P
>

Yes, I second that!  I always found Jeffrey's language quite refreshing, 
but then again, I'm significantly challenged in my on-line communications 
skills myself,
so maybe that's not a great recommendation!

Re: [julia-users] Unitful.jl for physical units

[Tom Breloff]

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

Re: [julia-users] Unitful.jl for physical units

[Tom Breloff]

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

Re: [julia-users] Unitful.jl for physical units

[Tim Holy]

I have long been meaning to get around to making SIUnits type-stable under 
arithmetic. I've only glanced at your code, but it looks like you just 
scratched one big, bad TODO item off my list! Seems like you've included a 
number of other nice features, too (many thanks for the microns support, it 
will make a difference). I'll be excited to play with this.

Best,
--Tim

On Friday, February 12, 2016 12:23:22 PM Andrew Keller wrote:
> I'm happy to share a package I wrote for using physical units in Julia,
> Unitful.jl . Much credit and
> gratitude is due to Keno Fischer for the SIUnits.jl
>  package which served as my
> inspiration. This is a work in progress, but I think perhaps a serviceable
> one depending on what you're doing.
> 
> Like SIUnits.jl, this package encodes units in the type signature to avoid
> run-time performance penalties. From there, the implementations diverge.
> The package is targeted to Julia 0.5 / master, as there are some
> limitations with how promote_op is used in Julia 0.4 (#13803)
> . I decided it wasn't worth
> targeting 0.4 if the behavior would be inconsistent.
> 
> Some highlights include:
> 
>- Non-SI units are treated on the same footing as SI units, with only a
>few exceptions (unit conversion method). Use whatever weird units you
>want.
>- Support for units like micron / (meter Kelvin), where some of the
>units could cancel out but you don't necessarily want them to.
>- Support for LinSpace and other Range types. Probably there are still
>some glitches to be found, though.
>- Support for rational exponents of units.
>- Some tests (see these for usage examples).
> 
> Please see the documentation for a comprehensive discussion, including
> issues / to do list, as well as how to add your own units, etc.
> Comments and feedback are welcome.
> 
> Best,
> Andrew Keller

Re: [julia-users] Unitful.jl for physical units

[Tom Breloff]

Andrew this looks really great.  Thanks for the contribution!

On Fri, Feb 12, 2016 at 4:27 PM, Tim Holy  wrote:

> I have long been meaning to get around to making SIUnits type-stable under
> arithmetic. I've only glanced at your code, but it looks like you just
> scratched one big, bad TODO item off my list! Seems like you've included a
> number of other nice features, too (many thanks for the microns support, it
> will make a difference). I'll be excited to play with this.
>
> Best,
> --Tim
>
> On Friday, February 12, 2016 12:23:22 PM Andrew Keller wrote:
> > I'm happy to share a package I wrote for using physical units in Julia,
> > Unitful.jl . Much credit
> and
> > gratitude is due to Keno Fischer for the SIUnits.jl
> >  package which served as my
> > inspiration. This is a work in progress, but I think perhaps a
> serviceable
> > one depending on what you're doing.
> >
> > Like SIUnits.jl, this package encodes units in the type signature to
> avoid
> > run-time performance penalties. From there, the implementations diverge.
> > The package is targeted to Julia 0.5 / master, as there are some
> > limitations with how promote_op is used in Julia 0.4 (#13803)
> > . I decided it wasn't
> worth
> > targeting 0.4 if the behavior would be inconsistent.
> >
> > Some highlights include:
> >
> >- Non-SI units are treated on the same footing as SI units, with only
> a
> >few exceptions (unit conversion method). Use whatever weird units you
> >want.
> >- Support for units like micron / (meter Kelvin), where some of the
> >units could cancel out but you don't necessarily want them to.
> >- Support for LinSpace and other Range types. Probably there are still
> >some glitches to be found, though.
> >- Support for rational exponents of units.
> >- Some tests (see these for usage examples).
> >
> > Please see the documentation for a comprehensive discussion, including
> > issues / to do list, as well as how to add your own units, etc.
> > Comments and feedback are welcome.
> >
> > Best,
> > Andrew Keller
>
>

Re: [julia-users] Unitful.jl for physical units

[Stefan Karpinski]

This is very, very cool. The implementation does seems to suggest some
interesting potential way that Base could support this better. Please don't
hesitate to bring these up as issues or on julia-dev. Really smooth support
for units in Julia is a killer feature.

On Fri, Feb 12, 2016 at 3:23 PM, Andrew Keller 
wrote:

> I'm happy to share a package I wrote for using physical units in Julia,
> Unitful.jl . Much credit
> and gratitude is due to Keno Fischer for the SIUnits.jl
>  package which served as my
> inspiration. This is a work in progress, but I think perhaps a serviceable
> one depending on what you're doing.
>
> Like SIUnits.jl, this package encodes units in the type signature to avoid
> run-time performance penalties. From there, the implementations diverge.
> The package is targeted to Julia 0.5 / master, as there are some
> limitations with how promote_op is used in Julia 0.4 (#13803)
> . I decided it wasn't
> worth targeting 0.4 if the behavior would be inconsistent.
>
> Some highlights include:
>
>- Non-SI units are treated on the same footing as SI units, with only
>a few exceptions (unit conversion method). Use whatever weird units
>you want.
>- Support for units like micron / (meter Kelvin), where some of the
>units could cancel out but you don't necessarily want them to.
>- Support for LinSpace and other Range types. Probably there are still
>some glitches to be found, though.
>- Support for rational exponents of units.
>- Some tests (see these for usage examples).
>
> Please see the documentation for a comprehensive discussion, including
> issues / to do list, as well as how to add your own units, etc.
> Comments and feedback are welcome.
>
> Best,
> Andrew Keller
>

[julia-users] Unitful.jl for physical units

[Andrew Keller]

I'm happy to share a package I wrote for using physical units in Julia, 
Unitful.jl . Much credit and 
gratitude is due to Keno Fischer for the SIUnits.jl 
 package which served as my 
inspiration. This is a work in progress, but I think perhaps a serviceable 
one depending on what you're doing. 

Like SIUnits.jl, this package encodes units in the type signature to avoid 
run-time performance penalties. From there, the implementations diverge. 
The package is targeted to Julia 0.5 / master, as there are some 
limitations with how promote_op is used in Julia 0.4 (#13803) 
. I decided it wasn't worth 
targeting 0.4 if the behavior would be inconsistent. 

Some highlights include:

   - Non-SI units are treated on the same footing as SI units, with only a 
   few exceptions (unit conversion method). Use whatever weird units you 
   want.
   - Support for units like micron / (meter Kelvin), where some of the 
   units could cancel out but you don't necessarily want them to.
   - Support for LinSpace and other Range types. Probably there are still 
   some glitches to be found, though.
   - Support for rational exponents of units.
   - Some tests (see these for usage examples).

Please see the documentation for a comprehensive discussion, including 
issues / to do list, as well as how to add your own units, etc.
Comments and feedback are welcome.

Best,
Andrew Keller