I hope that there is something I am missing, or making a mistake in the
following example:
r = rand(10)
test1(r) = sum( t^2 for t in r )
test2(r)= sum( [t^2 for t in r] )
@code_warntype test1(r) # return type Any is inferred
@code_warntype test2(r) # return type Float64 is inferred
This ca
I didn't actually test performance - the problem for me was re-use of the
output of test1. But it is hard to reproduce this with a simple example.
The same code works in some situations and not in others - I haven't yet
found out why.
sum( Float64[] ) = 0.0 ?
Yeah, this definitely matters for performance. It is a real shame since the
generators are so elegant to use.
inner1(R, i) = sum( R[j,i] for j = 1:size(R,1) )
inner2(R, i) = sum( [R[j,i] for j = 1:size(R,1)] )
function test(R, inner)
n = [ inner(R, i)^2 for i = 1:size(R,2) ]
N = leng
would it maybe be possible to introduce a macro like @inbounds that somehow
turns off the check that the generator is empty?
The sum of an empty set or vector is undefined it is not zero.
> you can rewrite it in a more explicit way
>
>>
>>
Actually a sum over an empty set is normally defined to be zero while a
product over an empty set is normally defined to be one.
why would type inference for sum(t^2 for t in r) be different from [t^2 for
t in r] ?
On Friday, 23 September 2016 07:42:00 UTC+1, Michele Zaffalon wrote:
>
> On Fri, Sep 23, 2016 at 2:23 AM, Steven G. Johnson > wrote:
>>
>>
>> We could use type inference on the function t -> t^2 (which is burie
I didn't quite follow what the conclusion is: is it a bug that should be
fixed (i.e. open an issue?), or is it expected behaviour and I should stop
using generators when I need type inference?
Thanks.
I am largely a fan of Matlab-idioms, but repmat is an exception, it leads
to code that only the person who wrote it will understand (at least for a
few days after they wrote it)
also look at `StaticArrays` and `reinterpret`
E.g.,
R = reinterpret(SVector{3,Float64}, r, m)
I use this a lot and find it very convenient.
I've used FixedSizeArrays in the past but switch to StaticArrays, they seem
more convenient in a few of ways, but for 90% of use cases they seem to be
comparable. To protect myself against a possible move to yet another
package, I added a layer of `typealias`.
f(n) = [ i^2 for i = 1:n ]
julia> f(0)
0-element Array{Int64,1}
On Wednesday, 12 October 2016 07:10:37 UTC+1, Jussi Piitulainen wrote:
>
> Does that mean that an empty array comprehension is always Array{Any}?
>
> that array comprehensions are now type-inference-independent. That means
>> that t
However,
g(n) = sum( i^2 for i = 1:n )
julia> g(0)
ERROR: MethodError: no method matching zero(::Type{Any})
Closest candidates are:
zero(::Type{Base.LibGit2.Oid}) at libgit2/oid.jl:88
zero(::Type{Base.Pkg.Resolve.VersionWeights.VWPreBuildItem}) at
pkg/resolve/versionweight.jl:80
zero(::Type
a collaborator of mine is using pyjulia in a similar way - implement
reasonably fast interatomic potentials in Julia, but use all the tools
available in Python for model setup etc.
In case it helps, you can look at
https://github.com/libAtoms/JuLIP.jl/blob/master/temp/julip.py
as an exampl
Have a look at `JuMOS`, `QuantumLab.jl` and `JuLIP.jl`, it would be nice to
coordinate rather than develop multiple molecular simulation packages.
There is also an issue about this somewhere
https://github.com/JuliaLang/julia/issues/1255
I haven't tried, but I think it should be
result = j.inv(randMat)
On Tuesday, 25 October 2016 05:05:47 UTC+1, Corbin Foucart wrote:
>
> How? If you don't mind my asking. It doesn't seem that documentation
> exists... Suppose in a python script, I have:
>
> [python imports]
> [pyjulia initializ
Is there as iterator implemented that allows me to iterate over all
non-zero entries of a sparse matrix or vector? E.g.
for (i, j, z) in nonzeros(A)
(I realise that nonzeros does something else!)
missed that - thank you.
So `findnz` converts the matrix to a tuple of arrays (triplet), and it
creates a copy of all data.
So it is not quite what I was looking for. An iterator would be better.
nzrange will work but is not as convenient.
I agree on Emacs , though there is a long thread here somewhere on light table
and sublime.
Great that so many are contributing to Julia, but I would question whether such
a large number of packages will be healthy in the long run. It will make it
very difficult for new users to use Julia effectively.
I have mostly been using the standard Julia mode until now, but I am
thinking of switching to ESS-mode. This has some obvious advantages, but I
cannot insert unicode symbols from latex anymore. I thought I'd notice
other things, but nothing else so far that really bugged me.
* Has anybody f
The short answer is: assemble the sparse matrix in triplet format, then use
`sparse` to convert to CCS format. Assembling in CCS format (what you are
doing) is almost generically slow.
Christoph
but on a second look, your matrix doesn't look sparse at all, but some sort
of lower triangular structure? I don't think sparsity can help you here.
Wonderful - I was planning to ask on this list whether anybody is planning
such a package.
Christoph
On Tuesday, 27 January 2015 22:46:59 UTC, Luthaf wrote:
>
> Hi julians !
>
> I am very happy to announce the release of Jumos, a Julia package for
> molecular simulations.
>
> You can find
What are your short-term and long-term aims with this package? A user code,
teaching code or research code? Do you have specific applications in mind?
Christoph
I've tried (but failed), with Julia 0.4, to use Markdown strings doc" . .
." as messages, e.g., error messages or just to make some complex program
output more readable.
If, in a REPL or IJulia, I just write
doc"blah `code` bleh"
in a single line, then this shows ok. But of course in a func
I was delighted to find that Julia has robust summation algorithms
implemented in Base.
In my code I also need robust inner product. Is that implemented as well? I
couldn't find it, but it is easy to write for myself
(trivially sum_kbn(x.*y), but this allocates extra memory)
But are there othe
Is this an existing issue somewhere?
On Sunday, 1 February 2015 12:18:42 UTC, Christoph Ortner wrote:
>
>
> Thanks for the clarification. It would be really great to have this
> functionality, especially, if it can be combined with MathJax!
>
> Thanks,
> Christoph
>
Thanks for the clarification. It would be really great to have this
functionality, especially, if it can be combined with MathJax!
Thanks,
Christoph
should this go in Docile, Lexicon, or Julialang?
Christoph
thanks for the suggestions; indeed, Rumpf's paper is my main reference :)
for these things.
created issue [10009](https://github.com/JuliaLang/julia/issues/10009)
many thanks - well I will implement it first of all, and then see where it
could go.
Christoph
Maybe this was obvious for most, but for those who didn't realise it,
stevengj mentioned in 1009 that `display` will correctly render a MD object.
Christoph
On Monday, 2 February 2015 16:59:19 UTC, Steven G. Johnson wrote:
>
> It might be nice to submit a patch to OpenBLAS to make their dot functions
> use pairwise summation; this is almost as accurate as KBN summation but
> with negligible performance penalty (for a large base case), so it should
hat as well - thanks.
Christoph
On Wednesday, 4 February 2015 00:04:13 UTC, Steven G. Johnson wrote:
>
> On Tuesday, February 3, 2015 at 4:48:20 AM UTC-5, Christoph Ortner wrote:
>>
>> For my own applications, I really need something much better than
>> pairwise s
I am trying to re-structure a molecular simulation code I've been working
on, to make it more readily extendable. I am puzzling over how to do this
most effectively in Julia, and would appreciate any thoughts from more
experienced Julia programmers. I am roughly trying to mimic the structure
o
Many thanks for the discussion.
On Wednesday, 4 February 2015 16:46:09 UTC, Josh Langsfeld wrote:
>
> For me, option 1 looks the most Julian. Maybe the clunkiness is arising
> because the calc object shouldn't be a field of Atoms? Fields are just
> suppose to store data, not logic or methods.
On Wednesday, 4 February 2015 16:59:14 UTC, Avik Sengupta wrote:
>
> I don't understand your domain of course, but the way I'd do this would be
> a slight variant of OPTION 1
>
> get_forces(a::AbstractAtom) = error("All AbstractAtom subtypes should
> implement get_forces")
> get_forces(a::Atom)
I don't understand your domain of course, but the way I'd do this would be
a slight variant of OPTION 1
>
>> get_forces(a::AbstractAtom) = error("All AbstractAtom subtypes should
>> implement get_forces")
>> get_forces(a::Atom) = get_forces(a.calc)
>>
>>
> this is indeed what I've done at the mo
On Wednesday, 4 February 2015 16:59:14 UTC, Avik Sengupta wrote:
> I don't understand your domain of course, but the way I'd do this would be
>> a slight variant of OPTION 1
>>
>> get_forces(a::AbstractAtom) = error("All AbstractAtom subtypes should
>> implement get_forces")
>> get_forces(a::Ato
On Wednesday, 4 February 2015 18:30:06 UTC, Josh Langsfeld wrote:
>
> I'm very much enjoying thinking about this and considering what might be
> the most Julian approach
>
> > I thought one problem with not having "proper" inheritance is that this
> doesn't really help? Even small variations ac
> thought one problem with not having "proper" inheritance is that this
doesn't really help?
>
> I meant more about commonality of behaviour.
>
I think this goes exactly in the direction that I discuss in the last post?
I just "assume" for the Abstract versions of the different types how they
On Wednesday, 4 February 2015 20:02:43 UTC, Josh Langsfeld wrote:
>
> On Wed, Feb 4, 2015 at 2:29 PM, Christoph Ortner > wrote:
>
> If I read this correctly, then what you are saying is that I am allowed to
>> assume that my concrete abstract subtypes will contain certa
I've used Reactive and Interact without any difficulties, but then again I
never had problems with Julia.
Christoph
Julia, conveniently provides an `Int` type, which is alias for `Int64`. I
like this because it frees me from thinking about which integer type to
use. But there is no corresponding `Float` type which is alias for
`Float64`. Why?
It seems a trivial thing, but who knows what shifts will happen
Thanks for clarifying; so in fact I am using `Int` the wrong way, and
should normally specify whether I want Int16, Int32, Int64?
Thank you,
Christoph
ok - thanks a lot.
Christoph
I just discovered the Cartesian package; what a nice set of tools! I have a
question though and couldn't find the answer anywhere (apologies if I've
missed it):
within an `@nloops` construct I can write, say
t = @nref A $N i
but I cannot write
@nref A $N i = t
and instead ha
that simple - thanks!
Christoph
[The Juno mailing list seems dead? Hence I am re-posting my question here;
apologies for posting twice.]
Juno doesn't seem to recognise doc strings, or am I getting something
wrong? Here is a short piece of code:
using Docile, Lexicon
@doc doc"Some doc with `markdown`."->function blah()
p
ah - just saw your reply there
http://discuss.junolab.org/t/julia-0-4-docile-doc-strings/120/2
Thanks a lot!
Also: I am quite enjoying working with Juno, even though I normally use
only EMACS - I just found that neither the standard Julia mode more the ESS
Mode are quite mature enough. So than
>
> For this reason, while I am happy to talk about how nice Julia is, I
> will not try to convince people to switch to it. IMO the people who are
> potential switchers at this stage have already looked at Julia, and
> evangelizing more aggressively could be counterproductive at this stage.
I th
In fact, I think Steven's suggestion is the approach may specialised
packages take anyhow?
Christoph
On Thursday, 5 March 2015 17:49:24 UTC, Stefan Karpinski wrote:
>
> On Thu, Mar 5, 2015 at 7:43 AM, Christoph Ortner > wrote:
>
>> For this reason, while I am happy to talk about how nice Julia is, I
>>> will not try to convince people to switch to it. IMO the p
I can send you some thoughts over email, but this is not Julia related, so
I won't post here. Christoph
I've started to work mostly with Julia 0.4 recently since has a lot of
useful tools for me. I noticed the following error message:
"indexing with non Integer Reals is deprecated"
I guess this is due to
Issue https://github.com/JuliaLang/julia/issues/10154. I may well be
missing a crucial point
Here is, right away, one other example that has annoyed me for a long
time: `meshgrid`. It may not be "Julian", but it is incredibly convenient
for quick experiments. I know I can get it from examples, but I don't
understand why it hurts having it in Base.
Christoph
Lex, Stefan: Would it not be possible to throw an exception when the
conversion is considered "unsafe"?
On Sunday, 15 March 2015 17:21:18 UTC, Ivar Nesje wrote:
>
> That's one place off at the end of a 10 petabyte array. We're really
> planning for the future. But as I think about it, we've grown 10 MB to 10
> GB arrays in 20 years, so who knows what the future will bring.
>
> Personally I think
For example, for finite elements or finite differences, the connectivity
information gives you the sparsity pattern, which you could assemble once
and for all and then change the entries as needed. If it is a low-order
method, then you have few elements in each column and it would be very
effi
A comment in **strong support** of the Julia naming convention: these are
just my personal impressions:
I think in much of numerical analysis (and to some but lesser extent
scientific computing) overly short variable names are fairly popular, I
think because they represent a direct translation
A P.S.: A few people complain about Matlab's naming conventions. But
something to keep in mind is that Matlab is an incredibly popular tool,
largely because of its simplicity of use. Something you don't want to loose.
:20 UTC, Christoph Ortner wrote:
>
> I think that the standard in mathematical typesetting is to write
> 2
> + 3
> rather than
>2 +
> 3
>
> so personally I find the Matlab syntax easier to read. One of the very few
> choices Julia mad
I'm surprised so few people are bothered by this. Maybe it is just sloppy
coders like myself who worry about it ;).
Christoph
On Friday, 29 May 2015 00:04:46 UTC+1, Yichao Yu wrote:
>
> Sorry. Somehow the gmail hotkey got messed up...
>
> On Thu, May 28, 2015 at 6:08 PM,
Tim's point about brackets makes sense to me. And I can maybe live with
that if Julia editors, in particular EMACS can highlight these cases well.
But without that, I think that
a = b ...
+ c
is visually *much* easier to read than
a= (b
+ c )
Christoph
Just to reiterate a comment I made above: the convention in mathematical
typesetting is
b
+ c
and not
b +
c
this is the main reason I have (more than once) fallen into this trap.
Anyhow, I will try to use brackets for a while and see how I like it.
Christoph
When implementing a function (overloading getindex to be precise) to allow
: as an argument I expected that I would need to do the following:
funA(_::Colon) = println("funA")
but the following works as well
funB(:) = println("funB")
Why? When I type ?: in the REPL I find that : is an instanc
ah - extremely embarrassing mistake. Thank you.
So was funA the "correct" way to implement this?
Christoph
great - thank you!
On Thursday, 4 June 2015 14:16:42 UTC+1, Yichao Yu wrote:
>
> On Thu, Jun 4, 2015 at 9:13 AM, Yichao Yu >
> wrote:
> > On Thu, Jun 4, 2015 at 9:10 AM, Christoph Ortner
> > > wrote:
> >> ah - extremely embarrassing mistake. Thank you.
f
>> end
>>
>> i'm not advocating for a mandatory line continuation character. that
>> would be terrible. but changing julia to look at the preceding line if the
>> current line doesn't make sense by itself would be great.
>>
>> ben
>>
>
Do I understand correctly that `eval` cannot be overloaded?
I get the following message (0.3.9):
Warning: import of Base.eval into Lattices conflicts with an existing
identifier; ignored.
Thanks,
Christoph
ially if indentation is used effectively.
>
> On Thursday, June 18, 2015 at 6:53:54 AM UTC-5, Christoph Ortner wrote:
>>
>>
>> I think parenthesis are "ok", but only just. They make the code busier
>> and more difficult to read.
>> Christoph
>&
I didn't fully understand this: are you saying that, unless I use
`baremodule`, I cannot overload `eval`?
my usage is simply that I have type A, say, that defines a function and I
want to call eval(A, arg) to evaluate. I am perfectly happy to just call
`feval` instead of `eval`, but I was curi
ok - thank you for clarifying!
Christoph
Has anybody succesfully interfaced with PyAMG (or any other Algebraic
Multigrid package) ? I need an AMG solver and would appreciate any
suggestions if somebody already has some positive experiences.
Thanks,
Christoph
One example are built-in iterative solvers, at least the basic ones such as
PCG, GMRES, but I think people made strong arguments against having these
in Base. At some point though there was a discussion about outsourcing
some of Base into a standard library, and in that case it could make sense
Just to comment on my own question: PyAMG together with PyCall seems quite
straightforward to use (so far).
Mostly for curiosity: I didn't find any code in PyCall that converts sparse
matrices to Python objects. Where is that?
Christoph
A little hack I use when I have "important" fields that are always present
and need fast access, but many others as well is this
type MyType
field1
field2
misc::Dict
end
getindex(m::MyType, i::Symbol) = m.misc[i]
function setindex(m::MyType, val, i::Symbol) m.misc[i] = val; end
Then I
The tendency seems to be to provide packages (easy to install) instead of
built-in.
For iterative solvers look at IterativeSolvers.jl. For AMG, I have just
started to use PyAMG (via PyCall) which was very easy to setup and seems to
work fine.
Christoph
Very interesting, then why does the following code work?
using PyCall
@pyimport pyamg
@pyimport scipy.sparse as scipy_sparse
# generate 2D laplacian
N = 10
L1 = spdiagm((-ones(N-1), 2*ones(N), -ones(N-1)), (-1,0,1), N, N) * N^2
B = kron(speye(N), L1) + kron(L1, speye(N))
# load into Python
B_py_cs
It seems this was it.
If I do the following:
function py_csc(A::SparseMatrixCSC)
# create an empty sparse matrix in Python
Apy = scipy_sparse.csc_matrix(size(A))
# write the values
Apy[:data] = copy(A.nzval)
# write the indices
Apy[:indices] = A.rowval - 1
Apy[:indptr
On Sunday, 21 June 2015 09:36:28 UTC+1, Tony Kelman wrote:
>
>
> One thing that might be interesting to do, if you really need the matrix
> to be CSR once it's in Python, would be to compare Julia's sparse transpose
> to scipy's.
>
Interestingly, the times are comparable even though Julia take
Should the conversion of Sparse Matrices into Python go into PyCall?
Christoph
A separate package just for the sparse routines might be overkill, but
maybe people would be interested in PyAMG? To be honest, it is still pretty
straightforward to just do it via PyCall, but maybe as a convenience
wrapper. I'll do it if there is sufficient interest.
Christoph
an obvious way to do it is
first(find(x))
last(find(x))
but there might be more efficient ways.
Christoph
On Friday, 10 July 2015 14:10:53 UTC+1, paul analyst wrote:
>
> How to find last somethink in vector ?
> how to find index of last "1"
> 1
> 0
> 0
> 1
> 0
> 0
> 0
> 1
> 1
> 0
I am curious where your problem comes from. If A and B are both stiffness
matrices (as opposed to A stiffness and B sparse) then the associated
eigenvalue problem (in the limit h \to 0) is in general ill-posed. So I am
first of all a little surprised that Matlab gives you a "correct" answer to
I seem to be in the minority "too many packages" camp. I would prefer stable
updates of julia version which means that key functionality should be included
in core, e.g. BLAS, sparse solvers, eig, eigs, basic plotting and so on and so
forth. But at some point there was an idea of having core and
For a long time I had a question which seems closely related to this
thread: https://groups.google.com/forum/#!topic/julia-users/621ta_jPdkA,
so it seems as good a time as any to bring it up :
I think the Julia package management is really wonderful, but what this
question relates to is what t
Thank you everyone for the comments and discussion.
Then again there are those of us who prefer to not think about types too much
on first implementations and worry about performance afterwards.
Christoph
Premature optimisation is the root of all evil.
>
> But I think Julia started off as very intuitive and educational and I hope
> it will continue on this road =)
>
+ 1e1e1e...
This is my first attempt at metaprogramming, so apologies if this should be
obvious from the documentation (or just obvious):
For defining an interface I am implementing "dummy functions" which just
return a tailored error message if an interface function has not been
implemented. At the moment
Thank you, both. Combined with your suggestions and some more fiddling I
got it to work; see below. This doesn't use all the ideas you suggested, so
it probably not the most elegant solution. I'll try to understand your
other suggestions and incorporate them. Many thanks again,
Christoph
m
Ok - thanks for the additional suggestions. I will have to spend some time
with these. Many thanks again.
Christoph
Just one last question though:
Is there a way to write the macro so that I could attach the doc strings as
usual, i.e.
@doc doc"yads"->
@protofun(ffun, Integer, String)
instead of
@protofun(ffun, Integer, String, "yads")
? I couldn't figure this out at all.
Thanks,
Christoph
This is wonderful - thanks!
But no chance to get it to work in 0.3?
Thanks, Christoph
1 - 100 of 361 matches
Mail list logo
