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 it's
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
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
t;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
the
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
.) 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.CHOLMOD.common
bles, 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 Noronha wrote:
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,
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
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
On W
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
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
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
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
`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 later for interacting with the C li
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.C_Spa
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
rsion 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
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, June 9, 2016 at 6:28:27
-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
. 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
julia&
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
>>>>
>>>>
>
_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
>>>
>>>
>>>
>>>
>&
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
>>
>>
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
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 heap a
. 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 test4. A
?
(In 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 += sum(z
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
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
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
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, 2015 at 4:52:21 AM UTC-4
) 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 false sense of security.
-- Steve Vavasis
On Monday
ometimes 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 entire book on the problem.
>
&g
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 Thursday
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 wrote:
>
> I have a
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 Sunday, October 18, 2015 at 8
-- Steve Vavasis
is 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
On Thursday, Octob
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 number is misleading
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 a method convert(eltype(b),a).
-- Steve Vavasis
rammer 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 improve its chances f
,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
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 you try @profile versioninfo() followed
. 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 the same
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 you try @profile
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)
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
that IntSet can hold 'nonnegative'
integers.
Thanks,
Steve Vavasis
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] +
(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
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. It needs
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 newsgroup, I
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
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 anyone know
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 some impressive
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
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
-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 inside a container. Consider
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
was 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
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
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
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
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
=a],[15=b]]) #line 6
println(a[1][-9] = , a[1][-9])
end
end
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
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\Documents\Projects
}
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 not sure how to define the types to accomplish my goal.
* a Token
} Array{Dict{K,D},1}
function makeADict()
a = ADict([[-9=a],[15=b]]) #line 6
println(a[1][-9] = , a[1][-9])
end
end
julia testnestparam2.makeADict()
ERROR: type: makeADict: in apply, expected Function, got
Type{Array{Dict{K,D},1
}
in makeADict at
c:\Users\vavasis\Documents
}
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 not sure how to define the types to accomplish
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}
typeof(t2) = Token
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
: 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 are using run-time eval
transformations that assume no-aliasing. (In other languages, the
situation is 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
,
the
situation is 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
in the
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++/python lib of
mine, for public
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:
Dear Julia
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 wrote:
Dear Julia users
!)
So why does Julia impose this apparently needless restriction on immutable?
-- Steve Vavasis
julia @time testimmut.type_upd_none()
@time testimmut.type_upd_none()
elapsed time: 0.141462422 seconds (48445152 bytes allocated)
julia @time testimmut.type_upd_fast()
@time
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
' mechanism.
-- Steve Vavasis
'const' mechanism.
-- Steve Vavasis
in its
'const' mechanism.
-- Steve Vavasis
, 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
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
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}...)
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 testimmut.type_upd_none()
@time testimmut.type_upd_none()
elapsed time: 0.141462422 seconds
message!)
So why does Julia impose this apparently needless restriction on immutable?
-- Steve Vavasis
julia @time testimmut.type_upd_none()
@time testimmut.type_upd_none()
elapsed time: 0.141462422 seconds (48445152 bytes allocated)
julia @time testimmut.type_upd_fast()
@time
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 needless restriction on immutable?
-- Steve Vavasis
julia @time
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 testimmut.type_upd_none()
@time testimmut.type_upd_none()
elapsed time: 0.141462422
(); testcodegen1.t2(3.0); toc()
elapsed time: 0.53437478 seconds
0.53437478
It seems that using ordinary 'if' statements to distinguish the debugging
mode entails a big performance hit.
Thanks for the help,
Steve Vavasis
On Wednesday, May 29, 2013 1:46:21 PM UTC-4, Simon Hardy-Francis wrote
in Julia, and I'm wondering why it
was omitted.
Thanks,
Steve Vavasis
P.S. Something unexpected and very helpful happened with these types: When
I created a SortOrderDict and assigned it to x, and then I typed just 'x'
into the shell, I got a really nice printout of my SortOrderDict (it
printed out
would outweigh the benefit.)
Thanks,
Steve Vavasis
P.S. Sorry again for my earlier post in which I complained that
start/done/next was incorrectly designed in Julia; I'll try to keep future
questions more intelligent!
of performance from 'if' at run-time
would outweigh the benefit.)
Thanks,
Steve Vavasis
P.S. Sorry again for my earlier post in which I complained that
start/done/next was incorrectly designed in Julia; I'll try to keep future
questions more intelligent!
Any arguments lead to one version of the routine with
run-time dispatch.
For my application, I would prefer to avoid run-time dispatch for
performance reasons, which means that I apparently can't use Steven's
suggestion if my understanding is correct.
Thanks,
Steve Vavasis
On Thursday, July 24
1 - 100 of 116 matches
Mail list logo
