julia large = [i^4 + 1e12 for i in 1:10^3] ;
small = [1:10^3] ;
plot(small,large)
or
julia large = [i^4 + 1e12 for i in 1:10^3] ;
small = [1:10^3] ;
p = FramedPlot() ;
plot(p,small,large)
In master Julia the result is 3. I must have changed that when I
reorganised the norm code. I think that 3 is the right answer anyway. In
Julia [1 2 3] is a 1x3 matrix, i.e. not a vector. If you want it to behave
as a vector, make it a vector. This causes some confusion when coming from
MATLAB,
Hi Andreas,
I understand, though from your email it is as if this was an unintended
behaviour.
It is still very error-prone. In such cases Matlab returns 6, which is
wrong from a matrix viewpoint, but probably closer to what people typically
expect.
Numpy has the same behavior. The latter is
I think it is unavoidable with some surprises when migrating from MATLAB or
some other language. Hopefully, most are covered [here](
http://docs.julialang.org/en/latest/manual/noteworthy-differences/?highlight=matlab).
Personally, I prefer consistency within the language over familiarity for
On Tue, Mar 4, 2014 at 11:02 AM, Andreas Noack Jensen
andreasnoackjen...@gmail.com wrote:
makes really good sense. The distinction between arrays and and matrices
in Numpy has been confusing to me, but actually it appear that Numpy agrees
with how Julia is doing it right now
In [1]: import
Hello all,
Is anyone aware of a linear convolution implementation?
The Base.conv and Base.conv2 functions are implemented with fft which makes
them circular convolution functions (as far as I know).
I'm looking for something alike Matlabs conv2 or SciPys signal.convolve2d.
Should be
I think that this is an unpleasant gotcha right now, when I started reading
this post I still thought that the matrix norm of a row/column vector would
reproduce the vector norm.
Because of multiple dispatch, we go to exceptional lengths in Julia to make
sure to only overload the same operation
Both conv and conv2 are linear convolutions but the implementations use the
fft. Maybe the documentation could be more clear on that.
2014-03-04 13:01 GMT+01:00 Oliver Lylloff oliverlyll...@gmail.com:
Thanks Tim.
Can't believe I missed that - been working with Images.jl all day. Nice
job by
I agree with Toivo's proposal.
Introducing vecnorm() would make code and behavior clearer, and at the same
time avoid the problems with the generic norm() function.
Also, since vecnorm() calls norm(), we only have to care about maintaining
the latter.
cheers.
Yes, with sufficient padding, you can compute a linear convolution (of
finite length vectors) exactly using a circular convolution. The FFT might
introduce a little noise in the result, but that is all.
On Tuesday, 4 March 2014 13:12:48 UTC+1, Oliver Lylloff wrote:
Well ok,
Maybe I
Thanks to everyone for the feedback, I actually tend to agree that the use
of two different y axes in the same plot should be discouraged. Sometimes
it's just too convenient...
In the end, I used `Geom.subplot_grid` with a `Geom.bar` plot which worked
fine. However, it only worked with
On Tuesday, March 4, 2014 4:37:15 AM UTC-5, Carlos Becker wrote:
Another option is to add a vecnorm() function, explicitly to treat the
argument as a vector, which would be undefined for other matrix sizes.
A vecnorm function could be defined to work on any iterable type, including
On Tuesday, March 4, 2014 7:05:02 AM UTC-5, Toivo Henningsson wrote:
Because of multiple dispatch, we go to exceptional lengths in Julia to
make sure to only overload the same operation on different types, not to
create functions that do different conceptual operations based on the type.
Tim,
a little bit offtopic question but might it make sense to break of the
algorithmic parts of Images.jl and put it into some signal processing
package?
I know that the imagemagick dependency is a soft one but all the filtering
stuff is IMHO so basic that it belongs to base, or rather into
On Tuesday, March 4, 2014 2:48:05 AM UTC-6, Andreas Noack Jensen wrote:
In master Julia the result is 3. I must have changed that when I
reorganised the norm code.
Since this is a breaking change with no deprecation, it should definitely
be mentioned in NEWS.
*Hi Harven,*
*There is still something wrong...I don't know why. *
*julia **large = [i^4 + 1e12 for i in 1:10^3] ;*
*julia **small = [1:10^3] ;*
*julia **p = FramedPlot() ; *
*julia **plot(p,small,large)*
*FramedPlot(...)*
julia using Winston
ERROR: could not open file
I'm fine with that. Do you want to start it?
--Tim
On Tuesday, March 04, 2014 05:32:02 AM Tobias Knopp wrote:
Tim,
a little bit offtopic question but might it make sense to break of the
algorithmic parts of Images.jl and put it into some signal processing
package?
I know that the
Somehow, I didn't find the reasoning in that particular example very
convincing. The real problem in that example---which the post completely
ignores---is that neither of the axes starts at 0. (The zeros should also
align between the two axes.) I can't see the objection to displaying the
There is DSP.jl: http://dspjl.readthedocs.org/en/latest/index.html
On Tue, Mar 4, 2014 at 10:22 AM, Tobias Knopp
tobias.kn...@googlemail.comwrote:
I don't want to give a definate yes to it but will think a little bit how
such a package could look like.
My Cartesian macro foo is currently
We have some standard DSP stuff in https://github.com/JuliaDSP/DSP.jl. Our
idea is to put everything DSP-related that is not application-specific in
there, and then make other application-specific packages depend on it.
--
João Felipe Santos
On Tue, Mar 4, 2014 at 10:22 AM, Tobias Knopp
I was worried about getting a little noise in the result, so I ran a
quick test in Matlab and Julia, and got almost exactly the same error. This
is the Matlab code:
Ts=0.01;
t=-10:Ts:10;
s=sinc(t);
sc=Ts*conv(s,s);
sc=sc(1000:3000);
sum((sc-s).*(sc-s))
ans =
0.3695
So, at least for
Thanks for the hint. This seems to be a good start although the available
functions already seem to be quite specialized.
The ndimage module from scipy
(http://docs.scipy.org/doc/scipy/reference/ndimage.html#module-scipy.ndimage.filters)
goes into a direction what in my mind could cover a
This depends a lot on the input sizes. For full length convolutions, the
fft approach should be more accurate because of less additions. For very
short kernels this does not hold anymore. But in practice these kinds of
errors are mostly negligable.
Am Dienstag, 4. März 2014 16:42:33 UTC+1
That's funny, because in my opinion the functions in scipy.ndimage.filters
are also specialized, as most of the time they seem to be used in image
processing (but also in time-series processing) :)
In DSP.jl we mainly have functions for one-dimensional signal processing,
though, and it would be
some info that's more beginner level than other replies (so sorry if this
is obvious).
the compiler translates x[end] into x[endof(x)] so you get this error if
you use [end] after something that isn't expecting it.
at the most basic, perhaps you thought something was an array when it
wasn't.
It looks a lot like you're trying to index into a pointer object as though
it were an array. Unlike in C, these are very different things – just as in
C, a pointer has no idea how long it is, whereas an array object knows how
long it is, so when you ask for the last element of it by writing
As a general matter, Python has probably been more heavily optimized for
text IO and dictionary performance.
However in this case, the Counter in library DataStructures.jl is your
friend. On my system it runs almost 2x as fast as the code in your gist,
presumably making it roughly
Part of the advantage is also possible by just declaring the type of your
container.
*counts=Dict{SubString{ASCIIString},Int}()*
Ivar
kl. 18:16:00 UTC+1 tirsdag 4. mars 2014 skrev Keith Campbell følgende:
As a general matter, Python has probably been more heavily optimized for
text IO and
Hi,
Several examples using MCMC.jl work fine, but I now started to look at the
autodiff examples and with linear_regression.jl I am running in below problem.
I added a few println statements to pinpoint the problem and indeed there is no
ExprH{:macrocall}(...) defined.
Is this due to changes
You might get much more response if you provide a (minmal?) executable
example. I can neither verify, nor help debug this issue, as I do not know
what the result variable is. If nobody else recognize the issue from their
own experience, and the rest of us do not have some code to run, we can
Thank you all for your suggestions and comments on the matter. :-)
I had not previously heard of IJulia nor of Sublime-IJulia and I am happy
to give both a go.
Alas, I have run into some difficulties with the IJulia installation. I
started out by using the Anaconda Python installer to get an
This is probably due to #4882https://github.com/JuliaLang/julia/issues/4882
where
we changed the behaviour of the ~ operator to translate to a macrocall
instead of a function. The code you reference will need to be updated.
Ivar
kl. 19:48:07 UTC+1 tirsdag 4. mars 2014 skrev Rob J Goedman
Or just
versioninfo(true)
Which combines the two functions.
kl. 19:52:47 UTC+1 tirsdag 4. mars 2014 skrev Jacob Quinn følgende:
Yeah, with how much DataFrames has been moving lately, we at least need to
know which version you're running. Can you post the output of
versioninfo()
It was probably some version incompatibility issues then.
It is not easy to know how much info is required to solve a problem.
Sometimes you are lucky and it is a silly mistake that someone recognize
and just tell you how to fix the issue. Other times you are unlucky and
nobody understand what
On Tuesday, March 4, 2014 3:38:15 AM UTC-8, Oliver Lylloff wrote:
Hello all,
Is anyone aware of a linear convolution implementation?
Not clear what you want but if it is to convolve a kernel with a longer
stream you are looking for an implementation of overlap-add or overlap-save
fast
Hi! I've tried using IJulia in sublime text because i love the idea of
that funcitonality... when i try to run it i get this error when i start
sublime text:
Plugin_host.exe
The program can't start because libgcc_s_seh-1.dll is missing from your
computer. Try reinstalling the program to fix
On Tuesday, March 4, 2014 9:39:18 AM UTC-5, Toivo Henningsson wrote:
I think you would want to do the opposite. Define
norm(x::AbstractVector, p=2) = vecnorm(x, p=2)
where you define vecnorm(itr, p) for any iterable type.
I like the idea to define vecnorm for any iterable type. I
On Tuesday, March 4, 2014 12:41:17 PM UTC-5, Ivar Nesje wrote:
Part of the advantage is also possible by just declaring the type of your
container.
*counts=Dict{SubString{ASCIIString},Int}()*
That speeds it up by about 20% on my machine. I get another 25% speedup,
bringing it close to
Does Julia otherwise work when started directly?
On Tue, Mar 4, 2014 at 4:20 PM, Jason Solack jaysol...@gmail.com wrote:
Hi! I've tried using IJulia in sublime text because i love the idea of
that funcitonality... when i try to run it i get this error when i start
sublime text:
Hi all,
I would like to know if there's any ways to distribute an array the way I
want it.
For example,
if I have I have 4 workers and an array, a :
julia a = rand(4,3)
and I want to give each worker a row to work on, how can I distribute the
array?
Julia has distribute function to slice
I would be completely fine with that.
On Tue, Mar 4, 2014 at 5:32 PM, Steven G. Johnson stevenj@gmail.comwrote:
If we have vecnorm(x,p=2), we won't need normfro any more, since
normfro(M)=vecnorm(M)
Hey Jason,
This is a known issue and is supposed to be fixed on master Sublime-IJulia.
I'm not sure if you have the latest or not, but one way ot make sure is to
remove and reinstall the package within sublime (ctrl+shift+p, type remove
package, select IJulia, ctrl+shift+p, type install package,
On Tuesday, March 4, 2014 3:01:13 AM UTC+1, andrew cooke wrote:
i assumed that passing by value was an optimization, but i don't know what
triggers it. it may be that it's only for immutable types without pointers
to mutable types. or it may be based on size. it might be something to
I got to about 0.55 seconds with the above suggestions. Still about 2x
slower than Python unfortunately.
The reason I find it necessary for hashing to work quickly is that I use it
heavily for both NLP and when serving data on a Julia webserver.
Thanks a lot for the suggestions.
On Tuesday,
It's odd that the performance gain that you see is so much less than the
gain on my machine.
Try putting @time in front of for w in words and also in front of
words= That will tell you how much time is being spent in each, and
whether the limitation is really hashing performance.
On
Panning and zooming work with PyPlot.
On Tuesday, March 4, 2014 7:05:07 PM UTC-5, Dan Becker wrote:
I just installed julia (v0.2.1) on windows, followed by winston. Plotting
works, but I see no obvious way to zoom or pan the plot. I also haven't
found anything about this in the
With Gaston, too, if that's any help.
-- mb
On Tue, Mar 4, 2014 at 8:16 PM, Steven G. Johnson stevenj@gmail.comwrote:
Panning and zooming work with PyPlot.
On Tuesday, March 4, 2014 7:05:07 PM UTC-5, Dan Becker wrote:
I just installed julia (v0.2.1) on windows, followed by winston.
thank you, i've opened an issue!
On Tuesday, March 4, 2014 5:52:06 PM UTC-5, Jacob Quinn wrote:
Hey Jason,
This is a known issue and is supposed to be fixed on master
Sublime-IJulia. I'm not sure if you have the latest or not, but one way ot
make sure is to remove and reinstall the
Thanks Ivar, the #4882 exchange you pointed me to gets me quite a bit further!
Even though it shows a deprecated Set() warning, I also had to update Set(...)
constructors to Set{Symbol}({...}) in a number of places.
I am now studying below issue, a good way to better learn/understand Julia ...
I updated the gist with times and code snippets
https://gist.github.com/lqdc/9342237
On Tuesday, March 4, 2014 5:15:29 PM UTC-8, Steven G. Johnson wrote:
It's odd that the performance gain that you see is so much less than the
gain on my machine.
Try putting @time in front of for w in words
See https://github.com/JuliaLang/julia/pull/6057
On Tuesday, March 4, 2014 5:47:11 PM UTC-5, Stefan Karpinski wrote:
I would be completely fine with that.
On Tue, Mar 4, 2014 at 5:32 PM, Steven G. Johnson
steve...@gmail.comjavascript:
wrote:
If we have vecnorm(x,p=2), we won't need
Nice. Mine actually takes 30% more memory now (from how I understand
Steven's comment mostly because we're making a copy of the Symbol) , but
time is ~5% faster. Still about 0.55 though.
Did you run the function several times in the REPL? I am getting these
numbers when running the script from
https://github.com/JuliaLang/julia/issues/6058
53 matches
Mail list logo
