rix's name
inaccessible, for instance, by giving the new matrix the same name as the
old one.
-- Steve Vavasis
On Saturday, November 5, 2016 at 8:32:58 PM UTC-4, Corbin Foucart wrote:
>
> I see. returning a new, smaller instance of the matrix was my temporary
> solution. Bummer that
ilar issue!
-- Steve Vavasis
"This declaration of Vector creates a subtype relation Vector{Int} <: Vector.
However, it is not always the case that a parametric typealias statement
creates such a relation; for example, the statement:
typealias AA{T} Array{Array{T,1},1}
does not create t
, size(V,1), 2, size(EV,2))
for k = 1 : size(EV,2)
for j = 1 : 2
for i = 1 : size(V,1)
result[i,j,k] = V[i,EV[j,k]]
end
end
end
There are some macro packages like Einsum.jl that let you hide the explicit
loops.
-- Steve Vavasis
On Friday, September 30
solutions that don't allocate heap memory?
Here are some other examples of operations for which I would like efficient
one-liners:
t = dot(v[p:p+3], w[p:p+3])
c += A[p:p+2, q:q+2] * v[q:q+2] # "gaxpy"; c is a length-3 vector
Thanks,
Steve Vavasis
"atreturn" function that registers functions to be called when a function
returns?
Thanks,
Steve Vavasis
In the case of a graph laplacian, you can regularize the problem by
deleting one row/column per connected component of the graph and the
corresponding entries of the RHS.
-- Steve Vavasis
On Wednesday, September 14, 2016 at 11:27:39 PM UTC-4, James Sharpnack
wrote:
>
> Dear Mladen,
&
benefit of not copying the entries).
-- Steve Vavasis
julia> a = [6 7 ; 4 5]
2x2 Array{Int64,2}:
6 7
4 5
julia> sort!(sub(a,1:2,1))
2-element SubArray{Int64,1,Array{Int64,2},Tuple{UnitRange{Int64},Int64},2}:
4
6
julia> a
2x2 Array{Int64,2}:
4 7
6 5
On Wednesday, Septembe
rse.jl
package.) I have run this code only on Windows 10 64-bit.
-- Steve Vavasis
module MySparseExtensions
import Base.sparse
import Base.SparseMatrix.CHOLMOD.FactorComponent
import Base.SparseMatrix.CHOLMOD.Factor
import Base.SparseMatrix.CHOLMOD.CHOLMODException
import Base.SparseMatrix
mutables, then
whenever you assign a dictionary entry it is safest to insert a 'deepcopy'
operation; e.g., the above snippet can be fixed by substituting the
following for d[a]=9.1:
d[deepcopy(a)] = 9.1
-- Steve Vavasis
On Thursday, August 25, 2016 at 2:21:30 AM UTC-4, Venil No
Dominique,
No problem! Just so you know, the "inner" sparse constructor (in which the
column-start and row-index arrays are directly specified) does not check
the ordering. However, the higher-level 'outer' constructors, e.g., the
constructor sparse(is,js,es,m,n) that mimics Matlab syntax, wi
I've been using the cholmod routines recently also in 0.4.6 (Windows 64)
and have never seen this error. The routine cholmod_check_sparse seems to
be in source code file cholmod_check.c of the SuiteSparse source code, and
it doesn't seem to do much except check that the row indices are in
incr
r to your example. The reason is that the garbage
collector needs to know whether there is a live reference to a mutable data
structure, and if references to mutable data structures were copied around
like bits objects, the run-time system could not keep track of this.
-- Steve Vavasis
Tony,
I would be happy to share my prototypes for these wrappers with you or
anyone else, but I would not be interested in implementing and testing
library versions of them. This was the point of my first posting. It's
not clear to me who would be interested in that thankless and
time-consum
Tony,
Here are a few Julia routines sparse matrix routines that I looked for and
didn't find. Maybe I looked in the wrong place.
- Getting the P'*L factor from SuiteSparse's sparse Cholesky back into
Julia. In other words, if F is the cholmod representation of the Cholesky
factor, then spars
Sparse matrix computation is a key aspect of scientific computing. The
creators of Julia made the smart decision to rely on SuiteSparse,
high-quality free C++ software that carries out most of the common sparse
matrix factorizations and related operations very efficiently.
The issue that conce
Dear Fengyang and Yichao,
I think my code is fully operational at this point. Thanks for the help!
Cholmod/sqpr have their own memory management routines, so I used
cholmod_l_free to free E. And the reason that my wrapper did not find the
permutation inside of return variable E is because E
ree
> with `free`, use `unsafe_wrap(Array)` to get an array
> 2. If the pointer is merely used to return a small amount of information,
> you can eagerly convert that info to a julia object
> 3. If the pointer is an opaque object or if you need exactly the same
> pointer late
gave an error message ("Objects of type
Ptr{...} cannot be finalized"). I cribbed the finalizer invocations from
spqr.jl but evidently not correctly.
-- Steve Vavasis
module test_qr_fac
import Base.SparseMatrix.CHOLMOD.common
import Base.SparseMatrix.CHOLMOD.
me a clue how to get access to the R factor of the QR
factorization computed by SPQR? Ideally I would obtain R as a
SparseMatrixCSC object.
Thanks,
Steve Vavasis
ation. (See below.) Does anyone know of a better way?
-- Steve Vavasis
# Compute the permuted cholesky factor of a sparse, symmetric
# positive definite matrix A.
function cholfactPtL(A)
n = size(A,1)
F = cholfact(A)
L0 = sparse(F[:L])
is,js,es = find
ed version of cholfact that exposes this functionality.
> But it would be better if the functionality were available in the library
> so that my code is not sensitive to changes in undocumented low-level
> routines.
>
> Thanks,
> Steve Vavasis
>
>
low-level
routines.
Thanks,
Steve Vavasis
o get high performance.)
There are several macro packages available such as Einsum.jl or Devectorize
that allow you to write code in the syntactic style of matrix/vector
operations while the macro 'under the hood' generates the necessary
for-loops.
-- Steve Vavasis
On Thursday, Jun
-vector
multiplication statement, but the next release should.) With these
changes, you should see a substantial speedup.
-- Steve Vavasis
On Wednesday, June 8, 2016 at 7:37:43 PM UTC-4, stst wrote:
>
> When I run the function below with @time brownian(5), it shows over
> 66MB
nsors. Can anyone explain this?
Thanks,
Steve Vavasis
julia> @time test_manyway.test2way(10)
0.001836 seconds (6 allocations: 272 bytes)
49837.4971725032
julia> @time test_manyway.test4way(10)
0.008931 seconds (7 allocations: 432 bytes)
50050.05619989492
j
on foo(x)
> > >>>>
> > >>>>macmac(something)
> > >>>>
> > >>>> end
> > >>>>
> > >>>>
> > >>>> Then whenever you've changed Macro.jl, you need to reload both
> Macro.jl
> > >>>> and Fun.jl, because as far as Julia is concerned,
> `macmac(something)`
> > >>>> isn't
> > >>>> "a reference to the macmac macro"; once Fun.jl has been loaded,
> > >>>> `macmac` is
> > >>>> completely gone from foo's definition, and replaced with its
> > >>>> macroexpansion.
> > >>>>
> > >>>> Doing that, I've never had any issue with reloading macros. Do you
> have
> > >>>> another problem in mind, or more specific code?
> > >>>>
> > >>>> On Monday, May 23, 2016 at 5:31:37 PM UTC-4, vav...@uwaterloo.ca
> wrote:
> > >>>>> First, thanks to Matt Baumann for answering my previous post so
> > >>>>> quickly!
> > >>>>>
> > >>>>> Next question: it seems that for developing and debugging a macro,
> the
> > >>>>> usual REPL cycle of edit/include/edit/include does not work., I
> find
> > >>>>> that
> > >>>>> using 'include' to reload the macro definition defined inside a
> module
> > >>>>> does
> > >>>>> not overwrite its previous definition. It seems that to replace a
> > >>>>> macro
> > >>>>> definition, I need to exit the REPL and start a new REPL. Is
> there
> > >>>>> some
> > >>>>> other way?
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Steve Vavasis
>
>
7;ve never had any issue with reloading macros. Do you have
>>> another problem in mind, or more specific code?
>>>
>>> On Monday, May 23, 2016 at 5:31:37 PM UTC-4, vav...@uwaterloo.ca wrote:
>>>>
>>>> First, thanks to Matt Baumann for answering my previous post so quickly!
>>>>
>>>> Next question: it seems that for developing and debugging a macro, the
>>>> usual REPL cycle of edit/include/edit/include does not work., I find that
>>>> using 'include' to reload the macro definition defined inside a module
>>>> does
>>>> not overwrite its previous definition. It seems that to replace a macro
>>>> definition, I need to exit the REPL and start a new REPL. Is there some
>>>> other way?
>>>>
>>>> Thanks,
>>>> Steve Vavasis
>>>>
>>>>
>
=1&usg=AFQjCNHXjC8cNNi7_jdVi1QPzKUvFFeMTQ>
>>>
>>> for documentation of my latest vaporware. If someone out there who
>>> enjoys macro-writing wants to take a crack at this before I do, feel free!
>>>
>>> -- Steve Vavasis
>>>
>
that
>> using 'include' to reload the macro definition defined inside a module does
>> not overwrite its previous definition. It seems that to replace a macro
>> definition, I need to exit the REPL and start a new REPL. Is there some
>> other way?
>>
>> Thanks,
>> Steve Vavasis
>>
>>
odule does
not overwrite its previous definition. It seems that to replace a macro
definition, I need to exit the REPL and start a new REPL. Is there some
other way?
Thanks,
Steve Vavasis
A macro I'm writing needs a function to check whether a string is a legal
variable name:
islegalvariablename("a_b1") => true
islegalvariablename("1gh") => false
I suppose this functionality must already be available somewhere?
Thanks,
Steve Vavasis
g wants to take a crack at this before I do, feel free!
-- Steve Vavasis
On Thursday, May 19, 2016 at 9:47:12 PM UTC-4, vav...@uwaterloo.ca wrote:
>
> The two functions test4 and test5 below are equivalent, but test5 is much
> faster than test4. Apparently test4 is carrying out a
ation. Is
there a macro package or other solution applicable to this form of
computation?
Thanks,
Steve Vavasis
On Thursday, May 19, 2016 at 9:47:12 PM UTC-4, vav...@uwaterloo.ca wrote:
>
> The two functions test4 and test5 below are equivalent, but test5 is much
> faster than
n the example below, if the indirect addressing via array i is
eliminated, then the two functions have comparable performance.)
Thanks,
Steve Vavasis
function test4(n)
y = [2.0, 6.0, 3.0]
i = [1, 2, 3]
z = [0.0, 0.0, 0.0]
u = 0.0
for j = 1 : n
z[:] = y[i]
u +=
ication of this capability (if it were
>> possible)? -- Steve Vavasis
>>
>> On Wednesday, January 13, 2016 at 3:59:57 PM UTC-5, Ritchie Lee wrote:
>>>
>>> As I understand it, Julia dicts use Base.hash when storing custom types
>>> as keys. Is ther
Could I ask what would be an application of this capability (if it were
possible)? -- Steve Vavasis
On Wednesday, January 13, 2016 at 3:59:57 PM UTC-5, Ritchie Lee wrote:
>
> As I understand it, Julia dicts use Base.hash when storing custom types as
> keys. Is there a way to look up
First, here is a point that you probably already know: you can define
another constructor for the type that takes zero arguments and fills the
fields with default values. Perhaps that partly solves your problem?
Of course, in this zero-argument constructor, you still have to call the
built-in
that g declares A as a const
argument.
My point is that in order to preserve the const-ness of a returned value,
it would be necessary to also extend the language with const arguments for
functions. I don't see how to have one without the other.
-- Steve Vavasis
On Tuesday, October 27,
but setindex! throws
an error.
(3) The promise that a routine won't change a 'const' argument could easily
be defeated by aliasing (i.e., a function is invoked with a const argument,
but another non-const argument refers to the same piece of data), so it may
give the user a fals
is sometimes called the
> 'Euclidean distance matrix completion' problem by mathematicians and the
> 'sensor localization' problem by engineers. If you search in google
> scholar on either of these terms, you'll find many papers. Jon Dattorio
> wrote an entir
ns and the
'sensor localization' problem by engineers. If you search in google
scholar on either of these terms, you'll find many papers. Jon Dattorio
wrote an entire book on the problem.
-- Steve Vavasis
On Tuesday, October 20, 2015 at 11:12:44 PM UTC-4, Spencer Russell wro
ld be possible for a team to ignore them, at least
initially. But I have also seen in previous projects that there is a
tendency for people (including me) to jump onto the fanciest possible
solution offered by the programming language to solve a software design
problem.
-- Steve Vavasis
On Thu
in order to carry out Kevin's mandate. But this
turns out to be not so hard!
-- Steve Vavasis
On Wednesday, October 21, 2015 at 1:00:25 PM UTC-4, Tom Breloff wrote:
>
> I think this discussion shows complementary definitions of traits:
>
>- verb-based traits: a type
s that lock you into a certain
path. This path may not be compatible with the flexibility needed for
scientific software projects.
I for one am glad that the designers of Julia decided not to make Julia an
object-oriented language, at least not in the C++ sense of the term.
-- Steve Vavasis
On
-- Steve Vavasis
ead of Bool, a quite likely error
for a former C++ programmer. Here is the message from Julia:
ERROR: LoadError: TypeError: T: in type definition, expected Type{T}, got
Function
(etc)
while loading c:\Users\vavasis\Documents\Projects\julia\testerror1.jl, in
expression starting on line 3
The line
ram correctness.
This example says that covariance for a container would undermine our
ability to reason about program correctness unless the container is
immutable. But in fact, Julia allows tuples (which are immutable) to be
covariant in version 0.4+, so we are still safe.
-- Steve Vavasis
gt; >> it thinks the programmer made a mistake. (See the trace below-- both
> are
> >> cases where Julia 0.4 changed behavior from 0.3).
> >>
> >> It is important for Julia to be vigilant about catching obvious
> programmer
> >> errors. This will help
nctions like in(x::Any,itr::Any) from reduce.jl or
start(x::Number) from number.jl that allow oddball user code to be accepted
by the compiler would be put into ExpansiveBase. The semantics for
'in(a,b)' when only Base is loaded should be either typeof(a)==eltype(b) or
that there exists
her than Pair{K,V} so it is incompatible with Dict.
I'm trying to understand the relevant issues in order to fix this. I am
running Julia 0.4, 15-day-old master.
Thanks,
Steve Vavasis
One way to check this would be to time a
>>>> function that involves multiple calls to the allocator (say, one that
>>>> creates arrays in an inner loop) versus a function that involves mostly
>>>> stack operations (say, a lot of floating point arithmetic). See
stly stack operations
(say, a lot of floating point arithmetic). See how these timings or
profiles compare to the timings/profiles of the same functions in a Julia
installation that is working properly.
-- Steve Vavasis
On Thursday, August 27, 2015 at 1:26:04 PM UTC-4, Chris wrote:
>
> (2) Did
. Did you try downloading and testing
a 32-bit version of Julia?
(2) Did you try @profile versioninfo() followed by Profile.print()?
-- Steve Vavasis
On Thursday, August 27, 2015 at 11:29:53 AM UTC-4, Chris wrote:
>
> I thought so. Is there a different function in 0.3 that will give th
I wrote a short macro for Julia 0.4 to generate fixed-length tuples using
comprehension-like syntax. This is useful in code where tuples are used to
represent fixed-length arrays. Here is an example:
v = @tuplegen [(i==2)? i * 6 : i for i = 1 : 3]
macro-expands to
v = (1, 2*6, 3)
I implemented a short macro that unrolls for-loops that have constant
bounds. For example
@unroll for i = 1 : 4
a[i] = b[i] + c[i] + (mod(i,2)==0? d[i] : e[i])
end
gets unrolled to
a[1] = b[1] + c[1] + e[1]
a[2] = b[2] + c[2] + d[2]
a[3] = b[3] + c[3] + e[3]
of the manual says that IntSet can hold 'nonnegative'
>> integers.
>>
>> Thanks,
>> Steve Vavasis
>>
>
>
In the latest 0.4 master, storing a 0 in an IntSet is deprecated. Can
someone explain what is the rationale for this deprecation? Even the
latest version of the manual says that IntSet can hold 'nonnegative'
integers.
Thanks,
Steve Vavasis
and datatype. After I fixed my error, both
snippets reported exactly the same type error (on sitofp). Sorry about
that. So the issue is resolved.
Thanks,
Steve Vavasis
On Saturday, July 18, 2015 at 8:46:46 PM UTC-4, Jameson wrote:
>
> Intrinsics.sitofp doesn't have a return type.
setindex2(m::SortedDict, d_, k_)
insert!(m.bt, convert(keytype(m),k_), convert(datatype(m),d_), false)
end
This is in Julia 0.4, 6-day-old master. Why is the type inferencing not
working as I would have expected?
Thanks,
Steve Vavasis
Simon (and Tim),
Thanks for all the help! Everything in the package seems to be working
now. As always, feedback is welcome!
-- Steve Vavasis
On Sunday, May 31, 2015 at 10:09:29 PM UTC-4, vav...@uwaterloo.ca wrote:
>
> Following up on an earlier discussion that I started in this new
defined
in include at boot.jl:252
in include_from_node1 at loading.jl:133
while loading
c:\Users\vavasis\Documents\.julia\v0.4\Modifyfield\test_modifyfiel
d.jl, in expression starting on line 11
Oddly, the exporting works fine when I load the package manually (i.e.,
include("c:/.../
Simon,
Sorry to follow up so quickly on my own post, but I'm not able to figure
out how to use generated functions for this purpose. Consider:
modifyField!(a,k,Val{:isadded}, true)
The generated-function routine modifyField! needs to know the base type of
a. In other words, there exists s
from the code_native and
code_llvm printouts whether the compiler is able to elide the extraneous
copying in modifyField! due to my limited knowledge of LLVM and Intel
machine language.
-- Steve Vavasis
On Monday, June 1, 2015 at 6:44:29 PM UTC-4, Kristoffer Carlsson wrote:
>
> Does anyon
Simon,
These are both great suggestions, and I'll see if I can get them
implemented. I did not know about generated functions until seeing your
post. Thanks for the feedback!
-- Steve Vavasis
On Monday, June 1, 2015 at 5:57:19 PM UTC-4, Simon Byrne wrote:
>
> That's
Kevin,
Sorry, I'm not understanding your point. Can you give me an example in
which the modifyField! routine might fail? It is completely standard Julia
without any pointer manipulation or other unsafe operations.
Thanks,
Steve
On Monday, June 1, 2015 at 12:16:41 PM UTC-4, Kevin Squire wr
Following up on an earlier discussion that I started in this newsgroup, I
have written a small package that provides a routine to modify a field of
an immutable object in the case that the object is inside a container.
Please refer to:
https://github.com/StephenVavasis/Modifyfield.jl
Feedback
julia-users, and please direct followups to that announcement.
Thanks,
Steve Vavasis
On Sunday, February 8, 2015 at 3:35:20 PM UTC-5, vav...@uwaterloo.ca wrote:
>
> I would like to request the following language feature: a function or
> macro to modify a field of an immutable insi
in the array x to be packed in memory rather
than accessed with pointers. If T were a 'type' then obviously the problem
would go away.
Maybe it is already possible to write a function or macro for this purpose
in the existing language?
Thanks,
Steve Vavasis
followed
in expressions with branching operators: ||, &&, ?:. My code is a bit of a
hack, so comments on how to improve it are welcome. It is available as
follows:
Pkg.clone("git://github.com/StephenVavasis/microcoverage")
-- Steve Vavasis
Kevin,
I agree that if the user decides to update a mutable key by accessing it
through a token, then the container has enough information to patch up its
indexing structure and keep it valid. However, in the trace of a Julia
execution in my original posting, the user clobbered a key inside th
Jameson,
This is going on a bit of a tangent regarding my original question, but in
other postings in this group I have advocated twice for the existence of
read-only versions of the various mutable types in Julia. (This is
somewhat akin to allowing a way for a function to declare that some of
I would like to point out that Python allows only immutable objects as
dictionary keys, presumably to prevent this exact problem. Nevertheless, my
own preference is also to leave things as they are (no new rules), since
Julia's purpose is different from Python's.
Having said this, I would stil
Dear Julia colleagues,
The 'Dict' container in the standard library has the following undocumented
bad behavior: if the key type is mutable, and the user mutates a key that
is already in the dictionary, then the associated (key,value) entry becomes
a zombie: it is no longer accessible either un
gt;
>>>> typealias TDict{K,D} Token{Dict{K,D}, Int}
>>>>
>>>> function makeADict()
>>>> a = TDict([1=>"a",2=>"c"], 5)
>>>> end
>>>>
>>>> end
>>>>
>>
rious error message in
>>> the latest build (952). Is it an error in my code or a bug in Julia? (In
>>> addition to the answer to this question, I would also like help with the
>>> code design question in my previous posting of two hours ago.)
>>>
>>&
;
> julia> testnestparam2.makeADict()
> ERROR: type: makeADict: in apply, expected Function, got
> Type{Array{Dict{K,D},1
> }
> in makeADict at
> c:\Users\vavasis\Documents\Projects\qmg21\julia\testnestparam2
> jl:6
>
>
>
> On Tuesday, October 7, 2014 10:05:09 AM U
d Function, got
Type{Array{Dict{K,D},1
}
in makeADict at
c:\Users\vavasis\Documents\Projects\qmg21\julia\testnestparam2
jl:6
On Tuesday, October 7, 2014 10:05:09 AM UTC-4, vav...@uwaterloo.ca wrote:
>
> Thanks for the explanation! Although I think I understand your answer,
> I'm n
and D are determined from the input args).
Can I write typealias SDToken{K,D} Token{SortedDict{K,D},IntSemiToken}? I
tried this and got an unexpected error message:
ERROR: type: test1: in apply, expected Function, got
Type{Token{SortedDict{K,D},
IntSemiToken}}
in test1 at
c:\Users\vavasis\Document
that the type of t includes dummy parameters K and
D, which aren't real types at all?
(2) Why is Julia not able to match t2 but it is able to match t to the
signature of test0()?
Thanks,
Steve Vavasis
julia> testnestparam.test1()
typeof(t) = Token{SortedDict{K,D},IntSemiToken}
t
(Could someone clarify that?)
Furthermore, if I ever try parallelizing the code, this may influence
whether (1) or (2) is better. (Could anyone comment on that?)
I'm wondering which approach is preferable in Julia. Perhaps there is a
third approach that beats both of these?
Thanks,
Steve Vavasis
mpiler, when applied to f3, cannot tell which
>>>> of the two methods entitled gsub is called. (At least, this is what I
>>>> guess from looking at the code_native printout. Unfortunately, I cannot
>>>> read assembler, but I can make conjectures by comparing
a
>> subscript-out-of-bounds error when the @inbounds macro is used, namely, if
>> the rule is violated, then anything could happen. There could be a
>> compiler flag called --possible-aliasing in which the user warns that
>> aliasing might be present and therefore instructs the
opposite: the compiler accepts a flag in which the user promises no
aliasing).
-- Steve Vavasis
On Thursday, August 21, 2014 12:46:30 AM UTC-4, Jameson wrote:
>
> If you called f(x) which calls g(x), but g(x) does not exist, you are
> going to get a no-method error. Or if you
' and either no update or slow update. You can see
> a HUGE hit on performance between slow and fast update for `type'; for
> immutable there would presumably also be a difference, although apparently
> smaller. (Obviously, I can't test fast update for immutable; this is
f readonly either by the caller or the
function. The third one (enabling automatic program transformations),
however, is possible only if the function rather than the caller imposes
the readonly requirement.
-- Steve Vavasis
On Tuesday, August 5, 2014 5:38:17 PM UTC-4, vav...@uwaterloo.ca w
posal is in a different thread in this newsgroup. The
consensus seems to be that the proposal works fine with existing Julia, but
some respondents questioned whether the proposal would get buy-in.
-- Steve Vavasis
On Tuesday, August 5, 2014 5:38:17 PM UTC-4, vav...@uwaterloo.ca wrote:
>
right direction.
-- Steve Vavasis
On Thursday, August 14, 2014 2:59:28 PM UTC-4, Rafael Fourquet wrote:
>
> Hi Julia users,
>
> As this is my first post, I must say I'm extremely impressed by julia, met
> 2 weeks ago. For many months I've meant to clean-up a C++/p
As a newcomer to Julia, I'm having a bit of trouble following this
discussion: is it OK if I try to summarize it in my own words and you tell
me whether I've understood?
'Traditional' Julia: you can pass a function f as an argument to another
function g.
Rafael's functors: instead you create n
ugh there is an open discussion about that matter on
> github).
>
> and a second minor disadvantage
>
> (2) The enforcement of read-only would probably would not work
> recursively, e.g., if a were an array of arrays. In fact C++ has a similar
> gap in its 'const' mechanism.
>
> -- Steve Vavasis
>
>
currently no abstract
> parent for Set (although there is an open discussion about that matter on
> github).
>
> and a second minor disadvantage
>
> (2) The enforcement of read-only would probably would not work
> recursively, e.g., if a were an array of arrays. In fact C++ has a similar
> gap in its 'const' mechanism.
>
> -- Steve Vavasis
>
>
In fact C++ has a similar gap in its
'const' mechanism.
-- Steve Vavasis
e that some file has defined in(x::Any,y::Any) to be false. Why
> is this so? This definition appears to impede debugging because, for
> example, if a programmer accidentally reverses the two arguments to 'in()'
> or makes some less obvious blunder with types, no error message is issued.
>
> Thanks,
> Steve Vavasis
>
>
ing because, for
example, if a programmer accidentally reverses the two arguments to 'in()'
or makes some less obvious blunder with types, no error message is issued.
Thanks,
Steve Vavasis
Michael,
I am much more of a newbie at Julia than you, but it seems to me that there
is a brute-force solution to this problem, namely define a few dozen
methods:
vcat(A1::CVXArray{T}, rest::AbstractArray{T}...)
vcat(A1::AbstractArray{T}, A2::CVXArray{T}, rest::AbstractArray{T}...)
vcat(A1::Abs
e first
> three use 'type' and either no update, fast update, or slow update; the
> last two use 'immutable' and either no update or slow update. You can see
> a HUGE hit on performance between slow and fast update for `type'; for
> immutable there would
ce between slow and fast update for `type'; for
> immutable there would presumably also be a difference, although apparently
> smaller. (Obviously, I can't test fast update for immutable; this is the
> point of my message!)
>
> So why does Julia impose this apparently needle
immutable' and either no update or slow update. You can see
> a HUGE hit on performance between slow and fast update for `type'; for
> immutable there would presumably also be a difference, although apparently
> smaller. (Obviously, I can't test fast update for imm
over current Julia.
-- Steve Vavasis
On Tuesday, August 5, 2014 5:38:17 PM UTC-4, vav...@uwaterloo.ca wrote:
>
> Dear Julia users,
>
> It seems to me that Julia's distinction between a 'type' and an
> 'immutable' conflates two independent properties; the co
t the performance hit, I wrote five functions below. The first
> three use 'type' and either no update, fast update, or slow update; the
> last two use 'immutable' and either no update or slow update. You can see
> a HUGE hit on performance between slow and
immutable there would presumably also be a difference, although apparently
smaller. (Obviously, I can't test fast update for immutable; this is the
point of my message!)
So why does Julia impose this apparently needless restriction on immutable?
-- Steve Vavasis
julia> @time testim
1 - 100 of 125 matches
Mail list logo
