Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Scott Jones]

How would this fit in with Jeff's work on types/subtypes?
At JuliaCon he did talk about improving the type system (something I've 
been really hoping to see).
It seems to me that it might be more logically consistent to return a type 
union for this, but I understand that currently it is easier to work with 
returning a simple sorted vector.

Scott

On Sunday, December 27, 2015 at 12:10:38 AM UTC-5, Kevin Squire wrote:
>
>
>
> On Saturday, December 26, 2015, Ray Toal  
> wrote:
>
>> I noticed that 
>>
>> *julia> **subtypes(Type)*
>>
>> *3-element Array{Any,1}:*
>>
>> * DataType  *
>>
>> * TypeConstructor*
>>
>> * Union *
>>
>> and was wondering if there was any significance in the order of the 
>> subtypes. If not, could the method have produced a Set instead?
>>
>>
> It could, but why?  A set has a bit more overhead than an array, and for 
> most types, the number of subtypes is small enough that sets wouldn't 
> really offer any advantage.
>
> Is there something you want to do with the results that you think requires 
> a set?
>
> Cheers,
> Kevin  
>

[julia-users] Re: strange behavior with float value multiplication

[Ismael Venegas Castelló]

You can see the binary representation of those `Float64`s with the `bits` 
function:

julia> for i in 1:10
 @show bits(a * i)
   end
bits(a * i) = 
"00001001100110011001100110011001100110011001100110011010"

bits(a * i) = 
"00011001100110011001100110011001100110011001100110011010"

bits(a * i) = 
"00100011001100110011001100110011001100110011001100110100"

bits(a * i) = 
"00101001100110011001100110011001100110011001100110011010"

bits(a * i) = 
"0011"

bits(a * i) = 
"00110011001100110011001100110011001100110011001100110100"

bits(a * i) = 
"00110110011001100110011001100110011001100110011001100111"

bits(a * i) = 
"00111001100110011001100110011001100110011001100110011010"

bits(a * i) = 
"0000110011001100110011001100110011001100110011001101"

bits(a * i) = 
"0100"



El lunes, 28 de diciembre de 2015, 3:59:24 (UTC-6), Yonghee Kim escribió:
>
> I wrote simple code like this
>
> --
> a = 0.2
>
> for i in 1:10
>   println(a * i)
> end
> ---
>
>
> and what I got is not 0.2, 0.4, 0.6, 0.8, 1.0  
>
> but this.
>
> 0.2
> 0.4
> 0.6001
> 0.8
> 1.0
> 1.2002
> 1.4001
> 1.6
> 1.8
> 2.0
>
>
>
> println(0.2 * 3) does the same thing. not 0.6 but 0.6001
>
> does anyone know why this happens? 
>
>

Re: [julia-users] Re: passing function as arguments and avoiding unecessary allocations

[Ismael VC]

How about this?

julia> sinc{T<:AbstractFloat}(x::T) = x != 0 ? sin(π*x)/(π*x) : one(T)
sinc (generic function with 1 method)

julia> methods(sinc)
# 1 method for generic function "sinc":
sinc{T<:AbstractFloat}(x::T<:AbstractFloat) at none:1

julia> @vectorize_1arg AbstractFloat sinc
sinc (generic function with 4 methods)

julia> methods(sinc)
# 4 methods for generic function "sinc":
sinc{T<:AbstractFloat}(x::T<:AbstractFloat) at none:1
sinc{T<:AbstractFloat}(::AbstractArray{T<:AbstractFloat,1}) at operators.jl:380
sinc{T<:AbstractFloat}(::AbstractArray{T<:AbstractFloat,2}) at operators.jl:381
sinc{T<:AbstractFloat}(::AbstractArray{T<:AbstractFloat,N}) at operators.jl:383

julia> @time sinc(rand(10_000));
  0.055184 seconds (45.92 k allocations: 2.139 MB)

julia> @time sinc(rand(10_000));
  0.000251 seconds (10 allocations: 156.563 KB)

julia> @code_warntype sinc(rand(10_000))
Variables:
  #102#x::Array{Float64,1}
  #s76::Int64
  #s75::Int64
  #s74::Int64
  #101#i::Int64
  #s73::Int64

Body:
  begin  # operators.jl, line 380:
  GenSym(8) = (Base.arraylen)(#102#x::Array{Float64,1})::Int64
  GenSym(0) = $(Expr(:new, UnitRange{Int64}, 1, :(((top(getfield))(Base.Intr
insics,:select_value)::I)((Base.sle_int)(1,GenSym(8))::Bool,GenSym(8),(Base.box)
(Int64,(Base.sub_int)(1,1)))::Int64)))
  GenSym(1) = (Base.box)(Int64,(Base.checked_sadd)((Base.box)(Int64,(Base.ch
ecked_ssub)((top(getfield))(GenSym(0),:stop)::Int64,(top(getfield))(GenSym(0),:s
tart)::Int64)),1))
  0:
  GenSym(3) = (top(ccall))(:jl_alloc_array_1d,(top(apply_type))(Base.Array,F
loat64,1)::Type{Array{Float64,1}},(top(svec))(Base.Any,Base.Int)::SimpleVector,A
rray{Float64,1},0,GenSym(1),0)::Array{Float64,1}
  #s76 = 1
  #s75 = (top(getfield))(GenSym(0),:start)::Int64
  #s74 = 0
  unless (Base.box)(Base.Bool,(Base.not_int)(#s74::Int64 === GenSym(1)::Bool
)) goto 2
  3:
  #s74 = (Base.box)(Base.Int,(Base.add_int)(#s74::Int64,1))
  GenSym(10) = #s75::Int64
  GenSym(11) = (Base.box)(Base.Int,(Base.add_int)(#s75::Int64,1))
  #s73 = 1
  GenSym(12) = GenSym(10)
  GenSym(13) = (Base.box)(Base.Int,(Base.add_int)(1,1))
  #101#i = GenSym(12)
  #s73 = GenSym(13)
  GenSym(14) = GenSym(11)
  GenSym(15) = (Base.box)(Base.Int,(Base.add_int)(2,1))
  #s75 = GenSym(14)
  #s73 = GenSym(15)
  GenSym(4) = (Main.sinc)((Base.arrayref)(#102#x::Array{Float64,1},#101#i::I
nt64)::Float64)::Float64
  $(Expr(:type_goto, 0, GenSym(4)))
  $(Expr(:boundscheck, false))
  (Base.arrayset)(GenSym(3),GenSym(4),#s76::Int64)::Array{Float64,1}
  $(Expr(:boundscheck, :(Main.pop)))
  #s76 = (Base.box)(Base.Int,(Base.add_int)(#s76::Int64,1))
  4:
  unless (Base.box)(Base.Bool,(Base.not_int)((Base.box)(Base.Bool,(Base.not_
int)(#s74::Int64 === GenSym(1)::Bool goto 3
  2:
  1:
  return GenSym(3)
  end::Array{Float64,1}

julia> sinc(rand(4, 4))
4x4 Array{Float64,2}:
 0.671308  0.28010.110566  0.0508818
 0.201512  0.416824  0.993366  0.537811
 0.999858  0.74607   0.836841  0.0222563
 0.592876  0.667453  0.612684  0.81811

julia> sinc(rand(4, 4, 2))
4x4x2 Array{Float64,3}:
[:, :, 1] =
 0.1301 0.406598  0.95419   0.0530077
 0.810275   0.917711  0.94  0.289211
 0.0391342  0.970136  0.456169  0.34722
 0.565740.726088  0.956873  0.99049

[:, :, 2] =
 0.632377  0.844147  0.963265  0.0472808
 0.569625  0.834078  0.183842  0.323166
 0.51727   0.989112  0.568156  0.874306
 0.533161  0.988943  0.931382  0.133851

julia>

​

Ismael Venegas Castelló

*Data Analyst*

Cel. 044 55 6434 0229

ivene...@richit.com.mx

Cerro San Francisco 357, C.P. 04200

Campestre Churubusco, Coyoacán

Ciudad de México




  

Tel. 6718 1818
richit.com.mx

2015-12-27 15:00 GMT-06:00 alan souza :

> Thanks for the tip. I was trying to annotate the function call before the
> loop without success.
>
> Do you know the reason for the speedup? Because the extra allocations
> still happening albeit a little less.
>
> thanks
>
> On Sunday, December 27, 2015 at 5:07:56 PM UTC-2, Lutfullah Tomak wrote:
>>
>> It seems adding typecheck is 2x improvements in my laptop.
>>y = zeros(T, n)
>> for i in eachindex(X)
>> y[i] = F(X[i])::T
>> end
>> return y
>>
>

[julia-users] strange behavior with float value multiplication

[Yonghee Kim]

I wrote simple code like this

--
a = 0.2

for i in 1:10
  println(a * i)
end
---


and what I got is not 0.2, 0.4, 0.6, 0.8, 1.0  

but this.

0.2
0.4
0.6001
0.8
1.0
1.2002
1.4001
1.6
1.8
2.0



println(0.2 * 3) does the same thing. not 0.6 but 0.6001

does anyone know why this happens? 

Re: [julia-users] strange behavior with float value multiplication

[Pranit Bauva]

Dear Yonghee Kim,

Floating point calculations are not exact because the decimal point is
represented by only a fixed number of binary digits. The more is the
bits allocated more will be the precision. This explanation would be
clearer if you see how to convert floating point integers to binary.
http://stackoverflow.com/questions/3954498/how-to-convert-float-number-to-binary

The series will be more and more accurate if more number of terms are
added and will each added term it error will decrease by 2^-(no of
terms). Furthermore this is the problem with almost every programming
language.

Regards,
Pranit Bauva

On Mon, Dec 28, 2015 at 3:29 PM, Yonghee Kim  wrote:
> I wrote simple code like this
>
> --
> a = 0.2
>
> for i in 1:10
>   println(a * i)
> end
> ---
>
>
> and what I got is not 0.2, 0.4, 0.6, 0.8, 1.0 
>
> but this.
>
> 0.2
> 0.4
> 0.6001
> 0.8
> 1.0
> 1.2002
> 1.4001
> 1.6
> 1.8
> 2.0
>
>
>
> println(0.2 * 3) does the same thing. not 0.6 but 0.6001
>
> does anyone know why this happens?

Re: [julia-users] Re: How to avoid extra allocations when passing a function as parameter

[Ismael VC]

Yes, from version 0.4 onwards you can use T <: AbstractFloat, for version
0.3 and before, I think it would be T <: FloatingPoint.
​

Ismael Venegas Castelló

*Data Analyst*

Cel. 044 55 6434 0229

ivene...@richit.com.mx

Cerro San Francisco 357, C.P. 04200

Campestre Churubusco, Coyoacán

Ciudad de México




  

Tel. 6718 1818
richit.com.mx

2015-12-27 14:58 GMT-06:00 alan souza :

> Sorry for the double posting.
> Actually I was only interested for "decimal" inputs (single and double
> precision) is there a better way to express this instead of using Real?
> thanks
>
>
> On Sunday, December 27, 2015 at 6:09:30 PM UTC-2, Ismael Venegas Castelló
> wrote:
>>
>> For calcF your variables:
>>
>> Variables:
>>   X::Array{Float64,1}
>>   F::F
>>   n::Int64
>>   y::Array{Float64,1}
>>   #s76::Int64
>>   i::Int64
>>   ##dims#7321::Tuple{Int64}
>>
>> and return value:
>>
>> return y::Array{Float64,1}
>> end::Array{Float64,1}
>>
>> Are correctly inferred if I use floats so it seems fine.
>>
>> But if I use int's as arguments to main I get an InexactError, are you
>> sure it should accept `T <: Real`?  Maybe you just need Float64?
>>
>>
>>
>> El domingo, 27 de diciembre de 2015, 11:21:35 (UTC-6), alan souza
>> escribió:
>>>
>>> Hi. I was wondering what is the correct way to pass a function as
>>> argument preserving the return type information of this function
>>>
>>> For instance in the following code:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *function sinc{T<:Real}(x::T)return T((x != zero(T)
>>> )?(sin(pi*x)/(pi*x)):(one(T)))endfunction calcF{T<:Real}(X::Array{T,1},
>>> F::Function)n = length(X); @assert(n > 0)y = zeros(T, n)for
>>> i in eachindex(X)y[i] = F(X[i])endreturn yendfunction
>>> calcSinc{T<:Real}(X::Array{T,1})n = length(X); @assert(n > 0)y
>>> = zeros(T, n)for i in eachindex(X)y[i] = sinc(X[i])end
>>> return yendfunction main{T<:Real}(min::T, max::T, d::T)X =
>>> collect(min:d:max)calcF(X, sinc)calcSinc(X)@code_warntype
>>> calcF(X, sinc)@time calcF(X, sinc)@code_warntype calcSinc(X)
>>> @time calcSinc(X)YF = calcF(X, sinc)YS = calcSinc(X)end*
>>>
>>> Running this code with julia (versions 0.5+dev or 0.4.2) I got these
>>> results:
>>>
>>>
>>>
>>>
>>>
>>>
>>> *  #s1 = GenSym(5) # /home/me/scratch/julia_fd/teste.jl, line
>>> 10:  GenSym(2) =
>>> (F::F)((Base.arrayref)(X::Array{Float64,1},i::Int64)::Float64)::ANY
>>> (Base.arrayset)(y::Array{Float64,1},(top(typeassert))((Base.convert)(Float64,GenSym(2))::ANY,Float64)::Float64,i::Int64)::Array{Float64,1}
>>> 5:   unless
>>> (Base.box)(Base.Bool,(Base.not_int)((Base.box)(Base.Bool,(Base.not_int)(#s1::Int64
>>> ===
>>> (Base.box)(Base.Int,(Base.add_int)((top(getfield))(GenSym(0),:stop)::Int64,1))::Bool
>>> goto 4  3:   0.080181 seconds (1.88 M allocations: 33.556 MB, 6.41% gc
>>> time)*
>>>
>>> and for the calcSinc function:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *   #s1 = GenSym(5) # /home/me/scratch/julia_fd/teste.jl, line 20:
>>> GenSym(2) =
>>> (Main.sinc)((Base.arrayref)(X::Array{Float64,1},i::Int64)::Float64)::Float64
>>> (Base.arrayset)(y::Array{Float64,1},GenSym(2),i::Int64)::Array{Float64,1}
>>> 5:   unless
>>> (Base.box)(Base.Bool,(Base.not_int)((Base.box)(Base.Bool,(Base.not_int)(#s1::Int64
>>> ===
>>> (Base.box)(Base.Int,(Base.add_int)((top(getfield))(GenSym(0),:stop)::Int64,1))::Bool
>>> goto 4  3:   0.031224 seconds (2 allocations: 4.794 MB)*
>>> Is there a way to prevent the result of function to "evaluate" to ::Any
>>> on the first case?
>>>
>>> thanks
>>>
>>>

Re: [julia-users] strange behavior with float value multiplication

[Yonghee Kim]

Dear Pranit Bauva 

Thanks for your kind explanation!
your answer helped me a lot. 

[julia-users] Re: How to avoid extra allocations when passing a function as parameter

[alan souza]

Sorry for the double posting.
Actually I was only interested for "decimal" inputs (single and double 
precision) is there a better way to express this instead of using Real?
thanks

On Sunday, December 27, 2015 at 6:09:30 PM UTC-2, Ismael Venegas Castelló 
wrote:
>
> For calcF your variables:
>
> Variables:
>   X::Array{Float64,1}
>   F::F
>   n::Int64
>   y::Array{Float64,1}
>   #s76::Int64
>   i::Int64
>   ##dims#7321::Tuple{Int64}
>
> and return value:
>
> return y::Array{Float64,1}
> end::Array{Float64,1}
>
> Are correctly inferred if I use floats so it seems fine.
>
> But if I use int's as arguments to main I get an InexactError, are you 
> sure it should accept `T <: Real`?  Maybe you just need Float64?
>
>
>
> El domingo, 27 de diciembre de 2015, 11:21:35 (UTC-6), alan souza escribió:
>>
>> Hi. I was wondering what is the correct way to pass a function as 
>> argument preserving the return type information of this function
>>
>> For instance in the following code:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *function sinc{T<:Real}(x::T)return T((x != zero(T) 
>> )?(sin(pi*x)/(pi*x)):(one(T)))endfunction calcF{T<:Real}(X::Array{T,1}, 
>> F::Function)n = length(X); @assert(n > 0)y = zeros(T, n)for 
>> i in eachindex(X)y[i] = F(X[i])endreturn yendfunction 
>> calcSinc{T<:Real}(X::Array{T,1})n = length(X); @assert(n > 0)y 
>> = zeros(T, n)for i in eachindex(X)y[i] = sinc(X[i])end
>> return yendfunction main{T<:Real}(min::T, max::T, d::T)X = 
>> collect(min:d:max)calcF(X, sinc)calcSinc(X)@code_warntype 
>> calcF(X, sinc)@time calcF(X, sinc)@code_warntype calcSinc(X)
>> @time calcSinc(X)YF = calcF(X, sinc)YS = calcSinc(X)end*
>>
>> Running this code with julia (versions 0.5+dev or 0.4.2) I got these 
>> results:
>>
>>
>>
>>
>>
>>
>> *  #s1 = GenSym(5) # /home/me/scratch/julia_fd/teste.jl, line 
>> 10:  GenSym(2) = 
>> (F::F)((Base.arrayref)(X::Array{Float64,1},i::Int64)::Float64)::ANY  
>> (Base.arrayset)(y::Array{Float64,1},(top(typeassert))((Base.convert)(Float64,GenSym(2))::ANY,Float64)::Float64,i::Int64)::Array{Float64,1}
>>   
>> 5:   unless 
>> (Base.box)(Base.Bool,(Base.not_int)((Base.box)(Base.Bool,(Base.not_int)(#s1::Int64
>>  
>> === 
>> (Base.box)(Base.Int,(Base.add_int)((top(getfield))(GenSym(0),:stop)::Int64,1))::Bool
>>  
>> goto 4  3:   0.080181 seconds (1.88 M allocations: 33.556 MB, 6.41% gc 
>> time)*
>>
>> and for the calcSinc function:
>>
>>
>>
>>
>>
>>
>>
>> *   #s1 = GenSym(5) # /home/me/scratch/julia_fd/teste.jl, line 20:  
>> GenSym(2) = 
>> (Main.sinc)((Base.arrayref)(X::Array{Float64,1},i::Int64)::Float64)::Float64 
>>  
>> (Base.arrayset)(y::Array{Float64,1},GenSym(2),i::Int64)::Array{Float64,1}
>>   
>> 5:   unless 
>> (Base.box)(Base.Bool,(Base.not_int)((Base.box)(Base.Bool,(Base.not_int)(#s1::Int64
>>  
>> === 
>> (Base.box)(Base.Int,(Base.add_int)((top(getfield))(GenSym(0),:stop)::Int64,1))::Bool
>>  
>> goto 4  3:   0.031224 seconds (2 allocations: 4.794 MB)*
>> Is there a way to prevent the result of function to "evaluate" to ::Any 
>> on the first case?
>>
>> thanks
>>
>>

[julia-users] Re: passing function as arguments and avoiding unecessary allocations

[alan souza]

Thanks for the tip. I was trying to annotate the function call before the 
loop without success.

Do you know the reason for the speedup? Because the extra allocations still 
happening albeit a little less.

thanks

On Sunday, December 27, 2015 at 5:07:56 PM UTC-2, Lutfullah Tomak wrote:
>
> It seems adding typecheck is 2x improvements in my laptop.
>y = zeros(T, n)
> for i in eachindex(X)
> y[i] = F(X[i])::T
> end
> return y
>

[julia-users] Re: strange behavior with float value multiplication

[Scott Jones]

That is simply because you are using binary floating point (Float64 in 
Julia), instead of decimal floating point.  There is a very nice package, 
DecFP.jl, (kudos to Steven Johnson, @stevengj on GitHub), that wraps the 
Intel decimal arithmetic library.
You can do `Pkg.add("DecFP") ; using DecFP` (you may get a lot of 
deprecation warnings, esp. on v0.5, you can also do a 
`Pkg.checkout("DecFP") ; Pkg.build("DecFP")` to eliminate all but one 
warning on v0.5), and then you can do:

julia> a = d"0.2"
+2E-1 

julia> for i in 1:10 ; println(a * i) ; end 
+2E-1 
+4E-1 
+6E-1 
+8E-1 
+10E-1 
+12E-1 
+14E-1 
+16E-1 
+18E-1 
+20E-1

The output is a bit funny, but the answers are exact, unlike most of the 
answers in the binary floating point case you showed.

Note: the most heavily used language in the world (at least up to the early 
2000s, I'm not sure what the stats would be like now), which was the 2nd 
ANSI standardized language, Cobol,
originally only had decimal arithmetic (Modern Cobols also support IEEE 
binary floating point).
A number of other heavily used (but not much talked about) languages, such 
as M/MUMPS, which happened to be the 3rd language standardized by ANSI, 
even before ANSI C.
The most used version of M/MUMPS these days is Caché ObjectScript - which 
adds many things, including objects and IEEE binary floats.
The Pick/MultiValue family of database languages also use decimal floating 
point.

There is now the IEEE 754-2008 standard for decimal floating point, which 
the DecFP.jl package conforms to (implementing 3 of the formats - there are 
some more formats which I'm trying to write a package for, which are also 
implemented in hardware on IBM POWER architecture processors).

There are a number of cases where it really is better to use decimal 
arithmetic, in order to not get in trouble with the tax man! (Lots of 
currency operations have this same issue)
Here's a real simple example: you have a store, where you sell something 
for 70 cents, and there is a 5% sales tax.  How much do tax to you charge 
the customer?

*julia>tax = *
> *.7 * 0.05*
> *0.034996**julia> *
> *round(tax,2)*
> *0.03**julia> tax = *
> *d".70" * d"0.05"*
> *+350E-4**julia> *
> *round(tax,2)**+4E-2*


As you can see, with binary floating point, you get the wrong answer 
(0.03), but with decimal floating point, you get the correct answer (the 
one the tax authorities will want you to give them).

Depending on your particular use case, you can either use the default IEEE 
binary floating point numbers in Julia, or the DecFP.jl package.

Scott

On Monday, December 28, 2015 at 4:59:24 AM UTC-5, Yonghee Kim wrote:
>
> I wrote simple code like this
>
> --
> a = 0.2
>
> for i in 1:10
>   println(a * i)
> end
> ---
>
>
> and what I got is not 0.2, 0.4, 0.6, 0.8, 1.0  
>
> but this.
>
> 0.2
> 0.4
> 0.6001
> 0.8
> 1.0
> 1.2002
> 1.4001
> 1.6
> 1.8
> 2.0
>
>
>
> println(0.2 * 3) does the same thing. not 0.6 but 0.6001
>
> does anyone know why this happens? 
>
>

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Stefan Karpinski]

No, please don't spend time on this. We're not going to change this to
return a heavyweight data structure like a Set when a simple structure like
and Array will do. In mathematics sets are simpler than ordered
collections, but in programming languages the relationship is reversed. In
general data structures like Set are only used when they are necessary,
such as when you need O(1) checking for inclusion. Since there's no such
need here, an array is simpler and better.

On Mon, Dec 28, 2015 at 2:40 AM, Kevin Squire 
wrote:

> Hi Ray,
>
> You're probably the first person to make this observation. I can see your
> point, and I don't really have a strong argument or opinion, really--the
> main reason it's sorted is probably because it looks nicer--at least if I
> did write that code, that would  have been my reasoning.
>
> If you're up for it, you could change it to create a set and submit a pull
> request. No guarantees it gets accepted, but the likelihood increases
> significantly over not submitting one. :-)
>
> Cheers,
>Kevin
>
>
> On Sunday, December 27, 2015, Ray Toal  wrote:
>
>> I'm sure the order won't ever change, but I'd still find it odd if the
>> documentation of subtypes were to say
>>
>> "Returns a list of subtypes, sorted by the name of the subtype"
>>
>> because, well, what about namespaces? What about all sorts of Unicode
>> collation definitions that would have to be a part of such a definition?
>>
>> Yes, as much as I would like to just assert that the result of calling
>> subtypes on Type produces the array [DataType, TypeConstructor, Union] it's
>> just not supposed to be an array, even if today we can guarantee that the
>> array will be sorted, and it is ridiculously unlikely to change.
>>
>> I just think of unordered collections as sets. I don't think anyone would
>> or should ever write code that takes advantage of the fact that this array
>> is sorted, though. :)
>>
>> Thanks for the responses
>>
>> Ray
>>
>>
>> On Sunday, December 27, 2015 at 5:10:46 PM UTC-8, Kevin Squire wrote:
>>>
>>> Thanks for looking and posting (I've been on my phone).  I think I might
>>> have written that code, actually. ;-)
>>>
>>> Cheers!
>>>Kevin
>>>
>>> On Sunday, December 27, 2015, Ismael VC  wrote:
>>>
 Kevin I tested in my Win laptop with 0.3.11, 0.4.2, 0.4, 0.5+ also the
 same versions in julia box, and the output is deterministically sorted, It
 seems this has been the way it works for some time now, then I looked at
 the code and it’s indeed sorted (should have done that first! :P ):

- http://git.io/vEXL9

 subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), 
 by=string)
 subtypes(x::DataType) = subtypes(Main, x)

 I would expect a very good reason in order to justify a change for this
 now.
 ​

 2015-12-27 18:06 GMT-06:00 Kevin Squire

> Ray, thanks for the clarification--makes sense. In fact, for
> introspection code like 'subtypes', performance is probably the wrong
> argument--it's unlikely that it occurs in performance-critical code. I
> think it's really that arrays are just simpler.
>
> One aesthetic change I could imagine would be to have the results
> sorted before returning, which would keep the same data structure, but
> solve your problem, and present the subtypes in a way the user would 
> likely
> find more useful.
>
> Ismael, it might be a little brittle to depend on the current order
> (unless it's always sorted now).
>
> Cheers,
>Kevin
>
>
> On Sunday, December 27, 2015, Ismael Venegas Castelló wrote:
>
>> You can just do:
>>
>> @assert subtypes(Type) == [DataType, TypeConstructor, Union]
>>
>> I just tested this:
>>
>> julia> @time for i in 1:1000
>>@assert subtypes(Type) == [DataType, TypeConstructor,
>> Union]
>>end
>>   3.025415 seconds (767.00 k allocations: 224.075 MB, 0.49% gc time)
>>
>>
>>
>> El sábado, 26 de diciembre de 2015, 12:52:51 (UTC-6), Ray Toal
>> escribió:
>>>
>>> I noticed that
>>>
>>> *julia> **subtypes(Type)*
>>>
>>> *3-element Array{Any,1}:*
>>>
>>> * DataType  *
>>>
>>> * TypeConstructor*
>>>
>>> * Union *
>>>
>>> and was wondering if there was any significance in the order of the
>>> subtypes. If not, could the method have produced a Set instead?
>>>
>>>

Re: [julia-users] Using MATLAB error

[Stefan Karpinski]

I'm not sure how many users of the MATLAB package there are here. You may
want to file an issue with the package if you're having trouble getting it
working.

On Mon, Dec 28, 2015 at 1:46 AM, Yao Lu  wrote:

> I installed MATLAB packages.
> "Pkg.add("MATLAB")
> ENV["MATLAB_HOME"]="F:\\MATLAB\\R2015b\\bin"
> using MATLAB
> x=[1,2,3]"
> The codes above are OK.
> When I type   "@mxput x",
> it shows   "ERROR: UndefVarError: @mput not defined".
> What's wrong?
>

Re: [julia-users] Using MATLAB error

[Mauro]

This works for me:

julia> using MATLAB

julia> x=[1,2,3]
3-element Array{Int64,1}:
 1
 2
 3

julia> @mput x
A MATLAB session is open successfully

on 0.3 and 0.4.1 (with lots of deprecation warnings)

@mxput does not exist:

julia> @mxput x
ERROR: UndefVarError: @mxput not defined

So, as cdm said: are you sure that you don't have a typo?

On Mon, 2015-12-28 at 16:19, Stefan Karpinski  wrote:
> I'm not sure how many users of the MATLAB package there are here. You may
> want to file an issue with the package if you're having trouble getting it
> working.
>
> On Mon, Dec 28, 2015 at 1:46 AM, Yao Lu  wrote:
>
>> I installed MATLAB packages.
>> "Pkg.add("MATLAB")
>> ENV["MATLAB_HOME"]="F:\\MATLAB\\R2015b\\bin"
>> using MATLAB
>> x=[1,2,3]"
>> The codes above are OK.
>> When I type   "@mxput x",
>> it shows   "ERROR: UndefVarError: @mput not defined".
>> What's wrong?
>>

[julia-users] Re: Using MATLAB error

[cdm]

can you confirm that there is not a typo in the REPL

the char strings after the @ decorator in your supplied
sample code are not the same ...

combinations with limits, though.

~cdm



On Sunday, December 27, 2015 at 10:46:27 PM UTC-8, Yao Lu wrote:
>
> I installed MATLAB packages.
> "Pkg.add("MATLAB")
> ENV["MATLAB_HOME"]="F:\\MATLAB\\R2015b\\bin"
> using MATLAB
> x=[1,2,3]"
> The codes above are OK.
> When I type   "@mxput x",
> it shows   "ERROR: UndefVarError: @mput not defined".
> What's wrong?
>

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Ismael Venegas Castelló]

Stefan, wouldn't using `sort!` instead of `sort` be better here in this 
case?:

subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), by=string)

subtypes(m::Module, x::DataType) = sort!(collect(_subtypes(m, x)), 
by=string)



El lunes, 28 de diciembre de 2015, 9:25:08 (UTC-6), Stefan Karpinski 
escribió:
>
> No, please don't spend time on this. We're not going to change this to 
> return a heavyweight data structure like a Set when a simple structure like 
> and Array will do. In mathematics sets are simpler than ordered 
> collections, but in programming languages the relationship is reversed. In 
> general data structures like Set are only used when they are necessary, 
> such as when you need O(1) checking for inclusion. Since there's no such 
> need here, an array is simpler and better.
>
> On Mon, Dec 28, 2015 at 2:40 AM, Kevin Squire  > wrote:
>
>> Hi Ray,
>>
>> You're probably the first person to make this observation. I can see your 
>> point, and I don't really have a strong argument or opinion, really--the 
>> main reason it's sorted is probably because it looks nicer--at least if 
>> I did write that code, that would  have been my reasoning.
>>
>> If you're up for it, you could change it to create a set and submit a 
>> pull request. No guarantees it gets accepted, but the likelihood increases 
>> significantly over not submitting one. :-)
>>
>> Cheers,
>>Kevin 
>>
>>
>> On Sunday, December 27, 2015, Ray Toal  
>> wrote:
>>
>>> I'm sure the order won't ever change, but I'd still find it odd if the 
>>> documentation of subtypes were to say
>>>
>>> "Returns a list of subtypes, sorted by the name of the subtype"
>>>
>>> because, well, what about namespaces? What about all sorts of Unicode 
>>> collation definitions that would have to be a part of such a definition?
>>>
>>> Yes, as much as I would like to just assert that the result of calling 
>>> subtypes on Type produces the array [DataType, TypeConstructor, Union] it's 
>>> just not supposed to be an array, even if today we can guarantee that the 
>>> array will be sorted, and it is ridiculously unlikely to change.
>>>
>>> I just think of unordered collections as sets. I don't think anyone 
>>> would or should ever write code that takes advantage of the fact that this 
>>> array is sorted, though. :)
>>>
>>> Thanks for the responses
>>>
>>> Ray
>>>
>>>
>>> On Sunday, December 27, 2015 at 5:10:46 PM UTC-8, Kevin Squire wrote:

 Thanks for looking and posting (I've been on my phone).  I think I 
 might have written that code, actually. ;-)

 Cheers!
Kevin 

 On Sunday, December 27, 2015, Ismael VC  wrote:

> Kevin I tested in my Win laptop with 0.3.11, 0.4.2, 0.4, 0.5+ also the 
> same versions in julia box, and the output is deterministically sorted, 
> It 
> seems this has been the way it works for some time now, then I looked at 
> the code and it’s indeed sorted (should have done that first! :P ):
>
>- http://git.io/vEXL9 
>
> subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), 
> by=string)
> subtypes(x::DataType) = subtypes(Main, x)
>
> I would expect a very good reason in order to justify a change for 
> this now.
> ​
>
> 2015-12-27 18:06 GMT-06:00 Kevin Squire
>
>> Ray, thanks for the clarification--makes sense. In fact, for 
>> introspection code like 'subtypes', performance is probably the wrong 
>> argument--it's unlikely that it occurs in performance-critical code. I 
>> think it's really that arrays are just simpler. 
>>
>> One aesthetic change I could imagine would be to have the results 
>> sorted before returning, which would keep the same data structure, but 
>> solve your problem, and present the subtypes in a way the user would 
>> likely 
>> find more useful.  
>>
>> Ismael, it might be a little brittle to depend on the current order 
>> (unless it's always sorted now).
>>
>> Cheers,
>>Kevin 
>>
>>
>> On Sunday, December 27, 2015, Ismael Venegas Castelló wrote:
>>
>>> You can just do:
>>>
>>> @assert subtypes(Type) == [DataType, TypeConstructor, Union]
>>>
>>> I just tested this:
>>>
>>> julia> @time for i in 1:1000
>>>@assert subtypes(Type) == [DataType, TypeConstructor, 
>>> Union]
>>>end
>>>   3.025415 seconds (767.00 k allocations: 224.075 MB, 0.49% gc time)
>>>
>>>
>>>
>>> El sábado, 26 de diciembre de 2015, 12:52:51 (UTC-6), Ray Toal 
>>> escribió:

 I noticed that 

 *julia> **subtypes(Type)*

 *3-element Array{Any,1}:*

 * DataType  *

 * TypeConstructor*

 * Union *

 and was wondering if there was any significance in the order 

Re: [julia-users] Re: strange behavior with float value multiplication

[Stefan Karpinski]

I would recommend against using decimal floating-point unless you really
must. On almost any hardware you're likely to use, binary floating-point
arithmetic will be an order of magnitude faster than decimal floating-point
arithmetic. Moreover, if you use decimal floating-point, you will
chronically find yourself unable to use standard numerical libraries
without converting your data first.

Instead, I would strongly recommend learning a bit about how binary
floating-point works. The basic fact you need to know is that the Float64
type can only represent real values of the form:

n*2^k where |n| < 2^53 and -1074 ≤ k ≤ 971 (both integers).


Some basic but potentially unintuitive facts that follow from this:

1. Only rational values whose denominators are powers of two can be
represented as binary floating-point values exactly. Most rational numbers
are not of this form, of course. When you write `0.1` in Julia (and most
programming languages), it does not mean 1/10. Instead, it means the number
of the above form that is closest to 1/10, namely:

3602879701896397*2.0^-55 =

0.155511151231257827021181583404541015625.


This value is printed as "0.1" by convention since that's the shortest
decimal input that gives you this value, and therefore in some sense the
most likely way to input it. However, there are many other decimal inputs
that produce the same Float64 value, such as 0.087
and 0.10001.

2. Unlike rational numbers, which are dense in all intervals of the real
number line, floating-point values are not at all dense: there is a gap
between each floating-point value and the next representable value. The
eps(x) function gives the distance to the next representable value:

eps(1.0) = 2.220446049250313e-16
eps(12.34) = 1.7763568394002505e-15
eps(1e25) = 2.147483648e9.


The gap between moderately sized values like 1.0 and 12.34 is very small,
but the gaps between large numbers like 1e25 is very large. In general, the
gap between values of size 10^n is around 10^(n-16). That is because
Float64s have 53 bits of precision and log10(2^53) ≈ 16.

On Mon, Dec 28, 2015 at 8:38 AM, Scott Jones 
wrote:

> That is simply because you are using binary floating point (Float64 in
> Julia), instead of decimal floating point.  There is a very nice package,
> DecFP.jl, (kudos to Steven Johnson, @stevengj on GitHub), that wraps the
> Intel decimal arithmetic library.
> You can do `Pkg.add("DecFP") ; using DecFP` (you may get a lot of
> deprecation warnings, esp. on v0.5, you can also do a
> `Pkg.checkout("DecFP") ; Pkg.build("DecFP")` to eliminate all but one
> warning on v0.5), and then you can do:
>
> julia> a = d"0.2"
> +2E-1
>
> julia> for i in 1:10 ; println(a * i) ; end
> +2E-1
> +4E-1
> +6E-1
> +8E-1
> +10E-1
> +12E-1
> +14E-1
> +16E-1
> +18E-1
> +20E-1
>
> The output is a bit funny, but the answers are exact, unlike most of the
> answers in the binary floating point case you showed.
>
> Note: the most heavily used language in the world (at least up to the
> early 2000s, I'm not sure what the stats would be like now), which was the
> 2nd ANSI standardized language, Cobol,
> originally only had decimal arithmetic (Modern Cobols also support IEEE
> binary floating point).
> A number of other heavily used (but not much talked about) languages, such
> as M/MUMPS, which happened to be the 3rd language standardized by ANSI,
> even before ANSI C.
> The most used version of M/MUMPS these days is Caché ObjectScript - which
> adds many things, including objects and IEEE binary floats.
> The Pick/MultiValue family of database languages also use decimal floating
> point.
>
> There is now the IEEE 754-2008 standard for decimal floating point, which
> the DecFP.jl package conforms to (implementing 3 of the formats - there are
> some more formats which I'm trying to write a package for, which are also
> implemented in hardware on IBM POWER architecture processors).
>
> There are a number of cases where it really is better to use decimal
> arithmetic, in order to not get in trouble with the tax man! (Lots of
> currency operations have this same issue)
> Here's a real simple example: you have a store, where you sell something
> for 70 cents, and there is a 5% sales tax.  How much do tax to you charge
> the customer?
>
> *julia>tax = *
>> *.7 * 0.05*
>> *0.034996**julia> *
>> *round(tax,2)*
>> *0.03**julia> tax = *
>> *d".70" * d"0.05"*
>> *+350E-4**julia> *
>> *round(tax,2)**+4E-2*
>
>
> As you can see, with binary floating point, you get the wrong answer
> (0.03), but with decimal floating point, you get the correct answer (the
> one the tax authorities will want you to give them).
>
> Depending on your particular use case, you can either use the default IEEE
> binary floating point numbers in Julia, or the DecFP.jl package.
>
> Scott
>
> On Monday, December 28, 2015 at 4:59:24 AM UTC-5, Yonghee Kim wrote:
>>
>> I wrote simple code like this
>>
>> 

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Stefan Karpinski]

Sure. That avoids unnecessarily copying the array.

On Mon, Dec 28, 2015 at 10:51 AM, Ismael Venegas Castelló <
ismael.vc1...@gmail.com> wrote:

> Stefan, wouldn't using `sort!` instead of `sort` be better here in this
> case?:
>
> subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)),
> by=string)
>
> subtypes(m::Module, x::DataType) = sort!(collect(_subtypes(m, x)),
> by=string)
>
>
>
> El lunes, 28 de diciembre de 2015, 9:25:08 (UTC-6), Stefan Karpinski
> escribió:
>>
>> No, please don't spend time on this. We're not going to change this to
>> return a heavyweight data structure like a Set when a simple structure like
>> and Array will do. In mathematics sets are simpler than ordered
>> collections, but in programming languages the relationship is reversed. In
>> general data structures like Set are only used when they are necessary,
>> such as when you need O(1) checking for inclusion. Since there's no such
>> need here, an array is simpler and better.
>>
>> On Mon, Dec 28, 2015 at 2:40 AM, Kevin Squire 
>> wrote:
>>
>>> Hi Ray,
>>>
>>> You're probably the first person to make this observation. I can see
>>> your point, and I don't really have a strong argument or opinion,
>>> really--the main reason it's sorted is probably because it looks
>>> nicer--at least if I did write that code, that would  have been my
>>> reasoning.
>>>
>>> If you're up for it, you could change it to create a set and submit a
>>> pull request. No guarantees it gets accepted, but the likelihood increases
>>> significantly over not submitting one. :-)
>>>
>>> Cheers,
>>>Kevin
>>>
>>>
>>> On Sunday, December 27, 2015, Ray Toal  wrote:
>>>
 I'm sure the order won't ever change, but I'd still find it odd if the
 documentation of subtypes were to say

 "Returns a list of subtypes, sorted by the name of the subtype"

 because, well, what about namespaces? What about all sorts of Unicode
 collation definitions that would have to be a part of such a definition?

 Yes, as much as I would like to just assert that the result of calling
 subtypes on Type produces the array [DataType, TypeConstructor, Union] it's
 just not supposed to be an array, even if today we can guarantee that the
 array will be sorted, and it is ridiculously unlikely to change.

 I just think of unordered collections as sets. I don't think anyone
 would or should ever write code that takes advantage of the fact that this
 array is sorted, though. :)

 Thanks for the responses

 Ray


 On Sunday, December 27, 2015 at 5:10:46 PM UTC-8, Kevin Squire wrote:
>
> Thanks for looking and posting (I've been on my phone).  I think I
> might have written that code, actually. ;-)
>
> Cheers!
>Kevin
>
> On Sunday, December 27, 2015, Ismael VC  wrote:
>
>> Kevin I tested in my Win laptop with 0.3.11, 0.4.2, 0.4, 0.5+ also
>> the same versions in julia box, and the output is deterministically 
>> sorted,
>> It seems this has been the way it works for some time now, then I looked 
>> at
>> the code and it’s indeed sorted (should have done that first! :P ):
>>
>>- http://git.io/vEXL9
>>
>> subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), 
>> by=string)
>> subtypes(x::DataType) = subtypes(Main, x)
>>
>> I would expect a very good reason in order to justify a change for
>> this now.
>> ​
>>
>> 2015-12-27 18:06 GMT-06:00 Kevin Squire
>>
>>> Ray, thanks for the clarification--makes sense. In fact, for
>>> introspection code like 'subtypes', performance is probably the wrong
>>> argument--it's unlikely that it occurs in performance-critical code. I
>>> think it's really that arrays are just simpler.
>>>
>>> One aesthetic change I could imagine would be to have the results
>>> sorted before returning, which would keep the same data structure, but
>>> solve your problem, and present the subtypes in a way the user would 
>>> likely
>>> find more useful.
>>>
>>> Ismael, it might be a little brittle to depend on the current order
>>> (unless it's always sorted now).
>>>
>>> Cheers,
>>>Kevin
>>>
>>>
>>> On Sunday, December 27, 2015, Ismael Venegas Castelló wrote:
>>>
 You can just do:

 @assert subtypes(Type) == [DataType, TypeConstructor, Union]

 I just tested this:

 julia> @time for i in 1:1000
@assert subtypes(Type) == [DataType, TypeConstructor,
 Union]
end
   3.025415 seconds (767.00 k allocations: 224.075 MB, 0.49% gc time)



 El sábado, 26 de diciembre de 2015, 12:52:51 (UTC-6), Ray Toal
 escribió:
>
> I noticed that
>
> 

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Ismael VC]

Ok then I'll make a PR for that, and see if I find more uses like this that
can be changed.

Ismael Venegas Castelló

*Data Analyst*

Cel. 044 55 6434 0229

ivene...@richit.com.mx

Cerro San Francisco 357, C.P. 04200

Campestre Churubusco, Coyoacán

Ciudad de México




  

Tel. 6718 1818
richit.com.mx

2015-12-28 12:12 GMT-06:00 Stefan Karpinski :

> Sure. That avoids unnecessarily copying the array.
>
> On Mon, Dec 28, 2015 at 10:51 AM, Ismael Venegas Castelló <
> ismael.vc1...@gmail.com> wrote:
>
>> Stefan, wouldn't using `sort!` instead of `sort` be better here in this
>> case?:
>>
>> subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)),
>> by=string)
>>
>> subtypes(m::Module, x::DataType) = sort!(collect(_subtypes(m, x)),
>> by=string)
>>
>>
>>
>> El lunes, 28 de diciembre de 2015, 9:25:08 (UTC-6), Stefan Karpinski
>> escribió:
>>>
>>> No, please don't spend time on this. We're not going to change this to
>>> return a heavyweight data structure like a Set when a simple structure like
>>> and Array will do. In mathematics sets are simpler than ordered
>>> collections, but in programming languages the relationship is reversed. In
>>> general data structures like Set are only used when they are necessary,
>>> such as when you need O(1) checking for inclusion. Since there's no such
>>> need here, an array is simpler and better.
>>>
>>> On Mon, Dec 28, 2015 at 2:40 AM, Kevin Squire 
>>> wrote:
>>>
 Hi Ray,

 You're probably the first person to make this observation. I can see
 your point, and I don't really have a strong argument or opinion,
 really--the main reason it's sorted is probably because it looks
 nicer--at least if I did write that code, that would  have been my
 reasoning.

 If you're up for it, you could change it to create a set and submit a
 pull request. No guarantees it gets accepted, but the likelihood increases
 significantly over not submitting one. :-)

 Cheers,
Kevin


 On Sunday, December 27, 2015, Ray Toal  wrote:

> I'm sure the order won't ever change, but I'd still find it odd if the
> documentation of subtypes were to say
>
> "Returns a list of subtypes, sorted by the name of the subtype"
>
> because, well, what about namespaces? What about all sorts of Unicode
> collation definitions that would have to be a part of such a definition?
>
> Yes, as much as I would like to just assert that the result of calling
> subtypes on Type produces the array [DataType, TypeConstructor, Union
> ] it's just not supposed to be an array, even if today we can
> guarantee that the array will be sorted, and it is ridiculously unlikely 
> to
> change.
>
> I just think of unordered collections as sets. I don't think anyone
> would or should ever write code that takes advantage of the fact that this
> array is sorted, though. :)
>
> Thanks for the responses
>
> Ray
>
>
> On Sunday, December 27, 2015 at 5:10:46 PM UTC-8, Kevin Squire wrote:
>>
>> Thanks for looking and posting (I've been on my phone).  I think I
>> might have written that code, actually. ;-)
>>
>> Cheers!
>>Kevin
>>
>> On Sunday, December 27, 2015, Ismael VC  wrote:
>>
>>> Kevin I tested in my Win laptop with 0.3.11, 0.4.2, 0.4, 0.5+ also
>>> the same versions in julia box, and the output is deterministically 
>>> sorted,
>>> It seems this has been the way it works for some time now, then I 
>>> looked at
>>> the code and it’s indeed sorted (should have done that first! :P ):
>>>
>>>- http://git.io/vEXL9
>>>
>>> subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), 
>>> by=string)
>>> subtypes(x::DataType) = subtypes(Main, x)
>>>
>>> I would expect a very good reason in order to justify a change for
>>> this now.
>>> ​
>>>
>>> 2015-12-27 18:06 GMT-06:00 Kevin Squire
>>>
 Ray, thanks for the clarification--makes sense. In fact, for
 introspection code like 'subtypes', performance is probably the wrong
 argument--it's unlikely that it occurs in performance-critical code. I
 think it's really that arrays are just simpler.

 One aesthetic change I could imagine would be to have the results
 sorted before 

Re: [julia-users] Using MATLAB error

[cdm]

also, what system and julia version are you on ...

per   https://github.com/JuliaLang/MATLAB.jl

The procedure to setup this package consists of three steps.

Linux
1 ~ Make sure matlab is in executable path.
2 ~ Make sure csh is installed. (Note: MATLAB for Linux relies on csh to 
open an engine session.)

3 ~ Clone this package from the GitHub repo to your Julia package directory
 


for more detail and/or other systems, review
the information at the repo linked above ...

good luck !!!

~ cdm


On Monday, December 28, 2015 at 8:32:40 AM UTC-8, Mauro wrote:
>
> So, as cdm said: are you sure that you don't have a typo? 
>
>

Re: [julia-users] Re: strange behavior with float value multiplication

[Scott Jones]

On Monday, December 28, 2015 at 1:10:25 PM UTC-5, Stefan Karpinski wrote:
>
> I would recommend against using decimal floating-point unless you really 
> must. On almost any hardware you're likely to use, binary floating-point 
> arithmetic will be an order of magnitude faster than decimal floating-point 
> arithmetic. Moreover, if you use decimal floating-point, you will 
> chronically find yourself unable to use standard numerical libraries 
> without converting your data first.
>

True - I was not advocating using decimal floating point *unless* you must, 
however, there are a number of use cases where that you do need to use 
decimal floating point,
and you might find that using decimal floating point can actually be faster 
than using larger precision binary floating point if you are trying to 
avoid some of the conversion issues that exist with binary floating point. 
 For example, in some benchmarks I ran comparing `DecFP.jl` to `BigFloat`, 
DecFP was about 2-3 times faster than 256-bit BigFloat.
(DecFP is very nice, in that it uses bitstypes, but BigFloat causes a 
number of allocations for every operation - which may indicate that some 
work could be done on Julia's BigFloat wrapping, to use bitstypes, instead 
of having to have both an allocation for the type, and the array of words).

*julia> **f1() = (a = big"0.0" ; for i = 1:1 ; a += big"0.1" ; end ; a)*

*f1 (generic function with 1 method)*


*julia> **f1()*

*9.859301e+02*


*julia> **f2() = (a = d"0.0" ; for i = 1:1 ; a += d"0.1" ; end ; a)*

*f2 (generic function with 1 method)*


*julia> **f2()*

*+1E-1*


*julia> **@benchmark f1()*

* Benchmark Results *

* Time per evaluation: 2.55 ms [139.77 μs, 4.95 ms]*

*Proportion of time in GC: 4.52% [0.00%, 16.41%]*

*Memory allocated: 1015.63 kb*

*   Number of allocations: 3 allocations*

*   Number of samples: 100*

*   Number of evaluations: 100*

* Time spent benchmarking: 0.31 s*



*julia> **@benchmark f2()*

* Benchmark Results *

* Time per evaluation: 792.35 μs [703.65 μs, 881.05 μs]*

*Proportion of time in GC: 0.00% [0.00%, 0.00%]*

*Memory allocated: 0.00 bytes*

*   Number of allocations: 0 allocations*

*   Number of samples: 100*

*   Number of evaluations: 100*

* Time spent benchmarking: 0.10 s*


*julia> **f1m() = (a = big"0.0" ; for i = 1:1 ; a *= big"0.1" ; end ; 
a)*

*f1m (generic function with 1 method)*


*julia> **f2m() = (a = d"0.0" ; for i = 1:1 ; a *= d"0.1" ; end ; a)*

*f2m (generic function with 1 method)*


*julia> **@benchmark f1m()*

* Benchmark Results *

* Time per evaluation: 2.03 ms [0.00 ns, 4.06 ms]*

*Proportion of time in GC: 3.73% [0.00%, 14.73%]*

*Memory allocated: 1015.63 kb*

*   Number of allocations: 3 allocations*

*   Number of samples: 100*

*   Number of evaluations: 100*

* Time spent benchmarking: 0.23 s*


*julia> **@benchmark f2m()*

* Benchmark Results *

* Time per evaluation: 756.59 μs [678.94 μs, 834.24 μs]*

*Proportion of time in GC: 0.00% [0.00%, 0.00%]*

*Memory allocated: 0.00 bytes*

*   Number of allocations: 0 allocations*

*   Number of samples: 100*

*   Number of evaluations: 100*

* Time spent benchmarking: 0.10 s*

[julia-users] Re: strange behavior with float value multiplication

[Yonghee Kim]

what I've been doing is kind of similar to tax problem (game economy 
simulation)
for now,turning floating number to integer is enough to solve all my 
headaches. 

But I will remember your recommendation when I ran into more complicated 
case.

Thank you 


2015년 12월 28일 월요일 오후 10시 38분 21초 UTC+9, Scott Jones 님의 말:
>
> That is simply because you are using binary floating point (Float64 in 
> Julia), instead of decimal floating point.  There is a very nice package, 
> DecFP.jl, (kudos to Steven Johnson, @stevengj on GitHub), that wraps the 
> Intel decimal arithmetic library.
> You can do `Pkg.add("DecFP") ; using DecFP` (you may get a lot of 
> deprecation warnings, esp. on v0.5, you can also do a 
> `Pkg.checkout("DecFP") ; Pkg.build("DecFP")` to eliminate all but one 
> warning on v0.5), and then you can do:
>
> julia> a = d"0.2"
> +2E-1 
>
> julia> for i in 1:10 ; println(a * i) ; end 
> +2E-1 
> +4E-1 
> +6E-1 
> +8E-1 
> +10E-1 
> +12E-1 
> +14E-1 
> +16E-1 
> +18E-1 
> +20E-1
>
> The output is a bit funny, but the answers are exact, unlike most of the 
> answers in the binary floating point case you showed.
>
> Note: the most heavily used language in the world (at least up to the 
> early 2000s, I'm not sure what the stats would be like now), which was the 
> 2nd ANSI standardized language, Cobol,
> originally only had decimal arithmetic (Modern Cobols also support IEEE 
> binary floating point).
> A number of other heavily used (but not much talked about) languages, such 
> as M/MUMPS, which happened to be the 3rd language standardized by ANSI, 
> even before ANSI C.
> The most used version of M/MUMPS these days is Caché ObjectScript - which 
> adds many things, including objects and IEEE binary floats.
> The Pick/MultiValue family of database languages also use decimal floating 
> point.
>
> There is now the IEEE 754-2008 standard for decimal floating point, which 
> the DecFP.jl package conforms to (implementing 3 of the formats - there are 
> some more formats which I'm trying to write a package for, which are also 
> implemented in hardware on IBM POWER architecture processors).
>
> There are a number of cases where it really is better to use decimal 
> arithmetic, in order to not get in trouble with the tax man! (Lots of 
> currency operations have this same issue)
> Here's a real simple example: you have a store, where you sell something 
> for 70 cents, and there is a 5% sales tax.  How much do tax to you charge 
> the customer?
>
> *julia>tax = *
>> *.7 * 0.05*
>> *0.034996**julia> *
>> *round(tax,2)*
>> *0.03**julia> tax = *
>> *d".70" * d"0.05"*
>> *+350E-4**julia> *
>> *round(tax,2)**+4E-2*
>
>
> As you can see, with binary floating point, you get the wrong answer 
> (0.03), but with decimal floating point, you get the correct answer (the 
> one the tax authorities will want you to give them).
>
> Depending on your particular use case, you can either use the default IEEE 
> binary floating point numbers in Julia, or the DecFP.jl package.
>
> Scott
>
> On Monday, December 28, 2015 at 4:59:24 AM UTC-5, Yonghee Kim wrote:
>>
>> I wrote simple code like this
>>
>> --
>> a = 0.2
>>
>> for i in 1:10
>>   println(a * i)
>> end
>> ---
>>
>>
>> and what I got is not 0.2, 0.4, 0.6, 0.8, 1.0  
>>
>> but this.
>>
>> 0.2
>> 0.4
>> 0.6001
>> 0.8
>> 1.0
>> 1.2002
>> 1.4001
>> 1.6
>> 1.8
>> 2.0
>>
>>
>>
>> println(0.2 * 3) does the same thing. not 0.6 but 0.6001
>>
>> does anyone know why this happens? 
>>
>>

[julia-users] Is it possible to initialize a type parameter with promote_type()?

[Jeffrey Sarnoff]

is there a way to do accomplish this?

immutable Ivl{B<:AkoBound, R<:Real}  # R <-- 
promote_type(typeof(lo),typeof(hi))
lo::Real   # allow lo, hi 
to differ in type (subtypes of Real)
hi::Real
??
end

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Ismael VC]

I thougt one advantage of using sets would be the ability to use set
operations, but they work on arrays to, by the way the documentation of ie,
union falls short, because it’s actually more general than what it says (*not
only sets*):

help?> union
search: union union! Union @unix_only function Function functionloc functionlocs

  union(s1,s2...)
  ∪(s1,s2...)

  Construct the union of two or more sets. Maintains order with arrays.

julia> union([1, 1], [2])# this also works!
2-element Array{Int64,1}:
 1
 2

​

Ismael Venegas Castelló

*Data Analyst*

Cel. 044 55 6434 0229

ivene...@richit.com.mx

Cerro San Francisco 357, C.P. 04200

Campestre Churubusco, Coyoacán

Ciudad de México




  

Tel. 6718 1818
richit.com.mx

2015-12-28 12:44 GMT-06:00 Scott Jones :

> How would this fit in with Jeff's work on types/subtypes?
> At JuliaCon he did talk about improving the type system (something I've
> been really hoping to see).
> It seems to me that it might be more logically consistent to return a type
> union for this, but I understand that currently it is easier to work with
> returning a simple sorted vector.
>
> Scott
>
> On Sunday, December 27, 2015 at 12:10:38 AM UTC-5, Kevin Squire wrote:
>>
>>
>>
>> On Saturday, December 26, 2015, Ray Toal  wrote:
>>
>>> I noticed that
>>>
>>> *julia> **subtypes(Type)*
>>>
>>> *3-element Array{Any,1}:*
>>>
>>> * DataType  *
>>>
>>> * TypeConstructor*
>>>
>>> * Union *
>>>
>>> and was wondering if there was any significance in the order of the
>>> subtypes. If not, could the method have produced a Set instead?
>>>
>>>
>> It could, but why?  A set has a bit more overhead than an array, and for
>> most types, the number of subtypes is small enough that sets wouldn't
>> really offer any advantage.
>>
>> Is there something you want to do with the results that you think
>> requires a set?
>>
>> Cheers,
>> Kevin
>>
>

[julia-users] Mysterious boxing

[Jamie Brandon]

I have two versions of this reshape function - 
https://gist.github.com/jamii/62b3c3695fba95f3f09b

The produce near-identical ast from code_warntype - 
https://www.diffchecker.com/awnv9zvv

But code_lowered shows that reshape naively boxes tuples whereas reshape2 
does something much more complicated - https://www.diffchecker.com/jb6aurpl

The result is that reshape2 is much faster:

reshape: 0.316513 seconds (2.00 M allocations: 95.036 MB, 5.41% gc time)
reshape2:  0.218963 seconds (41 allocations: 34.001 MB, 0.85% gc time)

What's going on? How can I make reshape avoid boxing?