Re: [julia-users] MathProgBase Conic problem specifying dual
Hi Kevin! thanks letting me know; and for the quick response, I will re-post on julia-opt; best, steve On Sat, Jul 9, 2016 at 2:29 PM, Kevin Squire wrote: > Hi, it's probably worth asking this question on the julia-opt list. > > Cheers, >Kevin > > > > On Saturday, July 9, 2016, steven Varga wrote: > >> >> Is it possible to specify the dual of an SOCP/SDP using MathProgBase >> interface? >> >> It is well documented how to specify primal problem, but don't see any >> pointers to formulate the dual. The dual formulation is motivated if A >> matrix is non-square having more variables in primal then constraints. >> >> Any help, pointers appreciated >> steve >> >> MathProgBase version: >> commit 2faa7b97af385f61ea2e829512b5fa1c1c2ceab1 >> Author: Miles Lubin >> Date: Thu Jun 2 15:30:42 2016 +0200 >> >> Julia Version 0.5.0-dev+1503 >> Commit 84fb0a4* (2016-05-27 03:12 UTC) >> Platform Info: >> System: Linux (x86_64-linux-gnu) >> CPU: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz >> WORD_SIZE: 64 >> BLAS: libmkl_rt >> LAPACK: libmkl_rt >> LIBM: libimf >> >>
[julia-users] MathProgBase Conic problem specifying dual
Is it possible to specify the dual of an SOCP/SDP using MathProgBase interface? It is well documented how to specify primal problem, but don't see any pointers to formulate the dual. The dual formulation is motivated if A matrix is non-square having more variables in primal then constraints. Any help, pointers appreciated steve MathProgBase version: commit 2faa7b97af385f61ea2e829512b5fa1c1c2ceab1 Author: Miles Lubin Date: Thu Jun 2 15:30:42 2016 +0200 Julia Version 0.5.0-dev+1503 Commit 84fb0a4* (2016-05-27 03:12 UTC) Platform Info: System: Linux (x86_64-linux-gnu) CPU: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz WORD_SIZE: 64 BLAS: libmkl_rt LAPACK: libmkl_rt LIBM: libimf
[julia-users] REPL: show( io::IO, x::Array{my_object,1} ) = ... overwrite
When overwriting Base.show for an Array of custom_type REPL eval() uses the
old version of Base.show with only partial delegation/dispatch; which is
cumbersome when working with large arrays of records in REPL.
Is this the expected behaviour, and there is a different approach to use
REPL + eval + show or some sort of a exception I happened to stumble upon?
any pointer/help is appreciated.
[I am aware when wrapping arrays again in an object this can be avoided,
but that requires implementing/dispatching methods Array{}() already has ]
short self contained minimal example attached
thanks,
steve
--- CODE ---
#!/usr/local/bin/julia
# minimal working example to demonstrate that one is
# unable to overwrite Base.show for Array{custom_type,1} when using REPL
#
# julia> versioninfo()
# Julia Version 0.4.0-dev+2895
# Commit a37025e* (2015-01-25 09:20 UTC)
#Platform Info:
# System: Linux (x86_64-linux-gnu)
# CPU: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
# WORD_SIZE: 64
# BLAS: libmkl_rt
# LAPACK: libmkl_rt
# LIBM: libimf
# LLVM: libLLVM-3.3
#
module repl_test
import Base.show
export show
type A
value::Int64
end
show( io::IO, x::A ) = @printf(" A: %i\n", x.value )
show( io::IO, x::Array{A,1} ) = @printf(" A: many values\n" )
end
x = repl_test.A( 5 )
show(x) # as advertised
x # same as above
# printout in REPL
# A: 5
# A: many values
y = Array(repl_test.A, 10)
show(y)
# still works as expected
# julia> show(y)
# A: many values
## like io::IO, x::Array{A,1} = ... didn't exist
y
# julia> y
# 10-element Array{repl_test.A,1}:
# #undef
# ... omitted
# #undef
# The above code when evaluated in REPL uses built in Base.show for array
and indirectly
# calls overwritten Base.show
# I find it very cumbersome and unfriendly when unable to pretty print
large arrays of structs
# imported from other systems.
# Is there a better/working solution to use the REPL similarly to when
interacting with GNU R?
repl_show_test.jl
Description: Binary data
[julia-users] matrix shape subview of a large size vector with julia 0.3
Hello,
As a beginner Julia user I have the outlined problem and a peer review
request if there is any implications of the proposed technique.
The problem:
To have a matrix{T} shape continuous sub-view of a vector{T} store the
following code, using pointer to array, seem to work:
myView{T,N}(a::Array{T}, dims::NTuple{N,Int}; start::Int64=1 ) =
pointer_to_array(pointer(a, start), dims, false )
v = zeros(20) ## must not be garbage collected until A,B referenced; v is
100M ~ 10G; in memory
#for i=0:large_number
# scatter
A = myView(v, (10,1), start=1)
B = myView(v, (10,1), start=11)
# IO heavy updates
A[:,:] = A[:,:] + 1; B[:,:] = B[:,:] + 5
#end
# implicit gather
show( v ) ##
Is this a correct Julian way to implement efficient large size shared
data-store, where A,B preserve matrix properties [BLAS/LAPACK]? Are there
any obvious impacts/alternatives to this approach that avoided my
attention? (cost of contracting sub-view versus BLAS.copy data back during
gather)
thanks,
steve
[julia-users] julia stable compile from julia-0.3.3_b24213b893.tar.gz
Hi, I compiled the latest git version of julia with MKL on linux Mint 17; most function (BLAS,LAPACK,...) worked however didn't stable for production use (Winston, Gladfly failed to load). Then turned to the stable release which produces the following error: double_conversion_wrapper.cpp:1:31: fatal error: double-conversion.h: No such file or directory #include "double-conversion.h" I tried the git then the tar version; the problem persisted; Can someone give me a hint what I am doing wrong? steve
